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

Register | Log in

< BLARGRARAAAAAAAmelonDS 0.8 >

Getting there! May 31st 2019, by Arisotura

OpenGL output under Linux! About fucking time. Was it a ride to get there, though. As I explained in a previous post, the first attempts with a GtkGLArea were a trainwreck. GtkGLArea is nice and all, but it's really limited in how much control you have over rendering, compared to, say, the Windows equivalent (get a GL context for any HWND and do whatever you want). For one, GtkGLArea provides no control over its GL context, other than "make context current now". No way to unset the current GL context, which is important in melonDS. Even though all the rendering is done in the emu thread, we do need to unset the GL context at times, because when changing video settings we do reconfiguration from the UI thread, and said reconfiguration involves GL calls. But, well. You may already know that GTK isn't thread-safe. As such, GtkGLArea really isn't designed to be used outside of the UI thread, or outside of one particular way. So, unless we rewrote melonDS's rendering system, this would have never worked. Besides, the emu thread is distinct from the UI thread for a reason -- I'm reluctant to having any work that may affect emulation done on something as uncertain as the UI thread. So, I began researching. And, now, the melonDS company proudly presents the result of all that research: the DIY GL area. Basically, I decided to directly use GDK's GL context API to get the level of control I needed. With this, you don't need a specific widget type, you can create a GL context from any GdkWindow (which you obtain from any realized GTK widget). You can then use the function gdk_cairo_draw_from_gl() to draw your OpenGL output to the widget. So I'd basically replicated the GtkGLArea, which in itself simply wraps around the aforementioned API. It's a simple framebuffer that you point OpenGL to, and that you resize as your widget gets resized. There is still one issue: when using GL contexts, GTK will issue GL calls when rendering the area widget, and will do so internally, before calling the widget's draw handler. This is a problem if these calls are issued while melonDS's emu thread is also issuing GL calls. To avoid this, I had to resort to some trickery: melonDS's GL calls are wrapped in a critical section, and I used a custom GDK event handler to wrap any GTK draw events in that same critical section, before GTK starts issuing GL calls. This way, only one thread can be doing its GL work at the same time, and we avoid potential shitshows. In reality, this took a while to get working, but, here we are. OpenGL output under GTK, stable and fast, and without needing to rewrite melonDS's rendering system. Oh also, this supports hi-DPI! Provided you have a good GPU and not too shitty drivers, you get hi-DPI OpenGL graphics, and that sure does look nice. There are still some tidbits to fix (like, some bugs in fog that appeared after I had to made a fix for Intel drivers), but we're way close to a finished product here. I will also try to see if I can make hi-DPI work under Windows, too.

9 comments have been posted.

< BLARGRARAAAAAAAmelonDS 0.8 >

Post a comment
Name:

DO NOT TOUCH