Kirby Triple Deluxe: Notes

[soiryl-pas]

I'd like to share some experiences when playing Kirby Triple Deluxe (EU) on Mikage, I hope it's useful!
I've tried a Debug build, Release build and Release build with -Ofast -march=native -mtune=native -funroll-loops to compare. The latter two actually only have minute differences in performance, so I'll just clamp them together as "Release".

Nicely enough, the game runs for the most parts with 60fps for me on Release! However, there is a heavy performance hit in the levels, as when progressing through levels, the frame rate drops to 20fps. Interestingly, this frame rate drop is pretty continuous and from what I could test, it's connected to level progression, not time spent ingame/rendering. With Tracy, I can see that GPU Emulation Zone takes longer and longer to finish, and in the default logs, there can be flocks of 15+ TRACE: Waiting for vertex buffer memory to be free again lines, so I presume it has something to do with the vertex buffer. Also, when opening the pause menu or touching the Miracle Fruit in the first level for the Hypernova cutscene, it immediately recovers to 60fps, until it resumes with the level, where it drops to the same fps as before.

Crucially, the game needs not yet implemented Pica::AlphaTest::Functions:

• 5, for the pause menu and sun stone menu to open
• 4, for the first door in the second level

When implemented in shader_gen.cpp and pica.hpp according to https://docs.mikage.app/GPU/Internal_Registers/#gpureg_fragop_alpha_test, everything just works neatly out of the box afterwards. I wasn't sure whether these little changes are worth a PR, especially as I thought there could be a reason for these missing right now, so I'm mentioning it here.

As for graphics and audio, I think it's rather likely that there's something wrong with my dependencies, but SDL software rendering and enabling audio don't work for me, only vulkan rendering does. SDL software rendering will only render the last frame and freeze on it, until I switch to vulkan with the 7 key. There's also expectedly some amount of graphical glitches, which like to occur frequently but inconsistently, where I'm however also really not that sure of how much is caused by the application renderer in contrast to my dependencies and my hardware.
As for consistent graphical glitches, the opening cutscene only shows a blob of coloured pixels, similar to #54. From my limited experience with GBA and DS, I would've guessed that there is a mismatch in the Screen-Colour-Format used by the game and expected by the emulator, but the graphics pipeline on 3DS works pretty differently, so that's really just a very wild guess. (Edit: This is due to Y2R, SetReceiving appears in these cutscenes a lot in the logs)

[neobrain]

Thanks and great job on the extensive analysis! There's a bunch of things here so I'll reply individually:

there is a heavy performance hit in the levels, as when progressing through levels, the frame rate drops to 20fps

Is the variable here session playtime (i.e. "how long has Mikage been running the game?") or game progression (i.e. "later levels are more strongly affected")? The former would indicate a need for smarter GPU resource management, whereas the latter could be a general effect of levels growing in complexity.

there can be flocks of 15+ TRACE: Waiting for vertex buffer memory to be free again lines, so I presume it has something to do with the vertex buffer

Seems to be more of an indicator that there are too many render batches still in flight. The vertex buffer memory is probably just the resource that is exhausted most quickly by that (as opposed to uniform buffers, textures, ...). This could be a bug with how Mikage manages render batches (i.e. not flushing them when it should, or not marking them flushed when it should), or perhaps simply increasing the vertex buffer size could fix it.

Also, when opening the pause menu or touching the Miracle Fruit in the first level for the Hypernova cutscene, it immediately recovers to 60fps, until it resumes with the level, where it drops to the same fps as before.

... now that's an interesting observation. If you're feeling adventurous, plotting some of the Vulkan renderer's resource values via TracyPlot and observing if any of them change drastically at that point could give some insight.

I wasn't sure whether these little changes are worth a PR, especially as I thought there could be a reason for these missing right now, so I'm mentioning it here.

Go for it! Just the fact that you verified the implementation works with a real-world use case is already useful and necessary testing work.

As for graphics and audio, I think it's rather likely that there's something wrong with my dependencies, but SDL software rendering and enabling audio don't work for me, only vulkan rendering does

Software rendering hasn't been tested in a while, so it might be broken (probably not the rendering itself but something silly in the ResourceManager or Display subsystems).

enabling audio don't work for me

The "enable audio" option enables audio emulation but not actual audio output. The Developer Edition uses Teakra for interpretation, which is too slow to produce pleasant audio output. As a result the option is only useful for debugging the handful of titles that won't boot without it.

