Back to General and Gameplay Programming

Reducing RAM consumption for Tile-Based map.

General and Gameplay Programming Programming

Started by Thevenin June 21, 2005 10:57 PM

28 comments, last by Enokh 18 years, 10 months ago

tolaris

288

June 23, 2005 05:04 PM

Quote:Original post by Thevenin
Or can 2MB worth of data be loaded quick enough?

You don't need to load it all in one go. Taken to extreme, you can reduce it to a point where when the player moves one tile left/right you only fetch single "new" column worth of data from respective direction (so at worst you just load single column and single row when player moves diagonally)

Thevenin

270

Author

June 23, 2005 05:36 PM

Quote:Original post by tolaris
Taken to extreme, you can reduce it to a point where when the player moves one tile left/right you only fetch single "new" column worth of data from respective direction...

I would have thought the seek time would be the greatest slowdown factor.

eg...

Loading 1 KB = 10ms
Loading 1 MB = 11ms.

tolaris

288

June 23, 2005 06:05 PM

Quote:Original post by Thevenin
I would have thought the seek time would be the greatest slowdown factor.

eg...

Loading 1 KB = 10ms
Loading 1 MB = 11ms.

Well, that's something for profiling to find out (given the O/S is likely to add couple cents here with the caching and whatnot) ... but if it turns out you can load 2 MB in total of (10 ms access + relatively insignificant extra time needed for data read) then there's hardly problem with fetching data for whole next tile fast enough in one go, isn't it? ^^

FritzMar

140

June 23, 2005 06:08 PM

been a while for me to but alot of the methods mentioned above are good

first off dont use a 2000x2000 tile map unless you can help it even if you are only using and 8bit varible to store your layer of tile data you still have to looking at about 4mb of data per-layer use a base layer using

correct me if i'm wrong but the old snes only had like 5 layers and 2 layers to background 2 sprites and 1 to above effects and they were able to get some really kick ass stuff of that. you need to rethink your system alittle bit.

*you should only need 1-2 layers for your base
*add a structure that contains building data with all the floors and stuff
and put that in a linked list and then draw that in

*when you say layers do you mean levels because from the what you are saying thats seems to describe what you are doing more

*i'm sure your little compition with 7mb ram is using all those tricks mentioned above

splitting the map in to section and loading off the sections as the play nears them is a good plan loading a diffrent section or area when you go up a floor will help with design and memory usage and give you more levels up and down

using a simple RLE compression well help greatly

0))))))>|FritzMar>

Outworlder

100

June 23, 2005 06:44 PM

Quote:Original post by Thevenin
Quote:Original post by tolaris
Taken to extreme, you can reduce it to a point where when the player moves one tile left/right you only fetch single "new" column worth of data from respective direction...

I would have thought the seek time would be the greatest slowdown factor.

eg...

Loading 1 KB = 10ms
Loading 1 MB = 11ms.

And it is! Take a game like Ultima VII, for example. Smardrive made a huge performance improvement, probably by avoiding unecessary disk accesses.

However, if the world is, say 10000x10000, why not store a (for ex.) 200x200 region, and let's take a 20x20 visible area(I'm making these numbers up).

Now, whenever the player moves, start "shifting" and prefetching tiles, preferably in a "lazy" way.

Since you've got a good buffer, you don't need to start fetching tiles right away. You can give your player a small room to move about before getting crazy with tile loading. Might even have a special code to handle the worst case: a player running non-stop in a single direction. And this tile loading could be backgrounded, you could have something to predict player movement and so on.

Those ideas are untested, but I've been thinking about it for some time now. It seems it would work just fine for tiles, but NPCs would give you character some trouble.

My advice? Download Exult and play with it. It's a engine to replace the aging(read: impossible to run today) and proprietary Ultima VII engine. Then look at the source, you might get some good pointers.

Gaiomard Dragon-===(UDIC)===-

Thevenin

270

Author

June 23, 2005 07:11 PM

Quote:Original post by FritzMar
correct me if i'm wrong but the old snes only had like 5 layers and 2 layers to background 2 sprites and 1 to above effects and they were able to get some really kick ass stuff of that. you need to rethink your system alittle bit.

Each layer is an elevation of which the player can walk on, much like a pyramid (Infact, that is the perfect description). I know your just trying to help, but that last comment hurt [bawling].

Quote:Original post by Outworlder
Quote:Original post by Thevenin
I would have thought the seek time would be the greatest slowdown factor.
eg...
Loading 1 KB = 10ms
Loading 1 MB = 11ms.

And it is! Take a game like Ultima VII, for example. Smardrive made a huge performance improvement, probably by avoiding unecessary disk accesses.

I'm flattered. [smile]

Quote:Original post by Dragon88
a method I have not yet seen suggested is to simply store the *unique* tile information, then just use pointers. A pointer is only 4 bytes long, no matter what it points to, whereas a tile structure could easily be 8 times that. Your milage will vary dependant on how many duplicate tiles there are, and how large the tile structures are. This may not work at all in your situation, but I thought I'd suggest it.

Definently a creative solution, but as DigitalDelusion pointed out..

42MB / (2000x2000x11) ~= 1 byte (unsigned char)

Walkable/not walkable is determined by the tile's graphic (A lookup table is used). And in the case where a player needs to interact with a tile, that tile is actaully an object that overlaps some arbitrary tile.

[Edited by - Thevenin on June 23, 2005 7:11:39 PM]

mattm

165

June 24, 2005 07:13 AM

Also bear in mind that 42Mb is not that much in todays memory (depending on what platform you are targeting). while there is obviously no harm in making your code better, or atleast understanding how to make it better, it can be too easy to get hooked up on things like this and not make any progress with your game (I speak from experience). Obviously, if you have done your sums and this is too much then optimise, otherwise see how it goes!

Inmate2993

222

June 24, 2005 12:20 PM

The elevations on the pyramid could be easily simulated with a single layer, so, I don't quite understand exactly why you'd need any more than 2 layers for normal graphics. If you want some background<->foreground parallax, than maybe 4 layers would work.

As for the 2000x2000 field width. Seems too long. Even with say a 256x256 field size, with 16x16 pixels per tile, this is 4096 pixels wide, which depending on resolution is huge. At 640x480, thats six screens wide and eight screens high. If you divide up your world into blocks and just have the old fade-out fade-in effect at the borders (or a zelda like scroll), then you wouldn't have any problems with memory usage.

william bubel

Synex

170

June 24, 2005 05:23 PM

This is mainly a RAM usage problem right? So you'd like to reduce the amount of memory you use when you load your maps into memory?

I'd simply load your map on a as-its-needed basis. So keep most of your map on disk, and only load the area around the player into memory.

This kinda the thing your looking for?

SynexCode Monkey

Enokh

122

June 25, 2005 11:03 AM

42 MBs? Why not continue coding other game systems, and make some progress on the game itself? If it proves to be a critical problem later on, then go ahead and work on it.

Reducing RAM consumption for Tile-Based map.

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reducing RAM consumption for Tile-Based map.

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines