Integration with SDL1/2?

[a-hurst]

Integration with SDL1/2?

[jwwalker]

I don't really know anything about SDL other than the fact that it's a cross-platform library. Presumably it's implemented using native capabilities of each platform, e.g., NSView on macOS. So I think what you'd have to do is see whether SDL has APIs that will reveal the underlying platform-specific constructs, and them pass them to Quesa.

[a-hurst]

I think you can probably get at the underlying windowing stuff with some platform-specific hacks, but it makes portability a pain.

Is the issue just that the window/context creation code and rendering code in Quesa are intertwined in a way that makes it hard to use Quesa’s OpenGL renderer with a window and context created by a different library? If that’s the case I might attempt writing an SDL platform back-end for Quesa: glancing through the source, it looks
like the main platform-specific code is found in the Development/Source/Platform directory and get wrapped in various parts of Development/Source/Core. A lot of the stuff getting wrapped (draw context creation, file handling, logging, etc.) is stuff that SDL already wraps cleanly anyway, so it’d just be mapping the APIs onto eachother. Are there any major pitfalls or quirks I should watch out for if attempting to add a new platform backend?

[jwwalker]

Quesa has a different draw context class for each kind of platform view/window, so one task would be to create a new draw context class. But the more involved thing is letting the renderer know how to deal with each draw context class. See particularly the file GLDrawContext.cpp. For instance you'll find the function GLDrawContext_New, which looks at what kind of draw context it's dealing with and then figures out how to create an OpenGL drawing context.

[jwwalker]

SDL is not currently a priority for me, but there is some SDL support in Jorio's fork.