Live data from Hacker News

Super Mario 64 has been decompiled

github.com

171–180 of 180 posts

Re: Super Mario 64 has been decompiled

#171
post #48

Earlier quoted context omitted.

Zelda OoT was based on the Mario 64 engine

That makes a lot of sense as it's not like they had a lot of 3D engines for the N64 during launch lol. Wonder if Pilot Wings (for example) also shares similar rendering pipeline.

I really don't think you can refer to these games as using different 3D engines. The 3D capabilities are ingrained in the N64. The SNES likewise didn't have any 2D engines (except maybe for when the extension chips were used). Perhaps what we're talking about are the game logic engines.

Re: Super Mario 64 has been decompiled

#172
post #74
post #55

Earlier quoted context omitted.

Super Mario 3D World's architecture goes back to Super Mario Sunshine. Some parts go back all the way to Super Mario 64, but not the object / actor management. The ring buffer isn't really emulating OAM, either. You can trace the evolution of "LiveActor" all the way through until it ends up in Super Mario Odyssey. Sunshine - https://github.com/shibbo/Corona/blob/master/include/actor/T... Galaxy 1 - https://github.com…

> The ring buffer isn't really emulating OAM, either. I mean, you're right, it's not a literal implementation of OAM in the sense of controlling the same things OAM controls. I was speaking kinda metaphorically. NES/SNES OAM was useful for reading back entity physics data (because it gave objects X/Y position registers) which meant that developers (incl. Nintendo themselves) often chose to rely on the OAM-object "com…

> developers (incl. Nintendo themselves) often chose to rely on the OAM-object "components" of a entity as the canonical handle for tracking the entity in the game physics

I don't know how the SNES worked, but AFAIK most NES games did not track objects in this way. Instead, the game engine maintained its own buffers containing object state and copied necessary information to OAM every frame.

OAM only stored graphics state for the rendering hardware, which is not a convenient form for the game engine for a number of reasons. For instance, objects are nearly always composed of several OAM sprites placed next to each other, objects that are not visible during a given frame are not present in OAM, and a single animated object can switch between so many different graphical forms that it would be complicated to identify which object corresponds to a graphics tile from OAM. Additionally, OAM doesn't have extra room for non-graphical object state (like behavior timers or velocity information).

Re: Super Mario 64 has been decompiled

#173
post #84
post #77

Earlier quoted context omitted.

On a distro like debian you can even use it to build-and-run userspace binaries for an unrelated architecture (some chroot magic was required last time I checked).

You (1) use binfmt_misc to tell the kernel to use `qemu-ARCHITECTURE` to run binaries for that architecture, then (2) make sure you also have all of the libraries that the binary is linked against, then that binary executable should just run seamlessly. Now, if your ARM binary was compiled to look for libc at /lib/libc.so, but /lib/libc.so is the host's x86 libc, then that obviously won't work; and the easiest way to…

I've used this to run some 32-bit Linux binaries under Windows Subsystem for Linux (WSL), which only natively supports 64-bit binaries. (Recompilation for 64-bit was not an option.) It wasn't ideal but it did work smoothly for the most part. I just used `dpkg --add-architecture i386 && apt update && apt install libc6:i386` rather than creating a separate chroot. I did have to edit the binfmt registration to remove the 'OC' flags set up by the qemu-user-binfmt package, since these aren't supported by WSL, and manually enable the i386 binfmt which is blocked by default on amd64 platforms. There is also a persistent SIGSEGV in one particular binary which may not be related specifically to running under QEMU.

Re: Super Mario 64 has been decompiled

#174
post #118
post #4

As an amusing side-effect, the team working on this effort also implemented IRIX userland support for QEMU since the original N64 toolchain ran on IRIX on the SGI Indy, and they need the original compilers to verify functional equivalence of their source: https://github.com/n64decomp/qemu-irix .

I wrote to SGI in high school asking for some info on their computers and they sent back a stack of beautifully printed, full-color brochures. The Indy had a webcam, which was very rare in those days. Also included was a brochure on the Indigo workstation, which Industrial Light and Magic used for Jurassic Park, etc. Nintendo is a little mysterious when it comes to what their actual tooling was, but I remember Donkey…

Rare: The Inside Story - The Retro Hour EP180 https://www.youtube.com/watch?v=ED7rX3ZIBoE

"We get the inside story on the legendary Rare with an all-star panel - David Doak (GoldenEye), Chris Marlow & Shawn Pile (Conkers Bad Fur Day, David Wise (Donkey Kong Country series) and Kevin Bayliss (Battle Toads/Killer Instinct)"

Re: Super Mario 64 has been decompiled

#175

"For Windows, install WSL and a distro of your choice and follow the Linux guide." I love these instructions! Also, I'd love to see this converted to a native executable. I wish Nintendo would actually allow that, although I'm sure they wouldn't.

If I remember correctly, some time ago I saw a video from someone who managed to build a substantial part of SM64 as a native executable and was able to verify that tool-assisted runs ran perfectly on in it (hence it being accurate). The video displayed the game as a wireframe and had no audio, since those parts are surely tied to the N64 hardware. I can not figure out the right keywords to find it again, but you may…

https://www.youtube.com/watch?v=7VbTe7U-bo4

Re: Super Mario 64 has been decompiled

#176

Earlier quoted context omitted.

I have an SGI rotting in my garage, what's amazing about them is the quality of the monitor. For CRT displays, the best damn monitor I ever experienced, just CRISP. The Nintendo 64 had a MIPS R4300 chip, the SGI Indigio also used the MIPS Rchip, the early one had R4000/R4400 chip, the later ones R8000+ chips. I can only speculate that by using SGI, you could run some of your non specific N64 code locally and debug fa…

Can you link more info about Sony's devkits using FreeBSD? BSD would've been a strange choice as the Playstation 1 debuted on December 3rd, 1994. "FreeBSD 1" came out just 13 months earlier The Playstation 2 "TOOL" machines ran Red Hat for some of them, which was a bit more mature by 2001 The Playstation 3 and 4 though both run Net and FreeBSD under the hood internally though

The Playstation 1 "TOOL" actually ran windows [1]. A large success of the the PS1 however was the the "twin ISA" card dev kit, which could be plugged into any PC-Compatible for PS1 development, which drastically lowered the cost of development for the PS1.

Also BSD != FreeBSD, BSD 4.3 Net/1 (the first BSD released under the BSD license instead of containing AT&T code) was released in 1989.

[1]https://www.retroreversing.com/official-playStation-devkit

Re: Super Mario 64 has been decompiled

#177
post #171
post #48

Earlier quoted context omitted.

That makes a lot of sense as it's not like they had a lot of 3D engines for the N64 during launch lol. Wonder if Pilot Wings (for example) also shares similar rendering pipeline.

I really don't think you can refer to these games as using different 3D engines. The 3D capabilities are ingrained in the N64. The SNES likewise didn't have any 2D engines (except maybe for when the extension chips were used). Perhaps what we're talking about are the game logic engines.

Ah, yeah that makes sense (I know more about SNES internals then N64).

Re: Super Mario 64 has been decompiled

#178
post #87
post #47

Earlier quoted context omitted.

Is a raspberry pi a good-enough platform to run N64 1080P games on?

N64 only supported up to 240p, or in rare cases, 480i, which is basically the same thing computationally. Displaying on higher resolution just involves scaling (or up-sampling, but at that kind of resolution jump scaling is probably more appropriate). I haven't tested N64 games on a RPi personally, but I imagine it would have no trouble with it, and there seem to be several retro-gaming projects that involve N64 game…

Super Mario 64 is a 3D game. The emulator can render the polygons at any resolution. The 2D textures should be replaced or carefully scaled, though.

Re: Super Mario 64 has been decompiled

#179
post #107

This is cool and illegal. What makes me envy of the West (or countries other than Japan in general) is that this kind of attempt is somewhat condoned and praised, while in Japan there would be a vocal outcry and finger-pointing campaign (with some media exposure) to the point where the author would be forced to shut down the project. It's a blessing that people can pursue things like this, and it's a huge shame that…

Your use of the term “open space” is interesting. The Comic Market could probably be considered a closed space but 600,000 annual attendants at a convention that glorifies and commercializes copyright infringement (to a good extent) suggests that there’s spaces in Japan for this sort of thing.

Doujin works organically grew underground before the internet era. I think the sole reason that doujin work is now somehow tolerated is that they're not minority anymore. They're big enough to gain public acknowledgement, but if a similar activity is attempted today by a much smaller group, they would be crushed by the public. It sucks to be a minority in Japan.

Re: Super Mario 64 has been decompiled

#180

It's amazing the level of effort and work that has gone into this and here I'm trying to finish a 100 line side project. :-]

You can get a lot more done with a team of people who are also getting paid.

Who was funding this decompilation? Was it from the speedrunning community?
Post reply on HN