Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Neo Geo Dev: Fixed Point Numbers

mattgreer.dev

Post reply on HN
Print view View original

11–20 of 49 posts

Re: Neo Geo Dev: Fixed Point Numbers

#11

Post by VyseofArcadia »

vardump wrote: post #2

On the PC side, most developers stopped predominantly using fixed point for high performance code somewhere in the Pentium 1-3 era. For 486 class systems it was still pretty useful. Other than on retro systems, fixed point is still useful in smaller microcontrollers.

A buddy of mine and I are working on a weekend project together. We recently realized that we don't need all that much precision, just a little, and switching from doubles or floats to 16-bit fixed point in our main data structure actually makes it small enough to fit an instance in a typical cache line (Completely unnecessary for our target platform but deeply satisfying.

Re: Neo Geo Dev: Fixed Point Numbers

#12

Post by twoodfin »

vardump wrote: post #2

On the PC side, most developers stopped predominantly using fixed point for high performance code somewhere in the Pentium 1-3 era. For 486 class systems it was still pretty useful. Other than on retro systems, fixed point is still useful in smaller microcontrollers.

A few years before that era, I was having a lot of fun with

https://en.wikipedia.org/wiki/Fractint

Re: Neo Geo Dev: Fixed Point Numbers

#13

Post by SideQuark »

__s wrote: post #6
fidotron wrote: post #5

It's worth saying the original Playstation was entirely fixed point. You can go surprisingly far with it. https://en.wikipedia.org/wiki/Fixed-point_arithmetic#Softwar... I spent so much of the early stage of my career doing early mobile stuff I practically still think in fixed point, and always have to adjust to floats, for example, fixed point results can be compared exactly while with floats that is not a great ide…

I think fixed point would be used a lot more with proper support in programming languages

I doubt it. It fails for far too many useful programming situations that it would cause more problems than floating point.

Cannot use it efficiently for nearly anything: finance software, science software, engineering software, high quality graphics software... 3d software, pretty much anything that has any range needed or ability to lower errors while doing accumulation of information.

This is exactly why floating point was invented and standardized - fixed point is a failure for most any program, and only can work with much effort only for certain situations.

(I've written tons of fixed point code, numerical libraries across the spectrum from high performance, high quality, tunable quality, arbitrary precision libs, posits and unums, IEEE half-float software implementations, and more, so I do know what I'm talking about).

Re: Neo Geo Dev: Fixed Point Numbers

#14

Post by nritchie »

When I was a freshman (or so) in high-school, our computer lab had just graduated from a time-share terminal to the next-door university to the Apple II. A kid (Ray Tobey) in the next grade up started to code a project to submit to a Byte Magazine game contest. The due date came and went, but he carried on in every moment of his free time. Long story short, this game became SkyFox of which Woz said "consider this flight simulator as the finest Apple game ever done." From Ray, I learned the value of using continued fraction approximations to trig functions using only integer math. Later, this became useful when I had to implement image rotation in a scan generator for a scanning electron microscope.

Re: Neo Geo Dev: Fixed Point Numbers

#15

Post by tralarpa »

On the Amiga and Atari, based on the Motorial 68000 like the NeoGeo, all 3D games used fixed point arithmetic.

At that time, such games were written in assembler, and you had to be very careful to place the instructions for scaling and descaling in the right places, not only to get the final result in the right units (i.e., screen coordinates), but also in intermediate calculations to preserve precision.

Re: Neo Geo Dev: Fixed Point Numbers

#16

Post by wk_end »

I always felt when learning about this stuff that people - pedagogically - make fixed point seem more complicated than it is.

Since this article is talking about more precisely positioning sprites in a 2D world, it could practically be a one-liner: "instead of tracking positions/velocities in pixels, track them in half pixels". Everything falls out of that intuition.

Re: Neo Geo Dev: Fixed Point Numbers

#17

Post by jerf »

SideQuark wrote: post #13
__s wrote: post #6

Earlier quoted context omitted.

I think fixed point would be used a lot more with proper support in programming languages

I doubt it. It fails for far too many useful programming situations that it would cause more problems than floating point. Cannot use it efficiently for nearly anything: finance software, science software, engineering software, high quality graphics software... 3d software, pretty much anything that has any range needed or ability to lower errors while doing accumulation of information. This is exactly why floating p…

