fixed point is taught wrong.

[eniko@mastodon.gamedev.place]

fixed point is taught wrong. instead of saying "to multiply two fixed point values you have to multiply them then shift them back into position" what it really should be is "when you multiply two fixed point values the result has a fractional precision in bits equal to the sum of the fractional precision of the two fixed point types multiplied"

[eniko@mastodon.gamedev.place]

this not only makes it easy to see *why* you have to shift (the fractional precision increased, so if you want to keep a lower one you have to shift) but it also makes it clear how multiplication between two fixed point types with different fractional precision works

[eniko@mastodon.gamedev.place]

if you multiply a fixed point value with 2 bits of fractional precision and one with 4 bits you wind up with a result that has 6 bits of fraction. if you want a result with 3 bits of fraction you shift right by 6-3=3 bits

this is easily understood, but only if the underlying concept is properly explained from the start

[jvmguy@mindly.social]

@eniko it’s a fun exercise to generalize that to mixed bases and mixed precision. Like a ternary number with 3 fractional digits and a binary number with 5 fractional digits yielding a base 12 number with 3 fractional digits.

No, I have no use case for it. That’s just where that comment reminds me of.

[eniko@mastodon.gamedev.place]

this also makes it easier to see that if you're transforming a fixed point type into another fixed point type via multiplication (like position * position = edgeweight for a rasterizer) you may want to not shift at all if you want the resulting fixed point type to represent the transformation precisely without any rounding

[jvmguy@mindly.social]

@eniko it leads to p-adic numbers, which are a lot of fun.

[gabrielesvelto@mas.to]

@eniko I remember reading about fixed-point math in asm tutorials that date back to the '90s and they made this clear with gorgeous ASCII drawings. I wonder what kind of resources show up today in a search and why they fail to explain this part

[lottievixen@toot.cat]

@eniko

I like your funny words magic fox

I understand nothing of precision almost everything I've ever done, has not needed to strictly worry about types apart from java but that felt different

I have a book on C programming on my floor I should probably get to at some point...

[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.