SMS Setup Information

I got my technical setup down to a fine art during my 3-year career lol. I’ll give details here to document my runs and in case they help someone.

Remember that I stuck to a lot of software versions because I knew they were reliable and didn’t want to spend time re-testing. A brand-new setup should generally opt for latest versions, and then establish their reliability to one-day supersede the advice I give here.

Contents

Wii Video + Capture

Wii

Тhings are still timed in real-time, so we use a Wii to save ~2 mins over a GameCube in loads. 3DAS is 2 mins faster than Wii but has 2–3f of extra intrinsic input lag (Wii/GC/Dolphin Emulator each have 3f total, so it’s 70% more at least), so is generally not run seriously. You can adapt to input lag but it adds variance to timing inputs so I prioritised cutting it out as much as was reasonable.

I used a white Wii until 2023/02/16 and black Wii from 2023/02/17 onwards. My white Wii is from July 2007, and older Wiis likely have slower disc drives. In one Any% run sample (on PAL, new file, including 2 savewarps), the white Wii had a load total of 5:57.55, while the black Wii had a load total of 5:55.84, 1.7s faster.

Capture Card + Cables

The key to low input lag is mostly in the monitor and the equipment chain between it and the Wii. We need 480p at 60Hz to be able to time inputs most consistently (and so have better fundamentals), which strikes composite cables and leaves us with component cables or a Wii2HDMI adapter. The latter is lagless even in generic AliExpress £3 form, tho the picture quality may be a bit naff. I was able to simplify, however, by finding a used component capture card, the AVermedia Live Gamer Extreme (GC550) from 2015, for £43 used on UK eBay in Feb 2020. This capture card records the component signal (my cable is generic) while converting it to HDMI (passthru), and connects to PC via USB3. It’s basically perfect – other than having light diagonal-line artifacting and being slow/unstable when switching between inputs for multi-game runs.

Good component capture cards are getting very rare as later revisions become HDMI-only. However, generic HDMI capture cards have since come down in price to where even a decent USB3 one can be copped for cheap (USB3 is a good baseline for reliability in my experience, since USB2 cards have oversaturated bandwidth and rely on onboard video compression to mitigate that), so they’re worth a shout with a Wii2HDMI. Retrotink (with 480p input) offers a vouched-for Wii2HDMI alternative that works for many games consoles, but is ~£100.

All of these options should have negligible input lag, but it’s possible to get stung particularly with generic equipment.

Monitor

The extra input lag in a decent LCD monitor versus a CRT is 2–8ms, bearing in mind that CRTs (at 60Hz) have an average of 8.3ms of input lag themselves (and 0 response time). CRTs cause eye strain, don’t usually take component/HDMI input, and nobody uses that shit anymore. We optimise input lag as much as we can, but we can let 1/4 of a frame go (1/4 at worst, a frame being 33.3ms) because speedruns are about reciting muscle memory and reactions are not significant enuff to optimise at this scale. If one can get good on 3DAS (whose 70% extra input lag causes a proportional increase in timing error bars) with an extra ≥2f then it’s all good.

I have a BenQ GW2470H monitor, a VA LCD from 2015 with 10.6ms input lag and 4.7ms response time, which I sum for a worst case estimate of 7ms over CRT. My monitor is very bog-standard, cost ~£100 at the time, and is poorly rated for response time. In practice, my whole setup has a total of ~3.1f of input lag – see test – and I’d consider <3.25f good enuff and 2.8f maybe the best possible.

When abroad, I’ve tested different TVs and all have had incorrigible extra input lag, at least 0.5f, despite me disabling as much post-processing as I could.

GameCube Controller

I learnt the game on an original-issue (official) GameCube controller, which was worn out as fuck but cost only £10 on UK eBay. As I’ve improved and required better equipment (in-tact notches, non-squished button pads), I’ve ~annually replaced it with a new Smash Ultimate official GameCube Controller, for ~£40 from UK or Japan. I have never replaced controller parts and have only three times opened a GameCube controller (for cleaning or reclipping potentiometers to mitigate dropped spinputs). These controllers do have tuff springs, so spam-spraying is harder if unmodified.

Wii Homebrew

Setup

Homebrew installed as per wii.guide. I’m a proponent of encouraging everyone to follow all steps of a nominated guide (this one) so they have the same context for any troubleshooting later (e.g. Swiss loader requires something like d2x cIOSes). I used an SD card for installation (tho a USB drive and internet connection can be used with e.g. str2hax) but switched to using only USB drives for homebrew later (always plugged into the disc drive–side USB port cos it does make a difference…). With Priiloader set to auto-boot The Homebrew Channel, I don’t need a Wii Remote either; this works on both my white (BootMii as boot2) and black (BootMii as IOS only) Wiis.

Nintendont

Nintendont 6.498 (and onwards) is the preferred choice for its near-instant loads. Nintendont can’t force 480p on PAL but has a lot of space for cheats and is easy to use, so is used with NTSC-J and NTSC-U ISOs for ILs. I don’t use disc, since the loads are then slower, but also since disc drives are the component of the Wii with the worst longevity and should be preserved for full-game runs. The exception is when I want to use the loading beep to time something (which became largely unnecessary when instant loads became a thing).

Swiss

This is very unreliable software so after I found a good version – Swiss r1060 – I stuck to it (for my white Wii). Upgrading to r1060 ended the gameplay crashes that happened particularly during Bianco 5, and sometimes ~5 mins after starting the game. But it does occasionally crash on boot still if not quickly started after turning the Wii on.

For my black Wii, I tried upgrading to r1420, and started using an SD Gecko to store settings. It is as reliable as r1060, with minor pros and cons:

I used r1730 for some ILs in late 2024 and it seems to be the best of both 👍.

Aspect Ratio
With Swiss, (on PAL disc) I force 480p and also 640px width, which is useful because it gives the dev-intended aspect ratio. SMS ordinarily outputs 660×448, which is then converted to analogue and, by the NTSC standard, rescaled by a factor of 10/11 horizontally to give 4:3. Analogue signals have continuous horizontal lines rather than pixels, but this visually corresponds to a 600×448 digital signal. However, 640×448 (non-rescaled) is the resolution where circles are circular, which is to say SMS looks wrong at 4:3/on CRTs (it looks too narrow).

This seems to be a dev oversight; my best guess as to what happened is that the devs (or their SDK) targeted a 640×480 4:3 resolution, and then rescaled to 448 hight (which is used because of overscan) while forgetting to rescale the width proportionately. This was then stretched to 660 width so that it would display at 4:3 (600-equivalent) on a CRT after NTSC-mandated ×10/11 width-rescaling. More info here.

Emulator

Dolphin

Dolphin is the only viable emulator for any GC/Wii games, and I used Dolphin 5.0-11991. The newer the version is, the more accurate to console it is, but I fixed a version in 2020 to have compatible save-states and to avoid risking the input lag changing.

Input Lag
I used emulator save-states to practise everything, and a Wii for actual runs, which relied on having identical input lag on both so muscle memory could carry over unchanged. It’s rare for anyone to achieve this lag parity, but there are many tips to try.

Lag is caused largely by the USB interface; that is, in my testing, I found that using:

This added up to 1.5f total. Most of these effects are due to controller-adapter/USB drivers rather than hardware. There is a custom driver for the controller adapter and installation guide that explains the nuances of the two adapters, their ports, firmware, polling and the PC’s USB controllers, and should be done as standard for any future emulator setup, on top of the standard Zadig driver setup. If this custom driver is used then the 4-port Mayflash ought to not have extra input lag. I never set up the custom driver because my setup predates the guide and was already lagless. The only benefit for me would be more consistency (console-like polling behaviour).

Other potential sources of emulator input lag, which I did eradicate in my setup but were too minor to be measurable with my testing, are:

In practice, my emulator setup had a total of ~3.16f of input lag (not a precise estimate) – see test.

Accessories

Input Display
m-overlay does a perfect job.

Memory Editor
I use Dolphin Memory Engine with the SMS RAM map to read and set RAM values sometimes, most notably for shine displacement – moving shine sprites for segmented IL grinding.

Save-States

To get save stating to crash rarely rather than often, and frame-advance to work at all, disable dual-core in Dolphin settings. My workflow was to make save-states during periods of no input like airtime, so I bound save state to spacebar and used my keyboard as foot-pedals. I rapidly reloaded save-states to grind segments using this floor keyboard (load state bound to numpad enter). So I’d save with left foot and load with right. This and techniques like shine displacement were key to rapid iterative (trial-and-error) learning – as high a rate of trials and results from those trials as possible.

This meant I’d have a set of save-states for each level, storing them at the other 9 slots (load-state/save-state hotkeys assigned to the numbers 1-9 and the letters right below them respectively). Then I could switch between them (by copying them into the active slot using spacebar) to practice a level. I’d switch between levels by switching folders of save-states in and out (at Documents > Dolphin Emulator) by renaming the “StateSaves” folder.

Autosplitters

I made two autosplitter setups, a visual one for real-time runs and a memory-based (emulator) one for fast runs (IWs/Any%).

Shine-Get Autosplitter

→ Shine-Get Autosplitter (article link). This is a visual autosplitter targetting the standard shine-get frame used for splits in full-game runs.

QFT Autosplitter

→ QFT Autosplitter (code link). This is a memory autosplitter usable with the QFT timer on Dolphin that, coupled with stage loader, allows Fast IWs, Fast Any% etc. to be done on cumulative IL timing. It automatically starts when leaving the file-select screen, resets when entering the title screen, and splits whenever QFT signals that a level has ended. The timer is dictated by this script (i.e. is not real-time), which pastes in exact IL times so that the final time is a sum of ILs.

The SMS version can be changed from PAL by editing the vars.gameID and vars.offsetMapID variables (instructions in the code comments). To use it, save the script from Pastebin as a .asl file, add the “Scriptable Auto Splitter” component to your LiveSplit layout, and configure it to read the .asl file, with every option on its tab in layout settings enabled.