so far i've had a game dev reply to my physics problems with "ah you should make this simpler" and also had a physicist reply to the same physics problems with "ah you should make this more complicated"
troublesome fox girl
- she/her
- eev.ee/
hello i like to make video games and stuff and also have a good time on the computer. look @ my pinned for some of the video games and things. sometimes i am horny on @squishfox
itch
eevee.itch.io/bluesky
bsky.app/profile/eev.eemastodon
queer.party/@eeveeYou must log in to comment.
in reply to @lexyeevee's post:
My game dev reply: Getting what you want to happen is the important thing. Accuracy is a false premise. (Accurate to what? 2D objects with physics collisions don't exist in the real world.) And the easiest way to get what you want to happen is to do less things at once!
My response (that of a numerical analyst!) was going to be: one big problem you’re facing here is that you’re trying to solve differential equations involving multiple orders of differentiation using explicit integration (taking into account only currently-estimated or recently-computed values of your target variables) using a somewhat arbitrary spatial discretization and a completely uncontrolled time discretization. This is a recipe for numerical instability.
One classic way to reduce instability in numerical simulations is to force known quantities to take on known values. E.g., if you know that momentum must be conserved, force it to be conserved. If you know that velocity must be constrained, force it to be constrained.
One potential problem here is that finding applicable constraints might be difficult. For instance, it seems like your physics engine is pretty general, and allows for arbitrary angles of incline. That’s great! But also, yikes, because now you’re introducing cosines and sines that you conceptually need to track with arbitrary precision. Maybe it would be worthwhile to discretize the allowable angles, which would allow you to force motion to occur only along those angles and would reduce numerical instability?
oh i know numerical instability. my water surface is modelled as a series of springs and has been subject to it before
i don't think it tends to crop up with general platformer movement though, since most of the behavior is stuff like constant gravity (solvable exactly), accelerating to a maximum walk velocity, or tending towards zero one way or another. there's not a lot of places for cumulative errors to creep in. and i do have e.g. a terminal velocity, too
as long as i have any kind of slope at all, there'll still be some irrational numbers in there begging to have precision errors creep in. even if i ported the whole thing to a CAS, the physics is currently vsynced, so Δt is effectively arbitrary. but for what it's worth i virtually never use any trig, and the core collision code itself all works with nothing more than square roots :)