Super Mario Bros warp zones were intended to work slightly differently [video] | Hacker News Reader

Super Mario Bros warp zones were intended to work slightly differently [video]

youtube.com

254 pointsraldi105 comments

For those who can't watch the video or just want a text summary:

The underground 1-2 level is supposed to stop scrolling as soon as the mundane return-to-surface pipe comes onto the right edge of the screen. (Unless you're walking on the ceiling.) But because of a programming error, it keeps scrolling, revealing that the warp zone room is there.

It was originally intended to be a much more hidden secret than it turned out to be.

(This is all explained much more thoroughly yet accessibly, and illustrated much more brilliantly, in the video; I suggest you watch it when you can.)

Now for some speculation on my part.

It's unclear whether the error was missed in testing or intentionally left unfixed because they decided they liked the erroneous behavior better. But there's a bunch of evidence that warp zones were added very late in the game's development, perhaps as a last-minute change.

This includes:

* Comments in original SMB source code (revealed in the 2021 "Nintendo Gigaleak") confirm that the programmer thought they were checking if Y = 0 when deciding whether to lock scrolling for the warp zone, even though the code doesn't do that. And these subroutines are located at the ends of their files/sections.

* Each object and enemy in the game is assigned a code, and the ones used to control warp zones are assigned the last codes used in the game.

* Memory addresses assigned to warp zone control variables are at the end of their respective tables.

* The code that decides where the warp pipes take you is implemented as: "Are we in World 1-x? Then 2-3-4. Else, are we underground? Then 5. Else, 6-7-8." This indicates that the level maps were stable when the warp code was written.

> But there's a bunch of evidence that warp zones were added very late in the game's development, perhaps as a last-minute change.

I assumed they were for testers to quickly go to some level on a release build?

Surely if that was the only goal, it would be easier to have a debug menu come up when you enter a certain sequence of inputs? Among other things, getting to the warp zone still requires playing 1-1 and 1-2, and you can’t warp just anywhere.

It could even only work for the P2 controller, or use inputs not normally possible like left + right simultaneously.

> use inputs not normally possible like left + right simultaneously.

Are there NES games (or mods) that have different (useful) behavior when an emulator permits such inputs?

In SMB, you can brake more quickly by holding L+R, which is impossible with an original NES controller, and as such that input is not allowed in official speed runs.

https://tasvideos.org/GameResources/NES/SuperMarioBros#Turni...

There’s controversy around this in the mario kart speed run community too. Apparently with snes controllers you can press L+R on the dpad if your dpad has been used enough to wear down the dpad’s plastic center pivot. What’s interesting is this created a schism bifurcating the community, and the one that allows L+R I hear is the more vibrant conmunity.

Not NES but I seem to recall playing Wonder Boy on a master system that had a missing D-pad and pressing up and down simultaneously made Wonder Boy drop through the earth and fall from the sky.

You just compile a dev version of the game during development.

It's quite common for games to have bugs or unintentional behavior when pressing left+right simultaneously. Super Mario Bros. is one example (as another commenter points out); another example is Super Metroid (for the SNES), which allows you to repeatedly wall jump in-place if you hold left+right: https://wiki.supermetroid.run/L+R_Walljumping

This sparked a mild controversy recently in the speedrunning community: L+R walljumping makes it possible to climb walls underwater without Gravity Suit or Hi-Jump Boots. Through the use of very esoteric and difficult speedrun tech, this enabled a runner to complete the game while collecting only 13% of available items, which would beat the previous low% record of 14% if left+right runs were allowed on the leaderboard: https://wiki.supermetroid.run/13%25_xCharge

Thank you, I'm so tired of 15 minute videos for something that can explained in text and images that can be read in one minute.

But how else would we make $300k a year on YouTube?

Ha! More like $10k (or even less).

Weird criticism.

Video is a nice relaxing medium with video and audio.

Some prefer it others prefer text, I prefer both depending on where I am.

Guess what I prefer on the couch

It's actually a reasonably detailed explanation that goes beyond that summary, including into how SMB levels were represented and video breakdowns of the state changes.

But TL;DR is a way of life.

My summary barely scratches the surface; the video gets deep into the code and the ones and zeroes. I don't think there's a wasted sentence in the entire piece.

While I agree with you in general, this is actually a really well-edited video full of lots of interesting stuff about how Super Mario Bros works beyond the conclusion.

So you know exactly how the minus world glitch works then? I didn't get that from the comment at all.

Star Wars is set in a remote galaxy where a civil war is taking place. Rebels, led by Princess Leia, are fighting against a baddy called Darth Vader and his Imperial forces. Leia steals some Imperial blueprints for a deadly weapon called the Death Star but she is then captured by Imperial forces so...

.. yes, text is great, but video can, too, be great, whether it's explaining something fictional or not. Different strokes for different folks.

I think the parent is more frustrated by videos that drag on for 10 minutes before getting to the meat of the content.

Kind of weird to put the comment on this one then, since it's edited so tightly.

I would expect such a comment to be attached either when the commenter has watched the video and it is as described or when the commenter has not watched the video because of the frequency of such videos on YouTube.

The cool kids know that Star Wars is much better in text than video

https://telehack.com/ -> starwars

(which apologies for video of text of video) https://www.youtube.com/watch?v=EJAbbRh9q4k

since the original is dead.

This is a good one. It gets right into it, and consistently provides quality information for very nearly the entire video. No fluffery, just good visuals and good explanation.

The video is well edited and the animation and drawing helps explain things much better than text and some images.

I think you've glossed over the most significant bug, which is that for no apparent reason at all the Scroll Unlocker increments the Warp Zone Control value, which configures the 2,3,4 warpzone to instead function as the World 5 Warpzone. If you don't get properly into the warpzone (which triggers the proper warpzone object), this is what causes it to function as a World 5 Warpzone, whereas the other bug is the one that allows you to scroll into it through unorthodox ways.

Also, the video has a lot of info about how levels are constructed in Mario in general, which I found very informative.

> Also, the video has a lot of info about how levels are constructed in Mario in general, which I found very informative.

If you'd like a lot more on this kind of topic, check out the book "I Am Error" by Nathan Altice (published by MIT Press; don't buy from Amazon). It goes into a bunch of detail about how the NES hardware worked and how specific games used it.

