[midnightclubbed]

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.

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.

[holmium]

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.

We have a kinda outdated document of weird IDO behavior which is worth a read if you want to trigger some PTSD: https://hackmd.io/vPmcgdaFSlq4R2mfkq4bJg#Compiler-behavior

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