Parallax Mapping

[dbchest]

let us pretend we created a new project and removed all of the plugins that are installed into the project by default. let us pretend we wanted to integrate parallax mapping into this project. i would like to discuss the key components a programmer should consider when designing a plugin to perform the back-end processing to work in tandem with parallax mapping. most importantly, what is actually going on in the background when we use parallax mapping?

 

[Poryg]

When you're doing full parallax mapping (so no tiles set through editor), you're essentially swapping continuous tile drawing for one parallax background (or... you know, images). If you use no plugins, there are these things you have to take note of:

ShaderTilemap and Tilemap now calculate tile positions etc. for no particular gain. Maybe you'd want to remove tilemap and shader tilemap, or at least the drawing functions, since whole tilemap removal is tough, because it contains important children - characters.
Other than that there are no real changes. The drawing still goes the same way and SceneManager.update and SceneManager.updateScene are still the two main functions that get called and start all that ruckus around.

Pro tip: Use directional passability! I have a tileset specifically for directional passability.
The X, O etc. are my direction markers, but I use empty tilesets underneath them. And why do I have two? One is for normal use, one is for bushes. The rest of them is in the second half.

 

[dbchest]

in your example above, you maintain normal character movement then? no pixel movement?

 

[Andar]

Pixel movement and parallax mapping are two entirely different things.
They can be combined, but that depends on the developers wishes and is not a technical requirement. On the contrary, even with pixel movement the events are usually restricted to the grid because removing all grid restrictions would require you to implement pixel collision as well as pixel movement.

That said, one of your first steps should be to decide what features you want to include.
As already said, the simplest forms of parallax mapping do not require any plugin, you can simply use parallax background and show picture events.
A plugin is only needed for additional functions like a lighting layer or so.

 

[Poryg]

Yes, no pixel movement. There was no talking about pixel movement after all, only parallaxing

 

[dbchest]

i understand parallax mapping and pixel movement are separate, but i have seen many projects that utilize parallax mapping also utilize pixel movement because parallax maps do not generally conform to grid alignment (unless the artist considers it during the design process) and unless you utilize some form of pixel movement the player tends to move unnaturally in an otherwise natural environment.

how about we talk about pixel movement for a few moments? does anyone have any insight on what could be considered "popular" methods of approaching a pixel movement plugin?

 

[Poryg]

My favorite pixel movement plugin is Quasi movement, but that one is demanding on cpu power. However, the ability to define custom colliders is nice
Just mentioning it for inspiration, since I don't really use pixel movement. But the most difficult part about pixel movement are collisions.

 

[gstv87]

