Hacker News Reader

Comment by phoboslab | Hacker News Reader

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

View on HN

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.

"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 ;-)

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?

Reply on news.ycombinator.com