R0J0hound's Recent Forum Activity

  • Tokinsom

    I made this one recently, but corner bouncing can be a bit odd.

    The idea was to try to move horizontally then vertically. So first move the ball horizontally and if it then is overlapping a wall move out of the wall and invert the x velocity. To simplify moving out of the wall I just moved the ball back to it's x position before it moved, which looks good enough. The same is then done in the vertical direction.

    Overall it works great for horizontal and vertical walls, but as I said corner bouncing still can look odd. For more accurate corner bouncing we need to find what the ball hit first, a corner or an edge.

    Attached is another capx example. To make the bounces even more accurate we just need to improve the normal detecting events. The only complicated looking math is in event 11 when speed_along_normal is set. It's doing a vector dot product which gives us the speed in a certain direction. One thing you can do is check if the ball is touching a corner by seeing if the distance between the ball and a corner is near the radius, then in that case the normal would be the angle from the corner to the ball.

    Anyways just some ideas.

  • The problem is an interface in the editor to define lines with a start and end point isn't really possible in c2's editor. We're limited to how sprites and other objects can be placed and manipulated. Another issue is behaviors can't draw anything in the editor as I recall. A way to do it from events could be done but it's not quite as user friendly.

  • The path editor part is not possible to do in C2's editor, so a c2 version of this is not likely.

  • Prominent

    Tilemaps aren't properly supported yet. There is some special handling for tilemaps in the built in physics behavior, but there's a few other internal things I want to tweak before implementing it. As of right now it should work with at least sprites and tiledbg.

    I'd like to add lines but I need to think of an intuitive way to do it. I'm leaning toward just another collision shape type, along with a radius (which can also be applied to polygon and box btw). If you mean something else or have any ideas of using lines that wouldn't be handled by my idea, let me know.

    Thanks for the report on using forces, it was working but I may have broken something with an update. I'll be sure to take a look after the holidays.

  • Update #6

    * Fixed the crash on nodeWebkit tumira SgtConti

    * Reworked it so changing the size/animation will change to collision shape automatically. As a result I removed the "Update collision shape" action which is no longer needed.

    * Fixed "pick nearest segment query"/"pick nearest point query" so it would work right when multiple object types are used.

    -Merry Christmas

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Colludium

    That's pretty cool it performs that good. It's better than I expected.

    A bit of an update with supporting things in the list.

    1. This is kind of doable now. You can cancel the acceleration from gravity by applying force -mass*gravity in the "pre step" trigger

    5. You can get collision info now with the "on post collide" trigger.

  • update #5

    * added preStep trigger. With it you can effectively stop any acceleration due to gravity by applying a force in the opposite direction.

    * added "on Post collide" trigger. With it you can get extra info about a physics collision such as:

    • contact points, normal, depth, impact, total energy and uid of other object.

    tumira

    Ah cool, that's the same bug that SgtConti was getting and I can reproduce it with NodeWebkit. I'll try to debug it tomorrow. Firefox and chrome are working fine though.

  • If you're interested in another physics behavior I've been working on one based on chipmunk2d here:

    It already has more features than the bundled physics behavior, although I'm unsure how it compares performance wise. It's beta but I've fixed every bug I've found so far, however it just needs more testing.

    Comparing it to your list it gets about half of them right now.

    1a It currently has collision groups and layers

    1 not currently, but it's a simple change to get it working.

    2 It has every joint chipmunk2d has to offer.

    3 Not currently. I can add segments with a radius as another collision shape so you can just use objects. Other than that I'm not sure of a good workflow, but I'm open to ideas.

    4a not directly but a pivot and gear joint together should work. It is possible to give bodies multiple shapes in chipmunk.js but I haven't come up with a good workflow, so only one shape is used.

    4 It can do ray tracing with line segment queries currently.

    5 Not yet. I'll add it to my todo.

  • Update #4

    * Forgot a few expressions: forceX, forceY, inertia, angVel

    * Added Actions/expressions for angular and linear speed limits.

    * Added tagging to the constraints, so now you can reference them later either by the tag or an index.

    • along with that you can set the set the max force of a constraint.
    • also you can destroy individual joints

    * Added a pointQuery and segmentQuery conditions along with appropriate expressions. Can be used to find the closest shape to a point or for raycasting.

    I think that's about it, I probably forgot a few things.

    Current todo:

    * Polish ACE table

  • Update #3

    * Added expressions for everything and more actions to set object properties including:

    -elasticity, friction, collision shape, mass, collision groups and collision layers.

    *Added simulation settings:

    • stepping mode: fixed or variable

    -set fixed mode timestep

    • set iterations

    -set damping

    * Added enabling/disabling and the ability to set immovable or not.

    Right now if you change the object size or animation you have to manually tell the shape to update with the "update collision shape" action. I'm not sure if I'll change that... If I make it automatic you'd have a performance hit with animated objects.

    Other than that all the functions seem to be working without errors. Feel free to try it out and let me know if you encounter any bugs. The main thing left to do now is polish up the ACE names and descriptions.

    SgtConti I've re-tweaked a lot internally so I'm not sure if that bug was squashed.

  • indiegrimes

    event 1:

    every time the number of pixel objects is 0, have the two images swap layers and...

    event 2:

    Do a loop to cover the objects with pixel sprites. They are sent to back so the overall order looks like this:

          +--- s1 sprite: blend: source in
      |
      +--- pixel sprites
   ___|______
  /   |     /
 / layer 1 /--- force own texture: yes
/_________/
      |
      +--- s2 sprite: blend: normal
   ___|______
  /   |     /
 / layer 0 /
/_________/[/code:18u4e1c5]

Events 3 and 4
set the blend mode for the image sprites depending on what layer they're on.

event 5
Destroys the pixels one at a time.  The repeat is so it goes faster than 1 pixel per frame.  The equations should simply be SPEED*60*dt where SPEED is in pixels per second.

  • VictoryX

    I made a capx with a lot of different approaches here: