next »

[ThemsAllTook]

It's definitely slower than floating point, but I don't know by how much yet. I'm just getting to the point where I can profile and optimize it in a real-world situation.

Fixed point is relatively well known, but not in very widespread use as far as I know. Floating point is a better choice in most cases. Fixed's main advantage is consistency; float calculations will differ across platforms, so the same inputs to a game running on one system may give different results than on another system. Since fixed point uses only integer math, the calculations are universally identical.

The reason I've chosen it for this project is to be able to play back an input session anywhere to see the same game behavior. This is super useful for debugging (I have a system that logs all player inputs to disk as they happen, so if someone runs into a bug once, they can send me the gameplay session file, and I can play it back and reproduce the bug 100% of the time), recording/exporting gameplay footage (don't have to deal with real-time recording software which sometimes drops frames; the game can play back an input session in non-real-time, export a PNG for each frame and a WAV for audio, and those combine into a frame-perfect video), and high score verification (score server doesn't have to trust client's reported score or time; client just sends an input session, and the server simulates it to learn the result).

[InfiniteStateMachine]

The sony playstation actually had hardware fixed point support. That's about the last time I remember hearing about it natively supported.

The issues you are describing. Don't those really only come into play when switching hardware to a chip that treats floats different? Of course your use case of having someone send you a demo has exactly that problem but I'm just asking in case i'm overlooking a case where on the same computer you could have different results.

[ThemsAllTook]

Yeah, different computers. The cases I'm thinking about are, for example, recording a replay on OS X and playing it back on Windows. One of my recent games used floating point and had a playback feature, and playback would desync in some cases if it wasn't done on the same OS as recording.

...actually, come to think of it, it's not necessarily a hardware thing. I'm pretty sure I got different results between Linux and Windows running on the same computer.

[gimymblert]

How is that possible? what do OS do? timing melding?

[Boreal]

Basically, what happens is that IEEE instructions running on strictly-IEEE compliant (configured to use no extensions like 80-bit FPU registers) hardware should be consistent.  The hard part is making sure that you limit not only yourself, but also the compiler, to emitting that subset of possible FPU instructions.  For example, although the addition/multiplication instructions are IEEE and thus consistent, the combined multiply/add instruction (which optimizers will try to use) is not.

http://yosefk.com/blog/consistency-how-to-defeat-the-purpose-of-ieee-floating-point.html

Differences between OSes are probably coming from optimization differences (i.e. different instruction usage) between compilers/interpreters for each platform.

[InfiniteStateMachine]

Yeah, different computers. The cases I'm thinking about are, for example, recording a replay on OS X and playing it back on Windows. One of my recent games used floating point and had a playback feature, and playback would desync in some cases if it wasn't done on the same OS as recording.

...actually, come to think of it, it's not necessarily a hardware thing. I'm pretty sure I got different results between Linux and Windows running on the same computer.

really? That seems really odd that there would be different performance across different os'es on the same hardware. Do you remember what compilers you were using?

I wonder if it would be the same or similar if you were to do something like use GCC/MingGW on the same computer as opposed to something like clang/msvc.

edit : talked to one of the senior guys at work with a lot of hardware experience about this. The conversation really blew up and now I have about 200 pages of reading to do :D. It did come down to that you probably could get the same results on the same hardware but you would have to make sure the compiler behavior is set to act the same way for float operations. For instance there's a bunch of flags in visual studio for affecting how floats are calculated (accuracy vs performance).

[gimymblert]

@boreal
Thanks!

[BorisTheBrave]

Yes, it's ironic, but fixed point is useful mostly because there is no support for it. All the clever optimizations of floating point don't help consistency.

Also, transcendentals like sin/cos aren't required to be 100% accurate by the standards. Presumably fixed point users don't use sin/cos at all, or stick with something consistently wrong.

[InfiniteStateMachine]

Yes, it's ironic, but fixed point is useful mostly because there is no support for it.

Haha very true :D

[J-Snake]

If you intend to simulate newton mechanics then best approach has to imply an appropriate use of both, float and integer/fixed point. You use integers/fixed point mainly to store positions, while you compute force vectors etc. in floats.

