R0J0hound's Forum Posts

  • C2 considers a sprite mirrored if it's width is negative, so you could use (sprite.width<0) in your expressions to see if it is mirrored.

  • Hmm, I seemed to have missed your last reply.

    The math is the capx is simplified for just horizontal ground. The first step would be to make it work with any angle. Actually you can do this by taking the velocity and using a dot product with the angle of the surface to get perpendicular and parallel velocities that can be plugged into the equations already there. That covers getting the bounce math to work.

    Next the collision detection and resolution would need an overhaul. This is what keeps the football from falling through the floor at low speeds and lets us know when to bounce. It is also what gives us the point of collision. Right now we have oval vs horizontal line working. New would be oval vs any line. The math there isn't too pretty which explains why ovals aren't usually a common shape in physics libraries. Also you'll need to work out the formulas. Either that or use the iterative approach.

    Ok, next we need oval vs oval collision detection. The simplest solution is to convert the oval to a polygon first. Then you'd take the two ovals and see if they overlap. If they do we need to separate them till they collide at only one point. The two ways to do this is to either move backward in time to they just touch, or use something like SAT or GJK/EPA to move them apart.

    That just covers the simple case of only one moving oval and everything else is static. For collisions between two moving objects the bounce math now needs to use the relative velocity (Va-Vb) between the two objects instead of just the velocity of one. Otherwise the stuff above is more or less the same.

    One caveat is when there are multiple objects that need to be pushed out of each other, then correcting one pair can push them into other objects. This is usually solved by repeating this check multiple times to reduce the amount of objects overlapping. You'll also want to make collisions faster by checking if the object's bounding box is overlapping first, before the other more costly oval-oval collision check.

    In summery you will be creating a full blown physics engine. I have roughly outlined one approach, but there are many tweaks that improve speed and accuracy.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Also from those expressions you can get the total speed with:

    distance(0, 0, sprite.physics.velocityx, sprite.physics.velocityy)

    You'll need to use system->compare or system->"pick by comparison" to compare it.

  • Run it with the debugger and look at the object counts, they are increasing constantly. You need to move the events that create them to be a sub-event of start of layout.

  • One way to do it is with the overlapping at offset condition. So say the ai sprite's size is 32x32 you could do this:

    [inverted] ai is overlapping ground at offset (-32,32)

    --- ai set angle to 0

    [inverted] ai is overlapping ground at offset (32,32)

    --- ai set angle to 180

  • jogosgratispro

    For a 10x2 array for example, you'd have to swap around not only array.at(curX), but the other values too. But no matter, just use the sort action and don't worry about it.

  • I don't think you need to worry about this. Loading of arrays, even gigantic ones, is negligible, and even then it's only done once. When it comes to arrays the only way it would slow things down is maybe if it's enormous (millions of values or something) and your events loop over it every tick.

  • Using a detector sprite is usually the way to go for keeping grid motion from going into walls. You could also just check the position on the tilemap to see if it's empty (-1).

    You can find some ideas ideas on how to only moving a certain number of squares by searching for "turn based" or "dijkstra".

    I have an oldish example that does that here:

    but the more recent topic here about flood fill pathfinding would be more useful to you:

    Finally your capx is running slow because it's creating all the wall objects every tick.

  • Functions are the typical way to do that, unless you had something else in mind.

  • Colludium

    I can confirm the bug. You can re-arrange it without an else to show the "or" is the only issue:

    every tick:

    --- set text to false

    mouse is overlapping tiledbackground

    -or-

    sprite is overlapping tiledbackground

    --- set text to true

    For me the second condition in the "or" block is always ignored.

  • imothep85

    To keep them from overlapping each other it's the same solution as with the pathfinding behavior:

    ElChuchis

    It's hard to see with those gifs but the way I had it setup is the LOS behavior had a range of about 200. So the waypoints should be less than 200 pixels apart. If a dude hits a waypoint and it can't find another waypoint in LOS within 120 degrees of the direction it won't get a new target, so it will orbit it's last target.

    In mine I also made the bullet behavior bounce off solids to avoid cutting through the buildings. In your gifs that looks to be happening.

  • Here's an idea. You can use the bullet behavior to move the people and the LOS behavior to pick a node to move to.

    https://www.dropbox.com/s/i6s5ga63ws7qv ... .capx?dl=1

    /examples33/city_walk.capx

  • This is the difference between an actual trigger and a fake trigger.

    "on key press" is an actual trigger and is triggered when the key is pressed.

    "on button pressed" is a fake trigger and is the same as

    "button is down"

    "trigger once"

    More info here:

  • Just make the objects global and destroy them at the start of the first layout.

  • The idea above it to save the velocity, move, then set the velocity from the saved one. Basically the reason fro this is moving the object changes the velocity, which can be useful for things like using dragndrop to throw physics objects.

    Alternatively the chipmunk behavior works fine with the wrap behavior by default.