R0J0hound's Recent Forum Activity

  • That bit of code just resolves overlaps between a bunch of circles that are the same size. Then to make it faster all the circles are first added to a grid spatial hash.

    So roughly it creates the grid spacial hash, adds the circles to all the grids their bounding box overlaps, then loops over the circles and uses the spacial hash to get other nearby circles, and finally it detects collision and pushes them apart.

    I don’t understand the question to have a rectangle instead of a square. You can make the grid of any size but it just needs to be the same size or smaller than the circle size.

    The layout size is used to have something to divide into grids. It could be made to reuse the same grids when objects are outside the layout. Probably by using x%layoutWidth or something.

    The angle is used for the push out logic for circles. Circles are the simplest to do that for. Using object bounding boxes instead are a bit more complex. Beyond that the push out logic would require some fancier algorithm such as SAT,GJK/EPA, MPR, SDFs,…etc to do the collision detection and resolving.

    If all you want to do is detect if two objects overlap it’s easiest to just use construct's js api overlapping function.

    That example was just tailored to a specific thing. It’s not really general purpose without a fair amount of modification.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • To predict a path basically involves repeatedly simulating frames to get the path. I think previous topics tried to simulate that, but I actually haven't tried your approach of using an impulse to simulate a frame.

    Here's the idea refined, and it seems to work great.

    The setup is to set the physics stepping mode to fixed. With that the time step is always 1/60. Then to simulate the path you'd copy an objects position and velocity and then with a loop use timestep*force for the impulse, and then manually advance the position with the velocity.

    dropbox.com/scl/fi/7o7pjwaffwty9n3u8dke0/perdict_physics_path.c3p

    You can use a larger time step but since gravity forces vary by position the resulting path will be approximate and diverge pretty quick. In the same way using framerate independent stepping mode the predicted path will vary a lot.

  • You’re welcome. I was thinking a bit more and since you can get the accuracy of some gps coordinates you can probably utilize that.

    Here’s some rough pseudocode of how the logic might look. The gps vars keep track of lat,lon,alt, and accuracy. 

    Start
— prevGps=getGps()
— TotalDist=0

