Hacker News Reader

Comment by devwastaken | Hacker News Reader

On the note of N64, N64 emulation, especially its GPU portions, are still incredibly hard to get right and has been fraught with problems for a long time. On modern systems the performance still can be less than desirable. One of the saving graces to this has been GlideN64, https://github.com/gonetz/GLideN64/releases

But even that is still in a lot of development. There's a lot of magic the N64 hardware uses apparently.

View on HN

Reading up on the N64 hardware a bit gives the impression that it was ahead of its time, more akin to the shader based pipelines of today than the kinds of hardware that was starting to show up on PCs at the time.

https://en.wikipedia.org/wiki/Reality_Coprocessor

This is the impression that most people end up with, but it's not really like shaders at all. My understanding is limited, but it seems the microcode serves a somewhat limited role in the graphics pipeline, something along the lines of decoding data and controlling hardware registers.

In most contexts, the RSP handles all T&L, making it analogous to modern vertex shaders.

This was pretty standard at the time - everything had a programmable DMA controller, which was capable of extensive data transforms, and often there had been some vector ALU stuffed in. The difference with modern arcs is that it was sitting in front of fixed function hardware. After you did whatever you wanted with the data it still went into the fixed function hardware and came out as pixels on the screen. You could have the same data pre-computed and fed to the GPU for the same result.

In modern architecture, there are programmable ALUs inside the fixed function hardware and its fixed functions are very limited, it's just triangle setup and color/depth buffer, usually. The GPU input is just a list of indices, which is transformed by the programmable processors inside.

RSP microcode switches are extremely slow -- they're designed to be programmed once when the game boots up, but some games switch back and forth between a 2D and 3D microcode during different modes. So they're not like shaders in that sense -- shaders are designed to be switched every frame. And keep in mind that the RSP doesn't handle blending. The RSP can kind of be compared to a vertex shader, and the RDP is the fixed-function unit that handles rasterization, interpolation, and blending. It's "programmable" in a glTexEnv sense, but you can't upload your own code.

FWIW, a lot of other 'fixed function' GPUs were internally little custom vector processors too, they just weren't exposed to external developers.

There's also a weirdly huge amount of drama in the N64 emulation space, so a lot of the more talented people have left over time. It's not that tremendously hard to build an N64 emulator, it was just a weird social space for the longest time and nobody really wanted to put up with it.

What kind of drama is there? Seems like a weird place for there to be drama about anything.

The emulation scenes are... odd. Not quite free software. Egos and entitlement on the part of the users a lot of the time.

The GameCube scene was excellent, however

You can broaden the scope to console hacking in general. Even if drama's your thing, you probably won't last more than a few years.

I wasn't very clear; yeah, exactly! I was talking more about the broader console hacking scene. It's a mess, heh.

Because there's just one emulator, dolphin. I'm unaware of any other major ones?

Exactly. The GameCube/Wii emulation scene does not have any of that drama like the N64 scene has, which leads to everyone in the scene being happy to work together on one single emulator instead of everyone working on their own projects.

Reply on news.ycombinator.com