SMS Setup Information

I got my technical setup down to a fine art during my 4-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. I tested both with one Any% run sample (on PAL, new file, including 2 savewarps), and the black Wii was 1.7s faster:

Wii enthusiast Aeplexi seems convinced those drives are revision D4v1 but I haven’t bothered to disassemble the Wiis.

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 is a bit naff (there are some scrolling diagonal interference lines). It doesn’t bother me at all, but Wii2HDMIs without this problem are an option for ~£20 – from Electron Shepherd or Mayflash.

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 or shit tech to mitigate that), so they’re worth a shout with a Wii2HDMI. The standard for this as of 2023 is the MacroSilicon MS2131 (see teardown), which I picked up for £8 from AliExpress at this link and tested. 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, which might not contain the chips it purports to 🧐.

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.3f good enuff and 2.7f maybe the best possible.

The same setup but with the MS2131 capture card came out to 2.9f of input lag :O – see test.

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.hacks.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 (meaning run HackMii installer to install BootMii + Homebrew Channel, then install Priiloader). 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 sometimes…). 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.

Swiss

Swiss is a loader that runs all versions of SMS (including PAL) at 480p and supports the practice codes (if you buy an SD Gecko for £3 from AliExpress).

We used to use specific versions of Swiss that were more or less reliable on different Wiis with no pattern, until I diagnosed the problem and fixed it with an interim method. Now, speedrunners have the option of installing a cMIOS with Swiss built-in, which uses a recent (Dec 2024) release of Swiss and no longer requires a separate swiss.dol file, nor a cIOS to install it. You can even skip using the Wii Swiss Booter, but it’s still the most convenient option.

Simply run the linked cMIOS installer to install it, and then you can start Swiss using Wii Swiss Booter from the Homebrew Channel (hold Y after starting it).

Aspect Ratio
With Swiss, I force 480p and also 1:1 horizontal width (the former is applicable to PAL, the latter to all versions), 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). Conveniently, 640px is SMS’s internal resolution, hence the 1:1 option does what we want.

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.

Nintendont

Nintendont 6.498 (and onwards) can be used for SMS practice codes. It gives near-instant loads, and also an advantage because it runs GameCube games in Wii mode, leading to reduced lag. It also introduces novel glitches related to stale registers. This lag advantage is necessary to be competitive on some ILs while they still use real time, but otherwise, Nintendont is inaccurate (not to mention unmaintained) so Swiss is better to use instead. You can report Swiss problems to Extrems in eir Discord.

You should avoid using disc drive for practice and ILs in favour of ISOs on removable media (meaning SD Gecko on Swiss), to preserve the longevity of your disc drive. The exception is using the loading beep to time something (tho this is unnecessary when using Nintendont with its near-instant loads).

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.

(It did eventually randomly stop working 🤔 so I switched to the new stable releases).

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.