ShadowWolf wrote:

I'm attempting to impliment a semi-proper physics element to my BYOND game ( required ).

Basically, I impliment my derived equations and what-not in a C++ environment, and I get something that works pretty decently. However, translating that to the BYOND environment yields completely out-of-this-world results ( RPM's in the millions, Velocities way above possibility, etc. ).

Is there some way to impliment or to alter how BYOND calculates things? I don't understand why it's failing. Anyone know anything about this?

Huge velocities and such are best dealt with by putting constraints on your calculations; you need some kind of limit in there. This isn't so much a problem implementing the physics as a design flaw. Any modeled environment will have to include constraints to keep the program from going berzerk. I can only conclude you're doing something in C++ to constrain the process that you're not doing in BYOND, or that didn't translate properly. (Given that they're different environments, a port problem wouldn't be surprising.)

A second problem you may have, though, is that BYOND is limited to single-precision floating point numbers. That means a lot of things that would yield no error in C would yield big errors in DM; I've seen this happen myself when modeling physics.

Lummox JR

ShadowWolf wrote:

The constraints are self-derived. Meaning it's impossible to get large results unless you pass 300 MPH due to the nature of the equations.

The only thing that seems to make perfect sense is what you said second. In that case, I don't know that there's any way I can progress with this game.

Don't worry; it's possible.
The key is keeping the numbers corraled; if they run amuck on you, that's when the rounding errors of floating point really get bad.

Lummox JR

ShadowWolf wrote:

Well, how would you do that and keep the nature of the game realistic? That's what always kills me, I hate games where it's obvious they are coralling numbers instead of using real physics elements.

Well, I'd best explain what I mean by that, then.
In a project I've been working on, I ran into big problems with the floating point restriction. A real problem area was when I was trying to solve for the intersection of an ellipse with a vector (that is, a vector and its starting point); if I was too far away from the starting point, the numbers in the calculation were large even though the result shouldn't ultimately have been any different--just shifted a little. Remember the good old quadratic equation?

x = [-b ± sqrt(b² - 4ac)] / (2a)

This was the basis for my solution.
It turned out that when the coefficients abc were very large, as they would be when further away from the origin of the vector, the discriminant b²-4ac would sometimes slip into negative or positive values, vs. situations where it was closer to the origin of the vector.

The best solution I found to this was to basically adjust the vector origin and pretend it was a lot closer to the ellipse, then just adjust the result. Also, I updated the proc so that I could supply a length for the vector, and that way I could use simple vectors like <1,0> for walls.
By keeping the numbers as low as possible, a lot of errors diminished to the point where they fell within my error tolerances.

That's basically what I mean by corraling the numbers. If you adjust them before calculations, and make counter-adjustments afterward, you may be spared an error that would creep in using the larger numbers.

Lummox JR