Finding the BEST sine function for Nintendo 64

You might also find this video interesting: "Finding the BEST sine function for Nintendo 64" [VIDEO]

Yeah, I used a ton of trig tables for software renderers in the late 80s/early 90s, but I'm just throwing ideas out there, since I've seen a lot of really great optimizations recently that were mostly missed during that time. This guy puts a lot of work into figuring out if there is a faster way to do trig calcs on the N64 than was used in SM64 (spoiler: there is): [VIDEO] Jez (CEO of Argonaut) once offered me an interview for the Starfox/DSP team, so I almost worked on this thing. He was very active on the coding groups on Usenet around that time.

This is the video that got me thinking: [VIDEO] I was writing software texturers etc in the late 80s/early 90s, and even recently I've seen x86 people humble me with all sorts of info that I had no idea about at the time, concerning pipelining etc. I would just sit all day randomly reordering assembler instructions and reprofiling teapot renders to see if anything would move the needle.

I always used to use lookup tables for sin/cos in the days of software 3D rendering. The developers of Mario 64 did the same, but this video dives into those LUTs and brings them into question: [VIDEO]

These are the sorts of questions I would like to solve. Were we mistaken in using fixed point for everything? Are there actually faster ways of doing most of these tasks. That recent Mario 64 rewrite has me questioning everything. At least Nintendo's first party developers made the same mistake, and they had the hardware guys right there. [VIDEO]

It's not useless if it's good enough for the problem at hand. Kaze Emanuar has two entire videos dedicated to optimizing sin() on the Nintendo 64 and he's using approximations like this without issues in his homebrew: - [VIDEO] - [LINK]

Not just modern machines, the Nintendo64 was memory bound under most circumstances and as such many traditional optimizations (lookup tables, unrolling loops) can be slower on the N64. The unrolling loops case is interesting. Because the cpu has to fetch more instructions this puts more strain on the memory bus. If curious, On a N64 the graphics chip is also the memory controller so every thing the cpu can do to stay off the memory bus has an additive effect allowing the graphics to do more graphics. This is also why the n64 has weird 9-bit ram, it is so they could use a 18-bit pixel format, only taking two bytes per pixel, for cpu requests the memory controller ignored the 9th bit, presenting a normal 8 bit byte. They were hoping that by having high speed memory, 250 mHz, the cpu ran at 90mHz, it could provide for everyone and it did ok, there are some very impressive games on the n64. but on most of them the cpu is running fairly light, gotta stay off that memory bus. [VIDEO] (Kaze Emanuar: Finding the BEST sine function for Nintendo 64)

I find him a bit abrasive even though I enjoy his videos (and actually submitted this a couple days ago). It's alot of cool work, but the way he presents it to laymen is kind of annoying. Even if he had never heard of data orientated design in the original video series (where he claims to not know what its called when you organise data to improve throughput) he should by now because clearly he does huge amounts of research. (Case in point at 9:30[0] he talks about localised memory patterns as though he's the first to come up with it). Again, love his work, watch every video and even submit to HN because I think others would. But that doesn't mean he's not very annoying. [0] [VIDEO]