Microsoft GDI documentation!

[OceanJeff32]

This stuff is confusing!  I've seen numerous examples of how people have succeeded in performing various graphics displays, games (freecell and other games that ship with windows are perfect example of gdi games aren't they?), fireworks, etc.

But they must have some other documentation besides the MSDN documentation.

According to the documentation on bitmaps, device contexts, selectobject(), and the WM_PAINT message (please correct me if I'm wrong...or better yet, upload source code to correct by example!):

Steps in creating an animated display (with WMPAINT message):

1) Store Handle to Window
2) Using 1 call GetDC(), store this (Window Device Context)
3) Using 2 call CreateCompatibleDC() to create Back Buffer (Memory Device Context)
4) Using 3 or 2, call CreateCompatibleBitmap() to create a Bitmap for using as drawing bitmap for back buffer.
5) Using 3 and 4, call SelectObject() to select the Bitmap into the Back Buffer (Memory Device Context).

Then you make various GDI calls, specifying the Memory Device Context (which draws to the selected bitmap).  When done, call InvalidateRect(), to trigger the WMPAINT message.

Then in the WM_PAINT message code block, inside the Window Procedure:

Call BeginPaint (retrieves DC for window to draw on screen)
Call BitBlt to transfer Memory Device Context to Window Device Context
Call EndPaint (deletes DC for window)

This is what I am going to try to do this week.

Comments anyone? Please??  :lol

Later,

Jeff C
:eek

P.S. The main reason why I want confirmation on this game engine framework...is because the VAZBREAK

http://www.bringyou.to/games

, breakout game on his website has the source code for a breakout using GDI, but it's not as cool, and graphically awesome as I plan to do! AND the fireworks code from

http://www.ronybc.8k.com

by Rony B Chandran, does NOT follow the above steps, but rather, just calls SETDIBITSTODEVICE(), and that's pretty much it...none of this back buffer stuff...and it looks spectacular.

Certainly there must be a middle ground, so you can have a decent graphical breakout, with some spectacular particle system in Windows GDI??

[Farabi]

Hai. I use CreateDIBitmap if I dont made mistake. That function give us a pointer to the screen memory.

[hitchhikr]

Banish GDI if you want to do graphical stuff like games, screensavers or whatever,
my definitive statement :toothy

[Farabi]

Banish GDI if you want to do graphical stuff like games, screensavers or whatever,
my definitive statement :toothy

Yes it is if you have a 2 ghz machine. BTW, you are the expert of 3D graphics. :wink

[JFG]

Actually, the DC you are creating with the CreateCompatibleDC function is not a backbuffer.  It is just a buffer you are creating to store a bitmap that you will then copy onto your window DC.  A back buffer is really pretty much a second window DC, and the difference is that you can make Windows swap that DC for whichever it was already using, rather than copying the image data.  It is important to note this difference because swapping buffers and copying data from one buffer to another are two completely different things, and confusing those two can cause problems being that you don't handle those two things the same way.

Now, if you want to do game stuff, I suggest you skip out on the compatible DC for use as a replacement for a back buffer, and just blit your graphics directly onto the screen from whatever source you're using.  Copying data to video memory is very costly on time; data moves very slowly through the graphics card data bus, and in all that time the CPU sits there doing nothing - at least if all you're doing is copying image data.  Merely moving data between different parts of the RAM, which you would do if you're not actually blitting to the window DC, is not quite as costly, but is also pretty slow, and in all that time too the CPU does nothing.  You want to avoid that waste.

Something else you can do is cut out the overhead created by working through the messaging system in Windows.  You can use the GetDC() and ReleaseDC() functions and draw whatever you want between them whenever, meaning that you can call your window update function directly, instead of telling Windows to post a WM_PAINT message and then making your program wait for Windows to get around to dispatching it that message.  You can still call your window update function from your WM_PAINT message handler of course, but you can also call it from your main loop for processing during idle time.  (That's the point at which this processing is normally done anyway.)  This too can save time for your game loop.