This problem was noticed while toying with openal branch, but seems to be more generic and unrelated to sound, as it happens even with '-nosound'.
Sometimes, upon entering either main game menu or load/save selectors, zdoom kind of freezes. 'Kind of', as the process is still running, but (keyboard) input is ignored. To trigger the bug just repeatedly press Esc on title screen.
Initially, I had no idea where the problem could be coming from, but then I recalled a sort of similar problem in Thyrion - see this thread.
Indeed, commenting out SDL_EnableUNICODE calls in src/sdl/i_input.cpp seems to prevent the freeze, but it's obviously not the proper solution.
Neither it was in Thyrion, but I don't quite understand the solution implemented there.
Given SDL code, you might need to have an IME running and XMODIFIERS set to the value correct for that IME to reproduce.
It's seems to be just about the only thing that SDL_EnableUNICODE changes on x11.
It seems there are two more important things I need to add:
- that freeze on the title screen happen always when menu is on screen; with some debug printfs, it looks like the last event delivered is SDL_KEYDOWN for Escape, the following SDL_KEYUP never gets delivered
- if I press '~' on the title screen, so that console drops down, zdoom by design locks itself in GUICapture mode and pressing Escape just switches between menu and console; under these conditions, zdoom doesn't freeze
So it seems to be a condition race, whether in zdoom, libSDL, libX11 or otherwise - I can't really tell.
Also, there's a funny thing: if mouse is enabled in menus, the freeze still happens, but:
- it affects only the keyboard; you can leave the menu by mouse
- zdoom acts as if Escape was still pressed, sometimes leading to funny results (for example I can enter "Quit Game" menu, but I can't press "Y" (or - in fact - any key) there)
It might be a problem in libSDL, but I can't come up with a clean testcase.
There's another funny thing: if "mouse in menus" is enabled, if the freeze is triggered and menu is left by mouse, it can be entered again by pressing Escape, but the freeze goes into effect immediately. Also, if mouse is used during freeze to enter console, the console isn't getting any text either.
It's not a hardware problem. Not only it happens with both usb and ps2 keyboard, but on two significantly different machines (one 32bit (a quite old one), the other 64bit).
So anyway, just for the record: at this point I'm pretty much convinced it's a bug in SDL1, but for the last three months upstream has been quite busy not doing a damn thing about this bug, so unless the bus is (as I suspect) one way or the other fixed in SDL2 and zdoom is ported to it, this will most likely stay unfixed.
[2.7.1] zdoom randomly 'hangs' upon entering menus
Moderator: GZDoom Developers
Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Re: [2.7.1] zdoom randomly 'hangs' upon entering menus
So, anyway...
Shortly after my last edit, SDL upstream decided to commit that cargo-culted thing I've attached to the bug report.
Given that there was no attempt made to actually discuss it, it makes me more twitchy than happy, but looks like the problem is at least worked around, even if only in the repo.
Shortly after my last edit, SDL upstream decided to commit that cargo-culted thing I've attached to the bug report.
Given that there was no attempt made to actually discuss it, it makes me more twitchy than happy, but looks like the problem is at least worked around, even if only in the repo.