Switch 2 Compatibility

Spacemario

Hi Fuze team! It's sounding increasingly like the Switch 2 will be officially unveiled in just a few weeks, with a March release. Just curious if this is on your radar, or if you plan to support the software on the Switch's successor.

Nintendo's President told investors the new hardware will be backwards-compatible, so hopefully Fuze will "just work"-- but it might be nice to eventually get support for 4K, or whatever additional functionality the new joy-cons may have.

Anyway, just figured I'd ask!

Spacemario

Every time Nintendo updates their compatibility list, I check to see if there are any mentions of Fuze, good or bad-- nothing yet: https://www.nintendo.com/us/gaming-systems/switch-2/transfer-guide/compatible-games

I wonder if Fuze has been through this testing program yet? I have a Switch 2 coming on launch day, Fuze will be the first thing I start just to see what happens!

Z-Mann

My interpretation of these lists is that if something is not on there, they have not found any problems, and I would expect that the very minimum test Nintendo did with everything is that they booted it up. That's mostly based on the obscurity of some of the titles on that list :)

Spacemario

@z-mann Absolutely, totally agree!

My question is, is Fuze esoteric enough that they haven't even gotten to testing it yet? Also, there are a zillion permutations of features you can use in Fuze-- it's not as simple as just firing it up to see if it starts, you know?

I have a hard time seeing a Nintendo QA employee learning the language to write a test bed application leveraging all of the functions, the map editor, etc. But who knows!

I guess we'll find out soon enough, Switch 2 is right around the corner (I'm super excited!).

Z-Mann

@spacemario said in Switch 2 Compatibility:

I have a hard time seeing a Nintendo QA employee learning the language to write a test bed application leveraging all of the functions, the map editor, etc. But who knows!

Yeah, I'm sure they're not doing that.

As a data point, FUZE competitor SMILE BASIC was on one of the lists, I have not checked for updates, and of course I don't know what problem they found exactly. But that can give you an idea about how obscure a software needs to get before they don't find problems.

My baseline assumption is that they are using some variation of the regular validation procedure on every single title. Probably not the procedure they use for new titles, but what they do for updates. And probably even less than that; at a certain point, they just have to stop testing, get the stuff out in the wild and then react to specific bug reports from users and developers.

I'd say there is a greater than 90% chance that things will be basically fine on day one.

Spacemario

@z-mann Great analysis, and me too-- I share in your optimism! I'm suspecting I'll fire it up, try some Fuze games, and they'll "just work"; the Switch 2 is so similar architecturally! But I'll post back here either way and let people know what I've found :)

Spacemario

Fuze seems to work great on the Switch 2! I haven't tested exhaustively yet, but I did fire up two of the games I wrote (Skatey-Cat, and Dredge) and both of them ran flawlessly.

Z-Mann

My Switch 2 arrived a day late, but that meant I was bored and I created a benchmark.

