R0J0hound's Forum Posts

  • cool

  • Mayfly

    The difference could be a lot of things. I have no definitive answer because I haven't taken the time to break it down and test it further.

    The prediction is based on an exact collision point, but the physics behaviors never collide at that exact point. Typically the collision occurs after the shapes are overlapping. So the objects are pushed apart first and then the collision point is used, but that likely is a bit off. There are a bunch of other little things such as the pushing out could be over several frames and there may be a tolerance to allow a little overlap.

  • One possible explanation would be events are not converted to JavaScript, instead they are converted to a bytecode of sorts that is interpreted by the runtime which in turn calls the functions in plugins and the runtime. CC did basically the same thing.

    Now JavaScript engines are really good at analyzing js code and generating fast machine machine code on the fly. That's how js performance can often rival a compiled language. My thought is the events bytecode is basically data and the javascript engine is unable to streamline the data as it does code.

    A fairly complicated solution could be to compile the event sheet to javascrict. Sounds simple but probably is a huge can of worms.

  • Mayfly

    The way you're calculating the expected direction could be off. Also increasing the simulation iterations could improve it.

    I've gotten a close before, but not completely exact which I attributed to the collision time being approximate.

    Unfortunately the capx is very wip and is left in incomplete state. Also it's a chunk of math to calculate the collision time and the result of a collision which I am no longer familiar with.

    https://www.dropbox.com/s/yz18begzbo294 ... .capx?dl=0

    Also here is some reading on the math it was based on:

    http://www.real-world-physics-problems. ... iards.html

    I just realized the capx uses the built in physics and not chipmunk if that matters. It's from an old attempt at the problem and I probably won't have the time to refine it. Basically it would be perfect if we replicated the physics simulation and advanced the simulation to see the path.

  • Hi,

    Sorry I won't be updating this plugin. Ideally webgl and canvas would be the same, unfortunately the canvas would require a bit of creativity to solve.

  • I like to use this expression:

    (var>0)-(var<0)

  • numbers are 64bit floating point values. You probably can get all the info you want by googling that.

  • Just to add, that is a geometric series and if you didn't have the floor there is a formula you could use to calculate the sum of any number of them without a loop:

    https://www.varsitytutors.com/hotmath/h ... ric-series

  • The code looks at each line segment and toggles the selection of the points below them. It toggles it instead of setting it because it matters how many line segments are above a point. Basically if you take any point and draw a line straight up, and then count how many lines crossed you'll know if it's inside or outside. Odd:inside, even:outside.

  • That's basically just manually doing the platform behavior, since it's the platform behavior that makes the objects act solid.

    Basically once the object overlaps a wall, you'd move it out in some direction till it's not overlapping. If the object isn't overlapping at its old position then move toward there. The other case is if you just place the Sprite in the wall, and it should just be moved to the closest open space.

    That's only the first part. After that try moving horizontally then vertically to get to the place it was overlapping. Of course just stopping short. When moving horizontally and it hits a solid then set the horizontal speed to zero. The same for vertical. Without this part the object would just stick to walls. When moving vertically you can find when the Sprite is on the ground, and there is where you'd simulate a jump if the jump key is pressed.

    Slopes would need some extra logic when moving horizontally, and moving platforms would need some logic too. It just depends what you need.

    Also here's an entirely different idea I posted elsewhere before. It still uses solid but makes a duplicate of the layout in a different location.

    https://www.dropbox.com/s/i1vr8srq201gw ... .capx?dl=0

    Here's the topic it's from. Maybe one of those solutions will help.

    ignore-selected-solids-workaround-list_t167029?&hilit=Disable+collision

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • That's probably the way to do it, even from JavaScript.

  • I somehow missed you wanted the lowest value. Sorted it will give the highest value with pairs or probably triples. For the lowest you could reorder the array every possible way and try each one to see which is lowest.

    I have a capx that does it that I can provide tomorrow if you want.

    edit:

    Here it is. It tries every combination and eventually gives the order with the lowest value:

    https://www.dropbox.com/s/ajbvvy32cwd8m ... .capx?dl=0

    The algorithm is O(n!) and the implementation is also slow. With 9 values it takes like 10 seconds on my machine. and gives this answer:

    1*8*9 + 3*4*6 + 2*5*7 = 214

  • lires

    There is a third party plugin already.

  • Turns out you don't need a recursive function to try all different orderings of the numbers. Instead just sort the list first and just multiply and sum them in order.