Colludium's Recent Forum Activity

  • Hi there. I recommend either Option 1 or you could disable Platform2 and use events to make the knock-back effect.

  • Construct 3 Physics uses the 2.3.1 wasm version of Box2D. The problem you have found is actually a feature of Box2D (at least the javascript version). When using framerate independent time-steps, each time-step is fed into the engine as a delta-time value that is slightly different to the previous delta-time (down to many decimal places). Box2D physics doesn't like that sort of varying time input, and that is why the objects never come to rest when the gravity is large.

  • Thank you indeed, Nepeo - those were the wise words I needed to help me isolate this.

    Update: Version 1.0.0.19

    Bugfix: Removed use of globalThis which may have been causing problems in Safari.

    Tombas - I hope this fixes this problem.

  • You can get them all on github.

  • Thanks Mikal for the reassurance. Tombas I think that it must be a problem with Safari. This wouldn't be the first time that Apple products were not compatible with the Mozilla standards... Sorry but I don't think there's anything I can do to stop this from happening.

  • Hi Tombas

    I haven't tried using a Mac, although I can't see why the variable globalThis couldn't be found. I haven't seen anything like this before. Out of interest, are you able to test in a different browser (ie Chrome vs Safari, although I'm not sure if any differences could be the cause here)?

    Nepeo - sorry to bother you, can you think of a reason why globalThis wouldn't be declared when previewing on a Mac? This has me stuck... As far as I can tell, the implementation in my plugin is similar to that of the standard Physics plugin, so there's no reason I can think of as to why the variable wouldn't be declared. Thanks.

  • Thanks Ashley - Wow, that's a long time! I only found out by trying to debug one of my plugins that wasn't compatible with the closure compiler, so I put the exported runtime.js through the online minifier and the code analyser identified it.

  • r276, in common_prelude.js file:

    In the set_from_poly function, as below (error is on line 6): 

    CollisionPoly_.prototype.set_from_poly = function (r)
{
	this.pts_count = r.pts_count;
	cr.shallowAssignArray(this.pts_cache, r.pts_cache);
	this.bboxLeft = r.bboxLeft;
	this.bboxTop - r.bboxTop;
	this.bboxRight = r.bboxRight;
	this.bboxBottom = r.bboxBottom;
};

    The 4th line should read: 

    this.bboxTop = r.bboxTop; //ie equals not minus

    The so-what is that this error could cause collision overlap checks to fail.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Update: v1.0.0.18

    Bugfix. Added preventative method to ensure that destroying a particle sprite doesn't cause the plugin to crash.

  • WackyToaster

    OK, I've made some progress with trying to understand these problems.

    ParticleBug.c3p. The bug where a particle moving to a negative position < -12,297.21 is because of how negative numbers are stored in binary (the particle falling upwards eventually exceeds the store limit of a float32). There is nothing I can do about this: it's a limit of the engine.

    ParticleBug2.c3p. When I made the plugin I hadn't anticipated this behavior. You can create multiple shapes of particles, each shape can be given the same tag so they all associate inside the same particle group. However, if you destroy all of the particles in the group (as in this example) then the next particle creation in that group causes the engine to fail. I don't know why this is (yet) and I'm still looking into it. The work-around (for now) for creating groups in a cycle like this, is to use a variable to set the group tag and increment it after each creation cycle (see linked example).

    discrepancy.c3p. This problem was caused by the same fault as above. See the example - by changing the particle group tag then the problem can be avoided.

    grouptagmaxcountissues.c3p. This appears to be another feature of the engine: if you try to create single particles totalling more than the max count limit then it causes a crash, but only if you create them in a new group in one game step cycle (tick). I think that it doesn't happen if naming the group "A" because the max count has already been initialised. I'll take a look to see if there's a way of editing the library to fix this (that won't create an overhead).

    Here are the adjusted bug examples with the workarounds I mentioned: link

  • WackyToaster - Thanks for the new c3p examples. I'm taking a look to see why you're finding this odd behavior. So far I have not been able to determine what's causing the issues.

    Some things that the plugin does that are worth bearing in mind:

    All actions should happen after an On World Pre-Step. This is because, otherwise, actions can accumulate. For example, you can't delete a particle twice if you use this condition. Same for applying forces and impulses to objects.

    The 529 vs 530 is caused, I think, because one of the particles is not being destroyed. If you look at the particle count every tick then that might show 1 when there should be 0. I have not tied down why one particle is not being destroyed.

    The sprites that indicate particle positions are not the particles. So, when a particle is destroyed (literally, a particle is a memory block of position and color inside the plugin) then a sprite is used to draw its position. Every tick the particle sprites are used to indicate particle positions. If any are left over (because particles have been destroyed) then they are place at -1000,-1000 to save the overhead of destroying the sprites. Then, if more particles are created in the next tick, the spare particle sprites are moved to indicate each new particle's position. Every tick, a particle sprite is allocated a particle to represent, but the particles and sprites do not correlate over time and the sprites will change which particle they represent (depending on the particle buffer array).

    The clean up sprites action is to remove these extra sprites. Let's say you have a large number of particles and then destroy them, knowing that there will be no more particles - use that action to remove the sprites that are in stasis.

    Once again, thank you for the examples. I will let you know when I have a solution.

  • WackyToaster

    From what I gathered online nobody bothers fixing any of this, at least not from the liquidfun-side :I Maybe you have an idea on how to work around it.

    My first look into this isn't promising. There appears to be a problem in the webassembly code that manages the particles, which means that the c++ has an error. It's going to be a bit of a nightmare to debug - I'll try to narrow down the cause by trial and error and keep my fingers crossed. One appears to be y position related (which doesn't make any sense) and the other appears to be associated with multiple destroy and create actions. Both are challenging... If I can identify the real cause (and thank you for those bug demos, they're a great help) then I can maybe edit the c++ to fix them.

    That being said, I´m having a ton of fun playing around with it and I hopefully can manage to make an actual game around it :) Btw. is there a way to set the particle density/dampening for individual spawns and not globally?

    I am really glad you're enjoying using it. I had a ton of fun putting it together. I hope you do get to make a game, it would be really good to see the plugin in action. I'll let you know if I get anywhere with these bugs...

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