NxEmuI released the first version of NxEmu about three months ago. At the time, it could only run 2048.
Since then, I’ve been working hard to improve it. So where does it stand now, three months later?
It still only runs 2048. Despite all the work, the user experience feels essentially unchanged.
So what’s actually changed?
Working on the foundations
It’s frustrating. I thought I’d be further along by now, but it is what it is. Most of the work so far has gone into foundational improvements: a new UI framework, modularized loading code, and automated build processes.
This kind of work doesn’t produce immediate results, but it’s essential. Without it, future development would quickly become messy and difficult to maintain. With the groundwork now in place, hopefully adding features and writing code will move much faster going forward.
UI Development
While the UI looks almost identical to the previous version, that is intentional. Under the hood, it is a completely different system.
The original version used a native Win32 interface. Now, the UI is built with Sciter, a lightweight HTML and CSS rendering engine designed for desktop applications. Sciter allows developers to build the interface using web technologies such as HTML, CSS, and a JavaScript like scripting language, instead of relying on traditional GUI frameworks.
It is much lighter than embedding a full browser engine like Chromium or Electron. It also has a smaller runtime footprint than Qt, which is what Yuzu uses.
Sciter provides solid cross-platform support. While not as comprehensive as Qt, it is still reliable, and far ahead of Win32, which has no native cross-platform capabilities unless you count Wine.
System Loader
I created a new, separate module for handling game loading. This sets the foundation for future support of decrypted file types by keeping all related code contained within a dedicated module.
Getting this to work required refactoring the existing code and migrating all file system operations. Reading and writing to the file system now happen exclusively within this module. The OS module can only interact with the file system through the interfaces exposed by the system loader.
This architectural change establishes clear boundaries around file system responsibilities, making the codebase cleaner, more modular, and easier to maintain.
Improvements to Horizon’s Service Code
While testing and integrating the new loader module, I brought in additional service code from the Yuzu codebase and expanded my own implementation. As a result, the service layer in NxEmu is steadily progressing and moving closer to Yuzu’s level of coverage.
Development Builds
I’ve set up Jenkins on a private server to automatically build and deploy NxEmu whenever a commit is made to the GitHub repository. This ensures that whatever I’m working on becomes available almost immediately.
All automated builds will go to: