RAM usage in a 3d map array?
Author
(I'm not a coder BTW)
So if I plan on making a 2D map that has, 200x200 tiles, and 3 layers (200x200x3) which = 120,000 tiles.
Each tile is 16x16. The colors are 16-bit (2 bytes per pixel right?).
Let's say there are 3 types of tiles total. A grass tile, a water tile, and a dirt tile. First of all, do the actual range of colors in each tile type affect how much memory the tile takes up (maybe depending on the image format)? If not, then each tile is the same amount of memory, which would be 16x16x2 = 512 bytes.
Now since the 3 tile images are stored somewhere and just need to be loaded up on the array, let's say all 120,000 tiles were dirt. In other words the 200x200 tiles is not one HUGE image, it's a bunch of loaded 16x16 dirt tiles, and the ONE dirt tile image is 512 bytes (probably). So how much RAM does it take for the array to display every dirt tile? (I'm just guessing here, you may find I don't know what I'm talking about, just trying to learn). Let's say to display every tile takes up 5 bytes. That means that the total RAM usage would be 200x200x3x5 ( = 600,000 bytes) + 512 = 600,512 bytes. Would that be correct?
Then if there were 3 different tiles being used, it would be 600,000 + 512(3) = 601,536 bytes.
Also if the water tile was animated with 2 frames, it might be 1024 bytes?
Just trying to figure this stuff, sorry for any lack of key knowledge!!
Hi,
Your calculations look correct. 600,000 bytes is equal to 600 kilobytes which is less than a megabyte. Nothing to be worried about. Modern games could easily require 1000 times that amount of memory.
You should use 32-bit (4 bytes per pixel) images for tiles, or you can use texture compression (will reduce the memory requirement to 1/4 or less) if you feel that they will take too much of memory.
You may draw the same tile as many times as you want and it doesn't really change the memory requirements.
Cheers!
Author
Thanks man!!!
One more thing: You said 600,000 was right - does that mean when I said 5 bytes memory per tile in the array, was I right?! Do arrays always take up 5 bytes per tile or does that number vary depending on the information stored in each tile or something?
One more thing: You said 600,000 was right - does that mean when I said 5 bytes memory per tile in the array, was I right?! Do arrays always take up 5 bytes per tile or does that number vary depending on the information stored in each tile or something?
So, there are a few issues at hand here, namely the map, the tile properties, and the tile graphic. All of these represent different structs/classes, and so they represent different collections of memory.
The tile graphic is just what you said, if they're 16x16 and 16bit color, each tile consumes 512 bytes, assuming no compression. Each additional frame of animation for an animated tiles is another 512 bytes.
The tile properties is some kind of structure or class which stores things such as tile properties, collision, and some kind of reference to the tile graphic (an index in an array, a reference, a pointer, etc.) This structure is what your map should probably reference. These will probably be just a few bytes, depending on your needs.
The map is just a simple 2D or 3D array. The contents of each array element need just enough data to index the full range of tiles available. If you have 256 or fewer tiles, then you only need 1 byte to access the full range of tiles. If you have more than that, 2 bytes will allow you to access up to 65536 tiles. Alternatively, you could store a pointer to the tile property directly, which saves a multiply and add for each tile, but this will cost you 4 bytes on a 32bit system, or 8 bytes on a 64bit system. You will also have to generate the pointers at load-time since you can't simply store pointers in a file and expect them to work the next time the program is loaded. Honestly, its probably best to just go with 8 or 16 bit indexes.
The tile graphic is just what you said, if they're 16x16 and 16bit color, each tile consumes 512 bytes, assuming no compression. Each additional frame of animation for an animated tiles is another 512 bytes.
The tile properties is some kind of structure or class which stores things such as tile properties, collision, and some kind of reference to the tile graphic (an index in an array, a reference, a pointer, etc.) This structure is what your map should probably reference. These will probably be just a few bytes, depending on your needs.
The map is just a simple 2D or 3D array. The contents of each array element need just enough data to index the full range of tiles available. If you have 256 or fewer tiles, then you only need 1 byte to access the full range of tiles. If you have more than that, 2 bytes will allow you to access up to 65536 tiles. Alternatively, you could store a pointer to the tile property directly, which saves a multiply and add for each tile, but this will cost you 4 bytes on a 32bit system, or 8 bytes on a 64bit system. You will also have to generate the pointers at load-time since you can't simply store pointers in a file and expect them to work the next time the program is loaded. Honestly, its probably best to just go with 8 or 16 bit indexes.
Quote:Original post by ravyne2001
You will also have to generate the pointers at load-time since you can't simply store pointers in a file and expect them to work the next time the program is loaded.
You can subtract the offset during loading to *fix* the pointers into the array. But indices are probably still simpler.
Author
Tile properties -- good to know!!!
Oh...so, when you say "full range of tiles available," and "256 tiles or fewer," you mean the different types of tiles stored in the memory like dirt, grass, water, right? So then if there are more than 256 tiles in memory, you are saying that to load the entire 200x200x3 array on screen, it only needs 2 bytes altogether? Or you mean 2 bytes per tile on the array (so 200x200x3x2 bytes = 240,000)?
I think I've read something about the pointers to the tile properties thing before (link the tile to an events list or something?) but that's a bit over my head for now.
Quote:Original post by ravyne2001The map is just a simple 2D or 3D array. The contents of each array element need just enough data to index the full range of tiles available. If you have 256 or fewer tiles, then you only need 1 byte to access the full range of tiles. If you have more than that, 2 bytes will allow you to access up to 65536 tiles. Alternatively, you could store a pointer to the tile property directly, which saves a multiply and add for each tile, but this will cost you 4 bytes on a 32bit system, or 8 bytes on a 64bit system. You will also have to generate the pointers at load-time since you can't simply store pointers in a file and expect them to work the next time the program is loaded. Honestly, its probably best to just go with 8 or 16 bit indexes.
Oh...so, when you say "full range of tiles available," and "256 tiles or fewer," you mean the different types of tiles stored in the memory like dirt, grass, water, right? So then if there are more than 256 tiles in memory, you are saying that to load the entire 200x200x3 array on screen, it only needs 2 bytes altogether? Or you mean 2 bytes per tile on the array (so 200x200x3x2 bytes = 240,000)?
I think I've read something about the pointers to the tile properties thing before (link the tile to an events list or something?) but that's a bit over my head for now.
Quote:Original post by swiftcoderQuote:Original post by ravyne2001
You will also have to generate the pointers at load-time since you can't simply store pointers in a file and expect them to work the next time the program is loaded.
You can subtract the offset during loading to *fix* the pointers into the array. But indices are probably still simpler.
Right, but I was assuming that if he was using pointers in the first place that the tile properties were new'ed sporadically. You make a good point though, that the pointers are easy to fix if the tile properties exist in an array.
Quote:Original post by Sylon
Tile properties -- good to know!!!Quote:Original post by ravyne2001
The map is just a simple 2D or 3D array. The contents of each array element need just enough data to index the full range of tiles available. If you have 256 or fewer tiles, then you only need 1 byte to access the full range of tiles. If you have more than that, 2 bytes will allow you to access up to 65536 tiles. Alternatively, you could store a pointer to the tile property directly, which saves a multiply and add for each tile, but this will cost you 4 bytes on a 32bit system, or 8 bytes on a 64bit system. You will also have to generate the pointers at load-time since you can't simply store pointers in a file and expect them to work the next time the program is loaded. Honestly, its probably best to just go with 8 or 16 bit indexes.
Oh...so, when you say "full range of tiles available," and "256 tiles or fewer," you mean the different types of tiles stored in the memory like dirt, grass, water, right?
Well, if your map refers to tile properties, and tile properties refers to the graphic, then the number of graphics is a moot point. Its possible, for example, to have a grass graphic linked to two tile property structures (say if you want one to be able to be walked on, and one that can't be walked on, but you want them to look identical for some reason -- hidden paths, for instance.) So if you have 256 or fewer distinct tile properties, then you can use 1 byte, if you have more, you need two bytes, but there doesn't necessarily have to be a 1:1 relationship between tile properties and tile graphics.
Quote:So then if there are more than 256 tiles in memory, you are saying that to load the entire 200x200x3 array on screen, it only needs 2 bytes altogether? Or you mean 2 bytes per tile on the array (so 200x200x3x2 bytes = 240,000)?
2 bytes per tile in the array, not altogether.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
