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

A Comprehensive Super Mario Bros. Disassembly

gist.github.com

Post reply on HN
Print view View original

21–30 of 87 posts

Re: A Comprehensive Super Mario Bros. Disassembly

#21

Post by bluedino »

davidscolgan wrote: post #6
jordigh wrote: post #3

https://gist.github.com/1wErt3r/4048722#file-smbdis-asm-L601... I think this is where the real gems start. The biggest contribution that SMB had was the "physics engine", to retrofit a modern term. The friction, the jumping, the inertia. If you compare it with the primitive physics in Donkey Kong or Mario Brothers, you can really grasp the groundbreaking novelty that was SMB. You can change direction in mid-air, but…

I once read that the way SMB was able to pull off the physics engine on such limited hardware was that it used lookup tables for physics instead of actually calculating velocity. My assembly-fu is weak but it looks like your link is to the section that contains all the lookup tables. I think JumpMForceData for example is a series of offsets for each successive frame after you hit the jump button. https://gist.github.…

You can also fine-tune the feel of a jump when you're directly editing a handful of values vs trying to find a function that describes your desired results.

Re: A Comprehensive Super Mario Bros. Disassembly

#23

Post by dEnigma »

raldi wrote: post #19

Check out the section under "DemoActionData": this is where it stores (and plays) the demo you see when you don't push Start and Mario runs around on his own volition. It just simulates player input and runs it through the regular game engine. (The alternative, playing a recorded video, would have been laughably data intensive.)

Same thing goes for Super Mario 64. The popular TASer pannenkoek actually explored whether it was possible to manipulate Demo-Mario's starting position in such a way that he collects a star with the demo input (this was for the purposes of special "A-Button Challenge" speedruns, where pressing the A-Button must be kept to a minimum, but since the demo input isn't actual player input it isn't counted) Sadly I think there was no conceivable way to do it. (i.e. manipulating the starting position is possible, but not in a way that leads to collecting a star)

https://youtu.be/-0emgkIEobI

Re: A Comprehensive Super Mario Bros. Disassembly

#24

Post by bluedino »

aquova wrote: post #10
tomduncalf wrote: post #4

This seems like a really impressive effort to make sense of all this! Would the original game have been written in assembly? And if so, would the source have looked similar to this? Having never touched assembly language (aside from learning some very basic cracking many years ago swapping JE for JNE in the serial check routine, haha), it seems like a true dark art to me, so I’m really curious to know!

Yes, all old NES games were written in 6502 assembly (named after the NES's 6502 processor), and even most games into the Super Nintendo and Game Boy days were written using assembly language. The source would've looked very similar to this, although I can assume the original labels would've been in Japanese. The difficulty in creating a disassembly like this isn't converting the machine code back into assembly, whic…

For another interesting read there's the guy that disassembled Robotron, and traced the code out by hand across 512 printed pages of assembly and fixed 2 long-standing bugs.

http://www.robotron2084guidebook.com/technical/christianging...

Re: A Comprehensive Super Mario Bros. Disassembly

#26

Post by derefr »

asveikau wrote: post #17
dieterrams wrote: post #15

Earlier quoted context omitted.

Lookup tables were indeed a common technique used by games in the past.

And present, too, right? It's not the same reason as it would have been in the 80s, but today in performance critical code it is not uncommon to reduce the number of conditionals for better CPU pipelining, and lookup tables are a very common tool for this.

I have a strong feeling that Super Mario Maker always has the same physics engine going, but just has four different lookup tables that it switches between depending on the level theme. Anyone want to partially disassemble it for comparison?

Re: A Comprehensive Super Mario Bros. Disassembly

#27

Post by derefr »

khedoros1 wrote: post #12

There's also a Legend of Zelda disassembly, but it's not as nice: https://github.com/camthesaxman/zeldasource It's a much larger game, though. I haven't checked, but I'm assuming that a lot of the giant chunks of statically-defined data are just graphics and audio (unlike many games, LoZ stored graphics interspersed with the program code and copied data over to an in-cartridge RAM chip, instead of storing the complet…

> unlike many games, LoZ stored graphics interspersed with the program code and copied data over to an in-cartridge RAM chip, instead of storing the complete graphics data in a ROM chip

This is because Zelda 1 was a port from the Famicom Disk System—no memory-mapped ROM chip to rely on, so you've got to load everything you're going to use to RAM. (Also like this: Metroid.)

I believe this is why both LoZ's and Metroid's maps are built out of individual "screens" with a "pause to transition" effect between them: in the FDD version, the game would be reading the new map from disk, and there'd (sometimes, if the load took long enough) be a loading screen involved. (You can see the screen for LoZ here: http://tcrf.net/The_Legend_of_Zelda/Console_Differences#Load...)

Re: A Comprehensive Super Mario Bros. Disassembly

#28

Post by jepler »

webXL wrote: post #25

I love stuff like this. Seeing the disassembly somehow adds to the nostalgia for a childhood pastime. What's this endlessloop for: https://gist.github.com/1wErt3r/4048722#file-smbdis-asm-L712 (Yes, please ;)

You can see that just above the endless loop, the code will "enable NMIs". I'm not sure about the nomenclature here (because normally NMI stands for non-maskable interrupts, meaning you can't disable them) but basically the game at this point becomes event (interrupt) driven, probably from the vertical retrace interrupt or another kind of timer interrupt. When no event is being handled, the CPU idles within this endless loop.

Re: A Comprehensive Super Mario Bros. Disassembly

#29

Post by jepler »

jepler wrote: post #28
webXL wrote: post #25

I love stuff like this. Seeing the disassembly somehow adds to the nostalgia for a childhood pastime. What's this endlessloop for: https://gist.github.com/1wErt3r/4048722#file-smbdis-asm-L712 (Yes, please ;)

You can see that just above the endless loop, the code will "enable NMIs". I'm not sure about the nomenclature here (because normally NMI stands for non-maskable interrupts, meaning you can't disable them) but basically the game at this point becomes event (interrupt) driven, probably from the vertical retrace interrupt or another kind of timer interrupt. When no event is being handled, the CPU idles within this endl…

https://wiki.nesdev.com/w/index.php/PPU_registers#Controller... states that bit 7 of the register at $2000 (which they call PPUCTRL, and this disassembly calls PPU_CTRL_REG1) will "generate an NMI at the start of the vertical blanking interval"

Re: A Comprehensive Super Mario Bros. Disassembly

#30

Post by corysama »

jordigh wrote: post #3

https://gist.github.com/1wErt3r/4048722#file-smbdis-asm-L601... I think this is where the real gems start. The biggest contribution that SMB had was the "physics engine", to retrofit a modern term. The friction, the jumping, the inertia. If you compare it with the primitive physics in Donkey Kong or Mario Brothers, you can really grasp the groundbreaking novelty that was SMB. You can change direction in mid-air, but…

I'll plug the book http://www.game-feel.com/ here because it has a 28-page chapter devoted to the physics of SMB.
Post reply on HN