OK then. Can you please:
- Test QuakeSpasm to see whether you have the same issue with it?
- Give me an almost foolproof way of reproducing the issue by myself?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, AFAICT, QuakeSpasm isn't affected (or at least triggering isn't as trivial). On a related note, I'd have been nice if in its readme there was a note on how to use it - sending people on wild goose chase for a faq with details like directory structure/lowercase files was a bit annoying.
As for a way to trigger it, I already said, what the most trivial method is: load a game, then press F3 (Load menu)/Enter (Confirm) alternatively (usually in less than 6 repeats it freezes).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, AFAICT, QuakeSpasm isn't affected (or at least triggering
isn't as trivial). [...]
As for a way to trigger it, I already said, what the most trivial
method is: load a game, then press F3 (Load menu)/Enter (Confirm)
alternatively (usually in less than 6 repeats it freezes).
OK. I still can't reproduce this myself, nor have any of our other
developers said so. We'll still go after this, though.
In the meantime, it may help if you tell us:
- which distro you are running on including cpu-arch, glibc version
- which compiler you are using (gcc/clang + binutils -- assuming that
you are compiling your own binary) along with any source/build system
changes you are doing (if any.)
- which SDL version
- versions of multimedia dependency libraries (libogg, libvorbis, mad)
as well as what timidity patches you are using, if any. (these need
not be related at all, but just in case..)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Technically, it's gcc 4.5.4, binutils 2.22, glibc 2.15, but it matters little - I can trigger it with amd64 binary from sourceforge too.
Timidity patches don't matter either: not only I've set USE_MIDI=no in Makefile, but all of the tests (including sourceforge binary) were with '-nomidi' ((nearly) all were also with '-sndspeed 48000 -vsync'). SDL version given above. libogg 1.3.0, libvorbis 1.3.3, libmad 0.15.1b (but -nosound doesn't make a difference either).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, yes and no.
Given the random nature of the freeze, I can't be 100% sure, but it seems, that with '-nomouse', the average number of tries needed to freeze is at least 2-3x as big.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Again, no guaranties, but it does seem to fix the freeze.
On a not quite related note:
- would it be possible to make Eidolon's Lair playable with 'notarget' ?
now, due to an old fix, Eidolon stays invulnerable till he spots the player
- thorough the game, there were several spots where pools were much harder to get out of than they should (or sometimes even impossible); am I that bad player or is i.e. something like jump height in water set too low ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, good to hear this does seem to fix it, I've just pushed this patch to the SVN repo. If you ever experience this freeze again please don't hesitate to let us know.
Regarding the hard-to-get out of pools: I know there are some, especially the one in the bedroom in "Palace Entrance". They aren't that hard to get out of once you know how to do it: first of all, don't use the "jump / swim up" key; for some reason, pressing it actually makes it harder to get out of (some) pools. Usually it is enough to dive under water, and then "run" upwards under a slight angle towards the edge of the pool. If that doesn't help, try using the "swim up" key (this is a separate key that behaves different than the "jump / swim up" key). Since this is physics related, I doubt there's much that we can do about it without the risk of breaking other things.
Can you please open a new thread for the Eidolon issue?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for reviving this, but could you explain what could have been the problem ?
I seem to have a similar problem in zdoom (well, similar cause input freezes and commenting SDL_EnableUNICODE helps), but upstream can't reproduce it. Even I can't on a different machine, that while significantly different hardwarewise (for a lesser example, keyboard on ther other machine is PS2, not USB), is pretty much alike in terms of installed library versions.
Looking at SDL sources, SDL_EnableUNICODE should have much of an effect, it just flips SDL_TranslateUNICODE, which seems to be referenced only by src/video/x11/SDL_x11events.c in this case.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, in the meanwhile, there's been both progress and no progress.
It seems that the problem is actually a bug in SDL, that's only triggerable if you have an IME running and XMODIFIERS is set to the value proper for that IME.
Unfortunately, it looks like as this is a bug in SDL1, the upstream is not interested in looking for a fix.
I wonder a bit how the change in Thyrion managed to workaround that deadlock (or - given the random nature of the freeze - did it made just significantly harder to trigger).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interesting that it is an SDL1 bug regarding IME, and that's possibly
why we never managed to reproduce the issue by ourselves. Do you have
a pointer to an SDL bug report and how it is fixed in SDL2?
The fix we merged changes the way we handle mouse enabling/disabling
under certain circumstances: some of such circumstances change the
way we handle certain keyboard keys, e.g. the numpad keys.
For the record though, the "fix" we merged resulted in a regression:
Run glhexen2 (I am running windowed), press F3, use up/down arrows to
select a save, press Enter to load. When it loads, press Enter to use
an inventory item (scrolling the inventory by the mouse wheel doesn't
change the result): it doesn't at first hit, but it does upon hitting
enter the second time. it works fine after that. I am uncertain as to
how I handle this, possibly revert the "fix"? Don't know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The bug has a link to sdl forum thread discussing something that I suspect was a similar problem. I'm not sure if it's really the same, therefore fixed in SDL2, but there are strong hints it is.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, it seems to fix help, but I already said a few times, that I'm at least 85% sure that patch is wrong - it was simply cargo-culted, badly at that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all, I just installed Hammer of Thyrion in my lubuntu 14.10 and I'm having a blast. However, I'm having this same issue. I'm adding this comment just to make it "two users" having it. :D Anyway, what's the best way to apply the patch? Actually, is there a way I can apply it without downloading the source and compiling the game myself? I'm no linux expert and it's been a while ever since I compiled a game. My sdl version seems to be already 1.2
libsdl-image1.2:amd64
libsdl1.2debian:amd64
1.2.15-10ubuntu1
1.2.12-5build2
Regards.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately you need to patch SDL yourself and recompile+reinstall. Or, report the issue to debian and/or ubuntu so that they can provide an updated and fixed SDL package. I myself did that for Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1126136) and they did deliver a fixed SDL.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
BTW, do you experience the issue in QuakeSpasm?
(http://sourceforge.net/projects/quakespasm/)
I'm asking, because the code is very similar.
galtgendo: Does the following patch help?
http://uhexen2.sourceforge.net/tmp/in_sdl.patch
(We are still interested in your experience with
quakespasm wrt this keys issue, if you can.)
No, for whatever the reason it doesn't.
Odd, looking at the patch, it indeed looked like something that should have helped.
OK then. Can you please:
- Test QuakeSpasm to see whether you have the same issue with it?
- Give me an almost foolproof way of reproducing the issue by myself?
Well, AFAICT, QuakeSpasm isn't affected (or at least triggering isn't as trivial). On a related note, I'd have been nice if in its readme there was a note on how to use it - sending people on wild goose chase for a faq with details like directory structure/lowercase files was a bit annoying.
As for a way to trigger it, I already said, what the most trivial method is: load a game, then press F3 (Load menu)/Enter (Confirm) alternatively (usually in less than 6 repeats it freezes).
OK. I still can't reproduce this myself, nor have any of our other
developers said so. We'll still go after this, though.
In the meantime, it may help if you tell us:
- which distro you are running on including cpu-arch, glibc version
- which compiler you are using (gcc/clang + binutils -- assuming that
you are compiling your own binary) along with any source/build system
changes you are doing (if any.)
- which SDL version
- versions of multimedia dependency libraries (libogg, libvorbis, mad)
as well as what timidity patches you are using, if any. (these need
not be related at all, but just in case..)
Technically, it's gcc 4.5.4, binutils 2.22, glibc 2.15, but it matters little - I can trigger it with amd64 binary from sourceforge too.
Timidity patches don't matter either: not only I've set USE_MIDI=no in Makefile, but all of the tests (including sourceforge binary) were with '-nomidi' ((nearly) all were also with '-sndspeed 48000 -vsync'). SDL version given above. libogg 1.3.0, libvorbis 1.3.3, libmad 0.15.1b (but -nosound doesn't make a difference either).
Does the -nomouse command line switch make any difference?
If it does, Sander may have an idea about fixing this.
Well, yes and no.
Given the random nature of the freeze, I can't be 100% sure, but it seems, that with '-nomouse', the average number of tries needed to freeze is at least 2-3x as big.
Can you try the attached patch and let us know if the issue is still reproducible with it?
Last edit: svdijk 2013-06-15
Again, no guaranties, but it does seem to fix the freeze.
On a not quite related note:
- would it be possible to make Eidolon's Lair playable with 'notarget' ?
now, due to an old fix, Eidolon stays invulnerable till he spots the player
- thorough the game, there were several spots where pools were much harder to get out of than they should (or sometimes even impossible); am I that bad player or is i.e. something like jump height in water set too low ?
Ok, good to hear this does seem to fix it, I've just pushed this patch to the SVN repo. If you ever experience this freeze again please don't hesitate to let us know.
Regarding the hard-to-get out of pools: I know there are some, especially the one in the bedroom in "Palace Entrance". They aren't that hard to get out of once you know how to do it: first of all, don't use the "jump / swim up" key; for some reason, pressing it actually makes it harder to get out of (some) pools. Usually it is enough to dive under water, and then "run" upwards under a slight angle towards the edge of the pool. If that doesn't help, try using the "swim up" key (this is a separate key that behaves different than the "jump / swim up" key). Since this is physics related, I doubt there's much that we can do about it without the risk of breaking other things.
Can you please open a new thread for the Eidolon issue?
Looks like you're right about that separate key - pity about the design, though.
Thanks for the help.
Sorry for reviving this, but could you explain what could have been the problem ?
I seem to have a similar problem in zdoom (well, similar cause input freezes and commenting SDL_EnableUNICODE helps), but upstream can't reproduce it. Even I can't on a different machine, that while significantly different hardwarewise (for a lesser example, keyboard on ther other machine is PS2, not USB), is pretty much alike in terms of installed library versions.
Looking at SDL sources, SDL_EnableUNICODE should have much of an effect, it just flips SDL_TranslateUNICODE, which seems to be referenced only by src/video/x11/SDL_x11events.c in this case.
Well, in the meanwhile, there's been both progress and no progress.
It seems that the problem is actually a bug in SDL, that's only triggerable if you have an IME running and XMODIFIERS is set to the value proper for that IME.
Unfortunately, it looks like as this is a bug in SDL1, the upstream is not interested in looking for a fix.
I wonder a bit how the change in Thyrion managed to workaround that deadlock (or - given the random nature of the freeze - did it made just significantly harder to trigger).
Interesting that it is an SDL1 bug regarding IME, and that's possibly
why we never managed to reproduce the issue by ourselves. Do you have
a pointer to an SDL bug report and how it is fixed in SDL2?
The fix we merged changes the way we handle mouse enabling/disabling
under certain circumstances: some of such circumstances change the
way we handle certain keyboard keys, e.g. the numpad keys.
For the record though, the "fix" we merged resulted in a regression:
Run glhexen2 (I am running windowed), press F3, use up/down arrows to
select a save, press Enter to load. When it loads, press Enter to use
an inventory item (scrolling the inventory by the mouse wheel doesn't
change the result): it doesn't at first hit, but it does upon hitting
enter the second time. it works fine after that. I am uncertain as to
how I handle this, possibly revert the "fix"? Don't know.
The upstream bug is https://bugzilla.libsdl.org/show_bug.cgi?id=2325 - it's in the process of being ignored.
The bug has a link to sdl forum thread discussing something that I suspect was a similar problem. I'm not sure if it's really the same, therefore fixed in SDL2, but there are strong hints it is.
Does a patched SDL acc. to https://bugzilla.libsdl.org/show_bug.cgi?id=2325#c2 fix your issue then?
Well, it seems to fix help, but I already said a few times, that I'm at least 85% sure that patch is wrong - it was simply cargo-culted, badly at that.
I see. (BTW, I only noticed now that you are the originator of the SDL bug report.)
Reverted the workaround at rev. 5275
http://sourceforge.net/p/uhexen2/code/5275/
SDL bug 2325 is now fixed on the 1.2 branch too:
https://hg.libsdl.org/SDL/rev/0aade9c0203f
Hope this resolves this issue for good.
Hi all, I just installed Hammer of Thyrion in my lubuntu 14.10 and I'm having a blast. However, I'm having this same issue. I'm adding this comment just to make it "two users" having it. :D Anyway, what's the best way to apply the patch? Actually, is there a way I can apply it without downloading the source and compiling the game myself? I'm no linux expert and it's been a while ever since I compiled a game. My sdl version seems to be already 1.2
libsdl-image1.2:amd64
libsdl1.2debian:amd64
1.2.15-10ubuntu1
1.2.12-5build2
Regards.
Unfortunately you need to patch SDL yourself and recompile+reinstall. Or, report the issue to debian and/or ubuntu so that they can provide an updated and fixed SDL package. I myself did that for Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1126136) and they did deliver a fixed SDL.