Update
— curGps =getGps()
— Dist= calcDist(prevGps, curgps)
— If dist>(prevGps.acuracy+curgps.accuracy)
— — totaldist = totaldist+dist
— — prevgps = curgps

    You could probably get away with just using the current gps accuracy. But regardless be careful to use the same distance units for everything or be sure to convert them to be the same.

  • Lat longs give a point on a the earth which is approximated by a sphere. You can use spherical coordinates to convert the gps to xyz vectors from the center of the earth.

    X=radius*cos(lat)*cos(lon)

    Y=radius*cos(lat)*sin(lon)

    Z=-radius*sin(lat)

    If you then do a dot product between the two vectors you can find the angle between them. A dot B = len(A)*len(B)*cos(ang)

    And finally you can use the formula for arcLength = radius*angle to get a distance.

    That should come out to the following with two lat,Lon’s.

    dist = acos(cos(lat1)*cos(lon1)*cos(lat2)*cos(lon2) + cos(lat1)*sin(lon1)*cos(lat2)*sin(lon2) + sin(lat1)*sin(lat2))*180/pi*radius

    Where the radius of the earth is 6371 km.

    You’d probably want to add the average of the altitudes of the two points too. 6371+(alt1+alt2)/2. But I’m unsure how much that would change things.

    You probably could just measure the straight distance between two points instead. That would remove the dot product and arc length step.

    Dist = radius*sqrt((cos(lat1)*cos(lon1)-cos(lat2)*cos(lon2))^2+(cos(lat1)*sin(lon1)-cos(lat2)*sin(lon2))^2+(sin(lat1)-sin(lat2))^2)

    I factored out the radius but you could be more accurate using the altitude per point if you wanted.

    You could try to find a js library to do the calculation too. No idea if they’d be doing anything beyond what’s being done here.

    And just thinking aloud, but the gps coordinates have a varying accuracy so you might need to filter or smooth things out. For example if you’re standing still the gps coordinates may drift around by the accuracy amount so you’d get distance when you didn’t actually move. To filter you could only add distances longer than say a few feet. Or to smooth you could collect multiple lat Lon’s and average them before using it.

  • It still is jerky huh?

    To be completely smooth we’d want every frame to have the exact same frame time and no frames skipped. We have some control over that with how much logic and rendering we do per frame, but it can still vary per browser or machine. Btw I wasn’t really noticing much jerky motion with your game.

    It’s probably easier to notice the frame variance when moving things in straight lines with constant speeds.

    Anyways, only other suggestion besides using lerp like that to do an ease out, is you can give the camera velocity and do some math to do a damped spring to move the camera. Tune the two values from 0 to 1.

    Var vx=0

    Compare: dt > 0

    -- add -0.005*(scrollx-player.x)/dt-0.1*vx to vx

    -- set scrollx to scrollx+vx*dt

  • To make the ball motion smooth, just use the bullet behavior or "set x to self.x+1200*dt" instead of the tween every 0.5 seconds.

    Another thing to try is use lerp in a frame independent way.

    set scrollx to lerp(scrollx, ball.x, exp(-200*dt))

    or

    set scrollx to lerp(scrollx, ball.x, 1-0.001^dt)

  • You could replace the drag drop behavior with the car behavior and just disable it on all the instances but the head. Or just set the head instance (sprite.i=0) position to the car.

    Also currently it just pulls objects together if they are farther than 32 pixels apart. You can also make it push the objects apart if you remove the max from the move at an angle equation. I think that’s what you meant by squish together when braking.

  • Here's a behaviorless way to do it.

    First chain tries to replicate the stretch from pinning to pinned objects.

    The rest order from head to tail with an adjustable stretch stiffness.

    dropbox.com/scl/fi/yzrr05uk5ch8fex2hrqrv/chain_stiffness.c3p

    Might be useful or give some ideas.

  • Lionz’ suggestion is by far the easiest. Just put invisible sprites on the edges of the platforms, and have the enemy change direction when colliding with them.

    If it’s too laborious to place the sprites then there is likely a way to automate placing them, but it depends how you make your platforms.

    Another way could be to detect the edges of the platform with a small detector sprite. Say the enemy is moving right. Move the detector sprite to the bottom right corner of the enemy. If the detector isn’t overlapping a platform the change the enemy direction to left. You’d do similar logic for moving left. You could also use “pick overlapping point” instead of a small detector sprite.

    A third way could be just to pick the platform the enemy is on and change direction when getting close to the edge. Would work well if the platform is just one long object. Logic for the right edge would be the following. Left edge is similar.

    For each enemy

    Enemy overlaps platform at offset(0,1)

    Enemy: is moving right

    Compare: enemy.bboxright>platform.bboxright

    — enemy: set direction to left

    Fourth way would be to just use the sine behavior to move the enemy. Place the enemy at the center of the platform, set the magnitude to half the platform width, set motion to horizontal and wave to triangle. I’m unsure if position would drift over time though with different frame rates.

    There are probably many other possible solutions.

  • There is a system action: Set layout vanishing point

  • You can do it with physics forces. Take the sprite you want, and create a family “other” from that so you can reference two instances at the same time. Then do something like this:

    For each sprite

    For each other

    Sprite.uid <> other.uid

    — sprite: apply force 1/distance(sprite.x,sprite.y,other.x,other.y)^2 toward (other.x, other.y)

    If it’s too subtle the increase the value of 1. Try 1000 or 10000

  • Choose() will use one of the values at random. You probably wanted chooseindex()

R0J0hound's avatar

R0J0hound

Member since 15 Jun, 2009

Twitter
R0J0hound has 157 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