Rodrigo Copetti

That post introduced me to both WebGL and reverse engineering back in the day. I remember reading it years ago and asking myself "seriously, is it that easy to do 3D in a browser???". The web as an app platform is not without its issues, sure, but for quick prototyping being able to just write some JS and have instant access to plenty of APIs is awesome.

Last year I decided to finally break out of the browser and get into actual PS1 homebrew. Unfortunately the state of the scene wasn't, and to some extent still isn't, that great: most homebrew games are still made using what's basically a modded version of the original Psy-Q SDK, which is rather limited in many ways. I started contributing to an open-source PS1 SDK instead [1] by first adding a dynamic linker, then revamping the build system entirely and now building a custom high efficiency FMV playback library (totally not inspired by pl_mpeg of course) that combines the hardware accelerated MJPEG-like decoder with the GPU's alpha blending capabilities. I'm also working with a few other people on reverse engineering one of the most famous PS1-based arcade systems, the Konami System 573.

It's a shame the PS1 isn't receiving the attention other consoles are getting in the homebrew scene. The hardware is architecturally simple yet powerful [2], but I guess nobody wants to fiddle with 120mm polycarbonate circles anymore.

[1] https://github.com/Lameguy64/PSn00bSDK
[2] https://www.copetti.org/writings/consoles/playstation

You're very welcome.

Computer graphics has a very interesting history, and like many things, there's a lot to learn from studying it. Surprisingly, many techniques and principles are still relevant to this day.

Thankfully, the Internet is full of documentation, post-mortem accounts and reference implementations to learn more about all this.

Here's a bunch of random noteworthy things and references I forgot to link (sorry for potentially digging rabbit holes):

The best information tends to come from official documentation detailing almost everything you want to know about the inner workings of systems. Additionally, unofficial community documentation can also be of great quality and complement official sources.

The architecture overview posts from Rodrigo Copetti (https://www.copetti.org/writings/consoles/) pack a lot of accurate information at a glance, and are a great starting point if a specific topic piques your interest.

The Resident Evil 2 microcode post-mortem: https://ultra64.ca/files/other/Game-Developer-Magazine/GDM_September_2000_Achieving_Full-Motion_Video_on_the_Nintnedo_64.pdf

Improved lighting, reverberation, Dolby surround and MP3 microcodes from Rare: https://youtu.be/jcIupBUAy98?t=41

H.264 decoding microcode: https://www.reddit.com/r/n64/comments/gpwxx0/my_dragons_lair_port_now_features_the_first_ever/

The Reality Signal Processor's programming guide:…

Impressive because a lot of N64 devs at the
time didn't do these now-common things

Absolutely, but it's also worth noting that these techniques might not have been viable in the context of a game (or at least, most games) anyway.

The author himself addressess this at the end of one of the videos and concludes that it might be a stretch unless a game was designed specifically around this rendering strategy.

He skips the N64's hardware Z-buffer (to conserve bandwidth) and DIY's it, which works for the demo because the demo room has exceedingly simple geometry. I don't know that this approach would work once you involve player models with 500-700 polys as seen here: https://www.copetti.org/writings/consoles/nintendo-64/

The transition between texture detail levels is also a bit jarring: it's an amazing demo, but might be too jarring or frustrating for a game.

On the positive side, the demo runs in the N64's hires mode, which could be avoided to free up some perf. Also the author admits that the highest detail level of the textures is not something that would necessarily be needed for a game.

One also wonders if a hybrid approach would work: "megatextures" and DIY z-buffering for the scenery, trad rendering for the characters. I don't know if that is possible.

> Old Nintendo consoles like the N64 or the GameCube/Wii didn't have programmable shaders.

The N64 did in fact have a fully programmable pipeline. [1] At boot, the game initialized the RSP (the N64’s GPU) with “microcode”, which was a program that implemented the RSP’s graphics pipeline. During gameplay, the game uploaded “display lists” of opcodes to the GPU which the microcode interpreted. (I misspoke earlier by referring to these opcodes as “microcode”.) For most of the console’s lifespan, game developers chose between two families of vendor-authored microcode: Fast3D and Turbo3D. Toward the end, some developers (notably Factor5) wrote their own microcode.

[1]: https://www.copetti.org/writings/consoles/nintendo-64/

A little more than just a multiplication instruction (the 68000, used in, say, the Sega Mega Drive, had one of those too). Have a look at https://www.copetti.org/writings/consoles/playstation/, and in particular, read about the GTE - it offered quite a bit of hardware support for 3D math.

Also, even though it didn't handle truly 3D transformations, the rasterizer was built for pumping out texture mapped, Gouraud shaded triangles at an impressive clip for the time. That's not nothing for 3D, compared to an unaccelerated frame buffer or the sprite/tile approach of consoles past.

> We also should not forget the Sega Genesis.

Thank you - I forgot about the 68000-based consoles :) Ironic, given how many great articles about console architecture[0] have done the rounds recently! The Atari Jaguar and Sega Saturn also had 68000s among the many processors in their complex architecture, albeit explicitly as a sound coprocessor in the Saturn.

Edit: I guess I didn't exactly forget - I was restricting my mental search to the 68030 specifically. But all the 680x0 systems were cool :)

[0] e.g. https://www.copetti.org/writings/consoles/mega-drive-genesis/