Hacker News Reader

Comment by rdlw | Hacker News Reader

If anyone is interested in new projects for N64 hardware, Kaze Emanuar has an amazing series about optimizing Super Mario 64 to run incredibly complex romhacks on original hardware.

Interestingly, SM64 is usually throttled by memory speed. This means that using 'inline' is detrimental to performance, since making the program larger can cause another read from memory.

Here's an overview video, he has many more specific videos about specific topics:

https://youtu.be/t_rzYnXEQlE?si=6yNnsTxOr7M5v4ub

View on HN

Romhacks are typically modifying the compiled binary ROM image. Kaze' work is based on the painstakingly disassembled code from the n64decomp project[1]. He's working in C, modifying the game and compiling it again for the original hardware. Not sure I'd call that a "romhack".

Great videos though!

[1] https://github.com/n64decomp/sm64

From a player's perspective, I do think they tend to be called romhacks if they are based on an existing game, although I agree that's selling the project short as it's based on the decompiled source with heavy changes made.

It's sort of been a smooth transition from literal ROM hacks, to hacks with custom assembly, to hacks that are compiled from source, but the name has stuck.

Developers for Nintendo consoles have been using C the whole time, even moreso after the SNES. I can't imagine how long it would take to make a N64 game if I had to do it all in assembly.

A decompilation of Super Mario 64 was only completed a few years ago; before that romhackers were indeed using assembly. The homebrew scene makes fully original games from scratch in C, but romhacks are alterations of existing games (although decomp blurs the lines between the two communities).

I highly doubt there was a readily available C compiler for the 6502 in the 1980s. In any case the idea that developers were widely using C pre N64 is bull. Even in the SNES era it was the minority.

I believe Hudson had a C compiler back then... if not, go check out a hexdump of some Koei games (Nobunaga's Ambition 2 comes to mind), you'll see text strings with the %s token... pretty sure those would only come from C.

So a handful of non graphically intense RPGs from a relatively obscure/cult publisher doesn't really contradict minority though. That particular game was released in early 1990, relatively late into the life of the NES and not exactly a first party title. By 80s, I meant more coincident with the release of the system.

> you'll see text strings with the %s token... pretty sure those would only come from C.

There is nothing inherent in % escaped substitutions that unequivocally implies C. You could pretty easily write an asm port of a basic printf function if one wanted to reuse previously translated strings. Not saying C wasn't used for the NES port of this title, but this by itself isn't as strong a clue as implied.

> You could pretty easily write an asm port of a basic printf function if one wanted to reuse previously translated strings.

In fact, the function for printf used to be implemented in assembly on Unix. In this link, the actual implementation is in doprnt.s, and the function printf (in printf.c) just passes its arguments to the function _doprnt. In V6 Unix, it was the same for scanf, but V7 seems to have replaced it with a C implementation.

http://tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/libc/stdio

> Developers for Nintendo consoles have been using C the whole time

It was only done with assembly on the NES.

So rust should solve all their problems right?

"Show HN: Ghidra Plays Mario" (2023) https://news.ycombinator.com/item?id=37475761 :

[RL, ..., MuZero unplugged w/ PyTorch ]

> Farama-Foundation/Gymnasium is a fork of OpenAI/gym and it has support for additional Environments like MuJoCo: https://github.com/Farama-Foundation/Gymnasium#environments

The Mario64 game can be won with a minimal number of stars;

> Farama-Foundation/MO-Gymnasiun: "Multi-objective Gymnasium environments for reinforcement learning": https://github.com/Farama-Foundation/MO-Gymnasium

Ghidra may or may not be useful for e.g. gadgets with mario64

Return-oriented programming > On the x86-architecture: https://en.wikipedia.org/wiki/Return-oriented_programming#On...

Although you're semantically correct, I do want to point out that the final game/mod will probably be distributed as a patch against the original rom - that's quite romhack-y if you ask me ;-)

> new projects for N64 hardware

There's an entire community doing N64 homebrew: https://n64brew.dev/wiki/Main_Page , including a faction who are working on a Rust SDK (basic demo: https://youtu.be/XmlmvRrRFqs).

I know a lot less about the homebrew community but it's also very cool! Do you know of a big project that would be an interesting entry point for getting into the community?

AFAIK most homebrew games tend to be the product of lone developers, rather than large collaborative efforts. I could be wrong though; there's a Discord linked on the wiki that you could ask in for ideas.

I love what he did, but it seems like his recent stuff is only running his romhack. Did he ever make a build of the original Mario 64 with all his peformance fixes, so the original game content can run at 60 FPS on a real N64?

No, and he made a video about it. Basically he worked on the optimizations together with his modifications. He should've done a separate branch on the codebase with only optimizations on the original code

He says he'll port his performance optimizations to the original game once he's done with his game / romhack. Otherwise he'd have to always update two codebases when he finds a new optimization.

Reply on news.ycombinator.com