Indeed. I'm the guy he thanks at the end of the video, and the inspiration I passed along came directly from that book. This video would not exist without it.

Even better. they take Y & <some other condition that is almost always true> expecting that condition to be false only when Y==0, but it appears to be false whenever the lowest bit of Y is 0, which means for any even numbered vertical position. Fantastic!

Here Y is the vertical position of Mario (0--> on top of the level). So, one bug is: there was supposed to be a scroll stop unless Mario was on top of the level. Because you can scroll the screen while not on top of the level produces the -1 level bug where you scroll Mario through to the warp zone with some junk in a certain memory location.

The memory location is corrupted because they set a boolean flag with an increment operation, which of course causes an overflow instead of setting a zero to a 1. (EDIT: I misunderstood this point, see discussion below)

> The memory location is corrupted because they set a boolean flag with an increment operation, which of course causes an overflow instead of setting a zero to a 1.

Huh? No, the increment operation simply changes the warp zone control flag from 0 to 1. The valid values are normally 4, 5, and 6 (since they only use the low 2 bits to index into a table, and 0 is reserved for "no warp zone") -- so 1 is treated identically to 5.

Why this increment is even there is not clear at all, since the 1 should just get overwritten by a 4 later on, once the screen is scrolled all the way to the right and the warp zone is properly loaded. The only situation where this 1 has any effect is when entering the warp zone before it's properly loaded in order to go to the minus world.

Given that this increment is right after the nonsensical AND, I'm just gonna guess that whoever wrote this code was very sleep-deprived :)

Perhaps they meant to increment another variable and typed the label or address wrong (labels back then were generally much more limited in length on the average development system, I bet that the actual name for the variable in question was nowhere near the length of WarpZoneCtrl, most likely it was limited to 6 or 8 characters). I don't know the low level logic of the engine enough to know if there is a different variable that it would actually make sense to increment in this place.

