Currently there is only one STREAMING texture that is drawn directly to the window using SDL_UpdateTexture to fill the pixels and followed by SDL_RenderTexture to print it on the screen.
SDL_UpdateTexture is better suited than using SDL_LockTexture/SDL_UnlockTexture as the core pixel_buffer filled by the core emulator is (and should stay) separated from the SDL frontend.
The problem here is the interaction between SDL_SetRenderLogicalPresentation currently used at the native GB screen resolution (160x144) and the drawing of UI related elements. This causes issues when wanting to draw something else on top like an UI, we wouldn't want that to be drawn at 160x144 !
There are multiple ways of dealing with that:
- Option 1: Don't change the way rendering is done with SDL, disable the Logicial Presentation setting when it's time to draw UI and flip it back on later (currently what is done as a workaround)
- Option 2: Create a second texture that would be of TARGET type, so that we could use the SDL_SetRenderTarget to set the Logical Presentation only on this texture. Then, the current STREAMING texture could be drawn directly on this TARGET texture, with the benefits of the logical resolution setting being applied only to it. The whole window target would stay unaffected from the logical presentation and wouldn't interfere with the drawing of other things on top
Option 2 would probably be cleaner when done properly
Currently there is only one STREAMING texture that is drawn directly to the window using SDL_UpdateTexture to fill the pixels and followed by SDL_RenderTexture to print it on the screen.
SDL_UpdateTexture is better suited than using SDL_LockTexture/SDL_UnlockTexture as the core pixel_buffer filled by the core emulator is (and should stay) separated from the SDL frontend.
The problem here is the interaction between SDL_SetRenderLogicalPresentation currently used at the native GB screen resolution (160x144) and the drawing of UI related elements. This causes issues when wanting to draw something else on top like an UI, we wouldn't want that to be drawn at 160x144 !
There are multiple ways of dealing with that:
Option 2 would probably be cleaner when done properly