Development Update 4

Development Update 4

It's time for a quick update on development progress again! But first, let me announce I'll be moving away from a weekly update cycle from now on. I became clear that a weekly schedule pushes development too much towards short-term progress that don't pay off well in the long run and hence keeps me from doing the more fundamental work that's required for the larger picture. From now on, Development Updates will be released on an irregular schedule, i.e. whenever meaningful progress happens as part of bigger ongoing development efforts.

With that said, let's take a look at what happened since the last update!

Progress on Super Mario 3D Land

After getting this game to boot last month, I implemented a number of features used by SM3DL later during the title screen:

  • The config blocks for parental controls and EULA version
  • Reading ExeFS data (such as the game icon) via filesystem module's SelfNCCH archive
  • A few configurations of the GPU's pixel pipeline
  • The "Previous Buffer" source for the texture environment

Of these, the ExeFS change required a lot of refactoring in the FS module code, but the other changes were fairly minor. With the fixes, the title screen goes a fair bit further now - note in particular the 3D graphics in the background!

Unfortunately, as soon as you try to start the game, Mikage will freeze up due to the lack of the Mii selector applet (and applet support in general). Implementing this will require a lot of testing effort, but the prospect of getting SM3DL in-game is promising!

Open-Sourcing Blobify

The other big item on this month's list is blobify, Mikage's internal serialization framework. Serialization is the task of turning blocks of binary data into meaningful objects such as C++ structures, and vice-versa. This comes up when reading 3DS-specific file formats (such as CXI or CIA), when decoding parameters for high-level emulation of services, when interpreting command buffers for GPU emulation, and generally whenever the emulator core needs to access data structures contained in the emulated 3DS's memory.

Considering how common this task is, I grew tired of reinventing the wheel for every component it came up in. To automate all of this redundant work, I created blobify as part of Mikage. blobify uses some very advanced C++ techniques to automate serialization tasks as much as possible, and it has proven to be a very effective tool at that. To allow others to benefit from this, I decided to spend a couple of weeks on extracting blobify from Mikage's source code and turning it into a proper library that can be used in other projects, too.

I released the fruits of this work earlier today on GitHub. This reiterates my dedication to open-source development, and is a first (if small) step towards open-sourcing Mikage as a whole.

Upcoming development items

Despite the progress, my todo list keeps growing! It's a good thing though - I'm getting a more accurate picture of what's required to get more games running, and hence it helps prioritizing development accordingly. Here are next "big items":

  • Shared font support, blocking many games from booting
  • Render target management fixes for the GPU core, currently causing many graphical glitches in various games (think of the radioactive water in Zelda OoT3D)
  • Applet support, blocking many games from getting past the title screen
  • Performance improvements to the CPU core

This post was originally posted on 31 August 2019 for patrons, and released publicly on 17 December 2019.

Mastodon