10 replies to this topic

[Splat]

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

[Splat]

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

[CGameProgrammer]

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( );

[Niels]

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

[Facehat]

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

[mhkrause]

The only real reason to store a sprite in a video memory surface is to take advantage of hardware-accelerated VidMem-VidMem blts.

Reading from video memory is a very bad idea, it is incredibly slow.

Writing to video memory is a bad idea also, it is incredibly slow (though not as slow as reading.)

If you want to write, read, and modify a sprite, and at the same time use blt, then you should use a system memory surface.

If you don't want to use blt, and just read or modify, then you should just use your own system memory buffer to avoid the lock()/Unlock() penatlies. If your hardware accelerates sysmem-vidmem blts (doubtful) you may want to then lock and copy into a system memory surface, then blt, otherwise lock the back buffer and copy your data in.