Colludium's Forum Posts

  • Thanks Mikal NetOne WackyToaster

    Update: I think that the web-worker issue I encountered previously was because I was testing in Chrome Canary - an update has fixed the problem!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Mikal,

    Yes - the size of the particle sprite is separate from the particle radius - by setting the default instance width/height in the normal construct way. Thus you can adjust both the sprite and particle dimensions to get the effect you're after.

    Getting the particles to render in the correct colors and to behave as one group was a massive headache, but here it is! :D

    The above example is just proof that the basic algorithm works. Of note, there is a slight delay when the sprite image texture is copied to an off-screen canvas and this won't be acceptable to everyone. So, I'm going to add methods so you will be able to obtain the image-to-particle data in a separate project from the game and then load the data into a particle system at runtime (array.AsJson, probably). Programmatic simplicity is the objective here, and I will include an image data extraction c3p example to demonstrate how it should be used.

    Edit: deleted web-worker compatibility paragraph. I think it was actually a bug in Chrome Canary...

  • Mmmm, if only there was a color picker for the editor.

  • newt - Yeah, creating a large group of sprites in the editor can be a pain. The plugin takes care of all of that behind the scenes, all you do is nominate the sprite type you want to use. The plugin then creates and moves instances to that type to the particle positions. Particles can only be created in groups in shapes (circle, box, polygon), with the polygon selection giving you the choice to derive the shape from an array.AsJson set of points or another sprite's collision polygon.

  • No promises - but inspired by Mikal 's example above, I'm looking into adding a separate set of particle system methods.

    Currently, when you create a particle system you can set a sprite to be used to render each particle. These are set by group or identified by a tag at creation. This means you can use different objects to draw different groups of particles, with or without running animations.

    What I want to do is analyse a sprite's image and then have the particle group create particles with color values to mimic the image. Because of a limitation of Liquidfun JavaScript, this color-particle option will not be compatible with the current way of drawing particles. However, most particles are small and using only one sprite image to render them probably won't matter.

    I need to have a good think about the system's versatility - if the reality is that people don't mind setting a particle group's color when a group are created (as opposed to identifying a sprite type to be used) then I may end up deleting the first set of methods. Then you'll just identify a render sprite once and then change the group color settings as appropriate. Or render group from an image...

    This is going to take a few days to work through. Just to let you know. And I have yet to test how SetUnpremultipliedColor() impacts on performance, so all of this might be nothing more than an experiment...

  • Mikal,

    That effect and its application are pure genius!!

    It is possible to also do this with LFJS, in the same way as in the example using the standard Physics - the behavior swap was easy and LFJS has similar performance.

    However, doing this with particles is an intriguing concept that I will look into today... I am not convinced it will be possible but it's definitely worth a look (particles don't have rotation, so each would have to be assigned one color from the large image - a photograph image may not work but some pixel art might well be ok).

  • Nearly there...!

    Interactive example: Demo

  • wow, nice!

    can your plugin create elastic particles, as in the original?

    Thanks, q3olegka

    And, yes - here's elastic/rigid becoming elastic/fluid (well, elastic / not-fluid...). Shape taken from the sprite's collision polygon:

  • WackyToaster / newt,

    Noita = Amazing!!

    It's hard to tell if the particles in Noita are from a port of Liquidfun or if the devs rolled their own version from scratch. Definitely c++ and some pretty amazing destruction effects.

    In LFJS you could do the physics destruction but the challenge would be to get the graphics to reflect the shapes you create. In LFJS you can set bespoke collision shapes from Array.AsJSON inputs using texture coordinates for a sprite, but there is no way in C3 to chop up an image and divide it into shapes (ie Canvas won't allow rotation, so that's no use here). The obvious work around would be to make your scenery out of already exploded sprite images, all carefully positioned to look intact, and then make them into dynamic bodies when they get broken off.

    To destroy objects in stages then you could add child objects to a parent body as fixtures (using the LFJS Assimilate joint) - first break off a parent and its children, then subsequently break off the children. There are limitations to this my plugin: you can't add a child object that is also a parent of other children - you'd have to be smart in how you designed your terrain/scenery destruction. Here's an example of progressive destruction using just this technique (it's to be included with the plugin). Be under no illusion - Noita is an amazing technical achievement!

  • Thanks noah,

    And thanks Nepeo . Eearcut is fast and is my polygon decomposition method of choice - it's proven reliable at breaking a complex shape into triangles so it can then be rebuilt into convex shapes. When I release I will be sure to explicitly document all known bugs - your advice about the disadvantage of delay is noted - thank you.

  • Thanks WackyToaster and Karentzos, I appreciate the support.

    I'm going include a simple function so that convex polygons with up to 8 vertices will definitely not get broken down, so you can design shapes that won't get decomposed and elicit this bug.

    I'm comparing two separator algorithms at the moment. One based on Earcut triangle decomposition and the other based on Poly-Decomp by Schteppe, both from GitHub. The each have their strengths.

    Then I've got some more examples to make, to demonstrate how to use the plugin. And then I'm running out of excuses to not release it...!

  • There's a bug with the Liquidfun library - when particles run along a surface that is made up of more than one adjacent fixture (ie when a concave or complex body is created and it has been divided up into separate convex fixtures). In this bug the particles appear to collide with the second fixture, even though the surface should appear continuous to the particles.

    I've reported it to google here but I don't know if/when it might get fixed.

    This is causing me to hesitate releasing the plugin. Depending on what you want out of the plugin, this could be a show-stopper...!

  • You need liquid particles and kinematic bodies - hold on a short while for my Liquidfun JavaScript (LFJS) behavior... :D

  • I'm using Chrome Canary at present, so if I have to clear my cache then it affects nothing in normal Chrome. I've also tried Firefox and Opera in the past - the latter is pretty good as well.

  • Hi. The isOnFloor returns true even if the behavior is disabled because there is no isEnabled check in the condition. dop2000 has correctly described how the isOnFloor will only return true if the player is exactly just above the floor object (inside the floor makes the plugin think that the player is stuck inside something and it then returns false).