Archived

This topic is now archived and is closed to further replies.

randomDecay

Level editor using directdraw?

Recommended Posts

I have a level editor working in GDI and frankly it looks like crap since GDI sucks so much. I am double buffering and it still looks like it is tearing and just generally slow to respond. I''m sure this is just GDI''s fault. Would it be a good idea to use ddraw to do the level editor? The only problem is not having custom menu resources like a menu, dialog boxes etc like I had in my GDI program. What''s the best choice? What about windowed ddraw?? Thanks.

Share this post


Link to post
Share on other sites
Certainly, DirectDraw would be faster. If you are writing a 2D game, I would use DirectX 7 to develop the level editor. To get best results, you have to use fullscreen mode. If you want to use windowed mode, you could experience quality deficits as things like back-buffers and so on are only supported in fullscreen mode, I think.

I don''''t need any signature ;-)

Share this post


Link to post
Share on other sites
DirectDraw is the way to go. GDI is often easier to get up and running but in the long run it is not recommended. DirectDraw fullscreen mode is fairly easy to get up and running but for your cases you will need windowed mode. I''m not at my house right not so I can''t remember the exact functions and stuff but here''s an overview of the usage:

0. Initialize DirectDraw
1. Create a primary surface without a back buffer
2. Create an offscreen surface to represent the back buffer. First try to create it in video memory. Then if that is not available create it in system memory.
3. Create a primary surface clipper and set its region to the window handle
4. Get the client rectangle for the window and create x,y values for the blitting location to the screen

When the window moves, you need to update the blitting location. Every frame, instead of flipping surfaces you blit the back buffer to the primary one just as if you were blitting any other surface. And for that surface wait until the primary surface is available before blitting. The blit location is where on the primary surface you blit your back buffer. See the primary surface represents your whole screen but your back buffer represents only your window dimensions so in order to draw the back buffer to the correct location on the screen, you need to know the location of the window which I believe you get from GetClientRect. Anyways, that''s all. And if you want to use GDI with DirectDraw (which is faster than regular GDI by the way), you get the Device Context for the individual surface from ::GetDC and ::ReleaseDC.

---
Brent Gunning | My Site

Share this post


Link to post
Share on other sites
OK I got it up and running and noticed that it draws frames so damn fast (using peek-based message loop). How should I limit my drawing? Tried using sleep() but it didn''t look as good as I want it? Any other suggestions?

Thanks for the advice so far.

Share this post


Link to post
Share on other sites