One tidbit that may be of interest (or not) is that if you see doubles being used in N64 C code it is almost certainly accidental. Doubles were slow on the N64 mips CPU but the mips C compiler would happily output them and promote surrounding floats to keep the precision it assumed you wanted.
Looks ok, except the constant is a double. Performance killer.
You'd get pretty good at seeing the missing f (and we eventually wrote some simple tooling to find functions using doubles) but I'm sure a number of games shipped with accidental double calculations.
hahah yes the "0.0f" is different from "0.f" is different from "0.0" is different from "0" is a great IDO meme as well. One of the changes we had to make when we started to support the PAL release, which was compiled at -O2, was to go back and change some constants from explicit "1.0f" to "1" to get the code-gen to match. IDO -O0 didn't care so long as you got the f32 vs f64 constant correct. But, IDO -O2 has different codegen.
The wonders of C constants. Sometimes IDO can do the conversion at compile time, and sometimes it can't. But, the compiler will treat things "0.0f" and a compile-time "(f32)0.0" as different constants for code-gen purposes.
Also, since SGI/MIPS/IDO was from Stanford (I think...?), there is actually a surprising amount of published papers on IDO's compilation model. Which comes in handy if you are trying for the ultimate joke of decompiling the written-in-pascal compiler into C: https://github.com/n64decomp/ido
float myValue = x_float + y_float * y_float * 3.0;
Looks ok, except the constant is a double. Performance killer.
You'd get pretty good at seeing the missing f (and we eventually wrote some simple tooling to find functions using doubles) but I'm sure a number of games shipped with accidental double calculations.