Liquidfun JavaScript - LFJS - [behavior]

  • WackyToaster - Sounds like it could be a bug. What do you do that makes the sprite vanish, with NaN showing in the debugger?

    Thanks for the Velocity Y type-o: that'll be fixed in the next update.

    The action to set acceleration XY allows you to set acceleration without having to first obtain the object's mass and then apply a force (to make it easier to move a player around, for example).

  • Quick question. Does this work well with the Solid behavior?

  • Quick question. Does this work well with the Solid behavior?

    It is Solid behavior agnostic. So the answer is yes and no, depending on what you hope for... :)

  • I don´t do more than apply some force to it when you press a button.

    wackytoaster.at/parachute/buggy.c3p

    I found that even other objects set to static not tied to the event can just disappear along with the sprite. Really odd.

  • WackyToaster - thank you for that bug demo.

    Update: version 1.0.0.17

    Bugfix. Applying an Acceleration XY caused an error. I had updated the emscripten bindings to improve performance and missed editing this function in the plugin.

  • > Quick question. Does this work well with the Solid behavior?

    It is Solid behavior agnostic. So the answer is yes and no, depending on what you hope for... :)

    Like Physics.

    Physics does not work with solid.

  • newt - that's correct.

  • That was quick! Thanks :)

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Colludium

    Found another odd bug that causes the game to freeze. I think I figured out the exact conditions... that is basically particles that go up and out of the screen and end up on a Y position lower -12000.

    No big deal, I really don´t need them up there actually, I think I can just destroy any particle that goes farther than -5k anyway, far before it gets to any problematic values. But if you come around fixing it I wouldn´t be mad either.

    Or so I tought. Hmm... Maybe I´m just doing something wrong?

    From what I gathered online nobody bothers fixing any of this, at least not from the liquidfun-side :I Maybe you have an idea on how to work around it.

    wackytoaster.at/parachute/particleBugs.zip

    That beeing said, I´m having a ton of fun playing around with it and I hopefully can manage to make an actual game around it :) Btw. is there a way to set the particle density/dampening for individual spawns and not globally?

  • WackyToaster - I just saw this and will take a look.

  • WackyToaster

    From what I gathered online nobody bothers fixing any of this, at least not from the liquidfun-side :I Maybe you have an idea on how to work around it.

    My first look into this isn't promising. There appears to be a problem in the webassembly code that manages the particles, which means that the c++ has an error. It's going to be a bit of a nightmare to debug - I'll try to narrow down the cause by trial and error and keep my fingers crossed. One appears to be y position related (which doesn't make any sense) and the other appears to be associated with multiple destroy and create actions. Both are challenging... If I can identify the real cause (and thank you for those bug demos, they're a great help) then I can maybe edit the c++ to fix them.

    That being said, I´m having a ton of fun playing around with it and I hopefully can manage to make an actual game around it :) Btw. is there a way to set the particle density/dampening for individual spawns and not globally?

    I am really glad you're enjoying using it. I had a ton of fun putting it together. I hope you do get to make a game, it would be really good to see the plugin in action. I'll let you know if I get anywhere with these bugs...

  • Good to hear! I´m pretty sure I can reasonably work around the -12k thing if it happens to be unfixable. For the destroying, I also think I probably won´t really need it for what I have planned so I think I´ll be fine either way, but obviously fixing it would be great.

  • I (maybe) got some more information on the memory out of bounds thing.

    First of all, the system max count of particles appears to be minimum 256. Even if set to 100, it will spawn up to 256 particles regardless. I don´t think this is what causes the error though (and I don´t really mind it)

    The second thing however are some discrepancies of created/destroyed particles that may lead to the issue.

    1. The spawnbox I have creates 530 sprites every time... EXCEPT the first time particles are created, where it only creates 529.

    2. The first spawn also seems to overlook the first created particle in the destroy action. So one particle will not be destroyed despite fulfilling the conditions. I nailed this down to the conversion of LFJS.ParticleUidFromSprite, it simply seems to be one off. If I add a LFJS.ParticleUidFromSprite - 1 it will destroy all particles but not the last one. (These particles keep flying until reaching the -12k issue)

    3. Destroyed particles are not actually destroyed, they are placed offscreen at -1000X -1000Y (I assume they are "stored" for reuse). Now if I just go ahead and check to destroy particles that have a Y lower than 300 it will permanently attempt to destroy those, just nothing happens since LFJS.ParticleUidFromSprite returns -1.

    As such I think I figured out the correct way of destroying particles is to filter out all particles that are exactly -1000X -1000Y (that is fine since naturally that will never happen, and even if probably not cause much issues) then use a for each sprite loop AND also use trigger once (Though I´m not sure why the trigger once is important, but it is required. I also tried using the pre world step trigger but that didn´t do anything)

    There is an action to clean up these unused sprites (destroy spare sprites) though I didn´t quite figure out a good place to put it. It usually seems to add issues and I don´t think in my case it will be useful. Either way, the discrepancy with the first spawn beeing one off still exists.

    4. There is also a weird correlation with this issue between the system max count aswell as Particle group tags. It´s a bit hard to explain. Basically if Group tag "A" causes particles of group tag "B" to despawn due to max count settings it will throw this error. If both tags are the same, it works fine. It also works fine even with different groups as long as the max count setting is "amount of newly created particles + 2"

    My conclusion is that this "ghost particle" is likely the root of that issue.

    See these two new projects for debugging.

    wackytoaster.at/parachute/particleBugs2.zip

  • WackyToaster - Thanks for the new c3p examples. I'm taking a look to see why you're finding this odd behavior. So far I have not been able to determine what's causing the issues.

    Some things that the plugin does that are worth bearing in mind:

    All actions should happen after an On World Pre-Step. This is because, otherwise, actions can accumulate. For example, you can't delete a particle twice if you use this condition. Same for applying forces and impulses to objects.

    The 529 vs 530 is caused, I think, because one of the particles is not being destroyed. If you look at the particle count every tick then that might show 1 when there should be 0. I have not tied down why one particle is not being destroyed.

    The sprites that indicate particle positions are not the particles. So, when a particle is destroyed (literally, a particle is a memory block of position and color inside the plugin) then a sprite is used to draw its position. Every tick the particle sprites are used to indicate particle positions. If any are left over (because particles have been destroyed) then they are place at -1000,-1000 to save the overhead of destroying the sprites. Then, if more particles are created in the next tick, the spare particle sprites are moved to indicate each new particle's position. Every tick, a particle sprite is allocated a particle to represent, but the particles and sprites do not correlate over time and the sprites will change which particle they represent (depending on the particle buffer array).

    The clean up sprites action is to remove these extra sprites. Let's say you have a large number of particles and then destroy them, knowing that there will be no more particles - use that action to remove the sprites that are in stasis.

    Once again, thank you for the examples. I will let you know when I have a solution.

  • All actions should happen after an On World Pre-Step

    Hehe yeah I figured that one out when I tested for framerate independence and things went bonkers :D In this particular case for deleting particles it didn´t seem to have any effect though while Trigger once made sure things happen properly.

    Good to know that particles and the sprites exist somewhat independent from each other.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)