I'm building Conway's game of life in MFC. I built it before using Allegro and want to try it out using MFC. So I start migrating the algorithms and stuff. It renders well using one core and it does the game of life algorithm rather beautiful just like in allegro. Conway's game of life is made up of little rectangle drawn using pDC->rectangle(x1, y1, x2, y2).
My problem is actually two, one of it is that everytime I call the pDC->rectangle(...) it draws it immideately, causing this chain reaction rendering style. I want it to display when it is done doing its job(i know you can do that in directx but I just want to do this using device context of MFC).
The other problem is the title, and probably my main problem. How do you using pDC with concurrency, I tried it and it did some weird stuff. I know I cant use pDC in OnDraw with concurrency because it is the same device context occupying the same memory but used in my 6 core. That's all, thanks in advance.
To avoid drawing immediately, you can draw in abitmap in memory and then blit on the real dc when you finished. Have a look here as a starting point, or at this article on CodeProject. For the multithreading part, you should be able to use the same in memory device Context from multiple threads, just ensure to properly coordinate the creattion of that sharted DC and the blitting/release.
Related
So im currently coding a snake game , and i need to draw the first pixel that indicates the head of the snake (positioned in the middle of the software). But i can't seem to find any function that does drawing on the screen . I've tried using DrawRectang and DrawPixel.
Any help ples?
wxWidgets has capabilities to custom draw a widget/window (or a small invalidated part of one) through it's own drawing API.
This is usually used for customized buttons or other controls, graphs, etc. You can handle EVT_PAINT (wxPaintEvent) where you can create a DC ("Device Context"). As well as on creation or size changes, you can force a redraw with wxWindow::Refresh or wxWindow::RefreshRect (for a small part). You might do so using a timer.
Note that the performance and capability is fairly limited. You can use OpenGL or Direct3D , or various high level libraries with wxWidgets, the native platform window handle is obtainable through wxWindow::GetHandle.
I'm doing a platformer game using gtkmm and cairo, and i can't find a way to set an image as a background, so i don't have to redraw it on every draw event. I'm managing images as pixbufs.
Is it actually possible, or am i thinking it wrong?
Redraw events are always necessary. The difference is about who has to take care of them. Lower level libraries such as Cairo require you to do that.
Maybe you should look into Goocanvas. Particularly for games where you have to move things around easily and capture events, a higher level library than Cairo is handy. GooCanvas also handles screen redraws.
You can just put in the image with GooCanvasImage, and forget about it.
If you're not bound to C++, then have a look at PyGame for Python - it not only handles those events, but provides loads of other tools for game programming.
I'm trying to create a simple D2D game engine (it must be able to display and move images in a window, at least), and everything went right until the moment when I decided to switch to the multithreaded version. I read this MSDN article, and it recommends using one multithreaded factory from several threads. But this article claims it would be more effective to have several single-threaded factories (though the article describes server-side rendering scenario, the principle is the same for my case, am I wrong?). When I tried to use one-thread-one-factory approach, all the images are displayed and moved, but there's terrible flickering. In my WM_PAINT handler I'm trying to do something like this:
for (CSingleThreadEngine *pElSingleThreadEngine : m_SingleThreadEngines) //each CSingleThreadEngine instance has its own D2D factory and an image collection
pElSingleThreadEngine->Draw();
and pElSingleThreadEngine->Draw() does drawing like this:
m_pRenderTarget->BeginDraw();
m_pRenderTarget->SetTransform(D2D1::Matrix3x2F::Identity());
m_pRenderTarget->Clear(D2D1::ColorF(D2D1::ColorF::White));
for (CGameImage *pImage : m_GameImages)
{
if (FAILED(pImage->Draw()))
throw runtime_error("An object cannot be drawn");
}
m_pRenderTarget->EndDraw();
I think the wrong thing here is having several ID2D1HwndRenderTarget instances for just one window because if I make drawing each thread in a separate window, it works just fine. But I want to draw in one window only, and I can't avoid using multiple ID2D1HwndRenderTarget instances for this purpose. So my questions are:
What are the best practices for creating multithreaded Direct2D applications at all?
If the approach I'm using is right, what am I doing wrong and how can I fix it?
Any help would be highly appreciated.
I can't see a reason why you use several HWND render targets for a single window. Have you tried creating off-screen bitmaps for each thread and draw those to a single HWND render target instead?
I already have a Direct3d device at my beck and call...
I am working on a Windows 8 modern UI application (Metro if you will)
What's the general technique of getting text drawn to the screen?
Extra points: Can I do 3d stuff with it too? This is what originally got me here as I started to do some direct2d thing then I thought, but how can I do 3d with direct2d... second of all the d2d create text functions require a handle to a window hwnd and there is no such thing (or it has been abstracted away) in windows 8 metro apps.
Anyone got any good examples or demos I can take a look at?
You should look into DirectWrite.
Regarding your second question you can render your text to a texture and then when you render that texture on screen do 3d stuff with it.
Rendering text with DirectWrite and Direct2D it's relatively simple, however, if you want something higher level, you can look into Drawing Library for Windows Store Apps, which wraps raw DirectX calls into some more GDI like.
I want to create my own tiny windowless GUI system, for that I am using GDI+. I cannot post code here because it got huge(c++) but bellow is the main steps I am following...
Create a bitmap of size equal to the application window.
For all mouse and keyboard events update the custom control states (eg. if mouse is currently held over a particular control e.t.c.)
For WM_PAINT event paint the background to offscreen bitmap and then paint all the updated controls on top of it and finally copy entire offscreen image to the front buffer via Graphics::DrawImage(..) call.
For WM_SIZE/WM_SIZING delete the previous offscreen bitmap and create another one with new window size.
Also there are some checks to prevent repeated drawing of controls i.e. controls are drawn only when it needs repainting in other words when the state of a control is changed only then it is painted e.t.c.
The system is working fine but only with one exception...when window is being resizing something sort of tearing effect appears. Now what I mean by tearing effect I shall try to explain ...
On the sizing edge/border there is a flickering gap as I drag the border.It is as if my DrawImage() function returns immediately and while one swap operation is half done another image drawing starts up.
Now you may think that it is common artifact that happens in many other application for the fact that resizing backbuffer is not always as fast as resizing window are but in other applications I noticed in other applications that although there is a leg between window size and client area size as window grows in size nothing flickers near the edge (its usually just white background that shows up as thin uniform strips along the border).
Also the dynamic controls which move with window resize acts jerky during sizing.
At first it seemed to me that using a constant fullscreen size offscreen surface could minimize the artifact but when I tried it results are not that satisfactory. I also tried to call Sleep() during sizing so that the flipping is done completely before another flip starts but strangely even that won't worked for me!
I have heard that GDI on vista is not hardware accelerated, could that might be the problem?
Also I wonder how frameworks such as Qt renders windowless GUI so smoothly, even if you size a complex Qt GUI window very fast negligibly little artifact appears. As far as I know Qt can use opengl for GUI rendering but that is second option.
If I use directx then real time resizing is even harder, opengl on the other hand seems to be nice for resizing without any problem but I will loose all the 2d drawing capability of GDI+.
If any of you have done anything like this before please guide me. Also if you have any pointer that I should consider for custom user interface design then provide me the links.
Thanks!
I always wished to design interfaces like windows media player 11 but can someone tell me that there is a straight forward solution for a c++ programmer (I want to know how rather than use some existing framework etc.)? Subclassing, owner drawing, custom drawing nothing seems to give you such level of control, I dont know a way to draw semitransparent control with common controls, so I think this question deserves some special attention . Thanks again.
Could it be a WM_ERASEBKGND message that's causing it?
see this question: GDI+ double buffering in C++
Also, if you need fast response from your GUI I would advise against GDI+.