next »

[Evan Balster]

Okay, but fixed point does all of that better.

If (1 - .89) is a valid value, that means any FixedFloat value -- even one close to zero -- can have a precision as low as 2^-24.  Getting more precision "for free" is a really weird way of thinking about it; why improve your best-case precision in a way that reduces your average-case precision dramatically?  With FixedFloat fully half of your numbers have 2^-24 precision whereas 32.32 fixed-point gives you superior 2^-32 precision everywhere.  Only 1/256 of numbers in FixedFloat will be equivalent or better.

Because your precision varies wildly across the small stretches of space between your integer steps, the "extra" precision of those lucky FixedFloats will actually make your simulation less consistent than it would be with an even distribution of numbers.

Fixed-point is what is needed for truly consistent behavior in different spatial positions -- I've implemented deterministic record-replay systems in Cave Story+ -- a pre-existing game -- and gotten them to consistently replay a simulation based on input data across platforms.  This was only possible because all the physics in Cave Story are written with fixed-point mathematics, which is perfectly consistent across platforms in a way which is near-impossible for IEEE 754 floats.  This property of consistency is why Amaya chose the format.

The same logic that applies to a replay system -- the same simulation proceeding from the same initial conditions and input -- applies to your argument with game mechanics.  If you want perfect consistency, fixed-point is the way to go.  You will find this approach genuinely easier, better-performing and more conformant to your "spec".


It's so strange how superstitious people get about floats.  They're just fixed-point numbers with a variable radix.  They alias like any other number does, and generally worse under operations of addition and subtraction.  :/

[Crimsontide]

(By the way, this might be a bit tangental but can anyone tell me what the proper way to extract high and low words during a fixed-point multiply is?  My implementation is subtly wrong or something and it's been giving me aliasing in some of my audio DSPs.)

Usually in programming 'aliasing' refers to the situation where the same data can be accessed through different means (http://en.wikipedia.org/wiki/Aliasing_(computing)) so I'm not sure what you mean by it in reference to extracting low and high words.

In C++ right shift on an integer is undefined.  Usually its assumed to sign extend, but its not guaranteed.  Perhaps that's causing the issue?  I'd personally go with the union route, but then its not 'endian-safe' without some macro or meta programming trickery.  The other option is to cast everything to unsigned and then perform any sign extension requirements manually.

[J-Snake]

I think in general one can consider fixedFloat because it feels like a saver bet overall. It offers flexible use. Don't forget that it can perfectly work with floats aswell. It has more compatible partners to work with. When it comes to more complex calculations involving multiplications and divisions to represent continuous happening: float vs int, float will win.

It is not like I see no use in fixedPoint, it was my tool of choice initially. I will use it for games where I know from the start important calculations sensible to relative error will not occur. (TrapThem is a perfect example where I use fixedPoint, pure int treatment would suffice here but it was not known at the beginning so I used fixedPoint as a superset to go sure)

[zalzane]

When it comes to more complex calculations involving multiplications and divisions to represent continuous happening: float vs int, float will win.

[Ben_Hurr]

Hey J-Snake, do fixedFloats actually give 0.2 when you add two 0.1 values together

or is it more of that 0.1999999~ float bullshit all over again

[moi]

in the real universe, only integers exist

[Udderdude]

I'm tempted to make a clone of TrapThem, just to see how simple I can get away with making the code work out.

[Fallsburg]

in the real universe, only integers exist

in the complex universe, only complex integers exist

[Glyph]

I'm tempted to make a clone of TrapThem, just to see how simple I can get away with making the code work out.

No, even if it will look and play exactly the same, it will lack the precision, accuracy and gameplay-depth that will make TrapThem J-Snake's self-proclaimed masterwork.

Go ahead and use FixedFloat, because if 7 pages of everyone telling you you're wrong, citing sources, giving specific examples, and claiming scores of years more experience than you isn't enough to make you change your opinion, then nothing will. Ever.

I'm not trying to be rude and I have nothing against you, J-Snake, but I'm not going to mince words either. Follow your destiny! Surprise us! Release TrapThem, and make us eat our hats!

[Ben_Hurr]

I think his TrapThem game is actually on the verge of release.  It looked like a pretty solid puzzler on Youtube at least.


But yeah, someone reverse engineer it for SCIENCE, and to prove how much tinfoil is contained in J-Snake's hat.  

[Udderdude]

I think his TrapThem game is actually on the verge of release.  It looked like a pretty solid puzzler on Youtube at least.

I honestly think the game's rules/elements/mechanics are pretty cool.  I'm just worried that it's only going to run on a Core i7.  And there's other issues like some of the levels being way too large and not scrolling.  I'm talking larger than 20x20, which is really huge.  And would also lead to performance issues.

[J-Snake]

I think you misread something. TrapThem is using fixedPoint, not fixedFloat.

TrapThem would run on the weakest cpu you can imagine. The main bottleneck will only be old netbooks with a very weak graphics-solution. It is only because I am rendering in more than Hd and screens not supporting it will scale down. Scaling down is relatively intensive operations. Scaling up not so much.

fixedPoint is my tool of choice, only  not in games with certain simulation departments.
I value Evans contribution in particular here. But chances are you overlooked some of my arguments. FixedFloat has more partners to work with who can do a better job regarding certain calculations.

[zalzane]

dude just implement it in a tech demo and compare it against doubles.

I for one don't give a flying fuck about theory, but if this is more accurate/precise than double (especially in the context of timing over extreme durations) then I'd be willing to give it a shot.

[rivon]

Yeah, do a demo which does a complex simulation (translation, rotated translation etc.) over a longer period of time (it doesn't have to have graphical display) in fixedPoints, doubles and fixedFloats and prints the resulting positions and rotations in the end. Then we can all run it, post our results here and see which one is the most consistent

[Ben_Hurr]

Seriously man, just do it.  Make the tech demo.
I want to see your fixedPoint in action compared to the other numerical types.

do it
do it
do itttt