Printable View
I am in the process of making an RPG and I am just curious as to what the advantages of making a tile based map system instead of just making 1 big bitmap, and setting that as your background/map? Thank You, btw I am using Allegro. If Tile-based is the way to go, anyone have any tips in doing it with allegro? :)
Using a tile-based engine for your terrain allows you to have huge maps, without taking up massive amounts of space for the bitmap.
a tile based design can also provide a foundation for things like collision detection, culling, and game event triggers.
ok I think I am going to try it. For each map would I just make an array of bitmaps, each bitmap a tile? And to display a map would I just use for loops? And one more question: How would I make the map move with the character (so the character is always centered) Is there a simple way to do this, because I am stumped... thank you for replies
Well, you could set up a tile-engine several ways. A simple way would to have an array of bitmaps loaded into memory. Then you load a file that contains a bunch of numbers. These numbers correspond to the position in the array. You use a couple of for loops that will display the map. To make the player centered, you just keep the camera moving whenever the player moves. If the camera reaches the edge of the map, it stops and wait for the player to reach the middle of the screen until it starts moving again. Some psuedocode:
That's right folks; pseudocode so pseudo you cannot even see it. Talk about taking things to a whole new level. Bravo.Quote:
Originally posted by frenchfry164
Well, you could set up a tile-engine several ways. A simple way would to have an array of bitmaps loaded into memory. Then you load a file that contains a bunch of numbers. These numbers correspond to the position in the array. You use a couple of for loops that will display the map. To make the player centered, you just keep the camera moving whenever the player moves. If the camera reaches the edge of the map, it stops and wait for the player to reach the middle of the screen until it starts moving again. Some pseudocode:
There is one huge advantage to a tile map. Lighting can be done on the fly. Let's say that you use Direct3D to render the tiles. Remember that iso tiles are simply 2 triangles which boils down to rendering your map as triangle strips - very fast. By changing the colors at the vertexes, D3D will blend the color coefficients with your texels thus creating some very nice lighting effects.
As well you can use Direct3D to render the sprites since a sprite is simply a quad or 2 triangles as well. By changing the colors at the vertexes of your quads you can even cause some of the environment lighting to affect your sprites - and at little to no additional cost.
It is very hard to alter a very large bitmap on the fly. You must first isolate the area, create a surface for it, perform the desired adjustment on it, and blend that surface into the bitmap in an instant. Imagine trying to add lighting to a section of a bitmap in real time and then seamlessly blend that into the larger bitmap. Yes, you could do it with lightmaps, alpha blending, and multi-texturing but there is an easier way.
Notice that with the above approach you can also change the location of the vertexes in your map thus allowing you to alter the landscape w/o drawing any more tiles in an editor. Your tiles are simply textured quads (2 triangles).
For more information on this approach go to www.gamedev.net and look at their tile engine section. It is titled Using Direct3D to render your 2D tiles. Sorry I don't have the exact link.
The way that I did this with the rpg I'm working on is to have the player have standard coords (x,y) and also have a set of screen coords (screenx,screeny). This is done in two easy steps. First you determine screenx and screeny using the players coords and the width/height of the map (assuming that the player's coords are the upper left corner of the bmp):Quote:
How would I make the map move with the character (so the character is always centered)
You repeat this for y with *.height and SCREEN_H, then you use these values when you're rendering:Code:if (player.x < SCREEN_W/2 - player.width/2)
screenx = 0;
else if (player.x > map.width - SCREEN_W/2 - player.width/2)
screenx = map.width - SCREEN_W;
else
screenx = player.x + player.width/2 - SCREEN_W/2;
I'm not on my computer so I'm not sure if that's the way draw_sprite() works, but you get the idea, right? Subtract screenx and screeny from coords when rendering? I'm not sure if this is what you were looking for, but I hope it helps.Code:for (i = 0; i < map.tilew; ++i)
for (j = 0; j < map.tileh; ++j)
draw_sprite(buffer,tiles[map[i][j]],i*tilew-screenx,j*tileh-screenh);
draw_sprite(buffer,player.bmp,player.x-screenx,player.y-screeny);
ichijoji, is your game open source? I would like to look at how you did that part in the actual game, may help me understand better heh.
I was wondering if what people would say about that :DQuote:
That's right folks; pseudocode so pseudo you cannot even see it. Talk about taking things to a whole new level. Bravo.
Whoa, whoa, whoa, let's not get ahead of ourselves. This guy is working on his first tile engine.Quote:
There is one huge advantage to a tile map. Lighting can be done on the fly.
Kinda partial to DX, eh? He said in his post that he is using ALLEGRO.Quote:
For more information on this approach go to www.gamedev.net and look at their tile engine section. It is titled Using Direct3D to render your 2D tiles. Sorry I don't have the exact link.
Ooops.
Sorry, guess I got ahead of myself there.
:D
Sorry this took so long, (this (not my) computer hates me). Here's a zip with all the stuff. The parts that you're asking about here are in player.cpp in player_t::move() and player_t::render(). Feel free to ask about anything in there that doesn't make any sense.Quote:
ichijoji, is your game open source? I would like to look at how you did that part in the actual game, may help me understand better heh.
I also included the actual game (which requires alleg40.dll to run), it's just the engine and a demo level right now, and not everything in there works just yet (using magic or items makes it crash, YARG!!!), but it's coming along nicely and any day now I'm gonna fix it up into a game.
awsome! thanks ichi!!
ichi, nice work on the game, but for some reason when I try to either 'continue' or start a 'new game' the program crashes. So I'm not actually able to play the game, which is too bad too.
Also, instead of making graphics for when dave is facing left or right, all you do is make the graphics for when dave is facing one direction. Then in your code you flip the character by using draw_sprite_h_flip when you need the character to face the opposite direction. For example, have dave face right in all the graphics then use draw_sprite_h_flip when dave needs to face left. This is much more efficient, imo.
:)
PS I could make you a lot better tile graphics in only a few minutes, even though, I'm sure those are only placements graphics for the time being. If you're interested send me a PM about it. Below is an example of some ocean water I made. **There is slight color displacement in the picture b/c I put in jpg format**
Man, that is some killer ocean water. You gotta show me how to do that someday. Don't say you used Paint to do that, it must of been something like Photoshop.
:eek:
ff, I'll show you how to do more than that:eek:
All you have to do is gently...lol...jk
Ok, I do use photoshop, and all I use is a couple filters here and there. I, also, try to seperate parts of the image to emboss parts of the picture bc thats how you do it in PS...here is an example of a beach. Tell me what you think of this one. I can make tiles pretty good, imo, and I'm willing to give out basically any tile to anyone who wants them...just ask (ewwww I'm a tile slut...I feel used:o)
Sry for posting so many pictures, but here is a tile of some lush looking grass. I'd have to say that the jpg versions are really making these pics look non-good as opposed to them looking better in bmp format. Ok, have a look see.
Quote:
Also, instead of making graphics for when dave is facing left or right, all you do is make the graphics for when dave is facing one direction. Then in your code you flip the character by using draw_sprite_h_flip when you need the character to face the opposite direction. For example, have dave face right in all the graphics then use draw_sprite_h_flip when dave needs to face left. This is much more efficient, imo.
I disagree. Since memory is no longer a major constraint in computers, having a paint program flip the image for you and include the new image with your master image(s) bank is better. It is much faster to blit an image as is than to flip it "on the fly"
Also there are some inherent problems in the tiles. The ocean tile is not symmetrical meaning that if you tile it you will most certainly see where each tile begins and ends. I've not checked the other tiles.
Bubba, I only say to flip it instead of a regular blit is because many times it's better to have a smaller file size for your program. Having a larger file size may detract people from downloading your program, and using a flip isn't much of a fps loss, either. Then again with Allegro you can use the Grabber, so file size typically isn't much of a concern when it comes to the graphics. I think you may be right on this one, but I guess it may just come down to a matter of taste.:)
I had Allegro and I have no idea what the grabber does, could someone explain (if they're bored because it doesn't really matter any more), also a lot of people have high band width now so download sizes aren't as much of a problem. Last but not least, how can you like change several bitmaps into a single file with the extension of your choice. I've seen a lot of comercial games do this and I always wondered how they did it. Just wondering. Thanks.
With the grabber it reads in a file (i.e. bmp) of your choice and however many files you wish to read in. Then after you are done with that you save it all, and Grabber compresses all of the data of the files into one single dat file. It enables you to not have to have so many large files instead you have one small size file. You can read the info that comes along with it if you need to know more.
My guess on changing the file extensions on file is to create a program that can save it as that file extension. For example, create a program that can read-in a bmp file. Then take all the data of that bmp and save it to another file with a different extension such as pmb. It's not a very complicated process from my understanding.
So you can actually use a grabber file to compress them into a dat, but how do you open them. Like normal, or do you need anoth specialized program for that?
You create your own file structure and write a 'grabber' to extract info from it.
For a tile engine you will have several (perhaps hundreds)bitmaps of tiles. It would not be smart to store these individually so you could do something like.
struct TileHeader
{
unsigned int TileID;
unsigned char *ImageData;
unsigned int size;
TileHeader *Next;
TileHeader *Prev;
};
struct TileMap
{
TileHeader *TileHeaders;
int numtiles;
...
};
Write the TileMap struct to disk which indicates how many tiles are in the map and tracks each of them.
Then each Tile is written to disk complete with its imagedata. Then when you have reached Tile.size - repeat the process - write the next TileHeader to disk and so on.
There are better structures but its just an idea to get you started.
Thanks, it'll take me a while to figure that out completely, but I think I have the general idea. Now instead of having 100's of bitmaps, I'll end up with 20 .dat files.
Yes, but again I don't recommend the above structure. Map files really just need to be arrays of numbers which represent which tiles go where. The master image file should have all of the bitmaps for the entire game in one file. The file should be marked as read only - even though this is easy to thwart. Each number in the map would correspond to a certain TileID which would indicate which bitmap goes where. Then at run-time you could re-compile this data into several maps in memory. This is as simple as inserting new bitmaps into the master list or TileMap structure. This can all be done during the load phase. The reason you want to load maps like this is because constantly looking up array indices to find which tile needs to be drawn is slower than simply iterating through a linked list of tiles. The ideal drawing scheme would be to link the tiles from back to front to aid in drawing.
There are hundreds of other methods and hundreds more you could come up with.
Cool, thanks. This isn't really that useful to me now, as I am still learning and have not started my project, but when I get there I'll at least know where to start.