First, a short list of common Nintendo stuff in titles analyzed:
- RNG - Up through SMB3 still uses the tried and true RNG introduced in Donkey Kong.
- Jump Tables - For the most part, the Intelligent Systems-mod.-SRD routine is used, but some areas forego this entirely and have their own local jump table indirects.
- NT/Background Init - The nametable setup during bootstrap is pretty darn similar to much earlier stuff, if it ain't broke don't fix it I suppose.
- General RAM Clearing - Nintendo stuff tends to have a page-based RAM clear by which some high page number is given and everything below that is cleared out, possibly including or excluding zero page and stack by default or option. This sort of stuff shows up in the SMB games too.
- Joypad Reading - The same basic core joypad strobe loop is in there, but it gets surrounded with different variations on debouncing and multi-player handling.
- Audio Engine - Nintendo has a pretty general engine they use over and over again for audio stuff, adding or subbing parts depending on what they need. Those fingerprints are still all over SMB3, and all the other SRD stuff, to the point I may make a separate git repo exploring just version differences with those since I may actually be able to get the code close enough to diff between titles effectively.
- Mapping - SMB1 is an NROM title, SMB2 and DDP both FDS, SMB3 is MMC3, so naturally this presents some complications in exploring some flow of code. Routines throughout these games had to probably be entirely rewritten to work with however things were split up in mapping, so it's a steep order to demonstrate that subroutine A in SMB became subroutine B in DDP, etc. when mapping plays heavily in however what that bit is works. Not to say it can't be done, common variable names help a lot in finding similarities but there are plenty of places in these games where the mapping dictates the layout and flow.
- Tight Main Loop vs. Real Main - SMB1/2 exhibit a pattern seen in earlier Nintendo stuff in which the main thread does some system bootstrap but then settles into a tight loop, at most doing RNG. SMB1/2 don't even do this, it's just a loop with maybe an effective nop thrown in. DDP and SMB3 both contain more significant main loops that actually represent the steps of iterating over the overarching flow of the title. Both for instance come out of the system bootstrap, construct the runtime for the titlescreen, then enter the title loop. The title in both cases then transitions to some sort of selection (save screen in DDP, map in SMB3), which involves some sort of bank switch (disk flip on FDS, MMC3 swap on FC). Then the game simply runs and runs until some sort of condition kicks it back all the way to the title screen. Still, the NMI just does graphics and timing-based requests rather than ending by entering the game simulation. This is one of the compelling reasons I believe SMB3 flows pretty directly from DDP, although it could be coincidence and in general SRD and others decided to ditch the old loop pattern. It would be interesting to see if other lineages that did the same tight loop concept dropped it as well.
- Mode Transitions - Along the same lines as DDP and SMB3 dropping the tight main loop and executing all in NMI, these titles also dropped the concept of a table of game modes then launching into processing for each of those modes states. For instance, in Super Mario Bros., there is a table for dispatching between the title, gameplay, victory, and game over modes. In DDP and SMB3, however, this is instead simply a function of the flow in the aforementioned main loop. The control simply loops around in different parts of this larger main loop, executing over portions pertinent to things like the title screen, stage selection, credits, etc. in their own little bits. At any given time, rather than a single index saying "you are in the title, credits, map, gameplay, bonus, etc." these abstract concepts become a function of several different variables that influence different things.
- Scroll Loading - Among the more glaring differences over time is the evolution of the scrolling engine. SMB1/2 featured uni-directional scrolling along one axis. Doki Doki Panic then introduced selectable horizontal *or* vertical scrolling in both directions. SMB3 then introduced a full vertical scroll into the horizontal scroll mode such that horizontally scrolling levels could have a two-page-high vertical scroll window as well.
- Title System - SMB1/2 use the real game engine to render the title, simply loading World 1-1, pasting the title graphics over it, and then letting the demo script run. DDP has a cinematic titlescreen so no interaction with gameplay to speak of. SMB3 is an interesting case in that there is essentially a snippet of the bare bones pieces needed to run the little demo you see play out between Mario and Luigi. For instance, each interaction with the Koopa shell is a specific subroutine, rather than generalized actor interaction with player objects. Literally just the actions needed are there. The powerups you don't touch don't have any of their other programming. Granting controls to the player characters in the intro could make for some interesting janky gameplay if it hasn't been done already. There is no metatile engine or scrolling to speak of, everything you see is loaded in via display list or OAM tables co-located with the subroutines.
- Metatiles - SMB1/2 and SMB3 use generally the same metatile format, although I have not yet sat with a magnifying glass over the subroutines that crunch the tables in each to see if the code bears similarities. Not only does the 16x16 format feature, but a technique for selecting the color palette for the metatiles is also shared: The high two bits of a metatile's placement in the 256-metatile table corresponds with that metatile's palette entry. In other words, the $100 metatiles are broken up into $40 metatile pages, with $00-$3F being color 0, $40-$7F color 1, $80-$BF color 2, and $C0-$FF color 3. The tiles are arranged in tables of each quadrant and some metatiles exist in more than one chunk. For instance the victory tile for the map in SMB3 is in all four metatile groups so you can get victory tiles with different colors from the same palette selections. I wouldn't be surprised if this is in other titles like Legend of Zelda, the $40-tile page corresponding with color selection is quite clever.
- Scenery and Actor Course Arrangement - This is getting into some terms I've half made up and half borrowed but in both engines the courses are generally broken up into "scenery" and "actors", with the former being large background objects like pipes, hills, and block rows. In actual SRD code, this sort of thing tends to be referred to as "obstacles" but they need not be physically obstructive. Actors then are the acting things like enemies, powerups, and so on. Both engines generate courses by stepping over tables of these two distinct types of entities. I haven't gotten quite deep enough into the SMB3 course engine yet to compare the rest of the course generation, but SMB1/2 generally uses the scenery engine to also specify changes in the vertical "mask" for the level, basically the placement of "wall" from the top to bottom until another such scenery object triggers a transition in the masked off rows. SMB3 has a lot more complexity what with overlapping platforms and things like that, so I'm not sure if I'll encounter the masking feature or not.
- Block Bouncing - A hallmark of Mario is hitting blocks, and nowhere is this high status more evident than the fact that blocks get their own special routines for swapping between BG and OBJ tiles for blocks which have just been bumped, animating the bump, then settling the blocks back as BG tiles when done. SMB3 generalizes it a bit more into a routine to write a block-shaped space and then calls this with blank or block tiles, but the general idea is the same: when a block is hit, overwrite the BG mapping for these tiles with blanks, at the same time placing OBJ tiles in the exact same spot. Until some timer counts down, the OBJ tiles do a bumping animation. When the animation is complete, the tiles are pushed offscreen and the original block is drawn back to the nametable. At any given time, only this block is moving, so only this block needs to temporarily become OBJ. Of note, SMB1/2 have spots for more than one active block at a time, but SMB3 reduces this to one. Only one could be active anyway as the single metatile draw uses a static buffer for the four quadrants of the tile. The flip side is this *could* be used by other things in theory, but in practice is only used for the block bumps.
