Jump to content
  • Advertisement

Archived

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

Inquisitor

Tile based blitting

This topic is 6916 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Could someone please educate me on how to handle tile based blitting? I have an isometric diamond shaped tiling engine. Currently I am using DirectDraw''s Blit function to blit every tile for every frame and naturally my frame rate sucks. Would I be better off building my entire map to a separate surface and then just blitting one screen-sized chunk of the map from that surface to the back buffer? Thanks for the help. `~Inquis~`

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
I don''t know the specs on my video card, but I''m using DirectX 6.2.

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

`~Inquis~`

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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??

Share this post


Link to post
Share on other sites
I think what nathany is trying to say is:

use sysram-sysram for all "regular" blits
use vram-vram for heads-up/overlay style surfaces

so a game could still use quite a bit of vram. (depending on size and types of overlays...)

hmm, maybe you could do something like this for a tile-based game:

put all tiles in vram, then vram-vram them as needed...
all units/sprited in sysram, then sysram-sysram them to the offscreen plain backbuffer (as mentioned above).
put all overlays in vram, then vram-vram them as needed...


This should be fast, and a good medium between all vram and all sysram, just another thought from Mr. Anonymous above...

Share this post


Link to post
Share on other sites
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 [i think you still can]... and if they don''t support alpha blending in someway via Blt, lets all harass them

- n8


nathany.com

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!