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

21–30 of 49 posts

Re: Neo Geo Dev: Fixed Point Numbers

#21

Post by 01HNNWZ0MV43FF »

city41 wrote: post #20
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.

They can't?

Re: Neo Geo Dev: Fixed Point Numbers

#22

Post by 01HNNWZ0MV43FF »

nritchie wrote: post #14

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 fli…

Oh cool! I think I played that on my family's Apple II. I think it was mislabeled as "Star Fox" and probably pirated. Sorry Ray...

Re: Neo Geo Dev: Fixed Point Numbers

#23

Post by 01HNNWZ0MV43FF »

mmaniac wrote: post #4

This sort of thing is ordinary for consoles without floating point numbers. It's easy to do in software with integers, but sometimes hardware acceleration will use it too. The SNES and GBA both supported affine transformations, where the elements of the multiplication matrix are fixed point numbers. The Playstation's geometry coprocessor (GTE) used fixed point matrices with quite low 16 bit precision. An emulator fea…

And just to head off the discussion that happens every single thread:

- Yes, the PS1 had "jittery" vertices because 16 bits is not enough precision

- No, it was not because of using integers, you can use integers (AKA fixed-point) to do 3D just fine. If it had been 16.16 (32 bits total) it would probably look fine.

- No, this isn't the cause of the texture warping, that's because unlike the N64 it only supported affine texture mapping, not perspective-correct texture mapping. The PS1 saw every 3D triangle as just a 2D triangle, and texture mapping in 2D differs from texture mapping in 3D

- Yes, the texture warping is why many of the best-looking PS1 games were basically built on a grid or found other ways to use a large amount of small triangles instead of a small amount of large triangles.

Re: Neo Geo Dev: Fixed Point Numbers

#24

Post by fizzynut »

Is it possible to get rid of all the macros TO_FIXED, FROM_FIXED, mult, etc and replace them with a class with the correct constructors / operator overloads?

Then your code doesn't ever need to be aware of the special fixed point math and horrible syntax everywhere and everything just works?

Re: Neo Geo Dev: Fixed Point Numbers

#25

Post by wk_end »

city41 wrote: post #20
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.

Not sure what you mean - sure you can.

Trying to read between the lines here, if your objection is to half-pixels because they’re not precise enough for (good) physics, then I apologize for being unclear - I mean half-pixels, or quarter-pixels, or eighth-pixels, or whatever.

Another way of wording my comment is that I think it’s easier - especially for beginners - to think in terms of smaller units (represented as integers) than in terms of a new number format for representing fixed-size fractional parts of larger units. But the two concepts are ultimately the same.

Re: Neo Geo Dev: Fixed Point Numbers

#26

Post by pistoleer »

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 wonder how many people have reinvented the concept of fixed point when they calculated using "cents" instead of "dollars".

Re: Neo Geo Dev: Fixed Point Numbers

#27

Post by taeric »

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…

My gut would be that you also get some benefit by some auxiliary choices. With a lot of precomputed constants, you can probably avoid a lot of known multiplications. That said, yeah, if you have to start doing a lot of fixed point multiplications, you could eat any savings you had.

Re: Neo Geo Dev: Fixed Point Numbers

#28

Post by msk-lywenn »

fizzynut wrote: post #24

Is it possible to get rid of all the macros TO_FIXED, FROM_FIXED, mult, etc and replace them with a class with the correct constructors / operator overloads? Then your code doesn't ever need to be aware of the special fixed point math and horrible syntax everywhere and everything just works?

Yes it can. I’ve seen it done properly only once though. You still have to pay attention to avoid overflows

Re: Neo Geo Dev: Fixed Point Numbers

#29

Post by BearOso »

Multiplying without having a larger intermediate is much more complex than the article states. You have to use the commutative property of multiplication and split the whole and decimal parts of each number out, otherwise you're stuck with single digit whole numbers or only multiplying fractions.

So you'd take

  A.a * B.b and split it into A*B + A*b + a*B + a*b
Or

    out = ((A >> fixedbits) * (B >> fixedbits) > fixedbits) * b)
        + ((B >> fixedbits) * a)
        + ((a * b) >> fixedbits);
If you can get away with a little less precision and smaller whole numbers, you can avoid some of the multiplications by just doing this, which is quite common:

    (A.a >> (fixedbits / 2)) * (B.b >> (fixedbits / 2))

Re: Neo Geo Dev: Fixed Point Numbers

#30

Post by vardump »

VyseofArcadia wrote: post #11
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.

For performance sensitive code memory bandwidth is very often the limiting factor, thus compressing values tends to make a lot of sense. The number of CPU cores is increasing much faster than memory bandwidth.

So not necessarily completely unnecessary.

Post reply on HN