I think what might help you the most, assuming you are proficient at C++, would be a book like "Windows Game Programming for Dummies". Not that you are a dummy but this book takes the sting out of reading the MSDN DirectX docs (which is what I did) and will also help you with more than just DirectDraw. I believe by the end of the book you have completed a small game engine.

However, if you need to learn C++ as well, you might want to settle for a slightly (read: much) less advanced project than a game. The scope of a game is quite large by the time you are complete.

But, to answer your question more directly, I think once you actually make a simple game loop, you will realize that it's fast enough without ANY need for optimization.

Also, if I'm completely underestimating your experience feel free to take a jab hehe

thanks for your reply. I do know how to make a game. I've been making 68k assembly games for the ti89 but that became boring. anyways, I know all about optimizing software routines, but directx uses hardware. even when I write 32bit assembly code it's not faster than the hardware. so I'm trying to figure out if I should do everything in system memory onto a sytem memory buffer and then copy that to the back buffer in video mem before I flip the pages if there is some tricks to faster techniques
I'm probably not making any sense because I'm rambling on and on...

Actually, after a second read your response made perfect sense! You definately have to keep in mind that hardware operations are going to be MUCH faster in most cases that CPU operations because of proximity to the actually video memory. However, there are a few considerations you must keep in mind. Basically, video->video blits are the fastest, then comes system->system blits, and last comes system->video blits (leaving out AGP stuff). So basically, if your game wants to display 1,000 different sprites, you have two options:

1) Leave the sprites in system memory, use a backbuffer in system memory, create your frame, then with one mighty blit copy it to the video card's backbuffer and Flip(). This is ideal when you can't/won't place your sprites in video memory.

2) Put your sprites in video memory, use the hardware blitter to blit to the video backbuffer, then Flip()

All of this makes little difference however if you are blitting maybe 30-50 times a frame. Or if you have a P2 350+!

Also, large blitting counts may make you want to simply Lock() the backbuffer and memcpy() or use a custom software blitter to copy the data in. This is because every blit in DirectX requires a Lock()/Unlock() sequence (hidden to the programmer) that locks the memory completely using a Win16 mutex (i believe).

Anyway, have fun with that. I hope I was helpful. This week has kinda been my introduction to programming forums, so my teaching skills may not be up to par yet.

- Splat

thanks, that helps. I was thinking that I could check the amount of video memory the user has and if he doesn't have enough I can set a flag that activates software blitting throughout the game. Also, when I blit large surfaces that are in vram it's a lot faster than blitting smaller areas. I need to draw tiled map data onto the screen. 32x32 pixels per tile. You mentioned locking the surfaces before doing the blits but I don't think that would work in video memory because memcpy would probably pull data from vram into a register on the cpu and then send it back down to vram, wouldn't it?

Sorry to interrupt, but what do you suggest about this?

I have a lot a bitmaps to blit to the screen. All available
video memory is filled up with bitmaps (the ones that are most used),
and the remaining bitmaps are created in system memory.

So I got both kinds.

I don't keep track of what bitmaps are in video and what are in system.
(Hmmm...maybe I should?)

And I have one flippable back buffer and one primary surface.
(I would think that these two are both video memory by default, but I
do nothing to specific it when creating them).

Right now, I blit everything (both video and system bitmaps) to the
flippable back buffer and then flip it, so nothing out of the ordinary.

Would you suggest I create an additional back buffer, however, this
one will be specified as system memory? And try to separate the
blits according to video (bitmap)->video (buffer), and
system (bitmap)->system (buffer)?

I don't know if this would be faster, since I would have to do an
additional blitting of this new system memory back buffer to the
flippable back buffer (video).

Does this makes sense?

One common mistake people make is in thinking that if they're using DirectDraw, every image must be a DirectDraw surface. If you're simply going to Lock/Unlock your sprite's surface to read/write it, why use the surface at all? Surfaces are only useful for primary/buffer surfaces, or if you're planning to use DirectDraw functions like Blt. Otherwise, simply store a string array of the bits of your sprite. This way you'll never have to lock or unlock it.

------------------
~CGameProgrammer( );

Dead on!!

That's how I do alpha blending - since DD doesn't support Alpha channels, all my gfx is stored in a proprietary format, and then copied to the backbuffer (Except for a few things that I use "blit" for)

/Niels

So let me get this straight... I should keep my bitmap data in system memory, not on a surface. and then use my own code to blit them onto other system mem surfaces. then when I'm done rendering my surface, I lock the back buffer and copy my system buffer to the back buffer. Does locking and unlocking take a long time? also, when I try to read bitmaps in they are sometimes twisted and distorted when I try to display them, depending on their dimensions. I need to know why that is also if I must manually read in bitmaps.
thanks,
matt t

Whether you use DirectDraw's blitter or your own depends on your needs. If you need to use alpha blending and other special effects you might store your stuff in your own block of memory and write your own blitter. But if you don't need fancy special effects then youll probably want to save your image in a surface and use DirectDraw's blitter (which is hardware accelerated).

Of course, another idea is to use Direct3D in a 2d game so that you have access to the users 3D hardware and therefore have access to a whole bunch of neat features. Of course this probably isn't the best approach if your just learning directdraw.

--TheGoop

hello, I am planning to make a scrolling platform game for the computer.. but I can't figure out how other games like Jazz Jackrabbit are so fast. If anyone could give me some tips for maximum speed out of direct draw I would really appreciate it.