1 decade ago by paulstraw
I seem to be having an issue with preRendering background maps when they're set to repeat. I'm using the "standard" code that Dominic has posted around to set the preRender property:
When I load the level, however, any layers set to repeat don't show up properly.
Without preRender:
for(var i = 0; i < this.backgroundMaps.length; i++){
this.backgroundMaps[i].preRender = true;
}
When I load the level, however, any layers set to repeat don't show up properly.
Without preRender:
1 decade ago by dominic
Well, I just experimented a bit: This is a bug, yes. How big is your blue background layer? I guess it's only 1x1 tiles or something?
The problem occurs for repeated background layers that are smaller than the screen size. To fix this, you have to make your background layer bigger. So if your game runs in 320x240, and the tilesize for your background layer is 8, it needs to be at least 40x30 tiles in size. Making the layer bigger wont have any performance implications - it's pre-rendered anyway.
Here's what's happening: When pre-rendering a layer, it is divided into chunks of
So for your background layer the chunk is only 6x6 pixels or something. But there's a bug when drawing these pre-rendered chunks for repeating layers on the screen: they are drawn at most 4 times per frame in a 2x2 grid - therefore a repeating background layer has to be at least as big as your screen to ensure it is filling the background completely at all times.
To fill the background with 6x6 pixel chunks defeats the purpose of pre-rendered background maps anyway. Pre-rendering should decrease the number of draw calls needed to fill the screen, but drawing 6x6 pixel chunks is as inefficient as drawing 6x6 pixel tiles.
So what the engine should have done in your case, is to pre-render the background layer into 512px chunks, instead of using one chunk of just 6px.
I'm not sure I will fix this in the next version, because it seems overly complicated to handle all the possible edge cases (e.g. should a background layer with a size of 320px be drawn on a 512px chunk when the screen size is 480px? How should it repeat?) - and also because it can be easily fixed by making a background layer bigger. I think a note in the documentation on how to avoid this problem would make more sense?!
Very nice graphics btw. :)
The problem occurs for repeated background layers that are smaller than the screen size. To fix this, you have to make your background layer bigger. So if your game runs in 320x240, and the tilesize for your background layer is 8, it needs to be at least 40x30 tiles in size. Making the layer bigger wont have any performance implications - it's pre-rendered anyway.
Here's what's happening: When pre-rendering a layer, it is divided into chunks of
.chunkSize (default 512px). If the layer is smaller than .chunkSize, the actual layer size is used instead. So for your background layer the chunk is only 6x6 pixels or something. But there's a bug when drawing these pre-rendered chunks for repeating layers on the screen: they are drawn at most 4 times per frame in a 2x2 grid - therefore a repeating background layer has to be at least as big as your screen to ensure it is filling the background completely at all times.
To fill the background with 6x6 pixel chunks defeats the purpose of pre-rendered background maps anyway. Pre-rendering should decrease the number of draw calls needed to fill the screen, but drawing 6x6 pixel chunks is as inefficient as drawing 6x6 pixel tiles.
So what the engine should have done in your case, is to pre-render the background layer into 512px chunks, instead of using one chunk of just 6px.
I'm not sure I will fix this in the next version, because it seems overly complicated to handle all the possible edge cases (e.g. should a background layer with a size of 320px be drawn on a 512px chunk when the screen size is 480px? How should it repeat?) - and also because it can be easily fixed by making a background layer bigger. I think a note in the documentation on how to avoid this problem would make more sense?!
Very nice graphics btw. :)
1 decade ago by paulstraw
Once again, awesome answer. Much appreciated. Once you explained it, it makes perfect sense, so I agree it's probably something better fixed with an explanation in the docs than a code change.
(and thanks, glad you like the graphics. =D)
(and thanks, glad you like the graphics. =D)
Page 1 of 1
« first
« previous
next ›
last »