Idont often use Deltatime for a few reasons (Ignoring that calculating Accurately inrementing Milliseconds in a Windows operating system possibly em..impossible : calls like GetTickCount() and timeGetTime() are jumpy, and using QueryPerformanceCounter() and QueryPerformanceFrequency() though being effective requies time itself, so by the time ou get the result time with presicion to milliseconds has passed)
Firstly, your involving a multiplication in so many values that that itself is an addition to any slowdown: Although i admit i dont like the look of extra code either, especially where a time related variable has to be passed to so many game procedures (youll never hear a global from me: Im OOP all the way, or as close as i can get).
Secondly, if a game is too slow to play, large choppy movements wont really solve the problem that well: Consider an fps where you turn right,a dn after half a second you get to see where your targeting: Its even less impossible to target than it would be were it running slowly such that a great amount of time would pass to turn around (Not that i would suffer playing like that either).
Sacrafice to the collision-queried positions in larger movements is also a trouble: {Er...by that i mean say you had a 2d blitz game, using ImagesCollide, where images might end up moving too fastly through each other if the frame rate was dropping}: Although that could be resolved by checking collision of objects through their paths or by dividing the lengths into the desired minimum distance intervals to check for collision and working each position out in order - again however more code to work through, more logic, more complication etc.
I desire accurate logic above my expected render-rates though: For example i mainly say, set a limit on the frame rate to 60 fps and render if the fps was high enough and the frame was even not odd {This (*Crappy*) method suffices simple projects} but i never take frames out of logic while letting rendering work at full pace: Not in a game.
Firstly, your involving a multiplication in so many values that that itself is an addition to any slowdown: Although i admit i dont like the look of extra code either, especially where a time related variable has to be passed to so many game procedures (youll never hear a global from me: Im OOP all the way, or as close as i can get).
Secondly, if a game is too slow to play, large choppy movements wont really solve the problem that well: Consider an fps where you turn right,a dn after half a second you get to see where your targeting: Its even less impossible to target than it would be were it running slowly such that a great amount of time would pass to turn around (Not that i would suffer playing like that either).
Sacrafice to the collision-queried positions in larger movements is also a trouble: {Er...by that i mean say you had a 2d blitz game, using ImagesCollide, where images might end up moving too fastly through each other if the frame rate was dropping}: Although that could be resolved by checking collision of objects through their paths or by dividing the lengths into the desired minimum distance intervals to check for collision and working each position out in order - again however more code to work through, more logic, more complication etc.
I desire accurate logic above my expected render-rates though: For example i mainly say, set a limit on the frame rate to 60 fps and render if the fps was high enough and the frame was even not odd {This (*Crappy*) method suffices simple projects} but i never take frames out of logic while letting rendering work at full pace: Not in a game.