Home | Downloads | Screenshots | Forums | Source code | RSS | Donate

Register | Log in

< Long-due status updateQuick news >

Merry belated Christmas Dec 28th 2023, by Arisotura

(to those who celebrate, that is) As I have received and set up my new laptop, I've been able to work on melonDS some. The goal is still the same: to adapt melonDS for supporting multiple instances within one process. The frontend is proving to be tricky, because it was largely built without many regards for code quality. Originally, the frontend was just quickly built around the program entry point in main.cpp, as it just needed to provide a means to use the emulator. We had a simple window, a dedicated thread to run the actual emulation, and that was it. Obviously, over time we added various features to the emulator, rebuilt the frontend around different UI toolkits, piled on more features, and so on. Basically, the frontend code became a mess, and everything was more or less just dumped in the global namespace -- there are some modules which live in their own namespaces, but it's all not very modular, and doesn't lend itself to running multiple instances of melonDS. I started by splitting main.cpp into separate files. We are far from done with the cleanup, so there's a lot of cruft around, but the basic idea is the following: * main.cpp just holds the entry point (main()) and global application-related stuff. * Window.cpp holds the MainWindow code, for managing the emulator window. We may also add support for multiple windows. * Screen.cpp holds the ScreenPanel code, that is, the panel widget that goes inside the emulator window and handles display and touchscreen input. There are two kinds of ScreenPanel: one that relies on Qt's graphics API, and one that uses OpenGL. * EmuThread.cpp holds the emulation thread. From there, each EmuThread would hold its own instance of the emulator core (which we mostly finished porting), and optionally point to one or two windows to display to (or none, in the case of a headless instance). After laying out this basic separation, I figured it would make sense to integrate the OSD feature into ScreenPanel. The OSD module was a bit of a mess, with having to maintain different code paths for Qt or OpenGL drawing. Now things are a lot cleaner. There's still quite a bunch of global state and stuff that we need to adapt before the dream of emulating multiple DS's within the same process can come true. But we're getting there, slowly but steadily. This is the perfect occasion to finally clean up and improve our frontend code.

16 comments have been posted.

< Long-due status updateQuick news >

Pages:12

Pages:12

Post a comment
Name:

DO NOT TOUCH