R0J0hound's Recent Forum Activity

  • If math can be equated to cooking, it’s easier to list good recipes than list recipes that contain a certain ingredient. Maybe you’re more after some useful math formulas that aren’t covered with the expressions provided in construct.

    Here’s a partial list of the ones I find useful on a regular basis. They aren’t covered by expressions normally. Admittedly a fair amount have to do with physics and a few geometry problems. But they can be useful. 

     // speed and angleOfmotion from vx,vy
speed = distance(0,0,vx,vy)
angleofmotion = angle(0,0,vx,vy)

// vx,vy from speed and angle of motion a. 
vx = speed*cos(a)
vy = speed*sin(a)

// it is also possible to represent directions as a unit vector (an xy vector with a length of 1) instead of with angles. so with a general velocity of vx,vy you can get the speed and direction vector with:
speed = distance(0,0,vx,vy)
dirX = vx/speed
dirY = vy/speed
// doing that gives the advantage of eliminating sin and cos from the formulas if you so desire.

// bounce angle a along normal n
a = 2*(n+90)-a

// velocity along a direction a
vx*cos(a)+vy*sin(a)

// stop velocity along an angle a. 
vrel = vx*cos(a)+vy*sin(a)
vx = vx - vrel*cos(a)
vy = vy - vrel*sin(a)
// multiply vrel by 2 to to make it bounce instead. 1.5 would be a half bounce...etc

// velocity of a point px,py on a spinning object with position x,y velocity vx,vy and angular speed w. 
velocityX = vx - (py-y)*w*pi/180
velocityY = vy + (px-x)*w*pi/180

//distance from line to point. with start sx,sy and angle a and point px,py
abs((px-sx)*cos(a-90)+(py-sy)*sin(a-90))
// remove the abs and the sign will give what side of the line youre on. 

// closest point on line segment. from point px,py to line segment x0,y0 x1,y1
t = clamp(((px-x0)*(x1-x0)+(py-y0)*(y1-y0))/((x1-x0)^2+(y1-y0)^2), 0, 1)
position = lerp(x0,x1,t), lerp(y0,y1,t)
// remove the clamp to treat the segment as an infinite line. 

// normalize an angle to the -180 to 180 range. 
angle(0,0,cos(a),sin(a))

// convert any angle to the 0 to 360 range
(a%360+360)%360

// signed angle differece between a and b. number of degrees between angles, but the sign gives the direction. negative for counter clockwise. More useful than constructs angleDiff expression. 
angle(0,0,cos(a-b),sin(a-b))

// rotate object a degrees around center cx,cy
set position to (x-cx)*cos(a)-(y-cy)*sin(a)+cx, (x-cx)*sin(a)+(y-cy)*cos(a)+cy
rotate a degrees clockwise

  • I think there is a split screen example/tutorial floating about that could be helpful.

    What you can do is use a canvas and paste stuff onto it. For performance the pasting is delayed till the frame draws, which leads to having to do juggling where you have to moving things into place, paste, and then wait a frame. At least last time I tried using it. Could have been updated since then.

    Another probably simpler idea is to just have the tv be its own layer and you’d just need to change the scale/scroll offset to move the rest of the game to fit onto the tv. You could do that with some trial and error I should think.

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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

  • 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