Based on the original leaked source code, it appears they really did intend to increment the variable they did. The comment matches the name and purpose:

             BEQ      PLTMRT          ; Scrool stopping ?
    ;                                 : yes !
             LDA      PLYPS1
             AND      <PLYPS0
             BNE      PLTMRT          ; Player Y pos = 0 ?
    ;
             STA      SRSTFG          ; yes !
             INC      CMSLFG          ; Chimney  select flag

The buggy AND is really interesting to me -- the comment suggests that maybe the programmer meant to use an ORA instead, which would have been a clever way to check if both bytes of the Y position were zero. But that's still not something that makes sense to check, right? Assuming I'm understanding the video right, that'd only unlock the scroll if Mario was way up above the top of the screen...

I believe the NES's 6502 didn't have a logical-OR operator (which is what the situation calls for), only bitwise. The apparent goal was to find out, "Are either PLYPS0 or PLYPS1 equal to 0?"

They probably started with ORA, and when that didn't work, tried AND, and that seemed to work, so they went with it.

Ohhh, that makes sense. Thanks!

You can still get the minus world bug even if you go above the top of the screen. If you only fix the scroll stop AND bug, do the normal minus world bug, reach the right side of the screen, jump up on top of the level (to unlock the scroll), and drop down into the warp zone room as soon as possible, then the text hasn't loaded yet but you can still enter the pipes, which results in the normal minus world behavior. The real bug is that the scroll stop unlock object, for some reason, increments the variable the video author calls WarpZoneCtrl, resulting in it containing a value of 1, while the actual warp zone routine expects 4, 5, or 6, which it subsequently ANDs with 3 (removing all but the bottom two bits, leaving 0, 1, or 2). Entering this subroutine with an incorrect value of 1 results in the value remaining 1 (since 1 AND 3 is equivalent to 5 AND 3) and thus treating the warp zone as world 5, which is corrected when the routine that prints the warp zone text appears. The real minus world bug is the incrementation of WarpZoneCtrl. Removing that, and keeping the value at 0 until the warp zone text loads, makes the pipes use the last known pipe destination - the L-pipe that leads to the normal 1-2 level end.

The video author did not discuss level 4-2, but I would presume there may be a similar scroll unlock object present at the end of that level (in fact, my long history of playing SMB1 leads me to remember that I feel like I have also experienced in 4-2 that slight scroll hiccup the author mentions if you jump just right and keep the low bit of your X position set). However, since the standard end-of-level warp zone in 4-2 is meant to take you to 5-1, and there is only one pipe, the minus world bug doesn't apply as entering the routine with WarpZoneCtrl set to 1 is equivalent to entering it with WarpZoneCtrl set to 5.

Bugs with the scrolling exists throughout the game though. You can do wrong warps within both 4-2 and 8-4.

Do you happen to know why the minus world is the way it is? Was it a level that was designed, or is it a level where it's rendering some random program or other data? I'd love to learn more about that part too.

The minus world is technically an out-of-bounds level. The game treats it at world 36-1 (since the digits are tile numbers 0-9, followed by the alphabet, then a space tile at $24 or 36). Since doing so reads a whole host of other data out-of-bounds as well, it ends up pointing at the level layout for 2-2, but without the data that properly sets the pipe destination, resulting in an infinitely-looping level.

Other versions of SMB have different minus worlds (and some versions had the bug either fixed as in Super Mario All-Stars, or blocked off as in VS Super Mario Bros). Famicom Disk System version of SMB1 has a three-level minus world that ends with a Bowser fight that completes the game as if it was 8-4.

The minus world is a total bug. It was not designed or intended to exist. The bug was solely the result of the INC WarpZoneCtrl instruction that the video author mentions, which makes the game treat the warp zone pipes as the 4-2 warp zone until the text appears. Remove that INC, and the game will instead dump you out as if you'd gone in the L-pipe prior to the warp zone.

Obviously this bug doesn't exist at all in SMB DX for Game Boy Color, as it is a completely rewritten engine. I would presume the bug didn't exist at all in Super Mario Bros 35.

It’s pretty interesting how the game can continue to function in a level that isn’t supposed to exist. Metroid has similar areas I believe. It’s hard to imagine a modern game or any modern software handling a scenario like that without crashing.

I think it's a reflection of how incredibly simplistic these older systems and games really are. Modern games bear no resemblance to them as far as level design and asset storage go.

