Not to be anal Daishi, but a 1000x1000x16bit image is actually 16000000 bits in size and hence 2000000 bytes in size, which is only about 1.9 MB of memory. Still pretty big though.
And GergisKhan, as already stated, tiles are often rather small. The largest I''ve seen used is 64x64; I prefer 32x32. Maps on the other hand can get huge. For something like a world map, it''s not at all uncommon to have the map be larger than 100 tiles square. If that''s the case, drawing it all to an offscreen buffer would be a 6400 pixel square bitmap in your case. That would be almost 10 MB of bitmap there.
So that''s why the best idea is the one already mentioned: have an array of tile numbers and then draw only the tiles visible on screen. So at 800x600, you''d draw a subsection of... err... 12.5 tiles across by 9.375 tiles down...
Hmm... well, you''ll probably want to split that extra few pixels up so you see equal parts of the fringe rows at the top and bottom and equal parts of the fringe colums at the sides...
-Auron
Question on Tiling for RPG
You can find info on tilemaps under articles and resources, You have square (or rectangular), ISO (diamond), and Hex.
ISO and Hex are often used for Civ and strategy type games. Square and rectangular tile are used for top-down and side-scrollers mostly. Although this is not a rule, just an observation.
Another good point to remember of the use of fringe tiles, these are tiles that when layed over other base tiles give the appearance of a terrain transition. They are also called transition tiles for that reason. Eg. a grass tile is overlayed with a south facing sandy beach for a grass to water transition in that direction.
A quick tip on optimization:
Multiple and Integer (no remainder) Divide can be replaced with bitshifting for powers of two. Modulus can be replaced with bitwise and again only for powers of two.
,Jay
[edited by - Jason Zelos on June 28, 2002 4:37:16 PM]
ISO and Hex are often used for Civ and strategy type games. Square and rectangular tile are used for top-down and side-scrollers mostly. Although this is not a rule, just an observation.
Another good point to remember of the use of fringe tiles, these are tiles that when layed over other base tiles give the appearance of a terrain transition. They are also called transition tiles for that reason. Eg. a grass tile is overlayed with a south facing sandy beach for a grass to water transition in that direction.
A quick tip on optimization:
Multiple and Integer (no remainder) Divide can be replaced with bitshifting for powers of two. Modulus can be replaced with bitwise and again only for powers of two.
Var % 32 Var & 31 //mod, first 4 bits onlyVar * 32 Var << 5 //I hope I've remember which (int) Var / 32 Var >> 5 //way round these go.
,Jay
[edited by - Jason Zelos on June 28, 2002 4:37:16 PM]
A big thank you to all who posted; these tips are like gold.
I''ve talked to the artists and they seem to agree. Since they want to preskew to give the illusion of depth I don''t have to worry about using an isometric map and can simply go to horizontal coordinates.
Auron, your comments are very appreciated: for the reasons specified our viewport is 512 x 512 so as to make the math binary, and thus allow for 64x64 tiles to be drawn and therefore bitshifted as needed for drawing.
Sounds to me like the whole map is loaded in memory during load time, even if it is just 32 bits of info per tile; from there one indexes the tile to be drawn. I wonder whether or not other people have chunked a huge map into "zones" so as to only have say 10MB of map loaded at a time, and what one does about the zone-to-zone crossings.... but perhaps that isn''t something to worry about just yet?
I''ve talked to the artists and they seem to agree. Since they want to preskew to give the illusion of depth I don''t have to worry about using an isometric map and can simply go to horizontal coordinates.
Auron, your comments are very appreciated: for the reasons specified our viewport is 512 x 512 so as to make the math binary, and thus allow for 64x64 tiles to be drawn and therefore bitshifted as needed for drawing.
Sounds to me like the whole map is loaded in memory during load time, even if it is just 32 bits of info per tile; from there one indexes the tile to be drawn. I wonder whether or not other people have chunked a huge map into "zones" so as to only have say 10MB of map loaded at a time, and what one does about the zone-to-zone crossings.... but perhaps that isn''t something to worry about just yet?
I use a map divided down into fairly small 8x8 visual tile chunks. Each tile is 32x32 pixels. So each map chunk is 256x256 pixels, kept that size to make it easy to use as a texture.
Because I have a variable zoom level, I keep anywhere from a 3x3 chunk area to a 6x6 chunk area in memory at a given time.
Now that''s for static data only.
My dynamic data is kept at a smaller resolution, but in larger chunks. So each map chunk is 8x8 visual tiles, but 16x16 walkable tiles, i.e. each 32x32 pixel tile has four places a character can stand on. The dynamic area is divided into 64x64 tile areas, or basically covers four map chunks. Each dynamic area is a linked list of changeable objects in that 64 x 64 tile area. Every time an object moves it may have to leave one dynamic zone and enter another (remove from list, add to list).
My world is 1600x1600 visual tiles, 3200x3200 walkable tiles,
there are 200x200 static chunks and 100x100 dynamic lists
My static map file has all the chunk data. The start of the file contains a list of where each chunk is in the file, the position of each chunk is not constants because I also store a variable linked list of static objects in each chunk, things such as trees, rocks, etc...
anyway, it works well for me.
luck,
-mat
mat williams
Lead Programmer, Designer
Zero Sum Software
www.zero-sum.com
Because I have a variable zoom level, I keep anywhere from a 3x3 chunk area to a 6x6 chunk area in memory at a given time.
Now that''s for static data only.
My dynamic data is kept at a smaller resolution, but in larger chunks. So each map chunk is 8x8 visual tiles, but 16x16 walkable tiles, i.e. each 32x32 pixel tile has four places a character can stand on. The dynamic area is divided into 64x64 tile areas, or basically covers four map chunks. Each dynamic area is a linked list of changeable objects in that 64 x 64 tile area. Every time an object moves it may have to leave one dynamic zone and enter another (remove from list, add to list).
My world is 1600x1600 visual tiles, 3200x3200 walkable tiles,
there are 200x200 static chunks and 100x100 dynamic lists
My static map file has all the chunk data. The start of the file contains a list of where each chunk is in the file, the position of each chunk is not constants because I also store a variable linked list of static objects in each chunk, things such as trees, rocks, etc...
anyway, it works well for me.
luck,
-mat
mat williams
Lead Programmer, Designer
Zero Sum Software
www.zero-sum.com
quote:Original post by BadmanX
Another way to do this is if you''re making really huge maps is to use "chunks". Ultima VII did this to great effect - Ultima VII''s map is 24576 pixels by 24576 pixels - over 600 MILLION pixels. Yet the map only takes up just over a meg on disk.
Heh, the Scrolling Game Development Kit can do this without chunking and get it in well under 1 MB (Assuming 32x32-pixel tiles). It does this by having a very low overhead on tiles -- 1 byte per tile.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement