New build at bottom of post, quote to see link.
1080/60 video if you just want to watch:
https://www.youtube.com/watch?v=HPBiqGY41fU (fps indicator bottom left of screen)
So for the past few days I've had a lot of time to rethink the way I approached handling physics in (insert new name here). I was having some micro-stuttering issues that randomly occurred when playing after a specified amount of time. Now, setting Unity's timescale to 0 and back to 1 would rectify the issue for the same amount of time. This happens since setting the timescale to 0 will finish the curren't frame's loop before starting a fresh loop on setting the scale back to 1. Long story short my math was bad, rather, there's no such thing as physics running at a timestamp of 60fps.
I coded my physics in 60fps intervals but that was idiotic of me since:
1/60 = 0.016666666(a fafillion 6's later)6666666666~
There's no way to cleanly divide 1 by 60. Which left me to use 0.01666667 - which was a problem since you'd always have a remainder of 0.0000002 after every calculated second, slowly accumulating over time causing a phase shift between my set physics stamp and the refresh rate of a monitor (60/120/240). I would up using framerate based physics that calculated every frame before the screen was drawn. That might sound like a LOT to calculate but I have simplified the way I enforce physics, as well.
My method was pretty simple, i collect the previous 10 frames of deltaTime and compare them to one another, if there is no gross change in the delta - I continue with my current calculation based on the latest frame of rendered time. I set a breakpoint at which I look at the previous 10 frames to look for a drop on the latest frame that exceeded my breakpoint, if it has, i begin to lerp between the deltas and average in 5 delta chunks to get the current "guessed" frame time during a downwards or upwards frame spike. It sounds a lot more complicated than it is but it's nothing more than looking at an array and comparing, averaging, lerping and coming up with a final number.
The result is pretty spot on. I set framerate tests by capping the framerate and lerping it from 60, to 120, to 240, to unlocked - at one second intervals. I began spike testing by changing the cap flat without lerps, from 60 to unlocked. For me, unlocked is about 850fps - but in a typical run across the screen I have seen large fluctuations from 800-1k + (i stop counting frames if they are over 1k, since, yeah). Even with those drastic fluctuations I've pretty much nailed down buttery smooth movement without speed changes, without physics bugging out and without hiccups (unrelated to monitor refresh rates, of course).
I began refactoring all of my objects with the new physics in place, including rain, which now can boast up to 400 raindrops "living" in the scene at once, without a noticeable drop in framerate (all of my above mentioned framerates are with rain enabled on my humble i5).
So the way I handle my physics now is that it technically isn't physics until an object gets close enough to interact with another object, if it needs to interact with physics. Dunno why I never thought of that before, truthfully. The simple is that when the player is standing on the ground moving left and right - do we need to apply any forces like gravity? Nope. Simply put - there is 0 actual "physics" until an object needs to interact with another physical object like the environment, and even then - physics is only switched on for a few frames while the interaction occurs. I control the result of the interactions through code, instead. Movement still has acceleration, deceleration, both in the air and on the ground, independently of one another. Rain still has it's own mass, fall speed, is affected by wind, etc. But those are now all just simple math numbers rather than being acted upon by forces. Granted, I had to math them, myself, but it's far easier performing simple multiplication and division on a single float than it is to use actual physics to impact an object's movement.
"Physics" is calculated based on what should happen between 2 objects at collision, or based on state. Movement direction, speed, point of contact, etc. If the player is just moving on solid ground - we move by simply translating his position every frame instead of using physics to move him.
I'm quite happy with the result. I spent a few days in bed working out the specifics and spent the afternoon today coding. Feeling better and this was just icing on the cake.
NEW THINGS IN THIS BUILD:
-FRAME COUNTER (no need to use your own)
-New disc weapon
-Ability to zip multiple directions (with the halved energy cost this is great)
-Pickups are no longer "instant on" - there is a dedicated button to USE the pickup when you feel you need to. Pickups are saved in the HUD at the top of the screen. You can pickup a 2nd ability while the 1st is active, you cannot use multiple abilities at once though.
-Sprite random coloring, tiling and displacement (my Aphex Twin shader) for effect
-Added the ability to press UP and DOWN direction in addition to horizontal movement to direct your special attack
-Dropping from a wall now requires DOWN+JUMP instead of just jump. This also helps prevent unwanted drops from the wall while zipping around wall jumping (thanks for the suggestions!
-New camera follow. Now dampens movement slightly on the X axis - very slightly but cleans the scene up during movement and provides super smooth camera movement.
I wouldn't mind if you all gave it a whirl and told me where I messed up because I'm sure I did
DDD
Link visible below when quoted vvv:
