Submission #7405: Masterjun's SNES Super Mario World "mobile version" in 06:59.74

(Link to video)
Super Nintendo Entertainment System
mobile version
lsnes-rr2-beta24
25226
60.0988138974405
13016
PowerOn
Super Mario World (U) [!].smc
Submitted by Masterjun on 4/1/2022 9:00:49 AM
Submission Comments
Have you ever used your phone to record a landscape in portrait mode? The future is now. Earlier this year TASVideos officially started having a mobile-friendly website. No better time than now to submit a mobile-friendly movie.
Have you ever used your phone to play Super Mario World? The past is now. The imprecision of the touch screen and the total lack of useful buttons make for an experience. Mobile versions of games accommodate by removing all interesting gameplay controls. Truly the pinnacle of gaming.

🏁 Game objectives

  • 📱.
  • Fall.
  • I can't believe they made a mobile version of the game.
  • Beat the game!

💬 Comments

Welcome to my 12th entry in April Fools Day submissions featuring Super Mario World! This year I thought I'd follow the trend to make everything on the internet use portrait orientation. So why not convert our lovely retro games as well? Who needs widescreen hacks if you can have tallscreen hacks.
From this point I will assume you already watched the run.

🤔 Explanation

You might have noticed while Mario is falling towards the goal the rest of the game still works with regular gravity and physics. And this becomes much more apparent when watching the run in the emulator. The rotation is a video editing trick and Mario is actually falling sideways.

🎮 Control

As I've mentioned in the past, there are two types of playing around with ACE. The easy type and the difficult type.
When you have total control over a system, you actually only have control over the CPU and all types of RAM, which also means audio and video. And so the easy type of manipulation is creating a new experience, a new game, or a new program.
The only part you can't control is the ROM, after all it's Read-Only Memory. And here lies the problem. The ROM contains all of the data to execute the currently running game. If you want easy manipulation you can't use any large chunks of the ROM. This is the difficult type, once you start a routine inside the ROM you're locked in.
As a metaphor, the easy type is breaking out of jail to use limited resources to create a new building where you can do whatever you want.
The difficult type is breaking out of jail just to go back in and hope whatever changes you made outside allows you to eventually break out soon enough.
As you can tell from the run, most of the game is still intact. So this is the difficult type of manipulation.

🪐 Physics

Mario falling sideways is not a feature of Super Mario World. (It does have sideways running up a wall, but that's an extreme edge case with a lot of code just for the ~4 times it's used in the game.) The reason why the video still looks somewhat authentic is because I recreated the physics and simulated every frame sideways and wrote them to the Mario speed addresses.
However, since I have to let the game run normally the regular physics are also executed every frame. I decided to let the game handle collisions with blocks and enemies, and just override the speed. This results in some weird looking interactions and especially a lot of clipping into blocks. I tried to move around as naturally as possible. Well except for when I wanted to accomplish something more interesting, like the Big Boo boss fight. Speaking of boss fights.

👾 Bosses

Sorry, the mobile version has simplified bosses. That's just how mobile versions are.

🖼️ SNES PPU

The SNES Picture Processing Unit truly has amazing features. Did you know rotating tiles is not one of them? It can flip vertically and horizontally, it can prioritize tiles and change the palette on the fly. But rotating? Nope.
For this movie I had to rewrite the entire tileset of Mario graphics to turn every single tile sideways. While the game was running of course. It was also interesting to find every instance of horizontal flipping when turning and all that, and turn it into vertical flipping, because that's how it works now.
Every additional moving part made this more complicated, because not only did I have to reposition the tiles sideways, I had to recalculate the offsets. The upper tile of Mario, the lower tile, and the cape tile. I gave up at the swimming feet tiles, because apparently those aren't part of Mario's tileset so I couldn't easily rotate them.

🎥 Video

You might have noticed the encode showing more of the level than an emulator, similar to so-called Atlas videos. I used a Lua script to draw outside the screen using live level data. It's not perfect and in certain situations you can clearly see the original edges, but overall it was good enough for this run.
There are issues whenever Layer 3 is involved. Usually it's only Layer 1 for level tiles and Layer 2 for the background. But occasionally the game uses Layer 3 for things like moving water or smashing spikes. I had only just made Layer 2 work last minute, so I skipped the rare Layer 3. (I also ran into a lsnes specific bug where drawing outside the screen over both the gap area and left edge of the game area would write pixels out of bounds and crash the emulator.)
Of course no enemies or sprites can be seen. This is partly because... well... they don't exist off-screen, they despawn, most do at least. They do exist beyond a small area outside the game screen, but the varying animation tiles require running actual subroutines of the game to get the proper poses. This was too big of a challenge for a barely noticable effect because most despawn soon anyway.
Another noticable artifact is the mosaic effect or lack thereof in the added area. This could have been simulated, but with all the bitmap drawings existing I was already running out of Lua memory. Yes there is a lot of memory overhead. This is all done pixel by pixel and the performance was already poor. I also dreaded the docs saying "Note that mosaic is applied after scrolling, but before any clip windows, color windows, or math." I really don't want to recreate a snes rendering pipeline in Lua. I also didn't want to look into the maths of the fadeout circle.
I do think when it's working it looks nice! :D

Samsara: great, thanks, now i'm going
to have to format my judgement notes to
fit on a mobile device. please use your deve-
loper privileges to turn the site into an agree-
able mobile version, thanks in advance.
it's called a phone btw
Samsara: Okay, I'm going to admit some-
thing straight up. I have literally no idea how
to approach this. Like... As per usual, the bar
for your AFD submissions remains at the high-
est 50 star mark, so please enjoy your, like, 5th
or 6th rotatey-symboly minigame on my behalf,
but with the amount the site has changed since
last year, COINCIDENTALLY WITH YOUR HELP,
it became a lot more difficult to differentiate be-
tween submissions that are Quite Obvious Reject-
s, and submissions that could conceivably go to
Playground. Y'know, that thing you coded into
the site and all that.
This is not a Quite Obvious Reject anymore. In
fact, this is the first of your AFD submissions th-
at I've personally judged in which that is the cas-
e. As nice as it would have been to find some sort
of loophole like "it won't end in the lifetime of our
universe" or "it doesn't sync without a couple RAM
pokes", there is theoretically nothing wrong with th-
is run, apart from me stubbornly sticking to a joke
in my judgement notes that's going to bite me in
the ass given that it's being taken somewhat seri-
ously.
The only judgement loophole I can think of is,
sadly, to just reject it on the basis of it not being
meant as a serious submission to begin with. It's
not perfect, and I'm not saying I'm looking for an
excuse to reject it, but it severely simplifies things
for the near future while we try and figure out the
direction that Playground, and the site itself, is goi-
ng to be going in.
Don't get me wrong, I'm glad to have the issue of
"oh no, the site's more accepting now and I don't
know how to handle that yet", but I'm not exactly
glad to have the resulting issue of "oh no, there's
almost 100 submissions on the workbench right
now". In terms of keeping things running smoot-
hly, it's safer to stick this on the backburner and
focus on ensuring everything else is processed.
In that case, I'm gonna stick this on the backburn-
er.
Also, I want to stop this gimmick now. It's real fu-
nny, but it's getting pretty annoying to maintain.
Last Edited by Samsara on 4/18/2022 10:46 PM
Page History Latest diff List referrers