Liquidfun JavaScript - LFJS - [behavior]

Post reply
4 favourites

  • Colludium

    thanks lots. So the inputs are still from 0 to 100 (except damping which is 0 to 1)?

    yours

    winkr7

  • winkr7 - yes - all particle system settings are 0 to 100 apart from density and damping (which are 0 to 1 to remain consistent with the rigid bodies).

    Cheers.

  • Update: v 1.0.0.11

    Bugfix. Error when calling body property action (density, restitution, friction).

  • Update to v1.0.0.12

    Bugfix

    Spelling mistake in en-US.json file.

    Destroying a sensor after a Wait delay, when it was overlapping a body, caused a crash.

    OnBeginContact and OnEndContact were called for each fixture. Now fixed so that OnBeginContact is only called once until both bodies have separated and OnEndContact is only called once after both bodies have completely separated. This only really was a problem when a sensor object was overlapped by a body that had multiple fixtures.

  • Colludium Hi, I rewrite my game from Box2DPlus to LFJS and It works very well :-) ... I have some questions:

    1) Previous behavior has "linear velocity clamp" and "max velocity", how to made speed limit with LFJS?

    2) What are best practises for framerate-vsync independent results. Games like Bridge Contsructor works same everytime... I am using "fixed step rate" & "60 step/sec" & trigger "lfjs on PreWorldStep" when apply my force/impulse & C3 system "Set minimum framerate to 50 FPS"... and I think it works :-D ... any other tips?

  • Playing with adding a procedural noise effect to the particles. Adjusting the procedural noise texture offset parameters based on location gives a sense of movement/rotation/animation. Also adjusting color based on x,y, and gravity. Looking for more ways to use this with particles going forward.

  • Hi Tombas - glad to hear it's going well.

    To answer your questions:

    1) I may add a velocity clamp in future. Before then, you can obtain the VelocityX and VelocityY of the body you wish to speed clamp from the expressions.

    Then get the angle of travel, using VelAngle = angle(0, 0, VelocityY, VelocityX).

    Then get the absolute velocity using VelocityAbs = distance(0, 0, VelocityX, VelocityY).

    Let's say your clamped max velocity is MaxVelocity, then the final velocity will be VelocityFinal = clamp(VelocityAbs, 0, MaxVelocity).

    To apply this to the body then use action Velocity at angle to set the velocity to VelocityFinal at angle VelAngle.

    I may add this in future but I'm working on something else in the plugin at the moment. Hope this makes sense?

    2) You have all the correct settings there. Other tips would be standard for C2/C3 - minimise jank by avoiding creating/destroying large numbers of objects at any one time, etc.

    Thanks.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Mikal - loving that effect!

  • Update to v1.0.0.15

    Code tidying to improve the begin-contact and end-contact data tracking.

    Bugfix - one of the conditions wasn't working.

  • Is there a way to measure particles' velocity (or velocity change) yet? To simulate more realistic water I mentioned earlier. Sure I can compare velocity change for each sprite, but that's heavy on performance

  • SIMPLE Games

    You can obtain the particle velocity using its UID and the ParticleVelocityX & ParticleVelocityY expressions.

    For performance reasons the plugin doesn't obtain the particle velocity buffer unless one of these expressions is called. Then the velocity buffer is obtained for all particles for that tick. That data then remains stored in the plugin for that tick, in case you make any other calls to obtain the velocity values of other particles. That way the velocity buffer is only accessed once per tick - to minimise the overhead of talking to the webassembly module.

  • Thanks

  • Update: v1.0.0.16

    Added new feature: Enable/Disable Particle System Strict Contact Checking.

    Strict contact checking is an option that ensures correct particle behavior when their fixture contacts are ambiguous. With this enabled the engine is more careful to make sure particle behavior is what you would expect, but at the expense of a CPU factor n*log(n): so only use this if necessary. Adding this feature removes one of the known bugs that was previously listed in the first post.

    There is a new demo added: Particle System - Strict Contact Check.c3p. This demonstrates the 'bug' and how enabling this prevents incorrect particle-fixture collision.

  • Saw this on Utube

    youtube.com/watch

  • Colludium

    I finally found a reason to try it out but I found something strange.

    If I do this, the Sprite just vanishes. The debugger puts its position on NaN. I actually can get around it by using Force XY instead but I suppose that´s not exactly the intended behavior.

    Also, for Velocity X the description states "The Y velocity" and for Force XY it states Y twice, just a copy&paste oversight :)

    Oh there is also Force at COM that works exactly how I need it. But what is Acceleration XY then? Since it also states "plugin applies a force to the center of mass"

Post reply
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)