fixed point is taught wrong.

[eniko@mastodon.gamedev.place]

@gabrielesvelto i've read about fixed point math many times on the modern internet and i don't think i've ever seen this pointed out. i had to come to it on my own and it's not super intuitive

[rk@mastodon.gamedev.place]

@eniko i want to write a small library/toy language of sort to help me deal with fixed points math, mainly for embedded projects. the main problem i found is when you also need to account for the non fractional bits to avoid overflowing the integer type, and sometimes adjusting things have a ripple effect that is a pain to deal with. some side verification and a bit of code generation would really help. too bad that lately i am constantly overworked to allocate time for that tho!

[gabrielesvelto@mas.to]

@eniko and ofc this is also important for different types of fixed-point operations, like how you can do repeated divisions by multiplying by the reciprocal of the divisor where the reciprocal is just (1 << $precision) / $divisor

[lottievixen@toot.cat]

@eniko but more seriously.. uh this sounds cool but also legitimately.. out of my knowledge zone by quite a bit., right over my ears n tail.

[eniko@mastodon.gamedev.place]

@Rk yes, fixed point requires a lot of thinking about your exact problem domain and what the limits are before overflow occurs

which is why it's so vexing that it's usually explained so poorly because you can get way better results by having many different fixed point types with different bit layouts for different tasks, precisely so you can avoid overflow

but mixing different types is basically never explained

[eniko@mastodon.gamedev.place]

@gabrielesvelto it's also very important because with fixed point you constantly have to figure out what precision you want for a particular problem domain so that you know your limits and when overflow could occur

which means different types with different levels of precision are best but nothing ever explains it in a way where a newcomer would feel comfortable mixing different fixed point types, leading to worse results

[gabrielesvelto@mas.to]

@eniko indeed. I can see how that can be a problem for something like rasterization, where you need a certain amount of subpixel precision but not necessarily as much as what you need for dealing with geometry... but you're converting between the two if your entire pipeline is fixed-point so the problem does come up in relatively common situations

[gabrielesvelto@mas.to]

@eniko oh look! Some of that stuff is still available! I haven't found the 68000 ones but those are probably in .lha files on Aminet.. In the meantime check out some classic tutorials on software rendering like fatmap.txt, fatmap2.zip or texture.txt.

https://mikro.naprvyraz.sk/docs/Coding/1/
https://www.gamers.org/dEngine/rsc/pcgpe-1.0/

This stuff is an incredible resource to understand how things were done back in the day, what were the constraints and the reasoning around them.

[rfnix@piaille.fr]

@eniko that makes me realize I have no idea how to reason about fixed-point math. I never did that stuff in school, never had to use it in $dayjob and barely met some mentions of them in datasheets for electronic components or somesuch

[gabrielesvelto@mas.to]

@eniko hah, look at this stuff! This is a gold mine: https://flipcode.com/archives/articles.shtml

[gabrielesvelto@mas.to]

@eniko I'm bookmarking all these things and making sure they're on the Internet Archive too: https://www.modeemi.fi/drdoom/3dica/

[rk@mastodon.gamedev.place]

@eniko some years ago i helped with a project in a low energy context: once in a while a sensor would trigger an interrupt, waking up the device. not all the wake ups needed an action, to figure it out you would need to do a bunch of non linear calculations and react accordingly. using floats pushed the device over the maximum energy consumption, as it was powered with non rechargeable caps. fixed point math with an iterative solver outperformed fp, doubling the expected life of the device.

[eniko@mastodon.gamedev.place]

@Rk nice 😌

[rk@mastodon.gamedev.place]

@eniko sometimes the old techniques are the appropriate ones. too bad juniors are actively told that dealing with bits and low level concepts is not relevant and 'premature optimizaiton'. one of my clients has engineers with a terrible fear of exoteric concepts such as 'bit masks'... such is life!

[willflux@mastodon.social]

@eniko Teaching shifting as if it were fundamental to fixed point seems strange to me. My attempt to explain it back in 2020: “Multiplication works as expected too, but the product contains twice the number of bits. Multiplying two Q4.4 numbers results in a Q8.8 product” - https://projectf.io/posts/fixed-point-numbers-in-verilog/

[breakin@mastodon.gamedev.place]

@eniko I think often I've seen fixed point multiplication as being from X:Y * X:Y = X:Y, ie same precision. Increasing precision of the result means actually changing the type (which is ok like you say) but it is another operation. Maybe that is where the confusion come from from places that describe it. I like your view of it of course and it builds intuition.

[pmdj@mstdn.social]

@eniko @gabrielesvelto I seem to remember the "Graphics Gems" series of books containing a lot of great information on fixed point maths, including various useful algorithms. Unfortunately I'm pretty sure those books are long out of print (exorbitant prices anyway) - I read them at our university library over 20 years ago.

[gabrielesvelto@mas.to]

@pmdj @eniko I'm sure there must be copies on the Internet Archive

[oblomov@sociale.network]

@eniko one would expect that anyone familiar with hand calculations like long multiplication would be aware of that … aren't these things taught in like primary school?

[eniko@mastodon.gamedev.place]

@oblomov you still do a lot of long multiplication/division? Cause I haven't in 30 years