The final step: getting it all to work under Linux
Well, yeah, or almost. It works, and is nearly clean, but only under Windows, because I didn't code the required support for GTK.

And I'm not getting into the Mac side, which I will have to get into eventually. Getting OSX working in a VM and managing to do things under an environment I'm completely unfamiliar with is going to be a whole pile of fun, I can feel it already.

Anyway, back on topic, and get ready for a big moment of 'fuck technology'.

So, I happily went and booted under Linux, getting ready to code shit and expecting to have it working without too much trouble. Just spawn a GtkGLArea and you're good to go, right?

Haha. You're cute.

I'm not getting into the hours wasted by fighting ass-obscure issues that, in the end, mostly translated to 'you need to update your distro'. When all that was done, PoroCYon had already started working on the GTK-side code, so I just grabbed their pull request. With a bit of work, I finally got OpenGL going.

Yeah, except it's a total and complete fucking trainwreck.

Basically, it's not rendering anything. When resizing the window, I can sometimes get a nearly-complete static picture with more or less distortion, as if it was reading random video memory, but it will inevitably crash at some point.

Because, of course.

The way GtkGLArea is intended to be used is, well, not really compatible with melonDS's workflow.

On one hand, GtkGLArea provides you with 'realize' and 'render' callbacks which is where you're supposed to do your OpenGL initialization and rendering, respectively. Which is already different from how you're supposed to do things under Windows (doing OpenGL shito in the WM_PAINT handler is not recommended).

On the other hand, well, melonDS does all its emulation work in a dedicated thread (EmuThreadFunc), separate from the UI thread. There are several very good reasons for this design.

Which means that we're torn apart between two incompatible concepts. On one side, the current GL context must be activated on the thread which will be using OpenGL (in melonDS, even though all the work is done in the emu thread, both threads can be issuing GL calls, so proper context management is crucial). On the other side, well, GTK is not thread-safe, and trying to use it outside of the UI thread is generally a trainwreck.

Basically, as long as our GL context is tied to a GTK widget, this is bound to be a trainwreck.

So, what do we do, there?

I don't know.

I'm researching it, but the whole thing reeks of "what you want to do is so niche that nobody else has ever attempted to do it". Probably because they either weren't trying to write portable code, or just gave in to Qt's growing monopoly, or gave up trying to use an UI toolkit alongside OpenGL.

Don't get me started on Qt, I'm not going to use it.


We could rework the code that draws the screens to the window, so that it would run from the UI thread. Of course, but then, what about the OpenGL renderer? This one has to stay in sync with the rest of the emulator.



well, I guess the positive part is that, once we find a solution for this, you can expect the long-awaited 0.8 release
WarSlay says:
May 26th 2019
Keep working, you're amazing!!!
A dragon says:
May 26th 2019
If you've not looked into Vulkan, maybe that's what you should do for now. If I remember correctly, it was once called Open GL Next Gen, so it could be an option to consider for the time being if OpenGL's not working for you. I'll wish you the best of luck with this, Ariso.
Guest says:
May 26th 2019
Vulkan is certainly a possibility, since you could run OpenGL under Vulkan, and this may help clear up some of the issues.
Also, perhaps WxWidgets may help? VBA-M uses WxWidgets in conjunction with GTK, and OpenGL works without any apparent issues with this setup.

Also, and this is as a user who prefers GTK over QT, what is the issue with using QT? Apart from it belonging to a company?
A dragon says:
May 26th 2019
I did some searching just in case you decide to go with Vulkan:
For WxWidgets, here:
I hope this helps.
extherian says:
May 26th 2019
Good on you for not using qt, that shit is ridiculously bloated. Any emulator that uses it ends up with a 50mb file where 49mb of that is just qt by itself. Sheer madness.
poudink says:
May 27th 2019
melonds used to use wxwidegets, iirc. switch to libui because it was more crossplatform, I believe.
Amnesia says:
May 27th 2019
I really appreciate that you are working on this emulator, and mainly that you don't leave Linux aside. Thank you very much for this emulator...
123 says:
May 27th 2019
love you three thousand times!

nobody says:
May 27th 2019
The reason people don't use GTK+ anymore (and use Qt) is because it'd be more accurate to call it libgnomeui at this point. They (GNOME) don't actually care about API for other external developers to a large extent. Qt is much better designed (but admittedly is still terrible in certain ways.)

Also, extherian, you're doing it wrong then. Stop statically linking. :)

Either way, take your time Arisotura. Last thing we all want is for you to get burned out. :P
Arisotura says:
May 27th 2019
libui was chosen because I want something small and cross-platform, and using native widgets and shito as much as possible.

my gripes with Qt are multiple:
* Qt is like those megacorporations that want you to be using nothing but their products. once you start using it, it extends its tentacles through your entire codebase, everything is Qt-flavored.
* Javaism. the API follows the same design as Java, and I don't like Java. namely, having to constantly add #includes for every little thing you want to use.
* the fact it belongs to a megacorporation!! and that they're slowly but surely acquiring a monopoly, which is bad bad bad.
* Qt reinvents everything instead of using native widgets.

wxWidgets was not a bad choice honestly (save for all the "it's baaaaaaad because it's not hip and trendy anymore, use Qt like the cool kids" people), except that, well... wxWidgets was clearly designed around the Win32 API, which has its problems when it comes to portability.

libui has its flaws too, but atleast I can modify it to my liking.

also, the idea of using a SDL window and something like imgui would be nice, although an issue is that everything would be constrained to that window (including settings dialogs). but for something like a simple interface, it could work.
MelonMan says:
May 27th 2019
Hope you fix your GTK and GL bugs! Will there be any other new things in version 0.8?
A dragon says:
May 27th 2019
Maybe you could create something in python for the UI.
MegaSquirtle says:
May 29th 2019
I can't trade any longer on my Pokemon 4th gen games when I updated my windows from win8 to win10. do i need to adjust something? i need help. pokemon is my life. :(
Post a comment