Hey everyone! pellsson, threecreepio, and I are working on the 6.0 release of the excellent SMB practice ROM, and we're looking to expand the title screen so more than four faces can be included. This means that we will be able to include more top runners than just the top four. If you want to have your face included in the practice ROM, we ask that you submit a picture of your face in this thread to help streamline the process of including new faces. The picture you submit must have a width of 40 pixels, a height of 56 pixels, and use only four colors so that the picture is compatible with the practice ROM. Cropping your face and getting the correct resolution is best done in your imaging software of choice. To reduce the number of colors to four, I suggest you use the utility NESIFIER to do so. If you use NESIFIER, specify the palette to use as colors $30, $27, $17, and $0f, select "Floyd Steinberg" dithering and set the dithering level to 4 for the best results. The .BMP image format is preferable, but not required for the image you submit. Here is an example of the kind of image we are looking for: https://imgur.com/I8VQMs4
If you need help with cropping an image of your face to the right resolution or applying a four-color limit, you can feel free to reach out to me.
To put my two cents in, I think there is definitely an argument for allowing the MiSTer FPGA, especially since it is hardware-level emulation of the NES, although what form that would take depends on the consensus reached by the moderation team.
Unfortunately, that would be impossible. I took a deeper look into the exact handling of NMI in Super Mario Bros. and realized that I forgot to mention the fact that the start of the NMI handler disables interrupts unless the entire sequence of code in the handler is executed. So, in other words, code execution cannot return to the start of the game code unless the entire NMI handler has been ran first, even if that means that the game code must be processed over the course of two frames. This is why lag frames do not impact enemy patterns in speedruns; the console simply uses that lag frame to finish up code execution from the previous frame. So it's impossible for an interrupt to go off in such a way that the instruction to increment $06D6 can execute multiple times, as the game disables interrupts in the event of a lag frame.
Even if interrupts occurred during lag frames, the instruction to increment $06D6 immediately precedes the code to delete the object, meaning there would be a near-impossible timing window for the console to increment $06D6 but not delete the object due to an interrupt.
Super Mario Bros.'s game code runs within the game's non-maskable interrupt (NMI) handler, which the NES calls every frame. Whenever all code in the NMI handler is executed on any given frame, code execution transfers to an infinite loop at address $8057 until the NMI handler is called on the next frame. So Super Mario Bros. essentially runs on a frame-by-frame basis, and tries to execute everything in the NMI handler on every frame unless code execution takes too many CPU cycles, in which case the game will lag on that frame.
The only proper CPU interrupt the game uses is the aforementioned non-maskable interrupt, which unconditionally transfers code execution there each frame. However, the game code frequently uses JMP (jump) and JSR (jump to subroutine) opcodes within the game code to transfer code execution from one subroutine to others. The JMP opcode transfers code execution to the specified address. The JSR opcode does the same, but stores the address minus one of the next operation into the stack so that an RTS (return from subroutine) opcode transfers execution to the stored address plus one. Code execution is strictly linear so multiple subroutines cannot run simultaneously.
I know we're all good friends, but it's probably best to not make posts like these on SRC, especially since those who aren't in on the joke are just going to think you're really desperate.
Hello everyone, I've added samm_1703 as a Super Moderator to this game, to help ensure that the queue is cleared as effectively as possible and to help clean up existing issues with the leaderboard. I felt that he was a good fit, given his interest in the game and respected status in the SMB community. If anyone has any suggestions to improve the leaderboard or objections to current policies, please let one of the mods know. Have a great rest of your day.
Although I don't believe he's submitted any runs with black and white footage, I know speedrunner Alvaca has played the game in black and white. I don't see why you would have any problems with verification.
@Asgore89 Who is this ViableCorn guy? Kappa
@Mingura666 That's a really good idea! If I ever host a tournament, I'll be sure keep that idea in mind!
Yes, but it would be pretty crazy. Considering how fast 8-4 already is in a Glitchless run, saving the Glitcheless TAS framerule in 4-2 might be the only way runners are going to get 5:02. That framerule has only been saved by one person so far (LeKukie), and it was only saved by a frame. A faster 8-4 is always possible, but saving enough time in 8-4 for a 5:02 would be a monumental task. 5:02 is definitely possible, but pretty unrealistic right now.
Still don't exactly know why the thread was necroed, but the new resources are a good addition. Several people I know thought the patch on romhacking.net was broken because the .ips patchers they used didn't support the .bps filetype. Now no one should be confused about acquiring the game.
I added my .ips conversion under the Resources tab because several people weren't able to patch the game themselves, since the patch on romhacking.net is a .bps file and not an .ips file. Those people just asked me for the ROM haha
Alright, I'm not the best at explaining hard tricks, but I'll give it a go:
For flagpole glitch in 1-1 and 4-1, you want to land on the first pixel of the second stair from the top, releasing B before you land on the stair. In 1-1, you can fulljump from part of the green pipe to line yourself up to land on the first pixel; in 4-1, you can't quite do that. After landing on the first pixel, you want to walk for exactly one frame, then press and hold B, and then 2 frames later press and hold A. Basically, your inputs on the stairs should look like R, R+B, R+B, R+A, and keep holding R+A. You can get FPG if you land on the second pixel and press A a frame earlier than usual, but it's harder to get FPG that way. You can release A once you have reached maximum height. In 1-1, you should release the right button around the flag on the flagpole, and in 4-1 release the right button around your peak jump height. To clip into the flagpole block, you want to press left right before touching the flagpole block, and release left right after you press A to jump off the ground. Optimal pole inputs would be L, L, L, L+A. You can also hold the right button after you jump to potentially make pole inputs easier.
That's basically all you need to know. My response was rather wordy, so maybe this video can help:
@lazarlazar If you need help with speedrunning glitches, I highly recommend you join Maru's Discord, accessible from the Discord link on the SMB1 speedrun.com page. It's far more active than this site's forums.
@Corban_Pittman The run I'm pretty sure EBH was talking about actually got to 8-2, meaning it got the 8-1 flagpole glitch framerule save. The run wasn't 4:54 pace exiting 8-2 because Niftski didn't do the right setup to get TAS 8-2. Video of that run is here:
@DaTroll18 Ah that's right, was in a rush and forgot to turn that option on. Super sorry about that.
As it turns out, I'm experiencing the same error you are. I'll get the .ips uploads fixed as quickly as I can. Sorry about the inconvenience.
@samm_1703 Thank you! I'll probably have another moderator added at some point, and if so I'd love to bring you on board!