Colludium's Recent Forum Activity

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

    Ashley - That's great. I'm glad it helped and I hope this resolves the issue for everyone. 👍

    I have created a project example that repeatedly demonstrates this crash.

    Here's what it looks like. If you've lost work to this then you might want to look away... ;)

    Click to play if it doesn't do so automatically:

    Here's the project caproj:

    Crash test .caproj project

    Steps to reproduce:

    1) Open the project. Be patient, it can take a minute...

    2) Edit any sprite using the "Animations: Edit" in the properties bar (note, the open layout has no sprites in it, so memory use for this project is at a minimum).

    3) Close the sprite editor. If you're prepared to wait a minute then it might recover, but if you click on anything / try to close it again / click anywhere else then it'll drag up the windows crash popup.

    Things to note. C2 is using approx 152 Mb of memory with this layout open in the editor. After the crash and selection of "wait for the program to respond" then the reported memory use goes down to 20 Mb. Although C2 appears to have recovered, clearly it is not working properly...

    What's with the cycling through 150 sprites or so after initially closing the sprite editor...?

    Anyway, Ashley, I hope that this is what you need and it'll repeatably crash on your super-computer.

  • Update: v1.0.0.16

    Added new feature: Enable/Disable Particle System Strict Contact Checking.

    Strict contact checking is an option that ensures correct particle behavior when their fixture contacts are ambiguous. With this enabled the engine is more careful to make sure particle behavior is what you would expect, but at the expense of a CPU factor n*log(n): so only use this if necessary. Adding this feature removes one of the known bugs that was previously listed in the first post.

    There is a new demo added: Particle System - Strict Contact Check.c3p. This demonstrates the 'bug' and how enabling this prevents incorrect particle-fixture collision.

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