Colludium's Forum Posts

  • Update: Beta v1.0.0.4

    Change: Primary reference to each particle is now the particle UID (an LFJS-unique reference to each particle handle in Liquidfun). The deprecated expressions that change query index to buffer index have been altered so that thier output is compatible with the action changes, so there should be no problem migrating from the previous version.

    Actions changes:

    All of the actions now input particle UID instead of particle buffer index.

    Conditions additions:

    For each particle query loop.

    For each particle in group loop.

    Expressions changes:

    CurrentUID: the UID of a particle in a for-each loop.

    QueryUidsAsArrayJson: the particle query list of UIDs for an array input.

    GroupUidsAsArrayJson: the list of group UIDs for an array input.

    ParticleUidFromSprite: use the particle sprite UID to obtain the particle UID.

    ParticleUidFromBufferIndex: in case you wish to loop through the buffer index, use this to obtain the particle UID.

    Work to do:

    Next is to investigate direct setting of particle velocity via an action. This may not prove viable because the whole library is not designed to work this way. But it might be ok...

    Thanks Nepeo for the inspiration.

  • Success!! I've written c++ methods to transmit all of the particle handles/UIDs to the plugin in an array. And it's fast (0.1 ms for 3000 particles), so no problem using it during runtime. Now I'm going to attack the ACEs so that the current Actions that use buffer index will become deprecated: in future, the only way you'll be able to identify a particle will be by its handle/UID. This is going to take a little while, so please be patient.

  • Nepeo - thank you, I really appreciate the feedback!

    I must confess to being quite the amateur when it comes to compiling and working with webassembly. I have had some success at writing and building with my own methods that weren't written into the original Liquidfun cpp (like the set particle color as above), but more complex tasks like accessing the particle handle buffer array have proven problematic.

  • Nepeo - indeed - static indexes would be so much easier! I'm still trying to find a better way of keeping track of particles. The handle at first seemed like the answer, but they are only released on demand and only then one at a time. Getting buffer arrays to pass from cpp to JavaScript isn't my strong point, so it'll be a while before I get any success there, I think.

    Update:

    Version 1.0.0.3

    Added feature:

    Action: SetParticleColor(bufferIndex, red, green, blue, alpha)

    Expressions: ParticleRed(bufferIndex), ParticleGreen(bufferIndex), ParticleBlue(bufferIndex) and ParticleAlpha(bufferIndex).

    So now it's possible to change particle colors by reference to their previous color (if required) using their buffer index reference.

  • SIMPLE Games - that's about the sum of it, although small iterations might cause odd behavior (so be careful with those settings). Minimise use of particles and other physics objects and avoid creating/destroying bodies during runtime (no sprite animations on a LFJS body, for example). Optimisation for mobile is a big challenge for a JavaScript game engine, even when webassembly is being used.

    I'm about to write my own cpp methods for changing particle colors. I'll let you know how it goes...

  • And to add to the above:

    In LFJS, particles are referenced each tick by their Index (buffer index). If no changes are made to the number of particles in a system then each Index -should- reference the same particle between ticks. But this is not guaranteed (and is specifically mentioned in the cpp documentation as not being guaranteed - the library might change things around).

    Secure and tick-proof references to a particle do exist and the class is callede b2ParticleHandle. These are a bit like UIDs in that each Handle is unique to the particle system and remains attached to its particle. So far I have tried to avoid using Handles so that the plugin doesn't become overly complicated (ie you couldn't use a Handle in any of the current impulse/velocity actions and, if Handles were introduced, then all of the actions that input a buffer index will have to be duplicated in case you want to use a handle instead).

    Looking through the cpp for Liquidfun and it's clear that the example in the video was highly modified - there are no methods to directly control particle color on an individual basis (after creation), so they must have been programmed by the cpp guru who made the video.

    Not impossible and I'll take a look, but if we are going to track particles between ticks then Handles come into play, with all of the added complexities that this would mean for the plugin.

  • SIMPLE Games - thank you for the bug report!!

    Update now Beta v1.0.0.2, bugfix: render error when not using tint effect.

    That video is interesting - it looks like the full desktop version of Liquidfun, judging by the performance. The programmer has used a few things that are not currently available in LFJS, if my guess is right.

    1. Assign a color change to an individual particle. This should be possible in LFJS - I will check the source code and write the cpp headers to make it possible.

    2. It is possible that the example uses particle-to-particle collision and collision energy to allow a decision to be made as to whether to change the color of the particles to white. This option will not be available in LFJS because of the massive overhead called during each world step.

    3. Alternatively the programmer has stored the velocities of each particle and made them color white when there is a large velocity change (ie due to an impact).

    4. I don't think the example uses color mixing because the water doesn't get whiter and whiter with time - it always blends back to blue. Which means that the programmer has applied a general blend-back-to-blue color change to the whole particle system/group. That could be very expensive in LFJS because of the calls from JavaScript to webassembly.

    I will see what changes I can make to allow individual particle color-assignment and, maybe, group or system color assignment.

  • WackyToaster - Of course, you could do all of this with events and/or with JavaScript scripting (which is all any plugin is, after all!).

    Like other plugins, this one is a plugin of convenience - there is minimal set-up time and just one point of entry for controlling the particle system. It is also easily transportable between projects compared to one's typical project events for an equivalent control system.

    Also, I enjoy the logic battle of making plugins!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Particles2 is a world plugin that uses controlled sprites as particles, so they can be animated, rotated, colored etc. Most of the settings are available in the editor properties (no need for event setup). The example above used an extra 4 color fades that were input in the on start of layout event.

    Many of the inputs containing multiple values that are separated by commas. How does this work? Well, most are a means of entering min and max values to determine an on-spawn random number. For example, the Timer entry has "a, b, c, d" where a and b are the min and max delay times for the random delay that happens before any fading starts, then c and d are the min and max values of the random fade out time.

    The plugin supports sprites with "Tint" effect, which gives better performance (but no Tint is also supported).

    Bounce off solid is also supported, as is a 30 fps option. All of the random numbers can be spread linear or pseudo-Gaussian between the min and max values.

    This is still a work-in-progress and some options might yet change, but I've been wondering if there are any suggestions for features that I should add. Thanks.

  • Here you go - a plugin to get/set a sprite's collision polygon: link

  • Get, edit and change a sprite's collision polygon. This one's a freebie - enjoy :)

    Link to itch.io

    Physics use is not supported. I don't recommend you use this with Physics, but if you feel you must... after you've loaded the new collision polygon, you'll have to change the sprite size for one tick (to trick Physics to recreate the body and detect the new shape). One pixel should do it.

  • The LFJS plugin allows you to edit the collision polygon for the box2d physics engine (so you can create shapes on the fly).

    I made a plugin for c2 that did this (a long time ago); I'll convert it to c3 soon.

  • Update to v1.0.0.1

    Added support for particle sprite Tint effect control.

    You can now add the color Tint effect to the particle sprite and the plugin will then opt to use that to control the particle color. This is much faster than the previous color method, but it does have one limitation: if your particles are semi-transparent (ie alpha < 100%) then Tint might be slower. The plugin auto-detects the presence of Tint and you can override its use by a new Action. The Particles - color and shape from image demo contains an example of this action in use.

    Still in beta, but fingers crossed for a stable release soon...!

  • When a world object is created in a layout, I'd like to be able to make adjustments to the drawn image depending on some of its property values. If the object is copy-pasted then these may not be set to the defaults, so how can I obtain an object's properties in the OnCreate() function? Thanks.

  • Thanks for confirming this Mikal

    Bug report logged here.