-
Notifications
You must be signed in to change notification settings - Fork 157
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
Red Alert 2: Yuri's Revenge rendering freezes (sometimes) #131
Comments
It happened again around 0:49 in the log (attached) Doesn't look like much of interest, I did notice that it was 30 FPS on the screen when it froze, it's normally over 50 FPS. The only other thing I can think of that might be of interest is I normally play in 1600x900 resolution, since that seems to look the best on my display. |
With full debug build, I played 1h 22m game the log file was 17GB and it didn't crash. ~200 MB / min of logs is a lot, I tried to set-up logrotate with it, but unfortunately it's unable to rotate the log.
It would be very helpful if there was a way to have the cnc-ddraw.log file split itself or if there was a hotkey to tell it to close and reopen the log file handle that I could use to manage it from getting too large. At least, one good thing is that the log doesn't seem to grow if you hit |
I managed to crash once with the full debug build, though this crash had music, but I could not get units to respond to hotkeys... Unfortunately, the log was 17GB, even zipped it's 238MB, but I can't attach it... The log is 271 million (271702825) lines long, so I doubt you'd read it anyway. To try to make some sense of it I ran the follow on it: gsed -E 's/.{0,18}//;s/[(=].*//' cnc-ddraw.log | sort | uniq -c | sort -nr | tee -a stats.txt Here is the breakdown of message types and their occurance counts
|
First log looks good, render thread seems to be running still and no opengl errors in it either. So I guess the game doesn't trigger the redraw anymore, which should be done via the IDirectDrawSurface__Blt function in YR. Can you maybe upload just the end of the 17gb log? Last 1mb would probably be enough |
It's very hard for me to get the debug build to crash outright, I've only done it once and not like it usually crashes with non-debug or the debug-lite. What I have noticed is this debug build will seemly pause until I click with my mouse sometimes, it's pretty strange... The music will keep going and everything will be stopped, then I'll click and everything moves again. This crash (17GB log) that I have seems like that without the click unpausing. Here's the last 1mb... Don't think you'll find it very interesting, it is basically this (below) repeated over and over (DDLOCK_WAIT x 1689 times):
I'll have to see if I can find a better way to capture the original crashes; maybe I can figure out a way to run it under gdb or valgrind or something... |
Thanks! I found the problem: YR/TS want all surfaces to be in the video memory, otherwise they will change the way the renderer behaves and just do lock/unlock on the primary surface rather than blt. That's apparently unstable (the games are known to have all kinds of issues..). It also explains the bug @Mitradis reported here #125 Will have to think about a solution... I can't just revert the change because it would break some other games then |
Wow, that's really great to hear! It makes sense that TS and RA2 would share the same issues, RA2 was released 1 year after TS (there weren't any other games released between them in the series). They likely share a lot of the same code. |
Fixed! Here is the latest build: |
I'm sad to report this new build crashed the same way the previous full debug build crashed, everything stops except music and in my case a water flowing sound effect, the song finished and then just the water flowing sound effect continued to play, no response from unit hot keys. Alt+Enter didn't work. Can't screenshot with Shift+S... 😭 |
wow! on this version i have normal scroll camera speed and no more game freez. In clear TS. |
I can reopen the issue, but not sure if I can fix it
nice! |
No worries, I appreciate your effort; I believe I can use 1.3.9.0 to play YR stably... I'll play on that for the holidays and maybe see if I can figure out how to try to debug it in the new year. |
Can't reproduce, no one else seems to have the issue either, so I'm closing this for now. |
I believe this is the same issue as recorded in ts-draw here: CnCNet/ts-ddraw/issues/15
The symptoms are after some period of playing the game no longer renders to the screen, though it is definitely still running because you can hear audio and you can use hotkeys to select units and they will acknowledge.
Also it's possible to take a screenshot that the game saves in PCX format and that screenshot will show the current game state (which is newer that what you can see on your monitor)
Alt+Enter
to switch between window and full mode still works and doing so will see a couple of frames render (like 1/2 a sec) before the monitor is frozen again. I'm guessing this is because alt+enter might be forcing a repaint as the screen res changes.My system where this happens somewhat frequently is WS11WineCX6420.04 on OSX 11.6 with 4.4.5.0.
On the advice of #125, I tried it a couple of times with 1.3.9.0 on the system; with very limited testing I was not able to reproduce (yet), I let one game run for over 6 hours.
Next step is to try with the mini-logs debug version, to see if I can capture some logs.
The text was updated successfully, but these errors were encountered: