Displaying image as map - Bladurs Gate Style
Author
Ok,
So I was working on this level editor for my game. I was sitting thinking one day, I want the maps to be very detailed, so tilemaps are kind of retarted. So I pondered the idea of just making a giant image file for a map, then making a clipping stuff etc.
ok. so I thought this was stupid idea becuase a large image would just be insane. Here''s why,
I converted my 128x128 tile map. First of, each tile is 32x32. So therefor a 128x128 map is 4096x4096. So I open up Photoshop and make a 4096x4096 map. The temp file was ~50 megs. Which is very large for a map. Then I thought, well in a good image format it might work. a completely green 4096x4086 at a half image quality in jpeg format turned out to be 800k, which isn''t bad. But also a 4096x4096 pixel map really hurt Photoshop when it came to speed. So making that map would take a lot of time just sitting and waiting for photoshop to finish its processes.
From what I hear Baldurs Gate uses images like I said. So what is a practical way of doing this?
CrappySoft - game production team with a punk attitude. Mail me if you want to make levels, art etc.
Well, the biggest flaw with doing something like that is memory. Think about, 4096x4096x4 is 67.1MEG!!! Then you need room for sounds/other textures/data/program data/OS data/other app data and so on...So you would need some super way of compressing that data IN MEMORY...so if it were saved as a jpg IN MEMORY, you would need a way to decompress it fast enough to do the other stuff so forget that....rle compression just sucks....you''ll need a supervious way of compressing it. It just doesn''t work out, thats why tiles are used.
--Andrew
--Andrew
Bladur''s Gate uses tilesets from the actual images (probably rendered in MAX). These tilesets are blocks of 64x64 pixels with an associated palette for each block.
If your image is 4096x4096x24, the memory consumption comes to about 50meg. Using the tileset approach, this is reduced to about 17meg.
So you will need to make a tool which takes the big bitmap and reduce the 24bit color in each block to 8bit with a palette (octree approach is the best).
Hope this helps.
--Antz
Quanta Entertainment Ltd.
http://www.quanta-entertainment.com
If your image is 4096x4096x24, the memory consumption comes to about 50meg. Using the tileset approach, this is reduced to about 17meg.
So you will need to make a tool which takes the big bitmap and reduce the 24bit color in each block to 8bit with a palette (octree approach is the best).
Hope this helps.
--Antz
Quanta Entertainment Ltd.
http://www.quanta-entertainment.com
You don''t need to load the ENTIRE MAP into memory at once you know.
Split up your 4096x4096 map into big-ass-tiles, like 256x256 each. Then you''d only need to load the tiles that you are currently displaying. For a 640x480 screen, you''d only have to have 3x2=6 tiles in memory, maybe 4x3=12 tiles for camera overlap, etc ... assuming 16bpp, mem usage = 256x256x4x3x2 = 1536KB, which is not that bad.
And for an attribute layer (you know, places you can and can''t walk, etc) you could define an attribute block as covering 8x8 pixels, making your attribute map = 512x512 attribute blocks. If each attribute block was a single byte, this is only 256KB, also not too bad, plus you could break the attribute map into chunks as well, so you wouldn''t have to store it all in memory at once.
Here is a possible structure you could use:
struct MapChunk{ int graphics[256][256]; char attribute[32][32]; // each attribute block = 8x8 pixels, covering this whole mapchunk}; Whaddya think?
Loading chunks from the harddrive and decoding them in the middle of a game? Harddrives aren''t fastenough for that yet.
quote:Original post by Assembler015
Loading chunks from the harddrive and decoding them in the middle of a game? Harddrives aren''t fastenough for that yet.
Er, wrong. Ultima VII was doing this back in 1992. And that was before even Pentium processors, never mind 1GHz processors and UDMA disk access.
Author
Oh,
The problem I had was -never- with loading the image in the game. You''d display it just as you would a tile map, because if you drew the WHOLE entire tile map, even if it''s split up into tiles it would still run slow, which is why you only draw the tiles on the screen.
The problem is, the size of the map on the hard drive, and working with a map that size in an art program gets hefty. I was just wondering if there were any techniques in the level developing process that they used.
CrappySoft - game production team with a punk attitude. Mail me if you want to make levels, art etc.
The problem I had was -never- with loading the image in the game. You''d display it just as you would a tile map, because if you drew the WHOLE entire tile map, even if it''s split up into tiles it would still run slow, which is why you only draw the tiles on the screen.
The problem is, the size of the map on the hard drive, and working with a map that size in an art program gets hefty. I was just wondering if there were any techniques in the level developing process that they used.
CrappySoft - game production team with a punk attitude. Mail me if you want to make levels, art etc.
You are making a 4096 x 4096 pixels map?
Why not make 16 images, 1024x1024 each, and work on it in chunks?
Either do that, or upgrade your system.
quote:Original post by lower_case
...if you drew the WHOLE entire tile map, even if it''s split up into tiles it would still run slow, which is why you only draw the tiles on the screen.
Generally speaking, is it always a better idea to only draw the tiles on the screen? Does rendering speed good enough for scrolling while drawing the tiles on the fly, like if you are using directX? For instance, you''d need to clip screen edges during scrolling. I did some simple experiments while back but in the end I couldn''t figure. I can see that the biggest prob in drawing the ENTIRE map in offscreen buffer (from which you take chunks to render onto video buffer) is memory it eats up... so it''s unpractical for big maps, as everyone has said.
Any comments anyone can share on this?
Hi there,
if its under win32/winNT then you could use a
file mapping this way you can have any size of
bitmap you like and just store it on the
hard drive.
DIBS can handle bitmaps in this way and modern
hardware is capable of doing some pretty fast
normal blts using bitblt etc.
Hope it helps.
if its under win32/winNT then you could use a
file mapping this way you can have any size of
bitmap you like and just store it on the
hard drive.
DIBS can handle bitmaps in this way and modern
hardware is capable of doing some pretty fast
normal blts using bitblt etc.
Hope it helps.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
