SDL / OpenGL: implementation of the "boot stream"

I am currently trying to implement “Download Stream” for a very basic game engine that takes care of loading, for example. textures or audio, while the main stream continues to render the correct message / screen until the operation is completed or even plays normal game scenes, while the loading of smaller objects takes place in the background.

Now I’m certainly not an OpenGL specialist, but when I implemented such a “Download” mechanism, I quickly found that OGL does not like access to the rendering context from a stream other than the one that was created by a lot. I googled around and the solution seems to be:

"Create a second rendering context in the stream and share it with the main stream context

The problem is that I use SDL to take care of my window management and contextualization, and as far as I can tell from the API check, there is no way to tell the SDL to exchange contexts with each other :(

I came to the conclusion that the best solutions for my case are:

Approach A) Modify the SDL library to support context sharing using platform-specific functions (wglShareLists () and glXCreateContext () I assume)

Approach B) Let the “Boot Stream” load only the data into memory and process it in the OpenGL format and transfer it to the main stream, for example, take care of loading the texture into the graphics adapter. This, of course, applies only to data that requires a valid OpenGL context.

The first solution is the least effective, I think. I really don't want to cripple SDL, and besides, I read that context sharing is not a high-performance operation. So, my next approach will be on the second approach so far.

EDIT: Regarding the "high-performance operation": I read the article incorrectly, in fact it is not so strong. The article proposes to transfer intensive CPU operations to a second thread with a second context. Sorry for this

After all this introduction, I would really appreciate it if someone could give me some tips and comments on the following issues:

1) Is there a way to exchange contexts with SDL, and it would be all the same to do this?

2) Is there an even more “elegant” way to download my data in the background that I might have missed or didn't think about?

3) Can I intend to go with approach B, which is considered a good choice? Will there still be small overhead on OpenGL operations in my main thread that blocks rendering, or is it so small that it can be ignored?

+6
source share
1 answer

Is there a way to exchange contexts with SDL

No, strike>

Yes!

You should get the current context using platform-specific calls. From there, you can create a new context and make it general, as well as with platform-specific calls.

Is there an even more “elegant” way to download my data in the background that I might have missed or didn't think about?

Not really. You have listed the parameters well enough: hacking the SDL to get the necessary data or loading data is inefficient.

However, you can load data into mapped buffer objects and transfer data to OpenGL . You can only do the mapping / decoupling in the OpenGL stream, but the pointer that you get when matching can be used in any stream. So map the buffer, pass it to the worker thread. It loads the data into the mapped memory and flips the switch. The GL thread expands the pointer (the worker thread should forget about the pointer now) and loads the texture data.

Can my intention to go with approach B be considered a good choice?

Define "good"? There is no way to answer this without knowing more about your problem area.

+6
source

Source: https://habr.com/ru/post/893519/


All Articles