Add a simple, SDL2 UI

[Screwtapello]

higan's success up to this point is at least partially due to hiro and ruby; being able to provide a native-feeling UI across multiple platforms is a tremendous benefit. However, I know hiro's most solid backends are GTK2 and Win32, and while Win32 isn't going away any time soon, GTK2 definitely is. GTK3 and QT5 backends are available, but they're not as thoroughly tested. In addition, the complexity of higan's hierarchical system model is already bumping up against what can reasonably be implemented in hiro.

I'm worried that anyone who wants to do any UI work on higan in the near future will need to learn all about nall and its memory management conventions, all about GTK3 and QT5 and Win32 and Cocoa, and their overlaps and incompatibilities, and all about hiro's implementation and the compromises it makes. And that's just to write code — debugging it will be at least twice as difficult (because debugging always is).

Obviously byuu managed to learn all those things, but:

• few people are as smart as byuu
• it still took him twenty years to get to that point
• the complexity of the new higan UI was part of what burned him out

...so I don't have high hopes that anyone else will do a better job.

Therefore, I'd love to have a super-simple UI that just connects higan's hierarchical system architecture to a really basic, portable UI like raw SDL2. It wouldn't have to support configurable keybindings, or low-latency video, or importing games from other formats. Just an executable that takes a path to a higan system definition (the directory higan creates that describes all the components in a connected system), sets it up, and renders audio and video.

That should ensure higan is still useful even if hiro is not, and would provide a base for other, future UIs to be written.

[FitzRoyX]

The flickering and delays in the Windows port of byuu are tolerable, but in bsnes they're much worse. bsnes even crashes if you access configuration too fast. This would be a lot of work, but I think the long-term ideal situation going forward is to eliminate hiro in byuu and move to native UI code for each platform. This requires:

-having all essential options in the menu -moving advanced options to the cfg and eliminating the subwindows these options required. -keeping the cfg in a place people can find it to adjust non-essential values (brightness, volume, latency, path overrides, driver latency) -accepting that features only byuu uses (manifest viewer, tracer) are only going to be available on his platform. -accepting that fancy things like cheat editors and state managers are going to be in forks or as platform-specific contributions -the about menu is simply a link to here or his website -Statusbar would be forced. "Map Inputs..." and "Map Hotkeys..." would simply cycle through the 10 keys to bind and use the statusbar as a display.

I think the initial purpose of hiro was to more easily commit complex interface designs and changes across multiple platforms. However, it ended up causing rendering problems that apparently can't be eliminated. And rather than save byuu time, it tempted him to constantly tinker with UI and question entire paradigms.

If we pin down essential features for the menu, and relegate the rest to the cfg, then I think it's possible to create native interfaces that are optimally performant, stable, and maintainable.

[fprimex]

I just stumbled onto this while researching GUIs for my own projects. I looked at higan and I'm sure that the current GUI on Windows (and whatever else you wanted) could be reproduced with wxWidgets to have nearly 100% of the code multiplatform. I have experience doing this, and it looks like I'll be settling on wxWidgets once again after (re-re-re-)researching GUIs. Bonus: it's C++ as well.

I did just read about Dear IMGUI which looked interesting, but it probably won't work for my stuff. If you're interested in wxWidgets let me know.

[FitzRoyX]

I think moving to a different toolkit would be a fairly lateral move and probably double the binary size. I'm not saying it isn't a good idea ever, it's just overkill here. Debuggers and other kinds of apps with entry need toolkits for cross-platforming, but I think I've shown that we can get by with nothing but a menu and statusbar, so there's no need to inherit the drawbacks of any toolkit.

Also, note that I'm a fan of hardpathing when it's practical, because we avoid having to tell the emulator where every bios is before playing games, and it's better for portability (D: may be E: on the next computer, thus breaking path lookup the moment you take your USB-drive to another computer). Roms libraries can be massive, so it's fine that we don't hard-path those. But there are a total of 100 firmwares across every system byuu emulates @ 7mb. Sorry, but avoiding duplication and trying to "share" these files between emulators doesn't seem remotely worth it.

[Screwtapello]

6 is a good example of the kind of UI weirdness I don't think we have the time or energy to fix. I'm sure there'll be more examples sooner or later.

This would be a lot of work, but I think the long-term ideal situation going forward is to eliminate hiro in byuu and move to native UI code for each platform. This requires:

I agree that an actual native UI for each platform would be best, however I don't think a native UI requires any of those things. If we're OK with a different UI for each platform, each platform is natively going to support different features, put them in different menu structures, expose the configuration in different ways, and that's OK.

People have suggested alternatives like Dear ImGui or wxWidgets, but while I'd love to have either (or both) of those, writing a new, polished UI is way beyond the resources of the current maintenance team. That's why I specifically mentioned a simple command-line SDL2 based UI. Not because that's how I think higan ought to be used, or because that provides the best end-user experience, but because I think it'd be the best starting point if somebody comes along who does want to write a new, polished UI.

[fprimex]

If you're interested in a POC of wxWidgets holding an SDL2 frame I can put one together. There's plenty of example code out there that could be adapted. Is there an entry point in higan to hand it an SDL frame to render to?

If you like that then I would do the rest with wxGlade. At that point the GUI contribution bar is extremely low.

The static library is from about 3MB to 45MB on Windows depending on what components are included. Bear in mind the 45MB version contains a near complete implementation of a web browser among other things. With some continued tweaking I am betting it could be made smaller. Linux users probably would install wx from their package repos, and Mac users generally don't care about app size at all.

Not trying to push anyone in this direction. Just making myself available if you want to give it a shot.

[Screwtapello]

Is there an entry point in higan to hand it an SDL frame to render to?

I literally have no idea. This is exactly why I'm hoping somebody will add a command-line based, SDL front-end - so when somebody like yourself comes along and helpfully offers to make a nice wxWidgets UI, I can say "here's a simple SDL-based UI you can copy all the higan-specific details from" rather than "here's a haystack of C++ code, good luck finding that needle".

Thank you very much for your offer, and I wish I could take you up on it, but to the best of my knowledge nobody yet has the information you'd need to get started. If you want to study the existing UI code as well as write a new UI, you'd be more than welcome, but I totally understand if you're not comfortable signing yourself up for that much work.