It is of fundamental importance to see that the actual point of floats is not consistency in terms of equidistant number distribution. That is why it actually doesn't matter much if the results can vary from machine to machine. If you use float, you are not about that type of consistency. You use float when you need to keep a small relative error in every range
(relative error = dx/x, where x is the intended number and dx is the error). Typical use are complex numerical computations
where the end results are intended to be as accurate as possible, but not necessarily precise (means the error patterns can change and fluctuate, but the errors are very small, that's the actual point here)

So what mainly speaks against the exclusive use of floats in games is the physical position of an object. Unlike vectors, positions cannot be measured in relative terms. For example if a vector is one foot shorter than the other then they will still look almost identical if they are a mile long. However if you stand at position A and add one foot to it, it will always look like a significant shift in position. So floats are of ill use in representing positions since their absolute error grows bigger the bigger the number gets, yet they are still used for the ease of use. While at the same time there is no justification for the same physical activity at position A to behave differently at position B. Each space should have equal rights, we ideally want an equidistant distribution of positional values.

[gimymblert]

where the end results are intended to be as precise as possible, but not necessarily accurate

For kids that peek over here 

[J-Snake]

where the end results are intended to be as accurate as possible, but not necessarily precise

That's the correct version now and forever.

[Sik]

Basically, what happens is that IEEE instructions running on strictly-IEEE compliant (configured to use no extensions like 80-bit FPU registers) hardware should be consistent.  The hard part is making sure that you limit not only yourself, but also the compiler, to emitting that subset of possible FPU instructions.  For example, although the addition/multiplication instructions are IEEE and thus consistent, the combined multiply/add instruction (which optimizers will try to use) is not.

http://yosefk.com/blog/consistency-how-to-defeat-the-purpose-of-ieee-floating-point.html

Differences between OSes are probably coming from optimization differences (i.e. different instruction usage) between compilers/interpreters for each platform.

Don't forget FPU control flags, those affect the way the FPU performs its calculations. This can also lead to that kind of differences, even within the same OS.

[Schrompf]

Aaaand don't forget the Visual Studio project settings, especially the floating point model. In my experience the change both the outcome and the performance of the code measurably.

That's why I always change it to "Fast" even in Debug builds - to get surprise-free results.

[InfiniteStateMachine]

Basically, what happens is that IEEE instructions running on strictly-IEEE compliant (configured to use no extensions like 80-bit FPU registers) hardware should be consistent.  The hard part is making sure that you limit not only yourself, but also the compiler, to emitting that subset of possible FPU instructions.  For example, although the addition/multiplication instructions are IEEE and thus consistent, the combined multiply/add instruction (which optimizers will try to use) is not.

http://yosefk.com/blog/consistency-how-to-defeat-the-purpose-of-ieee-floating-point.html

Differences between OSes are probably coming from optimization differences (i.e. different instruction usage) between compilers/interpreters for each platform.

Aaaand don't forget the Visual Studio project settings, especially the floating point model. In my experience the change both the outcome and the performance of the code measurably.

That's why I always change it to "Fast" even in Debug builds - to get surprise-free results.

Don't forget FPU control flags, those affect the way the FPU performs its calculations. This can also lead to that kind of differences, even within the same OS.

IIRC the visual studio settings are affecting whether the FPU flags are being used.


This is why I'm kind of interested to see if doing linux build with gcc and a mingw gcc build on windows would yield more consistent results. Assuming they use identical flags etc.


J-Snake, what you are describing is well known but a different issue than what's being discussed. What we would like is to consistently have the same inaccuracy.

[J-Snake]

J-Snake, what you are describing is well known but a different issue than what's being discussed. What we would like is to consistently have the same inaccuracy.

Yet the average game programmer doesn't take it to heart, instead it is tried to fight the symptoms instead of tackling the core problem (I am not addressing Alex here, just a general note). I see that you want the "consistent inaccuracy" here to reproduce recorded game sessions exactly the same across different machines. But that shouldn't be your main motivation since the game is still inconsistent on the very same machine in terms of representation of space.

[ThemsAllTook]

I appreciate your pursuit of numeric perfection as a principle, but it's hard to take it seriously when it's presented this way. Different approaches to problems are something to be celebrated, not lamented. I don't think the approach you would prescribe is the correct thing for my situation, and that's OK! What I'm doing is deliberately different from a traditional physics system of the sort that would benefit from a more academic approach. If that was what I needed, I'd have been doing it very differently from the start, or using a prebuilt one.

[J-Snake]

I don't think the approach you would prescribe is the correct thing for my situation

What would that approach be that is not the correct thing for your situation, to be more precise? I mainly suggested to know the domain limits of fixed point arithmetics, if that was some source of your problems.

[ThemsAllTook]

Scratch that part. I won't presume to know what you'd recommend.

[InfiniteStateMachine]

I thought j-snake was referring to my name while quoting me then I realized there are many Alex's in this thread :D