Add libretro core build option

[SupervisedThinking]

Well since @schellingb added the quite nice https://github.com/schellingb/dosbox-pure core I was wondering if it doesn't make sense to combine efforts to have "one for all" dosbox versions.

So emulator like those:
https://github.com/hrydgard/ppsspp
https://github.com/mgba-emu/mgba/tags
https://github.com/NovaSquirrel/Mesen

already have an integrated libretro submodule and you can chose which libs or binaries you want to build instead of having to use an often dated, even outdated, libretro fork. I have actually no clue if this would work but I guess in the long run it would be easier to maintain & rely on one repo.

[kcgen]

There's also @realnc 's https://github.com/realnc/dosbox-core fork that uses libretro's back-end.

Both Core and Pure have replaced DOSBox's SDL-interfacing code (which provides video, keyboard, mouse, joystick, and audio interfaces to the OS) with libretro calls. But to be clear, this isn't a 1:1 "search and replace" effort: instead, big tangles of nasty SDL interfacing code needs to be ripped out and new libretro interfaces and logic put in.

To provide a buildable toggle between the two, we'd want DOSBox's interfacing code (ie: the stuff that hooks into SDL2 or libretro) to be abstracted and elegant.

A high-level design effort would be needed to layout the interfaces into both libraries and come up with a library-agnostic abstraction that accomodates both libraries. This would pave the way to more easily supporting other back-ends too (ie: say Android, if it has something like SDL and libRetro for App developers).

The pros:

• Would further future-proof DOSBox.
• Would allow more authors to rally around fewer forks; be it Staging or some future fork that takes on this effort.
• Would very-likely improve the compartmentalization of DOSBox's logic from the framework(s). This isn't a guaranteed win, but it usually is when a project's forced to support multiple frameworks.

[dreamer]

Personally, I would be very glad if we had a regular maintainer or contributor who uses and is dedicated to libretro (I don't use it), so we could make it new Tier-1 platform besides Linux, Windows, and macOS (which means tying into CI, official release builds, sharing the same buildsystem, etc).

We already talked a little bit about this with @realnc in #324 but back then it was practically impossible:

• libretro core requires fully-static build, and in DOSBox Staging we refuse to bundle code of our dependencies in our repo (because updating such code is maintenance burden and makes it harder to be packaged by Linux distributions). This problem will be resolved via Meson migration (the same way we handled mt32emu)
• at the time, DOSBox Core had some work that we haven't put into Staging - I don't know if we're on par now (probably not), but we definitely moved closer after merging a lot of great work by @realnc.
• DOSBox Core uses C++17… It's still a problem for us - we're still on C++14 and won't start transition to C++17 for another few months. I already know about several problems with C++17 and we just don't want to deal with them yet. GCC finally finished the implementation of C++17 in year 2020… If there will be no critical roadblockers, we'll switch to C++17 after Ubuntu 16.04 will reach EOL. And switching to C++20 is soooo faaar away, that there's no point in even talking about it.
• We won't remove SDL2 from our codebase, and we won't make it an optional dependency either. We can allow some libretro-specific dependencies and subsystems (if we'll develop proper abstractions to avoid code duplication), but C++ standard library and SDL2 are the only stable building blocks we depend on.

But perhaps the situation changed since last time we talked about it? @realnc What do you think?

As for DOSBox Pure - AFAIK @schellingb is not interested in cooperation and will not use modern C++. We won't move back to the ancient C++, because that language has so many problems and is missing so many features… Also, we have very different ideas about how ROM-like format for DOS games should be handled.

[kcgen]

Great points @dreamer. Provided SDL2 builds and supports overlapping platforms with libretro, then we could effectively use SDL2 for some functions and only tie into libretro where it makes sense (ie: maybe joystick and video handling).

Regarding differences of opinion regardling a DOS tailored ROM format - if we make it a relatively stand-alone class or library-like interface, then it could easily be disabled for forks that might not agree with it. But if it's a low-risk, minimally-invasive "bolt on", then I could see others adding it without issue (like -X, -Core, -ECE, and maybe even SVN)

[SupervisedThinking]

I'm aware that libretro basically replaces the gui & apis with a common ones that then can be used by Retroarch or Kodi Game (Retroplayer) or what else. Since there are plenty of "alternatives" there is no hurry for such a submodule but in the long run it's might something that could improve the everyday usecases.

[schellingb]

My project is actually intended to be much less "DOSBox" than any of the existing libretro cores (or forks). For example there is no conf file support and the built-in key mapper has been removed. So it is not intended for people who want these things exactly the way they always were in original DOSBox. That's not to say it is aimed at people who never used DOS or DOSBox. On the contrary, it is aimed at people like me who always loved the tech and possibilities of DOSBox but never liked the interface.
That is the main thing which might make it look like I'm not open to cooperate. If a project and its users likes the configuration and user interface of original DOSBox, then I'm certainly not telling anyone to stop using that.

I also want to add that I added support for mounting of ZIP files (and thus the saving of file system modifications into a separate file) because it seemed feasible both technically and as a feature that can be used in 2020 by a wide range of users. People either already have their games in a ZIP file or know how to make one. I don't have to come up with specs or file layouts or rules or anything. From my own testing/playing and from feedback I've received, I feel like it was a good choice.

That's not to say that I wouldn't mind a future were DOS games truly are like a NES ROM. But I feel like that is still very far off. Just technically, a NES emulator can run pretty much every existing game in its default configuration. But DOSBox still has a few options that it forces on the user (darn "no-line buffer hack" for Build engine games, the setting cputype that even in the help lists a few specific games that need specific type, etc). And then there's badly made games that are just very picky about environment and other DOS stuff (looking at you Daggerfall). So should such a "DOS ROM Format" just come with a dosbox.conf file to accommodate for it's shortcomings? That seems like a bad choice to me. Ideally the emulator would be improved so the settings are not necessary. Also why make the format DOSBox exclusive, shouldn't it be open to other emulators?

That part about me wanting nothing to do with "modern" C++? Yeah that checks out. I'd rather move to C99 or switch to something sane like ZIG :-)

[kcgen]

Archiving discussion

[kcgen]

Archiving discussion to: dosbox-staging/archived-discussions-for-dosbox-staging