#### Archived

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

# A great temporary map loader

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

## Recommended Posts

One great thing about TANSTAAFL's ISO book was the fact that it gave me some ideas that were off of the beaten path from what he talked about. I developed a great font engine from his templating system, and now thought of a way to load a map using a similar system. The problem with creating maps to test an engine is that it tends to be very time (and stress) intensive. You either have to write your own tool, or write godawful text files (neither of which is fun while you're developing your engine). However, I thought to use bitmaps to load my maps. You would have 2 bitmap files -- your tileset file (which you need anyway), and your map file. In the "map" file, you would draw your map using a number of colors that matches the number of tiles in your tileset. You would load the bitmap, and build your map from this bitmap file. So, say that I have a tileset which has 3 tiles -- grass, water, and dirt. In my map file, I draw the map using 3 colors (for sake of sanity, green, blue, and brown). For a simple 10x10 map, I could draw the following (g - green, b - blue, r - brown):
gggggggrrr
ggggrrrrrr
gggrrrbbbb
gggrrrbbbb
gggrrbbbbb
ggggrrrbbb
gggggrrrbb
ggggggrrrb
ggggggggrr
gggggggggg

(To draw these things, use any graphics program -- I use PSP -- just make sure to turn off anti-aliasing for whatever tool you're using so that the colors are pure. Keep in mind that you will and should see jaggies in your bitmap file). Anyway, to load make the map from this, all you would need to do is load the bitmap, and scan each pixel to see which tile it represents. The problem with this system is that it would require you to program the pixel colors. So, this is where TANSTAAFL's stuff comes in. You need to add one more column to the bitmap to hold the "tileset" information. Basically, this last column contains the color->tile mappings. This allows it to remain dynamic so that you don't have to recompile every time you use a new map color or add a new tile to your tileset. The last column contains the following: - The first pixel is a "NULL" color. This is a color not located in your map. This is used to tell your "reading" routine the number of colors in the map. - The next pixels in this column are the color mappings. The colors here match the colors in the map. They should be placed in the order in which the tile they represent are in the tile set (did that make any sense? hopefully) - The remainer of the column is filled with the NULL color. So, say that my tileset is arranged in the following order: grass - water - dirt Here is the map image with template using this ordering ("w" represents "white", the NULL color in this case):
gggggggrrrw
ggggrrrrrrg
gggrrrbbbbb
gggrrrbbbbr
gggrrbbbbbw
ggggrrrbbbw
gggggrrrbbw
ggggggrrrbw
ggggggggrrw
ggggggggggw

Now, if I add a "rock" tile to the tileset (as the fourth tile), and represent it with grey ("y") in the map, the map simply needs to be edited as follows (the bottom-left corner now has a rocky area, and the template column now has grey representing the fourth tile in the set):
gggggggrrrw
ggggrrrrrrg
gggrrrbbbbb
gggrrrbbbbr
gggrrbbbbby
ggggrrrbbbw
gggggrrrbbw
ggggggrrrbw
gyygggggrrw
yyygggggggw

To utilize this, you simply need to do the following: - Open the bitmap file - Scan the top-right pixel to determine the "NULL" color - Scan the right column for the next NULL pixel to determine how many tiles there are - Allocate enough memory for the color entries for these pixels, and then scan the pixels into this array. - Allocate your map-size based on the width of the bitmap (minus 1 for the template column) and the height of the bitmap. - Scan in each pixel, and assign the tile to your tilemap based on the color in the bitmap (I just loop through each of the "tile colors" until the pixel color matches one of them). - Deallocate color map memory All in all, this system works great for a temporary map loader, except for a few shortcomings: 1) No multi-layer support unless you have a separate bitmap for each layer (or do some other weirdness -- I can think of a hundred ways to do it -- none of them pretty) 2) There's only so much information that can be included in a bitmap file... stuff like blockage would need to be handled separately (or you could just expand your template to support this), or through a separate bitmap. 3) People could screw up your maps if you even think about using this as your final system. That's why I keep calling this a "temporary" system. 4) The number of tile types you can have is constrained by the height of the bitmap. The good news about this system is that it gives you a good "overview" of your map without having to develop a tool (it's nice to be able to look at a bitmap and immediately see what's where). It's also easy to use and expand -- if you can load a bitmap, you're already 3/4 of the way there. You can also easily write a converter to convert from the bitmap to your final storage system. Hope this all makes sense. -Chris Edited by - crouilla on February 7, 2002 5:56:20 PM Edited by - crouilla on February 7, 2002 8:31:59 PM

##### Share on other sites
Hi

Not the best way, but easy:

My engine writes the rought binary data from the arrays to a file, ~ 8MB. After that I compress it with zlib.dll, ~0.5 - 1MB

The steps:

save Data > tempfile > zlib compress > |Savegame|
|Savegame| > zlib decompress > tempfile > read Data

cu

##### Share on other sites
No doubt this is something like what I''ll implement in the long run (I already have some file format stuff I''m working on -- although I admit I never thought about using the zip library to compress it), but the nice thing about using the bitmap map is that you get instant visual without having to load your map into another program.

-Chris

##### Share on other sites
I had hoped that this was one of the areas where The Scrolling Game Development Kit would come in handy: as a map editor for a work in progress; one that gives a WYSIWYG interface to the map and offers features like tile matching so you don''t get jagged graphics. The map can be saved in the proprietary format (which includes an easy-to-find big chunk where 1 byte = 1 tile all in one consecutive block) or in XML format. Other formats could be output by writing a VBScript to create a file from the currently loaded map.

I''m not aware of anybody using it this way right now though. Too much overhead?

"All you need to do to learn circular logic is learn circular logic"