Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Further discussion about threading and overlays #32

Open
vanfanel opened this issue Feb 9, 2021 · 4 comments
Open

Further discussion about threading and overlays #32

vanfanel opened this issue Feb 9, 2021 · 4 comments

Comments

@vanfanel
Copy link
Contributor

vanfanel commented Feb 9, 2021

Hi there,

I am opening this to discuss the use of this as a workaround for the several seconds stalls in DL2:

SDL_CondWaitTimeout(g_yuv_surface->pending_update_cond, g_yuv_surface->mutex, 100);

Original PR:

#24

Original analysis by @lmerckx is copied here for convenience:

Some games (bega, astron, ...) freezes during some seconds and restart after a timeout message VLDP error! Timed out waiting for internal thread to accept command!:
This problems seems due to the "lock" system between methods vid_blit and vid_update_yuv_overlay.
Indeed, these methods use SDL_CondWait and SDL_CondSignal to avoid conflict when changing same texture.
But for these games, vid_update_yuv_overlay is called twice (setting vid_update_yuv_overlay to true) without any call to vid_blit.
It leads in a blocking call to vid_update_yuv_overlay, which also blocks the command handler; and avoid processing other command.
Only the timeout, after about 7 seconds, unblocks the emulator.
So, I replace SDL_CondWait by SDL_CondWaitTimeout (with a timeout of 100 ms) to solve the problem.

The blocking should not happen to start with. This seems like a workaround and not a true solution. Any ideas?

@lmerckx
Copy link

lmerckx commented Feb 9, 2021

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 :)

@vanfanel
Copy link
Contributor Author

@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.

@vanfanel
Copy link
Contributor Author

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.

@vanfanel
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants