Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Super Mario 64 has been decompiled

github.com

Post reply on HN
Print view View original

81–90 of 180 posts

Re: Super Mario 64 has been decompiled

#81

Post by LukeShu »

yellowapple wrote: post #69
bri3d wrote: post #35

Earlier quoted context omitted.

QEMU is thought of as a hardware emulator, but supports "userland" emulation where the processor ISA is emulated but syscalls and memory are translated to the host OS.

I didn't even know QEMU could do that. That's insanely cool; kind of a weird combination of traditional virtualization and Wine.

One very cool thing that you can do with it is to use binfmt_misc to tell the kernel to use `qemu-arm` to run ARM binaries, then you can chroot in to an ARM device's filesystem from your x86 workstation, and all of the ARM binaries just work.

Re: Super Mario 64 has been decompiled

#82

Post by [deleted] »

tempsolution wrote: post #26
PhasmaFelis wrote: post #15

Earlier quoted context omitted.

Same as any other impractical-but-fun project that gets featured on HN. It's weird to me that people keep being surprised.

It's more an indicator that apparently either not many meaningful things happen (which I doubt) or somehow people use this a some retro-wanking where they imagine "Uh yeah back in high school I was also working on stuff like this, those were the days". What I am saying is that it doesn't surprise me people do these projects, what surprises me is that enough people care about them for it to make the front page of HN.

[deleted]

Re: Super Mario 64 has been decompiled

#83

Post by bscphil »

LukeShu wrote: post #81
yellowapple wrote: post #69

Earlier quoted context omitted.

I didn't even know QEMU could do that. That's insanely cool; kind of a weird combination of traditional virtualization and Wine.

One very cool thing that you can do with it is to use binfmt_misc to tell the kernel to use `qemu-arm` to run ARM binaries, then you can chroot in to an ARM device's filesystem from your x86 workstation, and all of the ARM binaries just work.

I've used this to `apt-get upgrade` a netboot Raspberry Pi installation from the server way faster than you can do it on the Pi itself.

Re: Super Mario 64 has been decompiled

#84

Post by LukeShu »

kanox wrote: post #77
yellowapple wrote: post #69

Earlier quoted context omitted.

I didn't even know QEMU could do that. That's insanely cool; kind of a weird combination of traditional virtualization and Wine.

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 get the libraries all sorted out is to use a chroot with OS install of the target architecture. If you do go the chroot route, you need to make sure that `qemu-ARCHITECTURE` is statically linked, because it won't have access to the x86 libraries it needs to run after the chroot(2) call happens (which is why most normally-dynamically-linked distros have a "qemu-user-static" package in addition to their normal "qemu-user" package).

But with a multilib scheme like Debian's, where all libraries get installed to /lib/ARCHITECTURE-TRIPLET/ instead of /lib/, then it should be possible to install all of the appropriate target libraries on the host system without a chroot! You "should" just need to configure APT to let you install packages built for that architecture. (I haven't actually tried this; I'm not a Debian user, but I am envious of their multilib).

Re: Super Mario 64 has been decompiled

#85

Post by derefr »

chc4 wrote: post #51
derefr wrote: post #9

One thing I've always been curious about: is there any sort of clear continuity of architecture or design patterns between the games in the Super Mario series? Yes, they're probably all from-scratch rewrites of the engine, but could each successive engine be said to be a "descendant" of a previous one, on a design level? One thing I know (and can be seen in this repo) is that SM64 emulates a version of the NES/SNES "…

Super Paper Mario uses an extremely similar engine as Paper Mario: The Thousand Year Door, which uses a slightly modified version of the Paper Mario 64 engine.

Intelligent Systems seems to have a good head on their shoulders for code reuse. Enough so that I would suspect that their Fire Emblem and Advance Wars series—when they were releasing concurrently—were the same engine underneath.

(Side-note: I've always wondered how the mini-games in IS's WarioWare series work—whether each game is entirely custom code, or whether they've come up with some sort of DSL for specifying reflex games. If the latter, I would bet that that has a decent genealogy too.)

Re: Super Mario 64 has been decompiled

#86

Post by proverbialbunny »

derefr wrote: post #9

One thing I've always been curious about: is there any sort of clear continuity of architecture or design patterns between the games in the Super Mario series? Yes, they're probably all from-scratch rewrites of the engine, but could each successive engine be said to be a "descendant" of a previous one, on a design level? One thing I know (and can be seen in this repo) is that SM64 emulates a version of the NES/SNES "…

Ring arrays are so useful it would be unheard of if those games did did not use them, regardless if it is ES/SNES "Object Attribute Memory" or something equivalent. Every game today and then "should" have one or more ring array in them, but sometimes a junior dev or one in a crunch will use a linked list in rare situations. A notable example is when Starcraft used a linked list that caused a difficult to reproduce bug when certain parts of the code were threaded. http://www.codeofhonor.com/blog/tough-times-on-the-road-to-s... (Found @ https://news.ycombinator.com/item?id=5751702)

Re: Super Mario 64 has been decompiled

#87

Post by chias »

urda wrote: post #47
ortusdux wrote: post #22

I am looking forward to the mods that this will enable. I highly recommend trying mario 64 on dolphin EMU at 1080P with a texture pack. A HD mod that added a few more polygons would really round out the experience.

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 games and use the Rpi.

Re: Super Mario 64 has been decompiled

#89

Post by [deleted] »

bjornsteffanson wrote: post #80
urda wrote: post #47

Earlier quoted context omitted.

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

I got a pi 3b+ as I romanticized the idea of it, but it struggles a bit with SM64. I just use OpenEmu on my higher-powered laptop and HDMI out instead. Pi format is still fun to tinker with and I encourage you to get one if you're at all interested. The 3b+ just wasn't the right tool for the job in my case. I haven't tried the pi 4, however.

[deleted]

Re: Super Mario 64 has been decompiled

#90

Post by derefr »

proverbialbunny wrote: post #86
derefr wrote: post #9

One thing I've always been curious about: is there any sort of clear continuity of architecture or design patterns between the games in the Super Mario series? Yes, they're probably all from-scratch rewrites of the engine, but could each successive engine be said to be a "descendant" of a previous one, on a design level? One thing I know (and can be seen in this repo) is that SM64 emulates a version of the NES/SNES "…

Ring arrays are so useful it would be unheard of if those games did did not use them, regardless if it is ES/SNES "Object Attribute Memory" or something equivalent. Every game today and then "should" have one or more ring array in them, but sometimes a junior dev or one in a crunch will use a linked list in rare situations. A notable example is when Starcraft used a linked list that caused a difficult to reproduce bu…

It's not that it's a ring array; it's that it's a fixed-size ring array with an eviction algorithm, and specifically one that holds representations of entities, where the entity is considered to be destroyed in a semantic sense if it gets evicted from the ring array.

Picture a background jobs system like Sidekik/Resque. Imagine that one worker-node of this jobs system had a fixed-size ring array of jobs it had taken. Now imagine that you could push new jobs onto a specific node. And now imagine that the worker-node responded by not just overwriting one of the filled slots of the local jobs set, but actually ACKing said job to drop it from the global job-queue system. It's destroying a real entity with persistent global identity, in order to reclaim the slot that the local representation of that entity takes up.

That's what OAM is, when combined with the design pattern I'm talking about. It's a ridiculous system that'd never fly in a business; but it happens to work for games, where you control the world such that you can make the world hold "reminders" for the state you destroyed.

Post reply on HN