R0J0hound's Recent Forum Activity

  • This old one still works, although it could be cleaned up more.

    construct.net/en/forum/construct-2/how-do-i-18/parabolatracjectory-tracing-55313

    Here's a cleaned up version. The y acceleration is the gravity*50. Why? because the units with the physics behavior are wonky aka scaled. It will still be off slightly from the physics behavior's path and I figure the only way to make match perfectly would be to use js to load box2d, set it up identical to how the physics behavior uses box2d, run n amount of simulation steps.

    dropbox.com/scl/fi/htkostz6pa29v65ytxzh6/perdicted_path.capx

    Here's a test to figure out the differences of the physics behavior units.

    dropbox.com/scl/fi/f8pecd2r8hrltfh2z3zhn/physics_units_compare.capx

    Finally if you want to set the acceleration from a force you'd do it like this:

    mass = density*area /50

    acceleration = force*50*50/mass

    The density is the mass property in the editor.

  • There isn’t really any specific 2d game related uses of those math functions. It’s easy to shotgun possible uses but it won’t cover all cases.

    For leveling up you could go with whatever strikes your fancy. The player won’t care if you use exp(), some simple multiplication level to level or some other curve.

    Generally there are more than one way to do things.

    Most of the functions such as exp(), ln(), and log10() aren’t needed unless you are using some formulas you found online.

    Unlerp() isn’t really used much. Last place I’ve seen it used was with a scroll bar but in general I’ve mostly just used the math behind it.

    Anyways. Most math functions and operators have too many possible uses to list. I usually go the other way, decide what I want to do and figure out how math can be utilized to do that.

  • Probably too many to list. Math functions and operators are just so you can use any formula you can find. Depending on what you do they all can be used for game dev.

    But as a small example: log is used to convert the sound volume decibels to percent and vise versa. Another use for log is when converting a large number into 10b for example.

    The exact formulas can should be able to be found by a forum search.

  • Hi. The wall collisions are done with signed distance fields (SDF). Basically I just treated each wall as a line segment along the width with a radius of half the height.

    Anyways doing it with the sdf of a box instead is possible too. I just didn’t do it here. Although you can find some other posts where I do sdf collision examples in the meantime.

  • To record the collision velocity you’d put an every tick event at the end of the event sheet and set some variables from the player’s velocity there. This will give the velocity of the previous frame which is pretty close to the velocity when a collision happens. As you’ve already found out you can’t get the true velocity when you collide since the behavior already resolved it.

    The bounce is unreliable in my example for a few reasons. The bullet bounce action doesn’t always work well, using the previous frames velocity may not be good enough, and the platform behavior may be causing less bounce with how its internal logic works.

    To calculate the normal the most accurate would be a complex algorithm like SAT,Gjk, or Mpr as long as you can access the collision polygons of both. If you can approximate the player as a circle then another good way would be to represent the terrain as a SDF.

    Simpler approximate ways include doing a ray cast in the direction of the velocity before the collision, or sampling points for overlap around the player. Simpler still you could just sample four points around the player to see if you’re on the ground, next to a wall or below a ceiling. Then you could do the bounce if say you’re not on the ground, have a wall to your left and the x velocity is <0. Then you’d do logic similar for a wall to the right or above the player.

    It may also help to reduce the deceleration when in Jetpack mode so the motion is more floaty. There are probably more ways you can fiddle with the platform behaviors settings.

    Another idea which would take more work to do but give more control is to not use the behavior and do the motion with just events.

  • Should work now.

  • There are a few ways you can go about doing the bounce. But since you are using the platform behavior it's easier to work around that.

    Here's one idea. It has a second object with the bullet behavior, that you update the position and velocity from the object with the platform behavior. Then when that bullet behavior object hits a wall, you can bounce and transfer the velocity to the other object. Seems to work reasonably well.

    dropbox.com/scl/fi/vfpccikywdi5itdvn5h4q/platform_bouncy.capx

    It may be possible to have both behaviors on the same object and do some juggling where the bullet behavior is mostly disabled and the platform behavior's velocities from the previous frame are saved into variables.

    You can also cut out the bullet behavior completely and do the bounce calculations directly. You'll still need to save the previous frame's velocities to variables. The main downside is you'll need to get the normal angle of the collisions which is something not provided by construct. There are ways to calculate it but for simplicity it's nice to just use the bullet behavior's bounce.

  • You can do it with something like this. When the player collides with a wall, just compare the y velocity and move the zorder above or below the wall. 

    player: on collision with wall
-- compare player.8direction.vectorY <0
-- -- player: move zorder in front of wall
-- else
-- -- player: move zorder behind wall

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Offhand the use of trigger once with multiple instances sounds suspect. Idk for sure.

    Something like this should work fine. 

    start of layout
for each sprite
-- tween sprite to x,y

    Whereas this one will cause trouble. As soon a one tween finishes that sprite alone will move again (or as many that finished that instance). And after that it won't run with and other sprites that finish tweening. The only way to reset it is if none of them are finished tweening. 

    sprite: tween is finished
trigger once
for each sprite
-- tween sprite to x,y

    I'm not sure if that's what the tweening aces look like. I haven't used them.

    If you can avoid using trigger once and do something like this instead it would work better. 

    [negated] sprite: tween is tweening
for each sprite
-- tween sprite to x,y

  • Sounds like you are close. I have found using two Booleans to mark, and then visit the boxes works well for a flood fill like you are after. I use one family to be able to pick different instances at the same time.

    dropbox.com/scl/fi/av1nhfj6kuwgq59g4tdco/connected_boxes.capx

  • Here's one idea. It just takes the current velocity of the player and manually simulates future frames till a wall is hit. Could be further refined to move the landing out of the ground, but as is it seems to work well enough. You can ignore the shadow stuff, was trying a random idea.

    dropbox.com/scl/fi/6r8f40bd7yoqy38bps633/platform_shadows_and_landing_perdiction.capx

  • I don’t have any idea what’s going on there.

    The plug-in is meant to have only one instance and any 3d object creation is done in the same way as the examples. There is no limit to when you can create stuff. I cannot guess how you manage to get it to clip.

R0J0hound's avatar

R0J0hound

Member since 15 Jun, 2009

Twitter
R0J0hound has 155 followers

Connect with R0J0hound

buymeacoffee.com

Trophy Case

  • 15-Year Club
  • Jupiter Mission Supports Gordon's mission to Jupiter
  • 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
  • Forum Wizard Made 5,000 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • Unrelenting Visitor Visited Construct.net 180 days in a row
  • Continuous Visitor Visited Construct.net 365 days in a row
  • RTFM Read the fabulous manual
  • Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

28/44
How to earn trophies