Further discussion about threading and overlays about hypseus HOT 4 OPEN

Indeed, I'm not very proud of this workaround.

As you say, the proper way could be to avoid calling twice the method "vid_update_yuv_overlay" but I didn't find how to do that previously.
Now, it's very far from my memory :)

from hypseus.

@lmerckx @h0tw1r3 What's the game trying to archieve if it calls vid_update_yuv_overlay and does not call vid_blit?

My understanding is that all games should call vid_blit to show something on screen, be it a FMV frame and/or superinposed info like sprites or scoreboards, right?

Maybe I should simply let the games call vid_update_yuv_overlay unconditionally without waiting for a vid_blit call?

Maybe I am misunderstanding the internal architecture of the program here...

@h0tw1r3 I know you are busy but I need your input about this too.

from hypseus.

In other words: there MUST be a "central" function that calls SDL_RenderPresent, and that function is, from my understanding, vid_blit.

A game can update the YUV surface (via vid_update_yuv_overlay) but that doesn't send the YUV surface contents to the screen: that has to be done in vid_blit.

That or I just don't get how hypseus is supposed to present the video.

from hypseus.

Well, in the end I decided to disable waiting for texture updates for now.
If a game wants to update the YUV surface but doesn't want the video to be blit immediately, so be it.
It will prevent the VLDP thread to get stuck, at least. I didn't see any caveats, so here it goes, please merge:
#33

from hypseus.