How much parallax mapping do you need to use to affect the game's optimization?

[McKirity]

Hi everyone, I'm planning on using mostly parallax mapping to create my maps. However, a common warning I've seen about using parallax maps is that they're a much bigger drain on resources compared to using the engine's own map editor, and that you run the risk of inducing lag and even crashes. My questions are:

• Let's say I have a game where only one map partly uses parallax mapping, and the rest of it is made entirely in the map editor. Would the drain increase only when the player character is on that map, or would it increase for the entire game?
• From what I could tell, bigger maps = bigger drain. Would reducing the file size of the parallax map help in any way?
• Does anyone know the actual numbers on using parallax maps? For example, a 25x25 grid map that's built entirely from parallax maps will raise RAM usage by X amount/percentage
• I know that it'll wreak havoc on mobile, but if you mainly plan on deploying to Windows and Mac, is it still a concern?
• Will the type of RPG Maker engine affect how much resource parallax maps use? In other words, does it run better on MZ or VXA?

Thank you in advance!

 

[Danatoth]

Yes, parallax mapping can slow down rpg maker a lot because it's not optimized for it. Depending how you're going about parallaxing (what plugin) will also affect it. I'm using qmap and stick to a maximum of around 30x30 with 3 layers (base, overlay, lighting) and I don't get any lag.

MZ runs parallax better than MV because you can use it natively. I can't speak for XVA

I am actually going to make a 50x50 map sometime this week, and I'll let you know how that goes. In all my years doing parallax mapping I've never went that big, so we'll see.

 

[Eliaquim]

Hi there!

1 - No. The parallax mapping will only use the resources while they are active. Meaning if you transfer to another map, that does not have that same parallax mapping, you will be "free" from him. While you are on a map with a heavy parallax map, the game will "drain" the resources needed to run on that scenario.

2 - Regarding to the RAM it consumes, I believe will not help. Don't know for sure.

3 - I believe it is not a concern. I think you should be fine keeping it at a maximum of 65x65.

4 - I can just say that MZ performs better because of the advanced version of PIXI.js than MV. The other makers, I don't know.

There is a lot of threads about this, explaining how it works. Maybe try looking for it too. But I believe, if you are not going to mobile, you will avoid the downsizes of parallax mapping.
But performance, is a thing that has always multiple factors to count in...

 

[Andar]

• From what I could tell, bigger maps = bigger drain. Would reducing the file size of the parallax map help in any way?
• Does anyone know the actual numbers on using parallax maps? For example, a 25x25 grid map that's built entirely from parallax maps will raise RAM usage by X amount/percentage

1) no.
Filesize is compressed size, but to walk on the map you'll need the picture uncompressed in RAM.
Filesize will only affect loading times, not the amound needed in RAM.

Tip: BMP is an uncompressed format - it can't be used directly exactly because of that, but the filesize of a BMP picture is exactly how much RAM it needs uncompressed when loaded. So you can test saving as BMP to get the true numbers.

2) There is no direct formula, but the basics are easy to compare:
A tile-based map has one number per tile (less than 16 bit) per layer, plus the amount for the tileset.

A parallax map stores each pixel independently, that is in case of MZ 48x48 pixel per tile - or 2304 pixel numbers. Each color needs 3 numbers (RGB ), which means 24 bit per pixel minimum (you might have heard of 24 bit pictures or even higher numbers for a larger color range). And again, that is per layer.

Depending on the number of layers and tileset overhead you can usually estimate that a parallaxed map needs three- to four thousand times the RAM of a tilebased map.
And because the overhead like tileset-size is fixed, the factor gets larger the larger the map is.

But the overhead and a few other considerations on layers are also the reason why no one can give absolute numbers - on very small maps (limited to screen size) with extremely varying tiles the parallax map might only use double the RAM compared to the tileset, because of the overhead needed to store the tileset itself.

 

[McKirity]

Yes, parallax mapping can slow down rpg maker a lot because it's not optimized for it. Depending how you're going about parallaxing (what plugin) will also affect it. I'm using qmap and stick to a maximum of around 30x30 with 3 layers (base, overlay, lighting) and I don't get any lag.

MZ runs parallax better than MV because you can use it natively. I can't speak for XVA

I am actually going to make a 50x50 map sometime this week, and I'll let you know how that goes. In all my years doing parallax mapping I've never went that big, so we'll see.

Thanks for taking the time to reply! I plan on using Galv’s plug-in bc it’s the most intuitive for me. I’d love to hear about the outcome of a 50x50 map. If you don’t mind, I’m curious about your device specs as well so I can compare it

 

[Andar]

You can't really compare lag, because there are multiple causes - a single bad parallel process can create more lag than a large parallax, while most games have no problems running two or three dozen intelligently written parallel processes in addition to most parallaxes

In general, anything more than a 150x150 tile parallax needs a high-end-computer.
an average computer should have no problems with a 100x100 tile parallaxed map.
A low-end computer or a high-end mobile might be able to handle 50x50 parallax maps.
and a low end mobile should be limited to 25x25 tile parallax maps.

 

[Arthran]

A parallax map uses 4 bytes of RAM per pixel, per layer.

A 50 x 50 map would be 5,760,000 pixels. Multiplying by 4 bytes would result in 24,040,000 bytes, which is about 22 megabytes. Supposing you're using 3 mapping layers, that would mean that the map uses 66 megabytes total. This shouldn't be an issue on modern hardware.

However, as the RAM consumption increases exponentially as map size increases, be careful not to go too crazy with it, because it will start getting pretty high pretty fast. For example, if we double the size of the 50 x 50 map, it does *not* use twice as much RAM--it uses four times as much RAM. If we triple the size of the map, it uses nine times the RAM.

 

[Roxus]

Hi, sorry for hijacking the thread (not sure if this is against the rules) but I have a noob question about RAM usage in parallax.
I believe you can also use parallax for just adding shadows and lights.
So if I use a 50 x 50 map, does it still use as much RAM as an opaque parallax layer or is it significantly lower when using a transparent layer?
What about the weather effects? (They count as parallax layers, right?)
And lastly is it better to use plugin like say Shora for lights or parallax? (As in which uses more resources)

If such a question needs its own post, please let me know I will delete it. Thanks.

 

[Andar]

it mostly depends on how it is done.
each layer is added to the RAM requirement, the only thing variable is how many bits the layer adds per pixel - but the pixel number remains unchanged.

You'll have at minimum 24 bit for RGB on the ground layer, plus usually 24 bit for the RGB of the top layer. If you're using light and shadow layers those are added to the requirements, and it depends on what data they contain how many bits they add to each pixel requirement.

Weather effects are usually NOT parallax layers - in most cases they are done as mathematical functions like where to draw lines for rain. However if you decide to use a fog in layer form, then that is an added layer like any other

As for plugin use: it completely depends on what that plugin does. Particle light does not require RAM for layers, but it does require CPU power for processing (a static parallax layer has almost no CPU requirements).

As I mentioned above, resource usage and lag cannot be pinpointed and compared because there are too many different uses for the different resources. But nothing is free, everything needs to be handled someway.

 

[Roxus]

@Andar Thanks for the detailed answer but I guess it went a little over my head.
I will try to make my question more clear.
Say I am rendering the whole map normally, in engine using tilesets and only just using parallax to add lights and shadows hence using a transparent layer
Now comparing that to rendering the whole map as parallax layers (say 3 layers completely opaque) and then adding light and shadows (another layer)
So, does both impact the performance equally or does the second case impact performance far greatly than the first case?
I can guess the answer but I just want to make sure to ask an expert.

 

[Arthran]

Hi, sorry for hijacking the thread (not sure if this is against the rules) but I have a noob question about RAM usage in parallax.
I believe you can also use parallax for just adding shadows and lights.
So if I use a 50 x 50 map, does it still use as much RAM as an opaque parallax layer or is it significantly lower when using a transparent layer?
What about the weather effects? (They count as parallax layers, right?)
And lastly is it better to use plugin like say Shora for lights or parallax? (As in which uses more resources)