Such bugs are definitely still possible if you’re writing for modern systems in a similar style (large blocks of contiguous memory interpreted only as needed).

Just yesterday I was storing my color planes in three separate adjacent buffers for reasons, and if you looped the player off the bottom of the screen it came back up in a different color on the top. Now I need to figure out what to do with that…

That's quite different from an actual, playable level appearing out of a bug.

Not really - if I had any tilemap structures for the level yet, it would've had a similar effect.

The point is this stuff arises whenever you have, like `char level_data[8][4][10][100]` rather than, like `class level { std::vector<actor*> actors; std::vector<sprite*> background; }`. And storing stuff in large contiguous blocks that can be interesting when misinterpreted is still a pretty good way to write modern games if you don't have OO brain rot.

Sorry, I missed the part where you mentioned that you were writing your game in a similar style to classic games. Of course that does open up the door to similar bugs causing similar results.

It depends on the game, its level format, and how much error-checking it has. Games written in assembly from the 80's typically did not waste bytes & cycles on assertions/error-checks -- if you're at the point where you're decoding invalid level data, something's already gone so screwed up that it doesn't really matter what happen next. Add to that the fact that older consoles had no memory protection, so there's no such thing as a segmentation fault. You can even read from a memory address that's not mapped to anything, and you won't get an error; you'll get some value back based on analog effects of the memory bus.

Pretty much the only ways an NES game can "crash" is by calling an invalid function pointer, corrupting the stack, or getting stuck in an infinite loop somewhere. Otherwise, the game will more-or-less stumble on no matter what you throw at it -- accessing an array out of bounds will usually give you a nonsensical value taken from whatever comes after the array on the cartridge, dereferencing an invalid pointer will just give you some arbitrary data from RAM or ROM, etc. Therefore, the effects of going to an out-of-bounds level can vary from game to game, depending on what sort of format the game uses to store level data. Off the top of my head:

- Super Mario Bros. gives you slightly broken versions of regular levels, such as the various Minus Worlds. I haven't looked into the code, but presumably this is because a "level" is really just a header that contains indexes into tables of rooms & enemy lists & whatnot. So, going into an invalid level gives you a weird combination of existing rooms and enemies.

- Super Mario Bros. 3's level format has a lot of function pointers, so it usually crashes if you select an invalid level from the map screen. But the levels get decompressed into a big 2D array of tiles in RAM, so if you go out-of-bounds within a level you end up in a world of garbled tiles. Although some of those tiles will call invalid function pointers & crash the game when you interact with them; famously, this can be turned into an arbitrary code execution exploit. Here's a video of a speedrunner exploiting this in real time, manipulating enemies so that their positions in RAM form a short program that triggers the end cutscene: https://youtu.be/mUeozQtSmrg?t=202

- Mega Man 2 stores level data as a grid of tiles on the cartridge, but all the levels are stored consecutively, so if you go out-of-bounds you usually end up in a garbled version of another level.

- The famous MissingNo. glitch in Pokemon Red and Blue is caused by use of an uninitialized variable that causes a decompression routine to run on bad input, which then triggers a buffer overflow that stomps on part of your save file: https://youtu.be/ZI50XUeN6QE?t=880

Another fun example is Super Mario Land 2, where going out of bounds can lead to a “level” where blocks on screen directly correspond to general work RAM values, and breaking the block corresponding to the “game end” flag rolls the credits. Feels very Tron.

https://www.youtube.com/watch?v=24XHkmOJebA

That's because in modern software design, crashing is preferred to continuing to read invalid data, which has no upper limit on the amount of possible permanent damage it could cause. Would you rather have your game crash, or corrupt your 100-hour savegame? Crashing is the more elegant solution to this type of error, and a large percentage of language design after C++ went into turning undefined-behavior scenarios into crash scenarios.

Yeah I’m not trying to say it’s better or anything, I’m just so unfamiliar with environments where going out of bounds isn’t an immediate failure.

Really awesome, thanks for the explanation. You can get some really wild bugs when you write your game in assembly.

This fascinating article [1] on the history of SMB hacking in Japan gives some more details on Minus World-like worlds and how they could be manipulated by "hot swapping" Famicom cartridges.

