Quick question

[dr3adx]

Hello, is there an existing emitter that can spawn particles in circular motion? Something like ring except that all points should be on the outer edges of the circle not within. And I'd like to space them equally using something that "burst" type has i.e "particleDistance"

[andrewstart]

The ring spawn type is what you want, as you can set the minimum radius of the ring to the full radius, so that you end up with a circular line instead of a donut. However, it doesn't allow for regular spacing of particles, as only the burst spawn type does that.

[dr3adx]

The ring spawn type is what you want, as you can set the minimum radius of the ring to the full radius, so that you end up with a circular line instead of a donut. However, it doesn't allow for regular spacing of particles, as only the burst spawn type does that.

Thx a lot, btw is there any way to keep animations running once tab is minimized? Since im working on a game where its important. I was thinking of switching from pixi's ticker to setinterval but how would I update all currently running emitters from setInterval (code-wise)? Or do u think theres a better solution?

[andrewstart]

You could stop the PIXI ticker and then manually update it by calling its update() method, which would update everything attached to the main PIXI ticker. Otherwise, the emitters here are quite happy to have you call their update() methods and not be attached to the PIXI ticker at all. Note that the ticker and the emitters take different parameters to their updates - the current time in ms, and the elapsed time since the previous tick in seconds, respectively. I do find myself curious how advancing time in the background could be important though.

[dr3adx]

I do find myself curious how advancing time in the background could be important though.

I mean, if ur playing a game and minimize tab, u dont want player's animations to play once u switch back to the tab but rather play at all times even in the background while you have tab minimized, right? So you dont play animation that already happened in past or if you missed 50% of animation while minimized you should 'resume' seeing at 50%, that's why background advancing would be important, but maybe theres other ways to do this?

[andrewstart]

I'd want a useless UI animation before an action (like opening a loot box) to be done by the time I come back, but in general I'd want the entire game to be paused (except for those times when I am building the game and the window losing focus is because I am debugging something). To not play in the background but give the appearance of doing so, you could listen to the window page visibility API to save the last time the window had focus and then when the focus returns advance everything by that large amount of time immediately. If you don't take that route, according to the page visibility API documentation browsers do limit CPU usage of pages that are in the background, although it is unlikely that your animations would be heavy enough to run afoul of it.

[dr3adx]

I'd want a useless UI animation before an action (like opening a loot box) to be done by the time I come back, but in general I'd want the entire game to be paused (except for those times when I am building the game and the window losing focus is because I am debugging something). To not play in the background but give the appearance of doing so, you could listen to the window page visibility API to save the last time the window had focus and then when the focus returns advance everything by that large amount of time immediately. If you don't take that route, according to the page visibility API documentation browsers do limit CPU usage of pages that are in the background, although it is unlikely that your animations would be heavy enough to run afoul of it.

Okay I'm trying to implement your idea, however simply running emitter.update(2) to advance it 2 seconds doesnt do anything. So I was like maybe it accepts milliseconds instead so I tried 2000 but that finishes animation instantly. Does _autoUpdate need to be false before manually updating emitter?

[andrewstart]

It doesn't need to be (but should be). However, you may need to tell your PIXI renderer to do another render, because if your ticker is stopped it won't do it automatically. emitter.update(2) should be functional, which is why I am assuming the need for a render.

[dr3adx]

It doesn't need to be (but should be). However, you may need to tell your PIXI renderer to do another render, because if your ticker is stopped it won't do it automatically. emitter.update(2) should be functional, which is why I am assuming the need for a render.

Thx a lot, i got it to work. Btw quick question: what does "addAtBack" property do? What change does it bring whether particles are added at the back or at the front?

[andrewstart]

Default (false): uses addChild() when adding a particle to your designated parent, adding it on top of all current children. When true, uses addChildAt(<particle>, 0), adding the new particle beneath all current children. That's the only difference. With large, cloudy particles, adding at the back can look better because they don't appear to pop in. If you are adding particles to your main container with everything else, then addAtBack probably isn't good to turn on.

[dr3adx]

Default (false): uses addChild() when adding a particle to your designated parent, adding it on top of all current children. When true, uses addChildAt(<particle>, 0), adding the new particle beneath all current children. That's the only difference. With large, cloudy particles, adding at the back can look better because they don't appear to pop in. If you are adding particles to your main container with everything else, then addAtBack probably isn't good to turn on.

thx a lot, btw I thought I had solved problem with advancing particles by certain amount of time but my issue that i described before persists. The one where I advance emitters by certain amount of time after I focus on the tab after minimizing.

I do as follows:

         //advance is in seconds (e.g 0.6)
          e.autoUpdate = false;
          e.update(advance);
          e.autoUpdate = true;

But for some reason it just skips the emitter till the very end. Do you have any idea what the problem could be?

[andrewstart]

I do not have any ideas, beyond making sure that your advance value wouldn't naturally put the emitter at its end. Setting autoUpdate to false disables the code that messes with the delta parameter, so your input should be handled as straight seconds.