Rene Damm

... allowing you to substitute the superior x86 optimizer of the VC compiler with GCC's inferior optimizer. ... and substitutes it for the MinGW runtime which no one has installed.

You're right. Thanks for the pointer. Must admit I had only browsed through sections of that example. From the looks of it, this is basically what my current testbed is doing with all the Win32 stuff happening inside of Qt. Since it still crashes inside the engine DLL, I'm likely screwing up somewhere else.

Modifying Qt is not really an option due to the licensing amongst other reasons. It wouldn't be practical anyway since Graphics() does more than just GL context setup but rather open a complete window. All this is the responsibility of the GUI toolkit. Also, ideally, the engine should be able to render to more than a single GL widget which should be no problem if the GL context management entirely lies with the UI toolkit. Leadwerks has a nice API that separates all these things quite cleanly. Buffers are nicely separate from graphics window setup which is separate from input. This is pretty much exactly what I'm looking for. However, I fear that underneath in the implementation, these things actually aren't quite as separated and the engine won't run without actually setting up its own window management and message pump. Really hope I'm just flat out wrong here. Thanks for taking the time to respond.

The GUI won't do any GL rendering here. That's the part that is for the engine to do. So, it's the other way round. Leadwerks should do no OpenGL context setup but should do all the rendering. Qt does the render context management but no rendering. That's pretty much the whole point of custom buffers I'd guess. So, the problem is that I can't seem to get the engine to run without calling Graphics() but you can't call Graphics() when running inside Qt since the context and render management lies with the toolkit here and not the engine.

I'm trying to get the Leadwerks Engine working inside a Qt application. Here, the OpenGL context setup is done by Qt. Leadwerks should render to a buffer as usual (setup with CreateBuffer) and then do the final render (RenderLights) to the custom buffer (CreateCustomBuffer) associated with the QGLWidget rendering context. However, so far, I haven't been able to get anything but crashes inside the engine DLL. So far, it appears that the engine won't work without Graphics() being set up, i.e. without the engine creating its own window. Is this correct or am I missing something here? Thanks for any help. --- Some other gripes with the API: - CreateCustomBuffer should take a void* user data pointer. Right now there is no way to associate custom buffers with their corresponding user-side contexts. - All string arguments to the API functions should be const char*; the engine has no business altering strings outside its scope. If it wants to alter them, it should copy them to local storage. - The 'inline' specifier in C++ is generally pointless without the compiler also seeing the function body, so for the calls to actually inline, all the function definitions inside the .cpp files that just stub DLL function pointers should be moved into the headers. - It would be nice for all API symbols to have a consistent prefix to all names so it plays well when integrated into an application with other libraries. E.g. all names would start with "LE" (LECreateBuffer instead of just CreateBuffer) or something.