"Players quickly figured out that it was possible to access levels beyond 8-4 by hot-swapping cartridges.

What is positively known is that in 1986 a magazine called “FC Bug Boy Special: Super Mario 256W ” was released by JICC Publishing Office in Japan.3 This magazine detailed how to access worlds beyond 8-4 with the hot-swap method.4 It also included data tables and information about these mysterious levels.5 This publication most likely helped information about “256-World” spread through the budding player/hacking community."

This ultimately led to the release of the Tonkachi Editor, sort of like a primitive Game Genie where you could laboriously modify memory to more precisely hack together your own levels.

"It was a binary editor, but far from the sophisticated software available on today’s computers, it was light and simple at best, and could only patch data displayed in hexadecimal or ASCII code, not move or copy data. Since there was no environment, of course, no printout was possible. Moreover, due to the nature of quick disks, subsequent files could easily be destroyed if they were rewritten on a different drive or other device, and recovering them required a great deal of effort. In fact, even now that I am accustomed to using a Tonkachi, a task that can be done in a few minutes on a PC can take up to an hour or two on the NES if you use a Tonkachi."

This ultimately resulted in a ROM Hack version of SMB called Tonkachi Mario released all the way back in 1987, at least a decade before I'd have assumed such hacks were being released.

[1] https://glitchcat7.com/the-complete-history-of-kaizo-mario/

The Minus World is just World 7-2 with a different name and an exit that loops back to the beginning.

I was expecting typical youtube "you won't believe THIS!" but it was actually really informative, as someone without knowledge of how they stored levels in SMB1.

Displaced Gamers is great. Nice dives into the code and architecture of NES games. Not so deep that it's inaccessible, but deep enough that you could go start hacking on NES games yourself (assuming some prior exposure to assembly).

My only beef is the NES focus on the Behind the Code series. I'd love to see some Sega Genesis games get broken down like that.

> Displaced Gamers is great.

Seconded, their videos are informative and lean.

If anyone has a passing interest in NES architecture or just how NES games work I'd recommend checking out the creators other videos.

It feels to me that the voice is computer generated, but I can't be sure - if it is, text to speech has come a long, long way.

There's some pretty heavy emphasis on some words, but not when the same word is used elsewhere.

Very consistent tone and timing otherwise though, and it feels like the voice was overly compressed which gives a pretty robotic vibe. I watched a bit of some earlier videos which sound less robotic, but otherwise a very similar voice. I'd guess it's just more that the presenter has been recording a lot of videos and has gotten pretty mechanical after all of that.

It may also be that it's moderately heavily edited; what stood out to me was the "pauses" before "two" and other numbers sometimes, which is something that you hear in computer generated audio.

Nope, human one hundred percent of the way through. Same with RGME, which is an absolute wonder dive into (currently) the operation of the SNES from a very approachable position.

