Jump to content
Posted 18 October 1999 - 05:58 AM
Posted 11 October 1999 - 01:09 PM
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
Posted 14 October 1999 - 06:05 PM
Posted 15 October 1999 - 12:55 PM
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.
Posted 15 October 1999 - 06:52 PM
Posted 15 October 1999 - 07:59 PM
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?
Posted 15 October 1999 - 08:16 PM
Posted 16 October 1999 - 04:31 AM
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)
Posted 16 October 1999 - 06:25 PM
Posted 17 October 1999 - 06:03 AM
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.
Posted 18 October 1999 - 05:58 AM
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.