R0J0hound's Forum Posts

  • I'm not familiar with that game and I'm too lazy to google it. But anyways...

    Look at the mesh distort feature. You can animate the mesh points by moving them with events. The exact way you'd move the meshpoints is up to you and some artistic fiddling I suppose. Maybe you could use sin() or something to get a wavy motion.

  • After more tests I'm finding that stoppingDist=velocity*velocity/2/acceleration formula not well suited to stop on a fixed spot. You can compare it with the current distance to know when to start slowing down, but it will always be a bit late so it will overshoot the target position as you've seen. I also find it a bit annoying to have to handle the case where the velocity is away from the target.

    Anyways, here is one partial solution. For simplicity I'm just covering the case where the target is to the right of the position. I use a variable to store the state since we have to clamp the position and speed when moving. The result would be stopping at the target and discarding any remaining velocity. 

    if state=normal
-- //accelerate toward target
-- velocity+=acceleration*dt
-- position+=velocity*dt
-- distance2target = distance(position, target)
-- if distance2target < velocity*velocity/2/acceleration
-- -- state=slowing
if state=slowing
-- velocity= max(0, velocity-acceleration*dt) 
-- distance2target -= velocity*dt
-- position -= velocity*dt
-- if distance2target<0
-- -- position-=distance2target
-- -- velocity=0
-- -- state=arrived

    In a similar fashion it could be modified so when the state is changed to slowing we readjust the position/velocity as if it started slowing at the precise time between frames. That would make it so there was less to no velocity leftover when it arrives. However care must be taken to handle stopping short, so we'd probably need to check the case where the relative velocity becomes negative.

    Ideally all that fully implemented could be reduced to something simpler. In the end it would just be a linear motion so maybe just switching to an ease might be more user friendly.

    As an alternate idea you could try the Arrival Steering Behavior. That would be nicer in the 2d case as it would gradually turn before smoothly slowing down to the target. I had one issue with that though, the original paper basically relies on a fixed timestep, so when I added dt it made things overshoot more. As a fix I added a tuning factor to reduce overshoot. 

    https://www.dropbox.com/scl/fi/qoowuphapihsbvl0vg7lm/arrivalSteeringBehavior.capx?rlkey=quochzw7cd7fgp51elzqb2xx7&dl=1

    Another idea is to use a damped spring to do the motion. Pick a spring stiffness and then a damping so it's critically damped (aka no overshoot) and you're good. 

    https://www.dropbox.com/scl/fi/mjw9c25v91mezo18n7foj/dampedspringArrive.capx?rlkey=9rjkwlv09i5qc8uu17k89ucip&dl=1

  • A few thoughts:

    You want the object to start slowing down when it’s a certain distance away. That distance is probably hit between the last frame and the current one. You could solve for that distance and between the frames and start applying the acceleration then. You could do something similar when the target is reached.

    Another idea could be to adjust the acceleration to compensate since it will always start slowing down a bit late.

    Simplest would be to clamp the position to stop at the target so it doesn’t overshoot.

  • Simplest would be to just make an animation to do that. More complex would be to utilize distort meshes to make a piece of the object. You’d have to duplicate the sprite for each piece. Then set the mesh point xy to the edge of the shape used of the piece and the uv so that the image isn’t distorted. Doing that in a dynamic way is probably too complex so you could use a 3d modeler to chop up a quad into fragment polygons. They should be convex but you can have concave polygons in some cases. I think I’m only scratching the surface on how that could be done. There’s a lot of busywork and smaller puzzles to solve. So again it’s probably easier to do an animation or just draw the smaller prices. Or you could draw the object to a canvas and use a blend mode to mask out the part you want.

  • Should be the same with the same file. But I don’t know what the editor is doing. Anyways, keep at it. Maybe you’ll spot the difference. I’m not at a computer so I won’t be able to help.

  • I can’t debug it. So if it’s the same file I’m guessing it should give the same result as the hex editor. If it’s completely different then it seems like a different file or something is completely off.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Just use a grid hash or a AABB tree or something if you want it to work with objects being positioned anywhere. Or since you’re building the quad tree on the fly you could guess the bounding box of all the objects, build the quad tree and anything out of bounds is put into a simple list and the correct bounding box size is calculated for the next frame. If things are moving the new bounding box would still be a guess but it would be pretty close.

  • Roughly you’d load the file into the binaryData object instead of text. Then you can access individual bytes. You’d have to convert the byte value to hex to display as text. Then after changing the hex text you’d have to convert back.

    So something like this. 

    Start of layout
— Ajax: set response to binary BinaryData
— Ajax: request url “” as “data”

Ajax: on “data” loaded
Repeat BinaryData.ByteLength times
— text: append function.byte2hex(BinaryData.GetInt8(loopindex))

On function: updateBinaryFromText
— repeat len(text.text)/2 times
— binaryData: set int8 at loopindex to function.hex2byte(mid(text.text, loopindex*2,2))


On function: byte2hex
Parameter byte
— set return mid(“0123456789ABCDEF”, int(byte/16),1)&mid(“0123456789ABCDEF”, byte%16,1)

On function: hex2byte
Parameter hex
— set return to find(“0123456789ABCDEF”, left(hex,1))*16+ find(“0123456789ABCDEF”, right(hex,1))

  • Basically this? 

    function hex2dec(hex)
 — var num=0
 — repeat len(hex) times
 — — num = num*16+max(0, find(“0123456789abcdef”, mid(hex,loopindex,1))
— return num

    Btw your example is odd to me. W isn’t a hex digit.

  • Some tests of different physics integration methods with different timesteps. I included the platform behavior too to compare, but it just uses whatever dt currently is. It draws a nice graph to compare time vs y. The speed of the jump has to do with the timestep used, so it can be ignored. 

    https://www.dropbox.com/scl/fi/sluu3khqb1b0vzw5de0lu/integrationTests.capx?rlkey=0jjkfkcaww1evb03bs4fj9mpu&dl=0

    The results show that leapfrog, velocity verlet, and the platform behavior in c3 all have matching curves.

    You could do similar tests for the 8dir behavior vs an event based one.

  • It’s on Wikipedia.

  • The verlet you’re thinking of is slightly different. It infers velocity from position change which does work well for ropes and cloth.

    Anyways it’s something you can test either way.

  • Your math is off I think. Should be:

    (ScreenWidth-windowWidth)/2

    But You’re doing:

    (ScreenWidth-windowWidth/2)

  • Looks like that method is called leapfrog integration. It averages out changes to acceleration from frame to frame.

    Most behaviors use velocity verlet integration. Which handles constant acceleration motion perfectly no matter the timestep.

    When acceleration changes from frame to frame I don’t think there’s a silver bullet integration method to make it frame rate independent.

  • You mean something like this?

    Repeat 4 times

    — dx= round(cos(loopindex*90))

    — dy= round(sin(loopindex*90))