In order to avoid the emulator code from software scaling…
I have an emulator that writes primarily to a 640x480 offscreen streaming texture for performance.
I would like to RenderCopy this to an on screen texture (controlled by the GUI) that is :
- Located at various window coordinates.
- Can be resized.
- Already has STREAMING ACCESS.
However I can’t :
A. Create a second renderer associated to the same window to facilitate the RenderCopy (scaling) or
B. Create a texture with both STREAMING and TARGET access (core dumps)
I can get around A by creating the window renderer with TARGETTEXTURE. But can’t seem to get around B.
So does anyone know how I might approach this problem?
So you want to
SDL_RenderCopy a streaming texture into an intermediate texture, and then
SDL_RenderCopy that intermediate texture to the default renderer target (i.e. your window); is that correct?
What is the purpose of the intermediate texture? It is not obvious to me why you cannot achieve the required result by
SDL_RenderCopying your source (streaming) texture directly to the window in one step; that still gives you control over its size and position.
- Because the intermediate texture is a resource connected to AGAR GUI’s AG_Pixmap widget which it controls.
AGAR can delete it, change it or resize it at any time. The emulation graphics code spends a lot of time streaming to the streaming texture so having the texture unexpectedly changing is a disaster.
- While I could modify the AGAR SDL2 driver to queue texture deletions until an appropriate time I would still need to perform the rescaling in the emulator code. If I could avoid rewriting the emulator (proper) that would be better.
I wonder if you are right and I can just ignore the AGAR Pixmap Texture and write my streaming texture to the same window coordinates as the Pixmap Texture. I might get a bit of flicker between the two competing textures but I hope only when resizing.
I tried that and at first appearance it worked.
However if you select any other widget (menu, button etc) then AGAR redraws the entire window and some severe flickering occurs!
So rendering directly to the window bypassing AGAR’s Pixmap Widget is not a solution.
Ideally you want to render all the textures before calling
SDL_RenderPresent, that way there should be no flickering. It sounds from your description that AGAR is calling
SDL_RenderPresent itself; is there no way of stopping that happening?
However AGAR controls the drawing order of all the widgets (as you’d expect) and I’m trying to either find the best widget to facilitate textures or inject my SDL over the top. I do know where AGAR calls RenderPresent. I just need to figure out when it does that to make this work. Anyhow that’s up to me to figure out.
Thanks for your time.
I managed to work something out.
rtrussell made the best suggestion and I modified AGAR to produce a widget-drawn event that I register for. With this I am able to overwrite any particular widget with drawn content from my SDL2 Texture and I only need 1 texture without any intermediate texture.