   Tile Map Format Idea
  I have come up with an idea for a tile map format.Usualy, the map file has info about all the tiles, there place and the image but what if i were to create a tile map in the usual way using some sort of editor i make and then save it into the usual format, but dont include tile data in them.Insted of telling the engine were to put the tiles, could i just tell the engine to load an image of all the tiles combined to make the map. Then the engine could just draw that.Ofcource, the whole point of tile maps is that they are easy to create and fast to change(i think). So there could be 2 formats, 1 for editing, and when you are happy with the map, convert it into the special version which tells the engine were the map image is.Insted of the engine drawing lot's of individual tiles, it draws 1 image, clipped to fit the screen.is that a good idea?   
Quote:Original post by Lithis that a good idea?It is a possibility, but not necessarily a good one. Here are a few issues to think about:* Tile-based games often use tiles for collision/pathability data - you would need that to be encoded separately.* If you aren't going to use tiles in the finished game, why constrain your artist to using tiles? A decent artist will be able to produce a much nicer result by hand-painting the level as a whole.* What about odd shaped levels (i.e. not rectangular)? These are pretty simple to make with tiles, but as a single image you would have lots of wasted space.* The graphics hardware can't handle arbitrarily large textures, so you will have to chop it into sections at some point. Whether it is easier to compose tiles into sections, or split a larger image into sections, is not clear.   ;  Ok, so the map file would be larger if i were to use my method.the collisions will be handled separatly from the tiles. Also, i dont have any artists, im just a programmer, this is going to be an RPG engine using SDL. Im only making this for fun and to learn. It's going to be my 4th game i have made in c++.@swiftcoderYou said that the graphics hardware cant handle large textures, so i will have to split them up. So is it quicker to render 1 big image, or lots of small ones?Also where did the other reply go?   ;  Tilemaps are easy to use, yes, but they're also pretty efficient in terms of total filesize and memory consumption - those have been, and for some people still are, pretty important reasons. Baking all tiles into a massive image gives you a lot of repetition in that image - a waste of memory, really. Given that rendering a bunch of tiles shouldn't be a bottleneck on modern hardware (assuming you're using hardware acceleration of course), I don't see any benefits to this approach. Something that may be beneficial is storing all tiles in a single spritesheet, to make your tilemaps easier to render in a batch.Either way, 'quicker' isn't all that important if both approaches are quick enough already. Another thing to think about is the ability to dynamically modify tilemaps. You can't do that with a single large image (unless you also keep track of the original tiles, but that would still be harder).   ;  The tile maps I've used are saved as nothing more than a 2D array of tile IDs with other basic info like player position, image file names and the like. I've never stored a tile map with the positions of the tiles. The tile positions are directly related to their position in the array. A tile map should be minimalist by its very nature.Not sure I understand what you're getting at. [oh]   ;  Its not a worthwhile idea, particularly if you're just going to use it to replicate the 'tile' experience.Lets assume you've got an old GPU with maximum texture size of 20x8x2048 (That's anything as recent or more than an nVidia TNT card, IIRC -- by the way, for you youngins That's the model name that came *before* Geforce, which came *before* FX, which came *before* the return to Geforce, which came *before* the current Fermi/Tesla).At a modest screen resoultion of 1024x768, you get about 5 & 2/3rds screens worth of map on that single texture, and many of the 'tiles' are duplicated.Now lets assume tiles are 64x64 pixels in size. On that same 2048-square texture, you could fit 1024 tiles -- 4 times that if tiles are 32 pixels square. Since each tile is unique in this texture, it stretches much further than a mere 5 & 2/3rds screens. I'd wager, without any sort of real measurement to back it up, that some of the SNES greats like Final Fantasy II or III didn't have much more than two or three times that number of tiles for the entire game!In short, you're looking at creating and binding a new, rather large texture every couple screens in either direction, or binding one which will likely cover the entire active area of the game (10s of screens in either direction) with any reasonable tileset.Also, If you've burnt up one whole texture for just a single ground layer, you're going to need additional textures for sprites, objects and other additional layers (overhead, effects) so you're binding all those textures. Having a tile-atlas type texture allows you to be more flexible and save memory.;Quote:Original post by maspeirI've never stored a tile map with the positions of the tiles. The tile positions are directly related to their position in the array. A tile map should be minimalist by its very nature.Although that wasn't what the OP meant, I'd like to mention that storing tile positions is not necessarily a bad idea. It's not really a tilemap anymore, but being able to freely place sprites anywhere does give level-designers more flexibility, allowing them to get away from the 'blocky' feeling of tilemaps.   ;  Create tile index image (map) and tile library image (tileset).Then just scale indexmap with "nearest" filter, and do all magic of placingtiles to right spots inside of pixel/fragment shader./Tyrian;Quote:Original post by Captain PQuote:Original post by maspeirI've never stored a tile map with the positions of the tiles. The tile positions are directly related to their position in the array. A tile map should be minimalist by its very nature.Although that wasn't what the OP meant, I'd like to mention that storing tile positions is not necessarily a bad idea. It's not really a tilemap anymore, but being able to freely place sprites anywhere does give level-designers more flexibility, allowing them to get away from the 'blocky' feeling of tilemaps.Doing this will mean you can't use a 2D array to hold the blocks, which in turn makes collision detection with terrain, and choosing which terrain to draw, significantly more complicated. It's not impossible by any means, but it adds complexity, so you have to decide if the improved capabilities added complexity.   