Finding the BEST sine function for Nintendo 64

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.

in “SNES Coprocessors: DSP-1 and Friends” · View on HN

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.

in “SNES Coprocessors: DSP-1 and Friends” · View on HN

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

in “How do computers calculate sine?” · View on HN

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)

in “Even Faster Asin() Was Staring Right at Me” · View on HN

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: - ▶ this video - [link]

in “Less Slow C++” · View on HN

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. ▶ this video

in “RIP Google Groups Dejanews.com Archive” · View on HN