The parallax is always processed along with the map, from the beginning.
The update sequence updates parallax, tiles, characters, events and pictures (don't know if specifically in that order) every frame.
Using parallax and tilesets is kind of redundant unless there's a portion of the screen that is supposed to be the background (no tiles, thus, transparent).
If you design the map with tilesets and it occupies the whole screen, having a parallax will only put more work on the processor.
If you only use parallax and no tiles, it could work a little faster..... it remains to test if the size of the image affects the processing, because I know how laggy it can become when working with large images.

for pixel movement, I don't think you need large plugins for that (except for things like registering interactions with events, if you have other event-based plugins working along with that)
I mean, the engine always accounts for pixels, it just considers lots of pixels (16,32,48,etc) when calculating movement.
Just override that grouping, and you should be set.

 

[Poryg]

Actually, I've done quite a bit of testing on this.
Having one sprite of 1024x1024 takes almost no time to process. Having 1024 1x1 sprites takes enormous processing power. It still isn't enough to drop the FPS. But if you double the size, you'll notice the difference between a 2048x2048 sprite and 2048 1x1 sprites.
The reason for that is exactly the amount of operations from one sprite vs. 1024 sprites. So having a parallax will always be faster than using tileset. If you use PIXI, it will be even faster, but from what I've seen, MV uses PIXI to draw Parallaxes on screen by default (it just uses Javascript to both load - which I was drawn to understand recently, and generate - which I still don't get why; instead of generating texture through js and then using new PIXI.Texture they could just do PIXI.Texture.fromImage instantly - the texture ).
Of course the tilemap is designed pretty well, so it's not as heavy on the cpu as it would be without any optimization, but MV's tilemap spends time recalculating tiles positions, while parallax background is just a tiling sprite. Of course tiling sprite means constant recalculations of the frame, but again, you're recalculating only one image, not 600 tiles. And quite surprisingly, size of one image doesn't matter too much. It will affect loading times, however tiling sprite always renders a particular area (mv's parallax background is defined to Graphics.boxWidth and Graphics.boxHeight), so it's never rendering more than the screen area.

 

[gstv87]

Having one sprite of 1024x1024 takes almost no time to process. Having 1024 1x1 sprites takes enormous processing power.

precisely my point.
I still don't know what the minimum size of sprite is, that it wouldn't justify to just merge a couple of them into one larger sheet.
for instance, if the engine allocates equally 10mb of memory for a 1x1 or 100x100 sprite, then it's always safer to make the sprites *at most* 100x100.
that's the problem being discussed over at the preloading thread.

either way, 1 image is always faster to process than 2 images, CPU-wise, because of how the engine is set to update them (sequentially one after another)

 

[Llareian]

Twice now it's been suggested to remove tilesets completely, but if you do that, wouldn't you HAVE to include a custom collision method? I mean, if you have no tilesets, you can't define a collision tileset, right?

 

[gstv87]

you could make it work with regionID, although it would require some tweaking of the movement functions to account for that.
or, you can include a simple blank tileset.... for the purposes of using the logic of the object tileset, the object will still exist with a standard bitmap property, or a non-standard bitmap property.
it just won't show as it should, which you wouldn't mind since you're not using it for the looks of it.

 

[Poryg]

MV gathers collision data upon movement from flags saved inside tileset. If you completely remove tilesets, then yes, you need a custom collision method. But you can define it using MV's flags. Although I think I might define my own collision method, because I'm quite lost in the tileset flags. That is the place where I'd love a greater level of customizability of Map000.json files (well, you can customize them as you like, but an edit of the map and save will kill your edits). Because I defined for example a variable that contains data about water placement on maps. While it would be great if I could just implement it to Map.json without fear of it disappearing. But well, nevermind

 

[dbchest]

yo. you guys are on a different level entirely. XD

 

[Quxios]

Here's a few things I'd consider:
1. (previously mentioned) Disable the tilemap / don't render the tilemap. It's unneeded in most parallax. You can keep the tilemap data in the $gameMap for collisions, but no need to render it in the spriteset.
2. Implement culling. MV and pixi don't have any culling. Culling can greatly improve performance when dealing with multiple sprites which with parallax mapping you should for proper layering
3. Marking parallax images are static/dynamic. Only add the dynamic images into an arr that loops through to call their update func. This can lower your loop size, or you can call different update funcs based on their mode, ie, dynamic can run an update with like animation updates while the static one runs a minimum one.
4. (obvious) Being able to set the position, anchor and scale. And don't get lazy on the anchor, set proper anchors!

 

[Poryg]

@dbchest Sometimes it scares me how I managed to advance in past month without even realizing it But don't worry, we'll be sure to help you get there. If there's one thing I like on programmers, it's that they stick together in need

@Quxios You don't need to mark images to be static or dynamic. Just use PIXI.Sprite for static images. Since I'm pixifying the entire engine, I will be only using PIXI.Sprite, PIXI.extras.TilingSprite and Sprite_Anim, which is a prototype of PIXI.extras.AnimatedSprite. Since PIXI.extras.AnimatedSprite has an update function, I updated it in Sprite_Anim so that it sets renderable to false once the animated sprite gets off screen to spare some power. It doesn't stop UpdateTransform though, it only stops rendering the sprite in places where you can't see it.
Although now that I think about it, I'll need to define one more sprite class for moving characters.

Also, what is culling?

 

[dbchest]

Also, what is culling?

@Quxios yes. do tell.

 

[Quxios]

@Poryg Yup that's fine, but I mentioned the marking if someone was to make it similar to mv and using mv classes. Then somewhere in there code they'd have a:

someArry.forEach(function(sprite) {
  sprite.update()
})

with the "marking" that someArry can be shortend since it'd only have the sprites that need their update called.
(love that you're rewriting mv to make it pixi based, I was disappointed when I found out how lil pixi is involved/how much they wrote over it)

@Poryg and @dbchest Poryg basically explained culling, so he's using it without knowing lol

...sets renderable to false once the animated sprite gets off screen to spare some power.

So it's basically to not render sprites that are offscreen. Even a poorly written one like adding an inbounds func to all sprites can still yield better results vs no culling when there's lots of sprites though it'll probably slow down when there's not much sprites or if all sprites are on the screen whole time.
For more info you can just search google for like "game dev culling" or one of the 2 methods "frustum culling" or " occlusion culling". Though you'll probably find mostly 3d related articles.

 

[Poryg]

Thank you for the explanation
True, culling function is useless when sprites are on screen or when there aren't too many static sprites. Maybe building an event listener would be better?
But it is true that as it is, the update function is abused by MV, which is already bad on map, but hideous in battle! Note: Every sprite has an update function, so if you want to add culling, not the hardest. Just add this chunk of code to Sprite.prototype:

if (Math.abs (this.x - this.width) > Graphics.boxWidth || Math.abs(this.y - this.height) > Graphics.boxHeight) {
this.renderable = false;
}else {
this.renderable = true;
};

But I'd recommend to just throw the default sprites anyway if you're parallaxing and reformat it. More work, but it will be much cleaner. And whatever it takes, edit Scene_Battle, because the lags are hideous.

 

[gstv87]

I've been thinking lately, that *maybe* it would be faster if the validations weren't based on conditional checks, but on function results.
if the function is set correctly, it will always return something that could be read as true or false, removing the need for a conditional.
the problem is, it would be a mathematical nightmare, because, relations, and absolutes, and square roots maybe.
in theory, anything can be written as a mathematical expression that would return 1 or 0, and those 1 and 0 read as true or false.









(in theory)