I'd like to ask a question on tile rendering in classic 2D RPGs. Though the theory should apply universally to all resolutions and cell size, I would say talking of 640x480 resolution and 32x32 cell size are most appropriate for this discussion. This means each screen would contain 15 rows by 20 columns of cells (unless it's scrolling, then more could be present, though clipped partially). Just to clarify, this is a "Straight" overhead tile map, like classic Ultima and Final Fantasy games. To cut a long question short, What's the best way to render this for smooth scrolling? If you know exactly what I'm on about at this point, please don't bother reading the rest of this post Say, you have Base array storing base cells (for base layer), and overlapping layer (so called "fringe"). You might have another layer for stationary animation cells or whatever. You might even have more layers for extra overlapping graphics. You also have "sprites" layer which contains sprites like players, birds, NPCs or whatever (anything that moves around). And all those overlapping layer cells are stored in link-list style (with *next pointer) in the Base layer. I think all of you know this popular format. Backbuffer is used to "cook" all those layers and sprites (they have correct perspective and so on) then flipped to Primary buffer. I've tried snippets here and there in the past. The most notable one was to create an off-screen buffer which was 2 cells wider and longer, centered around the focus Player Character (PC) who is standing in the middle of screen. So it was 17 rows by 22 columns of cells rendered in the offscreen buffer. Mind you, this was done for ALL layers separately (don't laugh). I think I had 4 layers then, so I had 4 17row x 22column offscreen buffers! Then I blitted as much as 640x480 from each of these offscreen buffers onto Backbuffer, in the correct order to provide perspective (so if NPC is standing behind a tree, it won't look like NPC is standing ON it). To smooth scroll, I would simply cut out another 640x480 chunks from the offscreen buffers (starting from wherever appropriate, depending on which direction I'm scrolling). When the focus PC moved by 1 cell width (after smoothe scrolling), the offscreen buffers were updated from scratch... so 17rows x 22columns were centered around the new location of the PC As you can imagine, this created a massive overhead. I spend days optimizing it just to make a point to myself that the Method is bad, and not the code... (I hope it was that way around lol). So I don't think I'll ever do that again for real. So... once again, Whats the best way to do this? I've looked around the internet and I found a few varying methods, but I want to know what is a good way for this particular sort of cell map. Should I just render All cells (clip cells as required) directly into backbuffer, from top row to bottom row, then following layers? In case you still don't know what I'm trying to achieve here, I'll name a few console RPG examples of the effect I'm trying to get. Here it is, I hope you know some of them: Final Fantasy 1, 2 and 3 (US version), Lunar series, Phantasy Star series, Tales of Phantasia, Dragon Quest (Dragon Warrior), possibly Seiken Densetsu series (if you know them...), Villgust, ... (list all the 2D RPG games from this era ) (There's another closely related question regarding the relationship between the structure storing the conventional layers and structure storing sprites. But to avoid confusion, I'm going to post this in another thread later today.) Thanks you. Edited by - PugPenguin on May 10, 2001 11:15:37 AM

I''m trying to develope a similar engine. Here is the way I''m trying to do it( this is my first atempt):

my basic map is a set of 2d array of tiles (each array is another layer):

firtstly do all Ai etc.
then calculate where the top-right hand corner of the display is in the current map eg pixel 40, 50
then calculate which tile cell is in the top right i did this by calculating how many times the cell width/hight fits in to the display position eg(in C) 40%32,50%32.
then perform a loop from this cell to this cell + how many cells fit on the screen eg
for(x = currentX; x<= currentX+20; x++)
{ for(y = currentY; y<= currentY+15; x++)
{
//draw tiles bellow sprite layer with
// clipping
}
}

draw sprites
for(x = currentX; x<= currentX+20; x++)
{ for(y = currentY; y<= currentY+15; x++)
{
draw tiles above sprite layer with clipping
}
}
(note code not tested just abasic Idea for you to look at)


that might help (I don''t know) as is said it is still in theory as I have no tiles to test it with as yet.

"Isometric Game Programming with DirectX 7.0" by Ernest Pazera has two whole chapters on optimized rendering. BltFast is about 10% faster than Blt, so if all you''re doing is blitting from a surface to another surface with a color key without any other fancy options such as scaling or rotating, you should switch to BltFast. But, the main rendering optimization lies in the frame buffer. This technique is called triple buffering. Usually, you redraw the frame each time on the back buffer and then flip it with the primary buffer. With triple buffering, you don''t erase the frame buffer each frame. For scrolling, you do a Blt/BltFast from the frame buffer to the back buffer and then update a small portion on the edge of the frame buffer. For other things, such as animations, unit movement, etc., you basically add update rectangles to a list. Then, each frame, you just update all of the tiles that are in an update rectangle. There are a lot of minor details to this method that I don''t have the time to write out, but the basic idea is there. Also, Ernest would probably not like me giving out the information in his book for free when he would rather have you pay $60 for his book.

Dohmnall''s idea is rather similar to one of my experiments... and from what I''ve seen, that gets heavy when there are many layers. Well, without side tricks anyway.

As for "Isometric Game Programming with DirectX", yes I did look it up in bookstore while back. It''s been barely available in the UK. But then US gets them first months before we do, usually. Amazon.co.uk has at last have one in stock (for ages they had a tag up saying it will take months to stock). I''ve been to all major book stores in London. Foyles (supposedly the biggest bookshop around in London) didn''t even have it in their database. Funny that. Anyway, I''m considering of getting that book anyway, at some point. Sounds like a good, solid reference.

Anyway, all I was wondering, though, was rendering methods for overhead field engine... not the whole mechanics of writing a tile based game.

I guess it''s more of trial and error then... Oh joy