I wonder if this kind of obsessive analysis of popular NES-era games will end in a couple decades, as the people who grew up in the console's heyday grow too old; or if they'll continue because interest in these particular games transcended a particular generation (and they're simple enough for people to really take them apart).

> they'll continue because interest in these particular games transcended a particular generation

Speedrunning seems to support this idea. That’s also one of the reasons retro games have been analyzed in such depth.

The day people stop studying ancient religious texts is the day people stop studying Mario ROMs.

To confirm you mean that the codebase for Mario ROMs are indeed ancient religious texts.

I interpreted the insinuation that way as well.

Not ancient. The apostles are still alive.

Archaeologists still study garbage heaps from tens of thousands of years ago to figure out things about past civilisations. So my guess is on no - people will study the digital garbage heaps of humanity as much as they study the... once-were- stinkier ones.

> Archaeologists still study garbage heaps from tens of thousands of years ago to figure out things about past civilisations. So my guess is on no - people will study the digital garbage heaps of humanity as much as they study the... once-were- stinkier ones.

Super Mario Bros. isn't a garbage heap though, it's more like a statue or a mosaic.

I was thinking more like will it end up like a forgotten pop song from 1890 or something like a Tchaikovsky song that's still played and appreciated (and not reliant on nostalgia for continued attention).

I have nostalgia for Super Mario Bros., and that's why I pay attention to it. It's getting old enough where we might be able to perceive effects independent from nostalgia (though I think there may now be a phenomenon of "nostalgia for other people's nostalgia" that may still make accurate perception difficult).

I'm vaguely sure that many of the hackers picking apart 8-bit games are in their twenties, if not teens. Meanwhile, even people who grew up with SNES and Genesis would now be in the late thirties.

include early 40s and even 50s!

video games aren't just for young people : )

I don't think so. Those are the only generation of games that can be analyzed this thoroughly. Plus, computer geeks in the future will still be interested in the fundamentals of computing. And console games are really the only piece of mainstream software whose assembly would be interesting to look at.

Granted, this is already niche content, and it will continue to be going forward. But I bet a lot of people watching those videos weren't even born when SMB came out or have even used an NES.

SNES, N64, and even Gamecube (though less so) games get this level of scrutiny as well. Some examples are Mario 64 and Super Smash Bros Melee as some of the most popular examples on later platforms receiving assembly-level scrutiny.

I'm also fascinated with the trend of decompilations of newer games that weren't written in assembly. There exists a functional decompilation of Jak and Daxter: The Precursor Legacy for PS2. I'd love to see/help make happen the same for Guitar Hero 1 and 2. I don't have the C++ knowledge to make it happen, but there does exist a community with a lot of knowledge about the non-code aspects of the engine (like the bespoke Lisp-ish scripting language).

Even the SNES is substantially more complicated than the NES. The tooling available to examine the SNES games like NES games are at least pretty similar, but the capability and complexity of the SNES is a huge step up from the NES.

The N64 content is a different league though. It's not nearly as easy to understand and follow. Plus, Mario64 is written in C and most of the content I've seen has been people adding features to it (HD upgrades, ray tracing, 60fps, etc).

NES games are still being played, analyzed, and mastered by new people, including people who have only known the NES as "retro" gaming.

Hell, the most recent winner of the Classic Tetris World Championship (which plays NES Tetris) was only 14 when he won the 2021 competition. The speedrunning community for NES games also contains a lot of people much younger then the games they're playing.

Given that, I think I can say with confidence that NES games will transcend a particular generation because they already have. And there's no sign of that slowing down anytime soon.

I was into console emulators in the late 1990's and believed even at that time that it was possible to know everything there was to know about the NES. So given that we're a couple decades plus later and random hackers at home are still digging up interesting information, I feel like the tail on this kind of thing is quite long.

(And I'm still continually surprised that 80's-90's retro gaming/computing as a whole is such a popular hobby! If my teenage self had a crystal ball, he would have been very pleased to learn this.)

I think the NES-era (and to a lesser extent SNES-era) will continue to be heavily represented. As you stated, they are simple enough for people to really take them apart, in a large part because the games were actually written in assembly, unlike later eras of gaming.

But also, the NES-era games have aged better than earlier games. As much as I love River Raid, it's no Super Mario Bros. Something about on-screen menus (what do you mean I need to hit "reset" to start the game, Atari?), having more than one button, and enough processing power for decent physics.

I suspect you'll still have academics doing it, but with less overall cultural relevance. There are still historians of early film, TV, etc. doing great work. Often it's by consulting new types of sources or using newly available technical tools.

It's funny to think about it - but the game is almost 37 years old, and how many billion hours of play has it gone through? Yet people are analyzing and discovering things.

Now compare that to the sheer size and complexity of modern games / software. Crazy to think how many bugs there are that will practically never be discovered.

I’d love to see this style of video (extremely deep technical dive with useful commentary and diagrams) applied to non-game things as well. It would be interesting to watch about Heartbleed or Rowhammer, for example.

Understanding the cause of a bug like this is intriguing. Like, it's interesting to see a mistake in one of the greatest video games ever made that I could see myself doing.

Here's another :)

https://tcrf.net/Super_Mario_Bros.#Unused_Spiny_Egg_Behavior

https://tcrf.net/Bugs:Super_Mario_Bros.

I loved the in-depth technical discussion in this video. If you're into this sort of thing, I highly recommend this pokemon/missingno discussion: https://www.youtube.com/watch?v=RNsEsZbXE-4

Thanks, this was interesting. I exploited this glitch with wild abandon as a kid. Fun to know how it worked.

I love how deep analysis finds stuff like this even nearly 40 years after a game's release. I hope we in the Guitar Hero II/Rock Band scene can reach that point someday.

You may enjoy this look at an easter egg from 50 years ago :) https://www.youtube.com/watch?v=z97TfAhDKGk

GH/RockBand scene??

...links? =]

