If you tried to make surface that big, you could run into problems... (since older versions of directx do not support surface widths greater than the screen width...)

I would do this...
Put all tiles on a single surface.
Put that surface into video ram.

The truth is the directdraw surface ->Blt() method is very fast, especially with hardware accel. What video card are you using, and with what DirectX version?

Absolutely. I''ll tell ya how I did it on mine. I''ve heard alot of different ways that tile-blitting can be done, but this seems to be the best:

Put your backbuffer in system memory. The reason I did this is because I had so many tiles needing to be blitted that only people with a big video card could even handle it. The other reason was because of special fx. It''s way faster to do transparency and things like that if it''s done through the system memory anyway.
Back to what I was saying.
Your backbuffer will be in system memory. Blit your tiles to the backbuffer, and then BLITFAST the whole thing to your primary buffer. This seems to work quite well, and even leaves the room in video memory for things like your heads-up display and stuff like that.
Again, this is only one way to do it, but it worked well in my case.
Good luck!
- Fuge

quote:Original post by Inquisitor
Fuge: What you are suggesting is pretty much what I''m already doing, except that I''m flipping my back buffer rather than BlitFast.

It sounds like your back buffer is in video memory though. For fuge''s method, your back buffer should actually be an offscreen surface forced to be in sysram. It shouldn''t be part of the flipping chain. You then BltFast the offscreen surface to your primary surface rather than flipping. [or if you want to keep your HUD in video ram, call your offscreen surface the workarea - where you create the main game window... blt that to your offscreen buffer, video to video blt your HUD stuff, and then flip]

Sysram->Vidram is slow... you want to minimize the amount of data Blted in this way. If you are Blting all the tiles/sprites each frame, the fact that they overlap means you are Blting more this way than if you compose the whole scene and Sysram and then Blt the whole scene at once.

There are basically the two methods:

Mr. Anonymous''s method is the fastest, but requires hardware acceleration and gobs of vidram to work. As your project grows, you will eventually run out of vidram. When you do, you will either get an error if you force your surface to vidram and it doesn''t fit... or the surface will be put in sysram and do sysram->vidram blts (which if you recall, are slow). Also, special fx like alpha blending are only supported in hardware via D3D... so you have to live without those, or use D3D and textured quads... and require a 3d card.

The other method (Inquisitor) is more commonly used in 2d games. With this method you compose everything in sysram (sysram to sysram is also quite fast). Then BltFast to vidram (the whole scene, or if there were no scrolling you could use dirty rectangles to speed it up). This gives you all of sysram to work with, so you don''t have to limit the number of tiles, sprites, etc.

If you go this route, you can also do your own ASM routines for alpha blending, etc. You will also find later on, that replacing BltFast with your own sysram to sysram routines for composing your scene will improve performance of this method.

- n8



nathany.com

This means that having a 32Mb video card is useless since we''re only using about 1Mb for the primary surface?

Am I right, or if not, what is the use of all that VRAM if we use SYSRAM instead??

dragon: that''s right. and it will also work on a card with only 4mb.

ideally you would support both methods (using sysram to compose the whole scene -or- using vidram if there is enough ram and the hardware supports whatever you want to do)

ziggy: if you do alpha blending, you never want to read from vidram. so you need to compose the whole scene in sysram if using a software routine to do alpha. or you have to use d3d to do alpha in vidram if supported. it doesn''t really make sense to -require- a 3d card for a 2d game though (even if pre-TcL 3d cards are only doing 2d type stuff anyway)

anyway, if you don''t care about alpha or similar fx you could do as you are saying... except you would have to sysram->vram your sprites if you actually want them to appear over your tiles .

if you do care about alpha, another alternative is to require a 3d card for it, but still have a working game without a 3d card, just with less fx. this could be a very good alternative, and i''m kind of hoping that dx8 makes it simpler to do this for a 2d game ...

sign up for the dx8 beta if you haven''t already … and if they don''t support alpha blending in someway via Blt, lets all harass them <img src="smile.gif" width=15 height=15 align=middle><br><br>- n8<br> <br><br><IMG SRC="http://nathany.com/images/arrow.gif" border=0 width=8 height=12 align=baseline> <A HREF="http://nathany.com" style="color: #cc9933; text-decoration: none; font-weight: bold;"><font color="#cccc99">n</font>athany.com</A>