next »

[J-Snake]

Let me introduce an example if you have difficulties of finding one: Let's assume a worst case scenario in fixedFloat. We won't even compare it to fixedPoint, we will compare it to the infinite resolution of the real world right there to see how even infinite resolution hardly matters here. And I think I chose an example not difficult to understand:

We will go directly to what Evan describes as its "deal-breaker-weakness". It is that it has less resolution in most of its space. However given the nature of motion we will see that this space doesn't matter that much here.

Now we use fixedFloat and the integer-part is representing a millimetre-resolution. We will let a ball roll with a very low but noticeable speed of 0.5 over a sufficiently long distance of 10 metres for better comprehension. We assume the worst we can do because we hate fixedFloat, let's just wrongly assume all of the consecutive addition-results will land in between 0.5-1 (the area with the lowest resolution) of the fraction because it is the worst we can do to fixedFloat and let's assume they land there each time with the maximum error possible:

Lets take an average float with a 23-bit mantissa, the error "e" in each 0.5-1 fraction is:

e < 0.5/(2^23) (in decimal 5.960464478x10^-8)

Now we need to translate the ball 20000 times to reach 10 metres. Now let's again wrongly assume that the errors do accumulate in a worst possible way.  

That means you will get a total error of 20000*5.96046478x10^-8 = 1.192092896*10^-3:

This is a approximately a micrometre (10^-6 metre). That is how much it can possibly differ. Even when you throw infinite bits of resolution to a fixedPoint, they cannot outdo it better than by this negligible error. It pales in comparison, you won't notice it.

What does matter are classes of problems which significantly affect macroscopic happening from microscopic domain. A lot of simulations do have this property. This is why in general fixedFloat has its compromise-value as a flexible system. You can use it for simulations but you can also use it for integer accuracy. Since the error-rate is the same across all of the macroscopic space it is also a suitable system for sportive car-racing sims and ego-shooters.

[J-Snake]

For a better correlation if some still have troubles with:
Assume you walk with an average speed in an ego-shooter around the globe given the mentioned system in fixedFloat: The accumulated error will be less than one inch.
A simulation sensitive to relative errors however will be significantly better.
 
So given that frame of sight you can ask yourself is it better to spend more bits for more precise macroscopic translations no one can practically notice or is it better to play save and keep the system ready for simulations aswell. I hope that makes it clear that the answer is not that trivial as you think.

[Evan Balster]

We've long since established that magnitude values like micro-impulses and velocities (which are vectors) are better-suited to floating-point than anything.  It maps to an exponential distribution, which is ideal for numbers that are frequently multiplied.

(technically mu-law would be better, but nobody uses mu-law because it's slow.  If you don't know what mu-law is at this point, you haven't been doing your homework.)

But anyway, I've talked all the sense I can.  I suppose I'll join the choir here and ask that you demonstrate your assertions with a configurable deterministic simulation of some kind.


But I suggest you bear in mind the most important parameter for optimization: years of life.

[J-Snake]

And I hope you have seen how insignificant it is giving macroscopic translation more precision;) Of course when an application like TrapThem demands perfect consistency in translations I will prefer fixedPoint. I could also use fixedFloat for it and achieve the exact same results by only working with its integer-part, it just wouldn't be ideal regarding the use of ressources here.

The reproduceability of a starting process from an arbitrary resting/snapped position is a trivial property of fixedFloat. I am considering to implement a fully physically working local time-travel system for my metroid-rethought. Perfect reproduceability from past to present is fully achieved with fixedFloat here. But you can also interfer in this domain and thus change it.

Also I can go with a procedurally generated planet of over 4000kilometres diameter where the integer-part is representing every millimetre. So if I want I can even apply micro-impulse physics with the same fine quality everywhere on this planet. No coordinate-shifts and related worries required.

[Gimym TILBERT]

This thread punch way above my weight (I'm mean apple to sun scale), but it does address (the whole discussion) problem I met and didn't know why, I just have develop an intuitive distrust of floats without knowing why. I only partial understand of why now ...

replying to follow

[J-Snake]

Doesn't bother me. I value your elaborative focus on game-desing instead

But it would be good not to be just the tech-head or the game-design head. In my opinion a great game-designer does need both skills.

[Ben_Hurr]

I've completely lost track of what you're trying to accomplish already.  

Are you trying to ensure that any one frame of your gamestate is perfectly predictable from the last? (which floats and doubles alone is notoriously bad for?)

[Schrompf]

Are you trying to ensure that any one frame of your gamestate is perfectly predictable from the last? (which floats and doubles alone is notoriously bad for?)

No, the FixedFloat option is just as unpredictable as a standard float, only slower. After being proven wrong in all other counts, JSnake resorted to "consistency" as the primary reason to use FixedFloat. To date I haven't read a mathematical description of what that is and why it's desirable. But it's the answer you were looking for: consistency.

[Ben_Hurr]

Oh, so
 


I already guessed that a Long Int used as a fixed-point number would be far superior, in practical use, for consistency then.

[moi]

Doesn't bother me. I value your elaborative focus on game-desing instead

But it would be good not to be just the tech-head or the game-design head. In my opinion a great game-designer does need both skills.

you guys should team up to make a game the game.
Think about it: gimmy/graham's game design ideas finally put to life, using Jsnake's perfect simulation engine.
It would be the ultimate abstraction.
Imagine a computer running that game.
Humans would probably become so affraid of this computer they'd send it into deep space.

[InfiniteStateMachine]

Think about it: gimmy/graham's game design ideas finally put to life, using Jsnake's perfect simulation engine.

I just came

[Udderdude]

Think about it: gimmy/graham's game design ideas finally put to life, using Jsnake's perfect simulation engine.

I just came

 

[st33d]

Thank fuck I don't moderate here anymore.

[Ben_Hurr]

Timmy Gilbert and J-Snake as a duo would be like the game design equivalent of Sherlock Holmes and Watson.

It'd be magnificent.

[Gimym TILBERT]

Come on, i don't seek perfection, I seek understanding, and it has always been immensely helpful and practical. I also draw a fine line between idea (role playing framework), game design (mechanical understanding of game structure) and what i call internally "playdesign" where theory is less useful and only give you broad guideline. I mean there is mathematical lesson to draw from lock and key structure that has little to do with opinion, but things like good control is only a matter of debate on which things each side thinks is better