If such a question needs its own post, please let me know I will delete it. Thanks.

Even if a layer is mostly transparent, it still takes up the same amount of RAM--4 bytes per pixel (1 byte for Red, 1 for Green, 1 for Blue, and 1 for Alpha).

You might notice that a mostly transparent image has a smaller file size than a mostly opaque image, because compression algorithms have ways to represent successive identical pixels in a condensed manner. However, when the engine loads the images, they are decoded into uncompressed raw pixel data in RAM... so even completely transparent pixels still require the same amount of memory as opaque pixels.

 

[McKirity]

You can't really compare lag, because there are multiple causes - a single bad parallel process can create more lag than a large parallax, while most games have no problems running two or three dozen intelligently written parallel processes in addition to most parallaxes

In general, anything more than a 150x150 tile parallax needs a high-end-computer.
an average computer should have no problems with a 100x100 tile parallaxed map.
A low-end computer or a high-end mobile might be able to handle 50x50 parallax maps.
and a low end mobile should be limited to 25x25 tile parallax maps.

Thank you, this is a very useful rule of thumb. As for that tidbit on parallel processes, would it surprise you to know that I understand it about as much as I do parallaxed maps? I've started trawling the forum for more information on it, but I may have to make another post asking what a bad vs well-written parallel process looks like

Even if a layer is mostly transparent, it still takes up the same amount of RAM--4 bytes per pixel (1 byte for Red, 1 for Green, 1 for Blue, and 1 for Alpha).

You might notice that a mostly transparent image has a smaller file size than a mostly opaque image, because compression algorithms have ways to represent successive identical pixels in a condensed manner. However, when the engine loads the images, they are decoded into uncompressed raw pixel data in RAM... so even completely transparent pixels still require the same amount of memory as opaque pixels.

Okay, this explains the process behind RAM and parallax maps really well. I finally get it now.

If possible, can you explain how tilesets differ from the process of parallax maps, and how they're able to save on so much more resources? Is this when file size actually matters, or is it still a non-issue?

 

[Roxus]

@Arthran Okay, I am staring to get it now.
As someone new to parallax mapping that was really helpful. Thank you.
The only question I have left is how much difference does it make using normal mapping vs parallax mapping, I guess the OP has the same question too.

 

[TheoAllen]

If possible, can you explain how tilesets differ from the process of parallax maps, and how they're able to save on so much more resources? Is this when file size actually matters, or is it still a non-issue?

When you have one or two tiles for a tree, the game only loads that tree. It is saved in a specific block of memory. Then it is referenced everywhere else where you want to draw/render that tree. In parallax mapping, however, it is just a plain huge image. You may have the same two trees in the parallax image, but it occupies different memory.

 

[Roxus]

@TheoAllen Alright, I guess normal mapping is better than parallax if you aren't doing something special, thanks for the explanation.

 

[Arthran]

If possible, can you explain how tilesets differ from the process of parallax maps, and how they're able to save on so much more resources?

Okay, I am staring to get it now.
As someone new to parallax mapping that was really helpful. Thank you.
The only question I have left is how much difference does it make using normal mapping vs parallax mapping, I guess the OP has the same question too.

It is as @TheoAllen says. To expand upon that a bit:

Tile Mapping - The game engine only has to load the tile sheets into memory, and then it uses the tiles to draw the visible portion of the map in real-time. This means that no matter how large the map is, it still uses the same amount of RAM. You could have a 9000 x 9000 sized map, and it wouldn't use any more RAM than a 20 x 20 map, because they both use the exact same tile sheets, and only the visible portion of the map is ever rendered at any given time.

Parallax Mapping - The game engine has to load each layer of the entire map into memory, as one massive image each. This means that as you increase the map size, or as you increase the number of layers, you increase the RAM consumption.

Is this when file size actually matters, or is it still a non-issue?

In the context of game performance, file size never particularly matters (other than a large file might take a bit longer to load). The reason I brought up file size was simply to try to explain that the file size of an image does not necessarily reflect the RAM usage of an image.