best way to create random scrolling parallax stars in phaser?

[BdR]

What is the best way to create random scrolling parallax stars using phaser? Btw I mean random stars so not a parallax scrolling tiled map.

 

I want to create this old demo effect with parallax stars scrolling vertically as the background in my game. There will be several layers of stars to create a nice illusion of depth. So there are larger stars in front which move faster and smaller star in the back which move slower. Also, it should use as few resources as possible so it won't interfere with the overall performance of the game or the frames per second.

 

What I've come up with so far looks ok but I suspect it may not perform well, see code in link below

https://github.com/BdR76/phaserparallax

 

It's basically doing this:

1) put all star sprites in a phaser.group

2) for each update() subtract counter -1 and add new random star if counter<0

3) add star with random scale 1.0 through 0.1

4) for each update() subtract y with scale for different speeds

 

 

Any thoughts or optimisations? Maybe it's less performance intesive to use tweens? If so how?

[JakeCake]

In the perfect world a filter would give the best result & performance, but it comes with the cost of not working on older browsers as shaders are WebGl only. Native shaders can do amazing stuff at very high frame-rates, but WebGl shaders are still somewhat edgy and doesn't give the speed of OpenGl in my experience, yet they should, so it might just be my system.

 

Depending on your target system, the amount of stars and quality/randomisation you're looking for, a filter might be the way to go.

 

Take a look at http://glslsandbox.com for examples, they integrate very well into pixi filters.

[InsaneHero]

To modify your approach very slightly:

- set the desired total number of stars at the beginning

- instead of 'create a new star when counter reaches zero', move stars that move off the bottom back to the top... optionally resize it

 

If you really want layers (bigger at the front) then you need to create several Groups to hold the sprites in different layers (probably faster than mucking about with the display list priority order)... so you could have

bigStarsLayer

medStarsLayer

smallStarsLayer

as three Groups and add all stars to the appropriate group when you pick the size.

 

However... stars cross quite rarely and if they're the nice bright white ones you've shown in that image, it won't be very obvious which one is in front or behind.  So I'd tend to just use a single layer for them all.

 

Following the recent 'Time' changes in the new dev build, tweens are processed as part of the renderUpdate instead of the logicUpdate.  This means that if you use tweens then even if the game's frame-rate starts to stutter, the stars will continue to move smoothly (unless the frame-rate gets so bad that the renderUpdate is held up too of course).

 

I don't think tweens are much (or at all) more efficient than coding the movement yourself, however they do have the nice benefit of 'set and forget' and a very handy 'onComplete' callback to tell you when they've finished and need to be reset to the top.

[BdR]

In the perfect world a filter would give the best result & performance, but it comes with the cost of not working on older browsers as shaders are WebGl only. Native shaders can do amazing stuff at very high frame-rates, but WebGl shaders are still somewhat edgy ..

 

You mean a star field like this?

http://glslsandbox.com/e#21149.2

http://glslsandbox.com/e#21027.1

 

My "target system" is cocoonjs and Android devices, so it's like you say there will probably be some compatibility issues. Also, I want to use sprites/pictures and not just shapes. So pictures of bubbles or leaves or clouds and not just shapes like dots and circles (the stars was just an example).

 

To modify your approach very slightly:

 

Good point, the problem with my current example is also that it starts with an empty screen. I'll make an example with groups, and then when a star reaches the top, just reset it within its current group back to bottom at a random x-position.

 

Using 3 groups might be too few, in my current example there are 10 layers which give a cool feel of depth. So I'll try with 5 groups or something like that to see how it looks.

[rich]

I would use a SpriteBatch for the best possible speed on WebGL. The only consideration you need is that they all share the same texture and are drawn in sequence, beyond that they are blisteringly fast.