Colludium's Recent Forum Activity

  • Thanks Mikal - I think I'm going to have to do some experimenting...

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I suspect that behaviors are sandboxed so they cannot access the object they are appended to when in the editor, but I'll ask in the hope that I am wrong. Is it possible for a behavior (editor instance.js) to access the parent object's IWorldInstance?

  • newt - you only added a pseudo-warm-up method - did you forget to add the other features using events? :p

  • Performance is a good question and it depends on what you want your particles to do...

    Presently, the performance on my i5 laptop for the demo above with Arnie has 450 particles, each with 8 animation frames with bounce off solid enabled, and it uses 3.5 ms to control all of the particles each tick. Not a lot, but a lot greater than zero... I'm about to look at a render version of the plugin that has the same properties but only has one image (like the standard Particle plugin). Performance should be much better, but animations will not be possible. Swings and roundabouts...

    Fade in - not sure. I don't want it to be possible for particles to last for ever if fade-out destroy is selected but particles only fade in. Let me ponder this one.

  • In c2 it is possible to draw a quad of texture1 onto texture2 by using: 

    glw.setRenderingToTexture(renderToTexture);
glw.setTexture(textureToPaste);
glw.quad(...args);

    Is this possible / supported in the c3 sdk? Thanks.

  • I guess it depends a little bit on what you want to do with your programming. I've tried python and c#, dabbled in cpp, but my favourite remains JavaScript.

    Some of the reasons why I like it are that browsers have many features you can access (like files API) so it's easy to make something useful, you can easily debug your code using the console and there are literally hundreds of good sites to learn from. If you want a good tutorial to start with then try free code camp. It's where I started and I think it's excellent.

  • 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.

Colludium's avatar

Colludium

Member since 26 Aug, 2013

Twitter
Colludium has 11 followers

Connect with Colludium

Trophy Case

  • 11-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • x3
    Coach One of your tutorials has over 1,000 readers
  • Educator One of your tutorials has over 10,000 readers
  • RTFM Read the fabulous manual
  • Email Verified

Progress

18/44
How to earn trophies