Kaze Emanuar
2 HN recommenders · recommended in 7 months, 2023–2026
26:41 · 418K views · Jun 24, 2023
Kaze Emanuar searches for the best sine approximation for the Nintendo 64, comparing the lookup tables in Mario 64 and Ocarina of Time with polynomial alternatives. It walks through numerics and 3rd, 4th and 5th order approximations.
Cited in discussions of sine implementations and whether lookup tables beat computation on memory-bound hardware.
8 comments from Hacker News
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): this 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: this 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.
You might also find this video interesting: "Finding the BEST sine function for Nintendo 64" this video
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. this 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] this video