Is there even any performance benefit on modern CPUs? I tried to consult some real tables but I'm not experienced enough to be sure I'm reading them correctly. If I'm reading something like [1] properly, it looks like it is not a clear win on modern hardware to use fixed point & integer operations. It would depend on the ratio of addition/subtraction/multiplication to division.

(Obviously one must factor out a lot of local considerations, which modern CPUs are full unto overflowing with; I'm kind of looking at a very, very broad average performance question across code bases doing enough different math operations to average out, not whether one particular loop can run theoretically run faster or slower with one or the other.)

[1]: https://stackoverflow.com/questions/2550281/floating-point-v...

Re: Neo Geo Dev: Fixed Point Numbers

#18

Post by ooterness »

jerf wrote: post #17
SideQuark wrote: post #13

Earlier quoted context omitted.

I doubt it. It fails for far too many useful programming situations that it would cause more problems than floating point. Cannot use it efficiently for nearly anything: finance software, science software, engineering software, high quality graphics software... 3d software, pretty much anything that has any range needed or ability to lower errors while doing accumulation of information. This is exactly why floating p…

Is there even any performance benefit on modern CPUs? I tried to consult some real tables but I'm not experienced enough to be sure I'm reading them correctly. If I'm reading something like [1] properly, it looks like it is not a clear win on modern hardware to use fixed point & integer operations. It would depend on the ratio of addition/subtraction/multiplication to division. (Obviously one must factor out a lot of…

It depends a lot on CPU architecture. Floating point units may be tied to each core, or they may be shared, so it may further depend on other concurrent workloads.

There's also SIMD instructions. Modern CPUs have built-in instructions for handling multiple ints or floats as a vector. If you can get your fixed-point varies to for into 8-bit or 16-bit fields instead of 32, then the same sized vector units can handle more values per instruction.

Re: Neo Geo Dev: Fixed Point Numbers

#19

Post by thequux »

SideQuark wrote: post #13
__s wrote: post #6

Earlier quoted context omitted.

I think fixed point would be used a lot more with proper support in programming languages

I doubt it. It fails for far too many useful programming situations that it would cause more problems than floating point. Cannot use it efficiently for nearly anything: finance software, science software, engineering software, high quality graphics software... 3d software, pretty much anything that has any range needed or ability to lower errors while doing accumulation of information. This is exactly why floating p…

You might be surprised at where fixed point is already used: * Finance software: if you're using floats, you're doing something horribly wrong. All balances are measured in integer multiples of some quantum; depending on the system, that may be cents, it may be 0.1 cents, or it may be 0.01 cents. Gradations finer than that simply do not exist, and integer overflow is both more likely to be noticed and more easily explained to be a bug than precision loss (and this matters when you have a regulator asking uncomfortable questions) * CAD software: floating point may make sense for simulations, but at least for PCB design, layout is done in fixed point. You need consistent precision across the board, and avoiding edge cases in your geometry kernel from precision issues makes everything much easier. Besides, with a 1µm quantum, 32-bit numbers are sufficient for a board 4km on a side. If you need larger, I would love to see your fab. * Robotics: maybe this one's just me, but expressing motion control algorithms in fixed point has saved me €1/part on more than a few occasions as a result of being able to use an MCU without hardware floating point. Compared to the €0.20/part saved by muntzing the rest of the circuit, the small amount of additional work was totally worth it.

Indeed, the tools for working with fixed point aren't great. C is a lost cause; the best you can do is name your variables things like velocity_12_4 and manually check that the precision lines up. Rust wasn't great when I tried, though const generics may have resulted in an improvement. C++ was, astonishingly enough, quite good; I made a header-only fixedpoint.h with a templated struct `fixed` and all inline operations. I get the impression that Ada would be even better, but I've yet to use it in anger.

Re: Neo Geo Dev: Fixed Point Numbers

#20

Post by city41 »

wk_end wrote: post #16

I always felt when learning about this stuff that people - pedagogically - make fixed point seem more complicated than it is. Since this article is talking about more precisely positioning sprites in a 2D world, it could practically be a one-liner: "instead of tracking positions/velocities in pixels, track them in half pixels". Everything falls out of that intuition.

I'm the author of the blog post. I just used sprite positioning as a simple example. Things like collision detection and physics can't be done with half pixels.
Post reply on HN