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.
If history is any indicator Nintendo will release these improvements on future virtual consoles as paid upgrades. They’ll credit the open source contributions they didn’t have to pay for to make this possible.
As far as I know they have repeatedly packaged open source emulation code in their work without notice. Guessing it hasn't become a big deal since nobody in the scene wants to anger Nintendo
The article you linked is about something quite different—Nintendo used a straight dump of their game from the internet. I'm guessing some engineer who didn't know about iNES headers thought they'd save time using the internet versus going through Nintendo's archive.
Newer VC releases haven’t had these headers, by the way. I guess if you were being conspiratorial you could presume Nintendo deleted the headers specifically, but we know it’s not like Nintendo doesn’t save these files. (See things like Star Fox 2; the complete version on the SNES classic was newer than any of the leaked versions.)
I’m really not aware of a time Nintendo has ever used code from a rom hack or emulator.
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.)
There are two different seams at play here. One is a 'loading seam' which is really just the vertically and horizontally mirrored area of the tile map. The rendered tile map is (simplifying a bit) basically 2x as tall and 2x as wide as the screen you see. The screen's position in it is effectively modulo the width and height of the tile map. If you move right 30px, it loads tiles and objects into the area 30px off the the right edge of what it already had loaded, wrapping back around to the left if necessary, then moves the viewport 30px to the right (again, simplifying).
So yes, there's always area that is kind of 'ready' outside the current viewport. It has tile data and probably objects loaded into it, ready to be seen. That's why you don't see 'pop-in' or whatever. Things are loaded before you get there.
But the game logic isn't activating all those things as soon as they're loaded into tile memory. You can probably actually view this in some emulator or another and what you'll see is things loaded up some time before they're actually on screen, but just sitting there until they're basically on the edge of the screen when they'll start moving.
How games do that will obviously vary quite a bit, but in SMW's case it "loads" sprites some specific distance off screen (which is not a full screen away), and then "activates" them pretty close to the edge of the screen. You can see this for yourself by like, going and finding a shell-kicking koopa or something and playing with the screen scroll. You will be able to get it to do it over and over again with only a little scrolling.
A lot of kaizo games were made quite a bit easier thanks to this, to the point where most of them now disable screen scrolling to prevent you from controlling spawns so easily.
I vaguely recall using the L/R scroll to intentionally alter event timing, and needing to be aware of viewport variations from my usual run as I got faster, to avoid something being in the wrong place. But it has been many years now since I last played. I don’t recall SMW having much that needed to trigger in any particular order or speed, outside of the autoscroll levels. But since some levels already have too many sprites to keep up performance, I don’t think they would have been as worried about time precision as much as stopping extra work as soon as objects are hidden off-screen.
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.
Exactly It seems that being widescreen doesn't change anything in this particular room, considering that the wall surface remains in the original size. Maybe if you're wearing the cape, the extra horizontal space can help avoid Bowser.
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.
I always liked the flat-shaded look, the gameplay and world, but when I revisited it as an adult I just couldn't play it due to the frame rate. I'm so used to playing at 90-144fps that anything below 60 literally looks like a slideshow. And 20fps is just crazy. Can't wait to try it at a higher one!
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)
As a technical novelty, it is interesting, but I personally don't like the spirit of such a project. I opened up a demo video of the gameplay, and started to 'see' things in the distance that wouldn't normally be seen - things that are meant to be hidden at first, and then 'stumbled' into as you advance a little bit, adding to the sense of mystery and adventure.
I don’t mind it so much for Super Mario World. In the original, you could press the L or R shoulder buttons to scroll the view forward or back. This essentially brings both into view for wide screen.
Was thinking the same thing. The Nintendo designers were always so meticulous about the design of the levels, especially what’s visible to a player at any given point.
To get a sense for this, watch this video [1] (from 7 years ago) walking through the design of level 1-1 of SMB. It’s crazy what (likely) went into planning the design of each level of the various Mario platformer games.
But like OP, this is strictly looking at it from a gameplay perspective, ignoring the impressive technical feet that this is.
I agree. I love that we have the ability to use an emulator or mister to play the stock rom but I love people thinking what could have been with old tech in a new world. Personally it’s fascinating. I wish my retro wasn’t confined to a mister to try it. I may figure out a non work pc I could use to try it.
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...