All we really have right now is a Discord server and a very small wiki. We focus on the Milo-engine games made by Harmonix, we don't really deal with the Neversoft GH games. We also made some pretty popular mods, like Guitar Hero II Deluxe, Rock Band 2 Deluxe, and Rock Band 3 Deluxe.

https://discord.gg/WWmsQvHSC6

https://milo.ipg.pw/index.php/Main_Page

The whole GH/RB scene is of course bigger than this, but this is the part I'm involved with that focuses on modding more than anything. There's also a smaller contingent elsewhere that still pokes at the later GH games. Clone Hero is the currently dominant meta.

TIL these games were written in assembly.

Yes, it was the only way to do the weird optimizations and tricks needed to make a cutting edge real time game like Mario.

Even in the '90s developers embedded assembly in the performance critical areas of C code.

My understanding is NES games were in pure assembly (specifically 6502), no C at all.

Yes. There may have been _some_ 8-bit or 16-bit games that were written in C for mainstream consoles but it wasn't until the 32-bit consoles (Playstation, Saturn, etc) that it was really practical to do so.

Does anyone out there remember / have more information on an effort to actually create the warp pipes in real life?

I have a very distinct memory of reading about this in Nintendo Power magazine in the late 90s / early 00s but have never been able to find anything concrete on the internet about it. I'm curious if I'm having a Mandela Effect type thing going on.

You're not talking about Hyperloop are you? They sure seem like human sized pneumatic tubes to me, and are highly reminiscent of the Mario pipes.

I'm not! This would be like pre-PayPal Elon times. IIRC, they were literally shaped green and meant for an individual wearing like a motorcycle helmet. I have no idea where my brain could've gotten this memory...

Is there any disincentivize to using the warp zones so that people don't always skip levels when they know how to?

No. My philosophy has always been, if you want to play less of the game, why are you even playing it to begin with? :) So I just don't use them.

Sometimes I want to listen to an album straight through; sometimes I want to skip to specific tracks. Either way, it's the same amount of experiencing the music/game; it's just a shift in what parts of the work you're giving your focus.

I agree with this philosophy for most games. I tend to play through them once and not revisit them once completed, so I try to experience as much of the game as possible on that first playthrough. (Up to a point anyway. Sometimes certain content e.g. gathering collectibles becomes boring or tedious. And sometimes I'm enjoying the content just fine, but feel the need to hurry up and finish the game so I can move on with my life.)

Needless to say, SMB isn't most games. It's the type of game you play again and again. And it does not natively include any game save or password system. The warp zones transform it from an hours-long marathon to something you can play through during an episode of your least-favorite Saturday cartoon.

It also depends on skill level too. I'd say I could complete a full home SMB1 run in about 30-45 minutes or so (the WR is under 19 minutes and is hyper-optimized, second only to any%).

Warp zones allow players to see more of the game. If you were a kid playing SMB, and was only allowed 30 minutes a day to play a game, you would probably never get to experience any of the later levels without the warp feature.

Not everyone games the same way. For many people, cheats add to the experience, they don't detract from it.

Yeah this. SMB was before save games :-)

The levels are fun to play :D

If you're playing for score (which doesn't mean much in SMB, but it's there if you want to), you'd want to play through all the levels.

Or if you want to get more lives for the later levels, you might want to play through easier early levels to stock up.

It's not exactly disincentives for warping, it's incentives for not-warping.

Not really, except for the shorter gameplay duration. Going through a warp zone even enables the hidden X-1 1-UP mushrooms that normally require you get all the loose coins in the preceding X-3 level.

The speed run community has a warpless division. Always good to add a different challenge. https://www.speedrun.com/smb1#Warpless

I think I would have prefer the scroll being correct, it would have made the discovery more rewarding. Good video

Reply on news.ycombinator.com