Was doing this part this weekend on my engine, was nice to see we came around very closely to the same solution. I do like the exact step for when the collision time is equal and you solve the higher velocity axis first. 👍
2:38 C does have a sign function in the form of copysign(1, x) which compiles to just 2 instructions (andps with -0.0, orps with 1.0). In the case of x=0 it behaves differently than the method in the video (it returns 1 instead of 0) but that should be ok for the case in the video
If we're calling sweep_response and static_response `iterations` times per physics_update() and and physics_update() is called once per frame isn't the true tick rate fps * iterations??
2:58 would it be reasonable to get rid of the if-statement and write hit.normal[(px < py)] = (px < py)((dx > 0) - (dx < 0)) + (px >= py)((dy > 0) - (dy < 0)) to make it branchless?
Are you sure you need stationary response? I remade this in Rust and I commented out my stationery response and I don’t have any issues with tunneling or glitchyness it’s as smooth as can be. Perhaps i am missing something or I am not hitting some edge case?
I have found that without the stationary response there is glitching through corners. Perhaps there's some difference in the way our code is running that prevents this? Keen to understand why.
i got stuck for days on it, glad i found your channel, thanks for the help
Was doing this part this weekend on my engine, was nice to see we came around very closely to the same solution. I do like the exact step for when the collision time is equal and you solve the higher velocity axis first. 👍
Nice one!
Here, have some motivation :D
Thanks :)
2:38 C does have a sign function in the form of copysign(1, x) which compiles to just 2 instructions (andps with -0.0, orps with 1.0). In the case of x=0 it behaves differently than the method in the video (it returns 1 instead of 0) but that should be ok for the case in the video
Oh good to know, thanks!
really great video! keep it up🙌
If we're calling sweep_response and static_response `iterations` times per physics_update() and and physics_update() is called once per frame isn't the true tick rate fps * iterations??
2:58 would it be reasonable to get rid of the if-statement and write
hit.normal[(px < py)] = (px < py)((dx > 0) - (dx < 0)) + (px >= py)((dy > 0) - (dy < 0))
to make it branchless?
Can you push this part's code to Git? Thanks!
Yes I can, cheers for the reminder.
Are you sure you need stationary response? I remade this in Rust and I commented out my stationery response and I don’t have any issues with tunneling or glitchyness it’s as smooth as can be. Perhaps i am missing something or I am not hitting some edge case?
I have found that without the stationary response there is glitching through corners. Perhaps there's some difference in the way our code is running that prevents this? Keen to understand why.
Can you publish your rust version?
Which ide are you using?
Neovim, with a few plugins - most notably Telescope, nvim-cmp, and the clangd language server
Thank you
beautiful, now consider rotated ellipses 😈
please convert that to javascript