Cross-platform GUI needed.

[ghost]

If anyone is interested, a cross-platform GUI library and/or widget toolkit (not too much overhead) would be a great step to enhancing the frontend of this emulator. It's not too much work and it can be really fun to do! I am working on platform-specific GUIs for frontend testing and to hook the cores to (in the future), but cross-compatibility is going to make all the difference! It should have menus, sub menus/screens for all the hardware profile settings, file loading procedures, and whatever else it can benefit from. Later on, it will be easy to converge the core settings and features/functionality to the actual hardware emulators when they're further along.

Ideally, a GUI library that does not tie any part of the program (as a whole) strictly to the GUI itself, such as to avoid problematic platform-switching or emulator core dependency on it (do not want that). We'd want it to work initially on these platforms:

1.Windows XP and up;

2.OS X (XQuartz, including Mavericks, Snow Leopard, and Mountain Lion);

3.Linux (Ubuntu, Debian, Mint, SteamOS, etc.).

Later on down the line we'll want these as well, so not too much precedence should be put on x86/x86-64 only code:

1.Android (ARM & x86);

2.iOS.

Ideas: Libretro, Qt, SDL+OpenGL, wxWidgets (x86/x86-64 only).

NOTE: Cross-platform pull requests are meant for the cross-platform branch.

[fuel-pcbox]

You won't be able to work on mobile platforms. PS4 emulation will take so much overhead that even the best computers would be looking at 5 FPS AT BEST.

[fuel-pcbox]

I would like to note that since the Dolphin team has had so much trouble with Adreno, I'm just going to say that Qualcomm is shit.

[ghost]

@vgturtle127 Would be great. Just send a pull whenever you get some stuff done and I'll merge to the main branch, or maybe create another one for cross-platform (you be the judge)?

About Android and mobile platforms, I'm aware that it's a shot in the dark for now, but this project will likely take years before it gets remotely anywhere with x86 to start with (if it ever does). By the time this project advances, when and IF this project can make any impact, I'm guessing the mobile platform will be comparable to at least Sandy Bridge-like architectures/designs. That should be enough to get something out of, so I wouldn't call the portability-potential off just because we're years behind.

As for my progress, I'm pretty much done with a Windows-only 32/64-bit GUI using just the Windows API with combo boxes, windows, some settings adjustments, and workability with DX 10. There's barely any code to constitute GPU emulation, and that's going to be a massive problem to overcome with the complex architecture that it uses. I'll try and see if I can get something going with the GPU as well, but I honestly have no good ideas on how to further the emulation of something so massive-scale and parallel.

[ghost]

Yes, it's fine. I created the separate branch for the cross-platform stuff as well, so make a pull there.

[inactive123]

@vgturtle127 Can you explain what is actually so 'slow' about libretro or is this just again baseless accusations on your part?

It's getting really annoying reading this stuff by you where you go around to every project and tell them that libretro is a bad idea (no proof as well or any quantifying statement behind your claims) when all you've done so far on this project is adding a README and some code comments and there is no indication you are actually a 'developer' at all that is capable of coding anything. At the very least refrain from making comments about stuff you don't understand. Thanks in advance.

[inactive123]

Well, most of the libretro cores have been thoroughly tested with at least Clang and GCC. MSVC can't compile most of the cores but it's slowly getting there. I'll have to check the Intel compiler as I admit I haven't really used that much. Anyway, the most likely explanation for why you'd have problems compiling cores with the Intel compiler is probably because nobody has yet used it on them.

Qt is kinda irrelevant for libretro cores though and I don't see why that gets brought up. The kind of core code that you compartmentalize in your libretro core should have no UI/toolkit/widget dependencies at all, so I don't see how Qt would enter into the picture or what if anything it would have to do with it. Qt strikes me more as libretro frontend code rather than anything you would really want to use in a libretro core - where it has no place really.

[andres-asm]

What does QT have to do with anything? I'm working on a QT menu driver and I don't really understand your statements. I even have a QT module partially working (just not doing anything) by now, and it's as small as the standalone QT test app I built.

https://dl.dropboxusercontent.com/u/149537/Desktop%2001.18.2015%20-%2019.05.51.03.mp4

For core developers, libretro is quite an easy target, they don't have to worry about video, audio or input drivers, at all, if anything it would make the core slimmer. Cores don't need a GUI, that's the beauty of this, if libretro frontends get better/prettier/fancier, all the cores are benefited not just one (without adding a single line of code to the core)

The end result may use more memory (in RetroArch's case since RA has many advanced features) but it wouldn't in minir, and RA can be built with a minimal feature set too.

[inactive123]

It seems like you fundamentally don't get the basic libretro paradigm. You shouldn't want to introduce such dependencies at all in libretro cores like SDL and Qt.

If you absolutely can't do without SDL in whatever program you're making that you want to turn into a libretro core, at the very least bake in the SDL source. Dynamically linking to some SDL libs that you just presume are there is really going to be very badly out of place compared to the other libretro cores.

LIbretro cores strive to be zero-dependency dynamic libraries that can be slotted into any libretro frontend. That is why trying to shoehorn Qt and SDL and other dependencies like that into a libretro core is a very bad idea, because you can't assume that those shared libraries are actually going to be there on whatever host platform the libretro frontend is targeting, and whether or not the libretro frontend is equipped to deal with that.

I mean there's a fundamental paradigm shift you need to come to grips with here.