SMB1 oddities

[therealtaftq]

Not sure if this is the right place for this kind of stuff, but I've found a few oddities in SMB1 that I thought you guys might find interesting.
Not sure if these have been discovered yet or not, but most, if not all of them seem to be undocumented, or at least largely unknown.

Oddities I've encountered:
Bill Blasters firing twice or even 3 times in rapid succession (probably caused by RNG jank)
Paratroopas going the wrong way (happens in World 8-2, might happen in other levels)
Bowser failing to shoot fireballs (seems to happen rarely and at random)
Pulley lifts still having collision after they fall (this one's screwed me over a few times)
Getting hurt by Goombas when trying to jump on them (only seems to happen when they're going down stairs)

I also made a document with a bunch of obscure Mario facts and glitches in it a while ago, and was thinking of adding it to the site's documents section after cleaning it up a bit. Would it fit there?

[FAST6191]

If you can relate it back to the code, or reproduce it then would be more fitting -- most documents here are either general info about games/formats/devices that might be useful to the would be hacker looking to make changes, or info on techniques they might wish to undertake, possibly by way of worked example. Various Mario wikis, including hacker centric ones, and speedrun type things might be more interested to have them as is though. I might wonder what goes for "feature not bug" stakes in some of those too.

Mario does have a full commented disassembly.
https://gist.github.com/1wErt3r/4048722

Analysing code in such circumstances can be tricky -- obviously you hope no crazy emulator issues https://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator/ , or, worse still, hardware variability (gamecube controllers in competitive smash brothers being among the more notable but plenty of others exist like RAM speeds in the original xbox where they used whatever just about worked from the scrap bins).
In the ideal world if what would be a simple compare and branch in the "if I was coding this to behave how the game typically behaves" becomes something more interesting then you have something to investigate*. Maybe it is some kind of bounds checking or error correction (character swapping commands in games might be more than simple insert character number into location, vblank handler or whatever picks it up when that next drops.

*without looking if you based it off early level behaviours you might expect something here only to find out it is the hammer throwing options as well that only kick in later.

Going down stairs sounds more like a collisions priority issue/bug with hitboxes, or at least that would be my first port of call.

Anyway after simpler/maybe obfuscated (you don't know what it is but as it is rather more complicated than is necessary there is something to look at sort of thing) we start getting into other territories where measuring timings is a thing, figuring out if there is some condition that might cause a timer to be reset (while things are based on frame count if the various speedrunning strategies are anything to go by it does not mean frame/millisecond perfect timings are there, or indeed even expected -- bonus "random" events does mix things up a bit, as was more famously seen in Castlevania fleas). This is where you want to be able to somewhat reliably reproduce it, in an ideal world you would presumably be running a full logging session (often gigabytes in size) as that was happening hence the reliably reproduce angle, in a less ideal world savestates at suitable intervals such that you could go back and step through things from there. You do have the benefits of a full disassembly there but you might still find yourself reaching for methods those without such things available might go in for -- if something is on screen there is going to be OAM or whatever controlling it, and that code is also going to be interfacing with memory at some level (you are probably not going to have full HP atk def... a la a brawler or RPG but will be something as the NES is no so primitive as to be solely graphics based for collisions and world awareness -- scrolling being doable in hardware being something of a selling point vs single screen).

[segwayspeedracer]

I've modded mario for about 10 years and nothing here sounds abnormal tbh:

Bill Blasters firing twice or even 3 times in rapid succession (probably caused by RNG jank)
   This can be attributed to how many enemies are on screen. If it's just one blaster it will spawn a bunch of them. Just like a lakitu by itself.
   If there are other enemies then it won't load as frequently. I think the game doesn't like 4 or 5 sprites on the screen before things start fading.

Paratroopas going the wrong way (happens in World 8-2, might happen in other levels)
   My immediate reaction is that the paratroopa (on the far right side of the screen) collides with blocks or enemies on the far left side of the screen. I'm sure someone smart can talk about how the screens load with each other. Same thing as a mushroom or goomba falling into a pit, and mario can collide with it when jumping up above the visible screen.

Bowser failing to shoot fireballs (seems to happen rarely and at random)
    Same as bullet bill.

Pulley lifts still having collision after they fall (this one's screwed me over a few times)
     Never used them. Can't help you there. 

Getting hurt by Goombas when trying to jump on them (only seems to happen when they're going down stairs)
     I think mario can only kill enemies if his velocity is negative (ie he is falling). But even you are falling and an enemy is descending on the stairs, I think this is a known bug that their hitbox is different. Like it's more toward the left than the graphic itself? I may be misremembering but I think there's a patch for this.

[ThroughT1m3]

I also made a document with a bunch of obscure Mario facts and glitches in it a while ago, and was thinking of adding it to the site's documents section after cleaning it up a bit. Would it fit there?

Mind sharing that document with me?

[therealtaftq]

Sure. I'll send you a PM in a bit.

[ThroughT1m3]

Sure. I'll send you a PM in a bit.

got it thanks

[SMB2J-2Q]

Not sure if this is the right place for this kind of stuff, but I've found a few oddities in SMB1 that I thought you guys might find interesting.
Not sure if these have been discovered yet or not, but most, if not all of them seem to be undocumented, or at least largely unknown.

Oddities I've encountered:
Bill Blasters firing twice or even 3 times in rapid succession (probably caused by RNG jank)
Paratroopas going the wrong way (happens in World 8-2, might happen in other levels)
Bowser failing to shoot fireballs (seems to happen rarely and at random)
Pulley lifts still having collision after they fall (this one's screwed me over a few times)
Getting hurt by Goombas when trying to jump on them (only seems to happen when they're going down stairs)

I also made a document with a bunch of obscure Mario facts and glitches in it a while ago, and was thinking of adding it to the site's documents section after cleaning it up a bit. Would it fit there?

Some of these quirks may have been cleaned up in the PAL version of this game, including:
Jump Spring -- in the NTSC version, if there were many enemies on the screen at once, the jump spring could load into a piece of memory normally reserved for power-up items or the flagpole at the end of the level, allowing for overwrites. The PAL version corrects this by adding a check for the jump spring.

~Ben