![]() The mathematic are a bit more complex than that - the tilemap has an overhead of storing the tileset, but on the other hand the tile storage doesn't vanish for the parallax map, especially if you use it for passability and so on. Save your parallax as a BMP as a test only - that file format has no compression, and that will tell you how much RAM you really need to reserve for that map picture while the player moves on that map. That is compressed size and pictures can be compressed a lot.īut you cannot work on a compressed map, for the map the player moves on the data needs to be uncompressed. YES, a parallax map needs 4600 times the RAM of a tiled map.ĭo not be confused by the small filesize of your parallax images on the harddrive. That multiplies to 13824 bytes per tile-sized area. The color is usually coded with three bytes (24-bit-color, 8 bit per base), and most parallax maps use two layers (ground and above). MV has three mapping layers, so that are three bytes of storage per tile.Ī parallax part of the same size has 48x48 pixels per layer to store. The viewport is only dependent on the screen size and mostly identical for both cases, so let's ignore that for now.īut how is the rest of the map stored? It always needs to be completely in memory for the map to work, and that uses RAM.Ī single tile of a tiled map uses one number for each layer ("Place tile number # here"). In both cases (parallax and tiled) you have a viewport of what you can see and the map storage itself. However, from experience I can say that is a very tedious thing to get some mathematics on the difference. But they increase map transition lag, because they use a ton of CPU resources, especially in larger numbers (of hundreds).Įssentially the best way to optimize the MV engine would be to make the loading asynchronous with a smart preloader. Then they notice the pointers are empty, so they will load new assets without releasing the previous pointers, essentially resulting in memory leak that will ultimately lead to a crash).ĭoodads are a nice solution. They will preload the assets you will ask them to (However, they are constructed in such a way that when the garbage collector flushes the images, the empty pointers will remain. TDDP preload manager and SRD's preloader core sacrifice RAM for CPU too. Nevertheless, too much can lead to crashes. Parallax mapping sacrifices RAM for CPU power, because you don't have to render and handle X objects. MV loads resources on demand, so it sacrifices CPU for RAM, but ultimately results in lag. You have to remember that you cannot optimize the game for every situation.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |