Colludium's Recent Forum Activity

  • Thanks winkr7 - this should now be fixed.

    Update: v.0.0.8

    Bugfix. Particle system setting actions are all now clamped to value ranges iaw the Liquidfun c++ files and/or have been tested to not produce odd results.

  • Thanks for that bug report winkr7

    Update to v1.0.0.7

    Bugfix - indexing error in c++ library sometimes called particles out of buffer range.

  • winkr7 - I am glad the bugs are fixed.

    I think that the effect you are looking for is Alpha Clamp. It is most efficient to apply it to a layer instead of to each object/particle.

  • Mosenrat

    Thanks for the fix!

    Love it!! Thank you for your thank you!

  • Nepeo - thanks for the assistance. Yes - it was a memory leak: quite a basic error of mine in some of the cpp coding I wrote when I modified the standard library to create the particle uid methods. Every day is a school day...

    Update: version 1.0.0.6

    Bugfix: Fix a memory leak that caused some odd particle behaviours. I hope that his should have fixed the issues seen by Mosenrat and winkr7 - please let me know if I have more homework to do...! Thanks.

  • This project is currently on hold because of an undefined bug (Uncaught TypeError: Cannot perform Construct on a detached ArrayBuffer).

    Edit / Update: I think I have found the problem. I will post a fix later today.

  • OK Mosenrat and winkr7

    Thank you for your patience. I can replicate the bug you've reported in the current version of Chrome.

    Could I please ask you to try the following: install Chrome Canary link and run C3 in that browser, with LFJS, and let me know if you see the same problems in the demos?

    I am hoping that a recent update to Chrome has created a bug that will be fixed when a newer version of Chrome goes live.... The joys of browser based game engines...

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Mosenrat - Something else to try: does the exported demo work for you (especially after you press "3")? Demo

  • Mosenrat - Mmmm. That's certainly not meant to happen.

    If you check the console, are there any error messages?

  • winkr7 - The elastic strength changes the springiness of the particle system. There is no way to make the block appear any stiffer than setting 100 - this is a limit of Liquidfun. Try adding a Wait 2 secs and then changing the system elastic strength and you'll see that the particle groups become more or less strongly sprung together. The only way to stop them from deforming is to make them rigid particle groups. Particle groups can only become rigid if they are rigid on creation - this is a limitation of Liquidfun. If you don't want them to be rigid after doing that then just create them as rigid and then set them fluid - that way you can later set them rigid again.

    Here's a version of the demo that shows you the how to do the actions as described above: link

    For the Particles - Create Singles.c3p - make sure you are pressing left mouse down to create the particles. They are then created from the center of the screen towards the mouse position.

  • rraffo - No problem at all. I'm happy to field all questions about this.

    That demo was for Box2d+ and is asm.js, so the performance is far worse than LFJS. The similarity between LFJS and the standard plugin's performance was so close I didn't bother publishing the demo that's included as an example.

    LFJS doesn't have an image scan to collision polygon feature. It only has one to create particles in the shape and colour of a sprite image. I considered it to be too risky to include it from Box2d+ because of possible glitches, due to my inexperience with the c3 runtime. I might include it in future, but no guarantees.

  • rraffo - good questions.

    1) No. LFJS is not a replacement for the standard physics plugin. It is just an alternative with more/different features - especially comprehensive joints and particles from liquidfun.

    2) I very tentatively say yes. There are more features to LFJS, but how easy it is to replace one with the other totally depends on how many events you have used in your project. The general design is similar, so actions should be transferable with minimum fuss (unless you have 1000 of them...). The functions and events do not all have the same names and will not automatically swap, so it will be an event by event process.

    3) The standard physics engine is very fast, but the implementation is not complete in C3. LFJS has similar performance to the standard plugin (based on a similar library) but there are a few more lines of code in the collision presolve callbacks. So, techincally, I expect that, if you were to enable collision points in LFJS, then LFJS might ever-so slightly under-perform compared to the standard plugin. There is a stress test demo that compares a tower of blocks in LFJS to the standard physics plugin and, to my humble i5 laptop, there's hardly anything between them (I think the standard plugin takes the edge, only just).

    All questions are welcome. :)

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