Colludium's Forum Posts

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

  • WackyToaster - I just saw this and will take a look.

  • matriax - That doesn't make any sense. Box2D+ has not control over your GPU, and the draw calls are made by c2's webgl renderer (and not Box2D+). I just tested it and found no difference in the use of my GPU.

  • newt - that's correct.

  • WackyToaster - thank you for that bug demo.

    Update: version 1.0.0.17

    Bugfix. Applying an Acceleration XY caused an error. I had updated the emscripten bindings to improve performance and missed editing this function in the plugin.

  • Quick question. Does this work well with the Solid behavior?

    It is Solid behavior agnostic. So the answer is yes and no, depending on what you hope for... :)

  • WackyToaster - Sounds like it could be a bug. What do you do that makes the sprite vanish, with NaN showing in the debugger?

    Thanks for the Velocity Y type-o: that'll be fixed in the next update.

    The action to set acceleration XY allows you to set acceleration without having to first obtain the object's mass and then apply a force (to make it easier to move a player around, for example).

  • matriax

    I don't know how to do what you're trying to achieve. There is no such feature to box2d that I am aware of. You could position a distance joint anchored on the swingarm and to the body above the swingarm, with the distance set to greater than the anchor spacing. Then add another one anchored below. That way the distance joints will act as a spring, always trying to center the swingarm. But I have not tried this and I have no experience of making machines like bikes using box2d, so it may not work.

  • matriax - That example video looked good. I think that, for a game, you don't need to accurately replicate everything about a vehicle's suspension if it looks about right. I guess that if you want it more realistic then you could use revolute joints to joint suspension items together, with the pivots at the same place as per a real setup. You'd need a distance joint or two to give the spring bounciness of suspension as well. It all depends on what effect you want to achieve.

  • matriax

    That looks great!!

    Unfortunately it is not possible to modify the distance joint parameters with the library I used for this plugin. It's not broken, it is just not a supported feature - it doesn't have the js to asm.js bindings that are required to make it work.