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

31–40 of 49 posts

Re: Neo Geo Dev: Fixed Point Numbers

#31

Post by VyseofArcadia »

vardump wrote: post #30
VyseofArcadia wrote: post #11

Earlier quoted context omitted.

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.

I expect it will have some effect given that we anticipate having ~1000 instances of that data structure alive at worst case, at least dozens at any given time.

Re: Neo Geo Dev: Fixed Point Numbers

#32

Post by edflsafoiewq »

thequux wrote: post #19
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…

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

The most common place is probably image/audio processing. Sample values are usually always quantized, even in intermediate stages. Decoding a JPEG for example is a bunch of fixed point math.

Re: Neo Geo Dev: Fixed Point Numbers

#33

Post by Joker_vD »

BearOso wrote: post #29

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

It's such a shame that multiplication in C (or most other languages, really) doesn't have its natural type (intM, intN) -> int{M+N}. Instead, you have to recover the higher half of the result either by doing additional narrow multiplication yourself, or by using some compiler intrinsic.

Re: Neo Geo Dev: Fixed Point Numbers

#34

Post by jnwatson »

FYI, the multiply assert isn't guaranteed to work and can be compiled out by a sufficiently smart compiler. Overflow of signed values is UB, the compiler can assume that UB is impossible, therefore the expression in the if resolves to false.

Re: Neo Geo Dev: Fixed Point Numbers

#35

Post by jnwatson »

Joker_vD wrote: post #33
BearOso wrote: post #29

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

It's such a shame that multiplication in C (or most other languages, really) doesn't have its natural type (intM, intN) -> int{M+N}. Instead, you have to recover the higher half of the result either by doing additional narrow multiplication yourself, or by using some compiler intrinsic.

Gcc can frequently tell what you're trying to accomplish and emit the correct instructions. Still I agree it would be ideal if this were explicit.

Re: Neo Geo Dev: Fixed Point Numbers

#37

Post by city41 »

wk_end wrote: post #25
city41 wrote: post #20

Earlier quoted context omitted.

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

But that's basically what fixed point is, no? Half pixels is fixed point with a single bit for decimals. Quarter pixels is two bits, and so on. I think the disadvantage is you now have to think in a strange unit that isn't intuitive. For my game I tend to think in screen sizes for things. Thinking in screen size*factor would be harder I think. Fixed point is basically just doing that for me and hiding the details really.

To be fair, rereading the post I realize I did make it sound like you would only need this for positioning sprites. I'll see about rewording it.

Or maybe we're both talking about the same thing and you're taking a different approach. That is fair too.

Re: Neo Geo Dev: Fixed Point Numbers

#38

Post by ack_complete »

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…

Address calculations are a place where fixed point can still have an advantage -- it's often less latency and fewer ops to step a fixed-point accumulator and shift it into an address offset on the integer units than to step a floating point accumulator, convert it to integer, then move that over from the FP/vector units to the integer units.

Re: Neo Geo Dev: Fixed Point Numbers

#40

Post by wk_end »

city41 wrote: post #37
wk_end wrote: post #25

Earlier quoted context omitted.

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

But that's basically what fixed point is, no? Half pixels is fixed point with a single bit for decimals. Quarter pixels is two bits, and so on. I think the disadvantage is you now have to think in a strange unit that isn't intuitive. For my game I tend to think in screen sizes for things. Thinking in screen size*factor would be harder I think. Fixed point is basically just doing that for me and hiding the details rea…

Yeah, we're technically talking about the same thing - just a different way of thinking about it.

When I was learning retro game dev (mostly Game Boy), I found fixed point very intimidating. Reading stuff like "the player will move at 1.5 pixels per frame, and to store the decimal point we'll use this special format where certain bits represent the fractional part and certain bits represent the integer part" scared the heck out of me when I was still, like, coming to grips with binary representations at all.

Whereas "the player will move at 3 half-pixels per frame" is just a really straightforward conceptualization. The data representation is the same, the code to convert from half-pixels to pixels is the same, but one way of understanding it feels very technical and abstract.

Especially when working in assembly language (like I was), where you don't really have any kind of typing mechanism, it never really made sense to build a fixed-point data type abstraction.

And, to be clear, I'm not trying to give you, specifically, any guff for this; it's as fine an article on fixed-point that there is.

Post reply on HN