I’m trying to get SDL2 to work with Qt (qt serving as the editor for a game engine). To kick things off I used a stackoverflow thread as a starting point, however it’s based on SDL and not SDL2 and the deprecated functions seem to not have a replacement I can use. In particular SDL_SetVideoMode is replaced with SDL_CreateWindow, which I don’t want as I need to draw within a widget. The idea here is that the engine runs in the widget and the editor manipulates it.
Okay, this is a little confusing…
So, what do you want to do with SDL2, and what do you want to do with QT?
I doubt you can combine both. You probably cannot create an SDL_Window and render on it using some QT functions.
I think it should be possible, but I have never done it myself…
Relevant might be:
- https://github.com/killeand/Qt-SDL this project seems to do what you want
https://wiki.libsdl.org/SDL_GetWindowWMInfo to get the platforms native window handle of an
SDL_Window*(that you might be able to feed into Qt somehow, no idea, never used Qt)
https://wiki.libsdl.org/SDL_CreateWindowFrom to create an
SDL_Window*from a native Window (the other way around)
I wonder how one is supposed to set relevant window flags (esp.
I don’t think the linked stackoverflow answer is super helpful, as it’s very SDL1-specific (I don’t think SDL2 supports this
SDL_WINDOWID thing, grepping for it in the SDL2 code yields no results).
You kind of have it backwards. I wanted SDL to do all the visual rendering and act as a widget to Qt where I can take advantage of qt for all the buttons and text fields. Everything in SDL becomes code particular to the game engine and Qt for editor purposes only, like changing camera position, property manipulation, etc, etc.
Daniel_Gibson thanks for the pointers, that might do the job. I’ll give it a try.
So after giving it some thought, I realized if I want to avoid mixing engine code and qt code, I’m better off just having them be separate windows. For those wondering how to make sure the two play nice. Create your std::thread for sdl before doing any Qt initialization and call join after calling exec() on QApplication. At that point it’s just a case of ensuring thread/memory safety