This is nuts. I didn't even know this would be possible.
I can't remember -- does Super Mario World have any "single-room" fixed-width gameplay areas? I mean, it must, right?
I'm wondering how they addressed those, since making any room wider would change gameplay. I also can't help but wonder if being able to see a little bit further to the right would ever make anything easier? Or is the distance forward (to the right) fixed to the same value, so you're mostly just getting more visibility into where you've already passed?
The video and GitHub repo don't seem to explain it. But I'm now super curious...
Look through the past couple hundred or so of Vitor's tweets; he's been one-by-one reprogramming all the troublesome rooms and screens for a couple weeks.
That guy is certifiably insane. He patched Contra III, Gradius III, Super Mario World, Super R-Type and Race Drivin' to use the SA-1 chip. Which means now those games have a higher/consistent framerate. Kudos to that guy.
Hopefully Nintendo learns to appreciate these contributions and doesn't try to seek legal action against him.
More than that; every level will be affected by this. It affects the timing of enemy and platform spawning which means the enemies and moving platforms will be in a different position when the player typically reaches them. In many cases that timing is an intentional part of the level design.
I don't expect that the developer did anything that would require players experienced with SMW to change their memorized routing. (If I were them, I'd be using 100%-playthrough TAS .smv files from the unmodified SMW as conformance tests, to ensure none of my changes "desynced" existing strategies for the game.)
What might be different, on the other hand, are subtle things about un-loading. I bet an .smv of the SMW credits warp wouldn't work on this patched ROM. (Not least because, IIRC, this patched ROM is based on an older set of SMW patches by the same author, that — among other features — has a sprite-limit removal patch, that improves the game's OAM memory-management algorithm.)
-----
But also, IIRC, the enemy/platform spawning (really, the loading seam) in SMW occurs far-enough outside of the viewport normally, that it might still be outside of (or just at the edge of) the expanded 16:9 viewport.
Recall that in SMW, you can explicitly scroll the viewport in the game (by pressing L/R). The game engine was necessarily designed around the assumption that, at any time you're in a free-camera scene (most of the time when you're not in an autoscroll area or small room), your viewport has an arbitrary horizontal scroll offset within some defined range. For gameplay to be deterministic/testable under such an assumption, the loading seam must be programmed to occur outside of that manually-scrollable region.
I'm guessing that the basic "insight" of this widescreen patch, is that in most areas of the game, the screen can be made exactly as wide as the entirety of the coverage-area of the camera's player-controlled scroll region, with no effects on gameplay; because the game was already designed to work "the same" within any sub-region of that area, and "all of it" happens to be such a sub-region. Presumably, this patch makes the screen exactly that wide, and then removes your ability to scroll the camera any further using L/R. (Without that last bit, you'd be very likely able to see pop-in by scrolling the screen even slightly.)
This would also mean that any area that was designed for a fixed or restricted camera (e.g. autoscroll areas; boss rooms; etc), may have been optimized by the original level designers under that assumption, and so "packed" with stuff that might load at the wrong time, or in the wrong order, if the loading seam were expanded (as it likely would have to be to make these areas look good.) Not having looked yet at the developer's progress reports for this patch on Twitter, I would pre-register a guess that fixing these types of rooms is where the majority of the work in making this patch went (beyond just adding more border tiles to small rooms.)
It's mostly impressive from a technical standpoint, since the programming of games from this era would be strongly tied to the display resolution, eg. a programmer could know which background tiles or entities could be shown in the viewport at any time, and dynamically load/unload them for performance reasons. All of these optimizations now need to be tweaked or removed in the widescreen version so things outside the original 4:3 viewport don't disappear at the edge of your 16:9 display.
More recent games use flexible approaches to allow for different aspect ratios, which would behave similar to eg. fluid design on the web.
Jon Burton of TT Games has an interesting Youtube channel where he goes over some of these old school development techniques, if you wanted to learn more; eg. https://www.youtube.com/watch?v=96DO4V8qrR0 uses a lot of techniques that would be difficult to extend to a 16:9 display.
Looking at the sibling vod, it appears as though they must have “extended” the fixed-width rooms, either with walls or more lava or whatever.
Looking at the second room of the first castle, widescreen seems to give you more actual room to move around in auto-scrolling levels, which offers a significant advantage beyond just information on what’s coming ahead.
The final boss room (Bowser in that weird balloon) is something I would love to see in a wide-screen arrangement. Part of the challenge of that room is to deal with many enemies in a very tight space.
https://arstechnica.com/gaming/2019/04/hd-emulation-mod-make... talks about "HD Mode 7" support, which relies on the fact that perspective backgrounds ("Mode 7") are scaled for TV display, but they don't inhenently have to be downsampled to TV pixels, and on a emulator outputting to a higher-resolution display, it can preserve the resolution instead of trying to get pixel-perfect accuracy. I think the widescreen stuff works on the same principle: the data is there and being scrolled, so you may as well render it.
If you want to get an idea of his approach look at the _astounding_ patch he made for Race Driving. He re-wrote the engine to essentially tween between frames because the original was more or less stuck at 5fps and certain things, like the position of your car and viewport when doing a loop-de-loop, were _hard coded_ into the game.
Oh this is Vitor!
They made a series of patches that allow games to utilize one of the SNES enhancement chips on various games. A fun example was using it in Super Mario World (notoriously minimal slowdown), where the enhancement reduced the slowdown from the end of level where the black circle encloses on Mario. That's actually a bit of slowdown rather than an effect.
I loved pilotwings when it first came out, but didn't think I would be able to stand the graphics now. With this I actually think it will look good enough to enjoy again.
Pilotwings is a huge exercise in Mode7 graphics. With some of the more recent builds of bsnes, it supports doing upscaling of Mode7, and it makes playing games like Pilotwings and Super Mario Kart a brand new experience. What's shown here won't do a whole lot for you, but this might be the trick.
Mhmm, this is great! someone should do something like this to create a "Mario 35" clone: Create the game based in the original ROM and then setup a page with a "diff" file that people can use to recreate it if they have the original ROM and game.
IANAL, but I think the difference there is that game was standalone and playable without a ROM file. Theoretically, a ROM patch and a bunch of netcode would be legal (though most people would still illegally obtain the ROM to patch).
E.g. see Project Slippi[1], a patch for playing Melee online with rollback netcode.
Interestingly, a tournament using was Slippi was issued a C&D[2], but Nintendo has issued C&Ds to Melee tournaments in the past just for using their graphics and making money and stuff.
30 years later and people are actively working on these games. Amazing. What will come of future games? With all the server backend code I guess we will lose most games once the company in charge no longer wants to pay server costs due to dying player levels.
Most games have all the assets loaded onto every client, and they just synchronize over the server like a glorified IRC channel. People reverse-engineered WoW servers, and then ran their own WoW communities for a decade until Blizzard finally decided to get back into the game. (but then Blizzard re-implemented the old content into the new engine, rather than starting up the old server code, so ended up being a lot more effort for them than just flipping a switch)
Readit News
I can't remember -- does Super Mario World have any "single-room" fixed-width gameplay areas? I mean, it must, right?
I'm wondering how they addressed those, since making any room wider would change gameplay. I also can't help but wonder if being able to see a little bit further to the right would ever make anything easier? Or is the distance forward (to the right) fixed to the same value, so you're mostly just getting more visibility into where you've already passed?
The video and GitHub repo don't seem to explain it. But I'm now super curious...
https://twitter.com/HackerVilela/
Hopefully Nintendo learns to appreciate these contributions and doesn't try to seek legal action against him.
What might be different, on the other hand, are subtle things about un-loading. I bet an .smv of the SMW credits warp wouldn't work on this patched ROM. (Not least because, IIRC, this patched ROM is based on an older set of SMW patches by the same author, that — among other features — has a sprite-limit removal patch, that improves the game's OAM memory-management algorithm.)
-----
But also, IIRC, the enemy/platform spawning (really, the loading seam) in SMW occurs far-enough outside of the viewport normally, that it might still be outside of (or just at the edge of) the expanded 16:9 viewport.
Recall that in SMW, you can explicitly scroll the viewport in the game (by pressing L/R). The game engine was necessarily designed around the assumption that, at any time you're in a free-camera scene (most of the time when you're not in an autoscroll area or small room), your viewport has an arbitrary horizontal scroll offset within some defined range. For gameplay to be deterministic/testable under such an assumption, the loading seam must be programmed to occur outside of that manually-scrollable region.
I'm guessing that the basic "insight" of this widescreen patch, is that in most areas of the game, the screen can be made exactly as wide as the entirety of the coverage-area of the camera's player-controlled scroll region, with no effects on gameplay; because the game was already designed to work "the same" within any sub-region of that area, and "all of it" happens to be such a sub-region. Presumably, this patch makes the screen exactly that wide, and then removes your ability to scroll the camera any further using L/R. (Without that last bit, you'd be very likely able to see pop-in by scrolling the screen even slightly.)
This would also mean that any area that was designed for a fixed or restricted camera (e.g. autoscroll areas; boss rooms; etc), may have been optimized by the original level designers under that assumption, and so "packed" with stuff that might load at the wrong time, or in the wrong order, if the loading seam were expanded (as it likely would have to be to make these areas look good.) Not having looked yet at the developer's progress reports for this patch on Twitter, I would pre-register a guess that fixing these types of rooms is where the majority of the work in making this patch went (beyond just adding more border tiles to small rooms.)
Yes. The have the bonus room after you get 100 endpoint stars. They also have vertical segments like a bonus room and a special world map.
More recent games use flexible approaches to allow for different aspect ratios, which would behave similar to eg. fluid design on the web.
Jon Burton of TT Games has an interesting Youtube channel where he goes over some of these old school development techniques, if you wanted to learn more; eg. https://www.youtube.com/watch?v=96DO4V8qrR0 uses a lot of techniques that would be difficult to extend to a 16:9 display.
Looking at the second room of the first castle, widescreen seems to give you more actual room to move around in auto-scrolling levels, which offers a significant advantage beyond just information on what’s coming ahead.
Deleted Comment
https://arstechnica.com/gaming/2019/04/hd-emulation-mod-make... talks about "HD Mode 7" support, which relies on the fact that perspective backgrounds ("Mode 7") are scaled for TV display, but they don't inhenently have to be downsampled to TV pixels, and on a emulator outputting to a higher-resolution display, it can preserve the resolution instead of trying to get pixel-perfect accuracy. I think the widescreen stuff works on the same principle: the data is there and being scrolled, so you may as well render it.
He has a framerate improvement patch for Starfox in the works that I am beyond excited about.
https://www.youtube.com/results?search_query=super+mario+wor...
https://www.vice.com/en/article/kzmykz/the-creator-of-mario-...
E.g. see Project Slippi[1], a patch for playing Melee online with rollback netcode.
Interestingly, a tournament using was Slippi was issued a C&D[2], but Nintendo has issued C&Ds to Melee tournaments in the past just for using their graphics and making money and stuff.
[1]: https://slippi.gg/
[2]: https://twitter.com/TheBigHouseSSB/status/132952108157785703...