Just when you thought that physics could create any click game.. turns out that Newtonian physics is false! At least when it comes to calculated computer game accuracry. Arggh... now I have to spend another week re-making up formulas for my game.
Edited by an Administrator.
Disclaimer: Any sarcasm in my posts will not be mentioned as that would ruin the purpose. It is assumed that the reader is intelligent enough to tell the difference between what is sarcasm and what is not.
Disclaimer: Any sarcasm in my posts will not be mentioned as that would ruin the purpose. It is assumed that the reader is intelligent enough to tell the difference between what is sarcasm and what is not.
Peblo Custom ratings must be 50 characters or less
Registered 05/07/2002
Points 185
12th February, 2008 at 20:35:52 -
Front page. (two words)
"Isn't it always amazing how we characterize a person's intelligence by how closely their thinking matches ours?"
~Belgarath
the biggest problem you will encounter with newtonian physics is that you cannot possible get precision out of it in a pixel-per-pixel setting. Instead, try saving the positions of all your objects as a seperate variable then their X/Y 'real' positions, as say (PosX * 1000)
So for example, at the start of my frames I give each object a variable A where A = PosX * 1000, B where B = PosY * 1000. Then, after all the funky physics stuff is done calculating each frame, I position it as:
PosX = A / 1000
PosY = B / 1000
If you don't do that, its very hard to get velocities between 1 pixel/frame and 2 pixels/frame, and such.
if you've got everything saved as precision floats newtonian physics shouldn't have any problems whatsoever unless you're doing something thats relevant to time dilation and special relativity, which you arent
@Pixelthief, Peblo: I use the exact same method myself, when building engines in MMF. It's the only way to make sure MMF doesn't lose any decimals along the way =P
Yeah I don't use MMF nearly as much as TGF, so I'm not quite sure what the rules are. I'm pretty sure that general in-expression division will only yield integers if both the operands are integers, but will return decimals if you change them to be floating point. So in terms of the actual in-side of the expression, it shouldn't be a problem. However, I believe that it will only save the final result for an alterable value or global value as an integer, not a floating point, which makes it very hard to do one equation to find the slope of a line, and another to use it. Or other such thingies. Like in my TGF engine for gravity, I risk overrunning the overflow point by having more then 9 digit long numbers, since I need to find a 3 precision gravity division applied to a 3 precision velocity vector, then sum that into a 3 precision position (although those last two stack on top of each other)
Advertisement
Post Reply
Edited by an Administrator.
