[HN Gopher] SNES - Super Mario World Widescreen
___________________________________________________________________
SNES - Super Mario World Widescreen
Author : gtonioli
Score : 407 points
Date : 2021-06-18 20:38 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| xtracto wrote:
| 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.
| chapium wrote:
| Someone did prior to its release and enjoyed a C&D takedown.
|
| https://www.vice.com/en/article/kzmykz/the-creator-of-mario-...
| crazygringo wrote:
| 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...
| goalieca wrote:
| > does Super Mario World have any "single-room" fixed-width
| gameplay areas? I mean, it must, right?
|
| 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.
| thaumasiotes wrote:
| Most obvious of all would be the Top Secret Area, or Yoshi's
| House.
| modeless wrote:
| 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.
| derefr wrote:
| 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.)
| stormbrew wrote:
| 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.
| a_t48 wrote:
| Scrolling with L/R does affect (at least some) spawns. It's
| completely possible to use it to scroll enemies on/off
| screen.
| manwe150 wrote:
| 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.
| SwiftyBug wrote:
| 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.
| [deleted]
| omoikane wrote:
| This room?
| https://twitter.com/furious_/status/1405693389723549697
| gtonioli wrote:
| Take a look on this vod:
| https://www.twitch.tv/videos/1059403286
| stochaztic wrote:
| 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.
|
| https://twitter.com/HackerVilela/
| 29athrowaway wrote:
| 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.
| easytiger wrote:
| If we take everything since Masters of Doom hence, it's
| obvious they don't like being offered help and don't need
| it either.
| gogopuppygogo wrote:
| 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.
| bennysomething wrote:
| Genuine question: when did this happen before?
| hyperhopper wrote:
| I recall a few times, googling found me one result
| quickly
|
| https://www.eurogamer.net/articles/2017-01-18-did-
| nintendo-d...
|
| 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
| Wowfunhappy wrote:
| 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.
| wjnc wrote:
| Do you find this troublesome? I'd personally think this
| hits a sweet spot but am curious.
| dwrodri wrote:
| From a Nintendo fan's PoV, this probably one of the
| highest possible honors. The bigger concern would be
| never being made aware that it ever happened.
| rytill wrote:
| I love this game, have played at least a hundred hours of it in
| my childhood, and this seems ... nice? What in particular makes
| this so amazing?
| rogerdb wrote:
| 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.
| yesco wrote:
| The gameplay and design heavily lean on there being a fixed
| aspect ratio so one would assume that expanding it would be a
| fairly challenging project.
| kevinventullo wrote:
| 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.
| [deleted]
| SixDouble5321 wrote:
| Very cool, but the performance of that core isn't good enough for
| my nvidia shield. :(
| jakemauer wrote:
| I've been a very happy patron of Vitor for months. I'm elated
| that this project is finally out in the world.
|
| He has a framerate improvement patch for Starfox in the works
| that I am beyond excited about.
| prvc wrote:
| Now that's exciting. It's already quite fun to play with
| emulated overclocking, btw.
| flatiron wrote:
| I personally can't stand it due to frame rate!
| Netcob wrote:
| 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!
| Keyframe wrote:
| I have an overclocked cartridge. Completely different game,
| feel to it.
| jakemauer wrote:
| 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.
| alphabet9000 wrote:
| 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.
| megablast wrote:
| What video?
| flatiron wrote:
| 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.
| lancefisher wrote:
| 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.
| jader201 wrote:
| 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.
|
| [1] https://youtu.be/ZH2wGpEZVgE
| geofft wrote:
| https://www.resetera.com/threads/you-can-now-play-snes-games...
| has a bunch of screenshots of _unmodified_ SNES games in
| widescreen (though they don 't work perfectly)
|
| 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.
| gxqoz wrote:
| Is there a YouTube video of this somewhere? Didn't see one linked
| from the github page.
| gtonioli wrote:
| https://www.twitch.tv/videos/1059403286
| ant6n wrote:
| Was the creator live-streaming his progress, or am I
| fundamentally misunderstanding twitch.
| gtonioli wrote:
| No. It was a famous SMW speedrunner testing the wildscreen
| ROM
| hypertele-Xii wrote:
| Several.
|
| https://www.youtube.com/results?search_query=super+mario+wor...
| maxerickson wrote:
| https://twitter.com/HackerVilela/status/1405972177225191427
| 14 wrote:
| 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.
| nrdvana wrote:
| 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)
| drusepth wrote:
| I think we'll see a lot of private servers, luckily. Most
| popular online-only games seem to have at least one PS
| alternative.
| resoluteteeth wrote:
| 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.
| belthesar wrote:
| 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.
| nohr wrote:
| 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.
___________________________________________________________________
(page generated 2021-06-19 23:03 UTC)