4 ms·

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

by vlunkr 4y ago

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.

jaywalk 4y ago
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.
- morelisp 4y ago
  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…
  - jaywalk 4y ago
    That's quite different from an actual, playable level appearing out of a bug.
    - morelisp 4y ago
      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.
      - jaywalk 4y ago
        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.
NobodyNada 4y ago
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 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 https://youtu.be/ZI50XUeN6QE?t=880
feoren 4y ago
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.
- vlunkr 4y ago
  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.

by vlunkr 4y ago

jaywalk 4y ago

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.

morelisp 4y ago
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…
- jaywalk 4y ago
  That's quite different from an actual, playable level appearing out of a bug.
  - morelisp 4y ago
    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.
    - jaywalk 4y ago
      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.

NobodyNada 4y ago

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 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 https://youtu.be/ZI50XUeN6QE?t=880

feoren 4y ago

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.

vlunkr 4y ago
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.