Fun stuff - subbed. I stumbled upon this as I'm writing some fixed-point for an ATMega328 microcontroller. I'm using "Q15.16" format in this case, in my motor control code. It is way faster than floats, especially when I also approximate the sine function using parabolas. Keep up the good work; will check out what else is on your channel.

Really impressed with the presentation and professional set up, the clear work on squared paper and it's well explained. Definitely heading into a level of explanatory quality that a certain UK university that specialises in computer files might put out :D Looking forward to the next coding video :D

One minor correction, the screen is 320 pixels across... You're using a mode that only uses 256 pixels across... :-P And that's before we discuss the half-width pixel mode... :-D -Dx

There is a much simpler scheme (at least in concept). JUST DON'T DO FRACTIONS AT ALL! How to do this & get reasonable accuracy? Up front, declare a small unit that is "smaller than max permitted calculation error" & do all calculations in integer quantities of that unit. In game, you may choose say 1/10000th (or maybe better 1/2^n) of the playing field's dimensions. There is no "fixed point" (unless you consider the one right of the LSB the point). For the money example, let the quantities be in pence. When units are dimensionless (such as angle), choose unit that is 1/(2^n) of a full rotation. You simply ignore all carries beyond the nth bit when doing that rotation math. This "retro math" should not be retro! For example in computer aided design, integer meth should be used. Floating point math is nothing but trouble. It is very important in CAD that tests for equality work (is the cursor EXACTLY on that "handle"? Is that line & arc "connected"?) Floating point causes quantities that can never be "equal" so the thing you just placed, you can never "grab" again because you can't get the cursor EXACTLY on it. There is also the famous problem of "leakage" in PC Paint app with the paint roller, because line endpoints don't exactly match up. Endpoints of arcs other than 0°/90°/180°270° can't be exactly on line endpoints, if they are specified by center location, radius, & start/end angles. The floating point "solution" is to add "slop" in the calculation (if abs(A - B) < some small number then...). The slop "is small enough unless it is too small". If I move something around in CAD workspace, its (X,Y,Z) parameters change in precision! And no, fixed point or integer math CAN & SHOULD be used for trajectory calculations! The problem with floating point is that it has resolution that differs with the distance from zero. If I put (0,0,0) at the center of the sun, what about when I am near Jupiter? Resolution & precision will degrade! Now I have a system with precision that depends upon where I choose (0,0,0). Floating point is for quick scientific calculations for those too lazy to properly scale their units.

Enjoyed this. Look for the cheats! Look up tables.

How would this apply in creating a world like Nintendo 64 if there was no FPU? What if you had a very fast powerful fixed point DSP instead? Could you make a Mario 64 or better yet the faster Mario kart 64? Thank you for the great video 😀

To be pedantic representing negative in binary isn't inherently different to decimal. I could write -01011010. The computer representation of a negative is different to how we write it. Well it can be, and generally is in practice.

good one!

I want to make a 3D engine that has a ps1 aesthetic so this is essential for me.