Err. Does anyone here get into hot water if we share the results (I'll also ask on Discord)? I suppose licensed developers are under NDA, or we would have seen the numbers.

I suppose it is safe to say this much: If you want to share your game, ideally test it yourself on a Switch 1, or have it tested, or listen to complaints of Switch 1 users.

Z-Mann

Two small disappointments. The first one is that the joycon mouse mode is not recognized. Neither can an USB mouse (that does still work in FUZE on the Switch 2) be used to navigate in the system UI.

No objections from Discord, so here we go. Pending share code of the crude benchmark is FZU73MND51.

There are five tests. Resolution is set to 1280x720 for all.

A whole screen drawImage() call from a loaded image.
loadImage()/freeImage() of "Selavi Games/classroom"
one quaternionMultiply() call
one bare loop, really just `for i = 0 to x loop repeat' (the last two tests run an internal loop, all other tests have little CPU overhead per run and iterations are managed by the calling code)
a 3D scene with 100 cubes and four worldShadowLights is rendered

A problem with benchmarking especially GPU stuff is that the operations are deferred and only executed on update(), which then also waits for the vertical refresh. So you have to do enough stuff per update() call to get less than 60 FPS, but not too much because that overflows the queue. A scaffolding function takes care of that, ramping up the number of times each function is run until it is slow enough, then running that twenty more times and taking the total time.

Results, all in low level Iterations per second, for the CPU tests 'M' stands for 'million', there was a lot of variation (thermal throttling, maybe?), so all values should be taken at most to +/- 10 %.

                  Switch 1 Docked   Switch 1 Handheld     Switch 2 Docked   Switch 2 Handheld
drawImage         5300              2300                  13000             7800
loadImage         200               220                   660               630
quaternionMult    1.4M              1.3M                  3.3M              3.6M
raw loop          5.3M              5.4M                  15M               17M
3D Scene          139               63                    480               282

The 480/s for the Docked 3D scene is actually me finding it difficult to go lower than 60 FPS total without overrunning the command buffer. That's just what you get if you render the scene 8 times per frame. It would not go much higher, though, I tried 10 iterations by hand, and it went up to 500/s only.
The loadImage test is probably just CPU bound and has nothing to do with actual data access. Its numbers are lower on the first run (100 on Switch 1), and since taking these numbers, I moved FUZE from the SD to internal storage and nothing changed.

So... yeah. That is quite a significant upgrade. A factor of 2 to 3. And, we knew that before, significantly less GPU/Bandwidth on Handheld mode... The worst practical spread would be in the 3D test, the 480 fps Switch 2 Docked vs 60 fps Switch 1 Handheld, a factor of 8! It is quite hard to run into problems with the GPU, mind. Even in the worst case, drawImage on Switch 1 in handheld mode, that is still an overdraw factor of 38, meaning you can have 38 parallax scrolling layers in your game (not much else, though).

I'll write a tiny bit of code that can detect whether you're on a switch 1 or switch 2 and suitable functions you can use to bring the performance you get on a Switch 2 down to Switch 1 levels. I mean, it's just going to be sleep(0.01) to take care of the CPU :)

The second disappointment is: Switch 2 Handheld seems to outperform Switch 1 Docked with a very comfortable safety margin. Switch 2 could run the handheld compatibility mode with the settings for docked play and let games make full use of the 1080p display, but they don't. (EDIT: Correction below) Of course, that'll drain the battery faster, and there may be problems with more complex pixel shaders. Oh well, actually, the upscaled 720p looks surprisingly good. Better than the native 720p on the Switch 1, I dare say, and I'm the guy who insists on using bitmap fonts wherever possible because antialiased fonts look too blurry, yes, even at 180 DPI.

Z-Mann

Darn, I should have scrolled up in the Discord, similar numbers were already shared there, credit to Node, Bird and joyrider3774.

And yes, sleep(0.01) is good enough to waste CPU time on the Switch 2 to bring it down to about Switch 1 level. It can't be perfect for all use cases, different loads have different speedups.

Full code, also in the shared benchmark (minus or plus typos):

// on Switch 2, call this function once per frame, no matter where, to get
// the remaining CPU power roughly in line with what it was on Switch 1.
// As this function only sleeps, it does not waste energy.
function switch2ThrottleCPU()
return switch2ThrottleCPU(1)

// more flexible variant. Use factor 2, for example, if you are aiming for a locked 30 FPS
function switch2ThrottleCPU(factor)
    // yes, it is that simple. Switch 2 emulation has about 3x the CPU power as Switch 1,
    // 10 ms are about 2/3 of 16.7 ms, a full frame at 60 Hz refresh.
    sleep(0.01 * factor)
return void

// on Switch 2, call this function once per frame, no matter where, to get
// the remaining GPU power roughly in line with what it was on Switch 1.
// There is no way to just pause the GPU, so we need to burn cylces.
// Use only for profiling your game.
function switch2ThrottleGPU()
return switch2ThrottleGPU(1)

// more flexible variant. Use factor 2, for example, if you are aiming for a locked 30 FPS
function switch2ThrottleGPU(factor)
    // different workloads depending on operation type
    var repetitionsBase = 120
    if docked() then repetitionsBase = 180 endIf
    var repetitions = int(factor * repetitionsBase)

    var source = createImage(1280, 720, 0)
    var dest = createImage(1280, 720, 0)
    
    var previousDrawTarget = getDrawTarget()
    setDrawTarget(dest)
    for innerLoop = 0 to repetitions loop
        drawImage(source, 0, 0)
    repeat
    setDrawTarget(previousDrawTarget)

    freeImage(source)
    freeImage(dest)
return void

And here is a Switch 1/2 detection function. It uses the GPU throttler to produce frames that are longer than 1/60 s on Switch 1, then detects that.
This might be useful if you want to consistently target 30 FPS on Switch 1 and 60 on Switch 2.
I'm using a GPU function for the test because I expect them to be more consistent in performance over future versions than tight FUZE code loops.

// call this to detect whether you are on Switch 2
function switch2Detect()
    // measure memory bandwidth with image transfers
    var deltaTimes = []

    // just wait two frames
    update()
    update()

    for outerLoop = 0 to 6 loop
        switch2ThrottleGPU(1.2)
        update()
        deltaTimes[outerLoop] = deltaTime()
    repeat

    // the first three frames are practice runs
    // count the number of frames that exceed 1/60 s
    // if we have at most one missed frame, we are probably on Switch 2
    int missedFrames = 0
    for outerLoop = 3 to 6 loop
        missedFrames += (deltaTimes[outerLoop]*60 > 1.1)
    repeat
return missedFrames <= 1

Z-Mann

Oh, I was very wrong! Bird found out that if you just setMode(1920, 1080) update() in handheld mode, that actually makes full use of the internal display resolution! Games, especially FUZE games, can CHOOSE to run with docked settings in handheld mode!

Spacemario

@z-mann That's awesome-- so we can do 1080p in handheld mode!! I need to look at your code above to see how you're detecting Switch versus Switch 2-- thanks for the great service you're providing by running these benchmarks! I'd love to see Fuze have some kind of second wind, not sure how to make that happen.