There's also expectedly some amount of graphical glitches, which like to occur frequently but inconsistently, where I'm however also really not that sure of how much is caused by the application renderer in contrast to my dependencies and my hardware

What GPU, GPU driver, and OS are you using?

[soiryl-pas]

Ah, I phrased it a little bit wrongly: The performance hits correlate with in-level progression, on a per-level base. Using the first level as example, it starts out with 60fps, then I go through the level and the frame rate will continuously drop little by little. When I'm arriving at the hypernova cutscene, it has dropped to approx 20fps, however, the cutscene itself plays with 60fps. Afterwards, the level continues with the 20fps it left with, right until the end of the level. The kirby goal game then plays with 60fps, and the overworld level select afterwards also does so anyway. The other levels I tested show similar behaviour, where they start off with high/moderate fps, and then, through the level, the performance continuously declines.

I then compared the performance of setting vertex_buffer_size in renderer.cpp to 1 * 1024 * 1024 and 1024 * 1024 * 1024, and the performance feels and is statistically pretty much the same. The flocks of TRACE: Waiting for vertex buffer memory to be free again also seem to occur equally often, so the buffer size doesn't seem to be correlated to this.

Playing through it again, it should be noted that while the frame dropping feels continuous and there aren't any abrupt frame drops, the levels do have certain... "chokepoints", where I know that if I just proceed normally, fps will fall in the next seconds to some lower niveau, and these points are always the same for each playthrough of the level at hand. It also doesn't seem like these chokepoints are associated with doors/transitions or some distinct level geometry, they're just... randomly there, but always at the same place.

... now that's an interesting observation. If you're feeling adventurous, plotting some of the Vulkan renderer's resource values via TracyPlot and observing if any of them change drastically at that point could give some insight.

That sounds intriguing, I'll check it out sometime!

Software rendering hasn't been tested in a while, so it might be broken (probably not the rendering itself but something silly in the ResourceManager or Display subsystems).
The "enable audio" option enables audio emulation but not actual audio output. The Developer Edition uses Teakra for interpretation, which is too slow to produce pleasant audio output. As a result the option is only useful for debugging the handful of titles that won't boot without it.

Ah, then that should be alright

As for my environment:

• OS: NixOS Warbler, 25.05(.20250804.ce01dae)
• GPU: AMD Radeon RX 7600 XT (RADV NAVI33) and this should be used for rendering and presentation, judging from the default log outputs
• GPU-Driver: Mesa 25.0.7 with RADV and Vulkan Instance Version 1.4.313 (from vulkaninfo)

To give a general description of graphical glitches that may occur: The title screen Kirby has a wrong shade of pink with missing eyes; some menu-button-areas show an incorrect background (made out of other tiles?); some characters of labels appear to be glitched; instead of clouds floating in the background, it's a melange of what looks like different tiles from the same level; Kirby's health bar is covered by a white rectangle;

Interestingly, these glitches don't occur always and it feels like there is some sort of system to it, at which time a sprite is presented glitchy and at which time it isn't.

[neobrain]

BTW I realized I had a WIP patch sitting around somewhere that should optimize batch management a fair bit. Let me try and get it updated to see if it helps here.

[soiryl-pas]

A little update; in the last weeks I was able to test on different (very old and low-spec) machines, because I was a little bit curious how they'd perform, and to compare to my main machine:

• Fedora release 42 (Adams)
• Intel(R) HD Graphics 4600 (HSW GT2)
• Intel open-source Mesa driver, 25.1.7

and

• NixOS Warbler 25.05(.20250826.4e7667a)
• Intel(R) HD Graphics 530 (SKL GT2)
• Intel open-source Mesa driver, 25.1.7

The graphical issues I mentioned prior (on my main machine) are not present there, so I concluded there are device- or driver-related reasons.
And indeed, using amdvlk instead of RADV made everything in Kirby Triple Deluxe display correctly. I'd thus think this is some upstream issue, without precisely knowing what causes it, though; I otherwise haven't had issues with RADV before. This could also always be an issue of how RADV is packaged in nixpkgs on NixOS, difficult to say
If that's perhaps interesting, as for performance, amdvlk stutters significantly more in the GPU emulation Zone, but apart from that their frame graphs mostly overlap in Tracy.

Also on a different note, I've delved a little bit into Tracy to attempt plotting interesting things, but I feel like I need a better grasp of how Vulkan works, so that'll probably may take a little more while.