Ok, I have considered posting about this for a while but due to my general slackness I put it off. First the questions (before you get bored) Has anyone heard of this being implimented before (I havn''t seen any articles on it)? Any Ideas how I could improve this (other than assembly)? I am currently in the proces of making a tile engine. The engine uses layers of tiles (32*32), to enable the world to be built. Since there are about 4 base layers (not including game items) I realised that each 32*32 portion of the screen was being drawn to multiple times. Some pixels being overwritten 3 times for just one frame. While trying to think up ways to make it go faster (increase frame rates) I figured that since the terrain (ie grass water roads etc) only scrolls about one pixel in any given direction a lot of the terrain is being drawn exactly the same for every frame even when it doesn''t change. So late one night the Terrain Buffer idea hit me. ie storing the currently visable terrain it''s own surface, as well as an extra row and column as a buffer. When the buffer is exhausted a new row/column of tiles is drawn to the buffer. The buffer is circular in both the x and y directions (trying to imagine this is very difficult) so when the top of the bufferrs surface is reached the next row is blitted at the bottom of the buffer (same in the x direction). Then to display graphics all you do is blit to the the back buffer. This reduced the number of blits for me from around 1000 per frame to; in the best case 1, and in the worst case 124, although it did require some extra calculation as well (i''ll optimise it soon) it generally doubled my frame rate. Obviously the buffer needs to be initalised at the start. A problem with this is when you have areas of terrain that scroll at differrent speeds to other areas. If this happens too often then the TB will make little difference. One last cool thing I discovered is that I can draw literally hundreds of bitmaps (craters and laser marks in my game) to the buffer and notice hardly any slow down at all since they need only be drawn once (once they leave the buffer though they are lost - unimportant for my game). Ok. Thats a rap... Sorry if I bored you. I just had to tell someone who cares (the rest of my family go - "so what it looks the same" - urggg). So lemme know if (you got any good ideas on improving this || any comments || if you don''t know what i''m talking about etc). Sephwrath

Thats a great idea for what you are doing. I can think of a few places where it would not work, but for what you are doing it seems OK.

---

ANDREW RUSSELL STUDIOS

Very similar technique that side scrollers used. I first saw
this in Jazz Jack Rabbit. Rather than blit the whole tile set
again you fill in the gaps.

This is what I love about optimisation. The time spent
in analysing what is happening and then attacking that area
makes computer game programming so rewarding.

Like Abrash says game programming is one of the few areas
where optimisation matters.

Well done for looking at the problem from a different angle

I can only confirm that. I used a similar setup once, and it did speed up the game.

quote:

---

Like Abrash says game programming is one of the few areas
where optimisation matters.

---

I can''t agree with that at all. Opimisation matters in all aread of programming. It''s just that, for some reasons, say M$ Office users don''t complain when their software uses up 40% more processing time than necessary.
If everybody optimised their code properly we''d live in a better (software) world. And all those hardware manufacturers would have to declare bankruptcy. Oh well...

cu,
Prefect

Yes after reading that I know you mean. I suppose the context he spoke about was
that optimisation in games is an absolute requirement. It is ok to say "Please wait
saving document" but saying "please wait moving character" is a different matter
because that would kill the game stone dead.

I agree optimisation should be in all walks of software.

Yes I do the very same thing. At first I thought this was only possible back in the good old DOS days where you could wrap around the video memory buffer. Not so you can achieve the same thing in DX as well.

If you think about it some more you can eliminate the need for the extra row/column in your buffer. If you do this then when the user moves one pixel in a direction, say to the left, all you have to update is one vertical row of pixels. This may help to speed things up on average. Especially if you limit the movement per frame to 8 pixels or less.

The other performace improvement is to copy only the changes to the back buffer. I am assumming that this terrain buffer is in system memory. If so take these steps:

1. Copy the still valid portion of the front buffer to the back buffer. If the player moved one pixel to the left then you would copy the front buffer rect [0,0,639,480] (x,y,w,h) to the back buffer rect [1,0,640,480].

2. Update your one pixel wide column in the terrain buffer.

3. Blt just the one pixel wide column to the back buffer.

4. Flip to the front buffer!

Now, none of the above deals with all the sprites that change position (static sprites like trees, buildings, or dynamic sprites that did not changes position this frame are OK). The main player, bullets, oponents, etc. all need to be kept in a dirty rect list. Each rectangle in the list has to be refreashed on the terrain buffer and that rectangle needs to be bltted to the back buffer (as well as the rectangles that encompass the new position of your dynamic sprites).

There is a ton of room for optimization in the dirty rect scheme.

Good luck,
hebertjo

In reply to the original poster:

That''s a pretty common algorithm from the old side scrolling games AFAIK.
Dunno if I''m pointing out the obvious here, but:
- doesn''t easily work with animated tiles
- your are on an iso forum here so: in the isometric projection you won''t be able to get the drawing order correct if you don''t use something like a z-buffer (unless I understood you wrong and you only draw the actual ground tiles the way you described - in which case I don''t think your method will give you such a huge advantage anyways)
- you can''t archieve smooth scrolling by scrolling one pixel each frame because you can''t guarantee a constant framerate on todays machines and operating systems. Besides being jumpy, scrolling will be very different from machine to machine (i.e. 60 Hz = 60 pixels/sec on one and 120 Hz = 120 pixels/sec on another). You can adapt your algorithm to account for different frame times and scroll rates, but it becomes more difficult and slower so it might not be worth using any longer.
- surface sizes may be an issue with some hardware. I heard it mentioned that some cards aren''t happy with surfaces larger than the primary, very possible that this is outdated info though

BuschnicK

Thanks for the comments guys. I''m gonna try that copying front to back buffer thing tomorrow (it''s late).

I figured someone else would have thought of this before, after all it seems prety obvious, given my game is a scrolling shooter.

Anyhow thanks again for the comments.