Fivetonsofflax / opentyrian

Automatically exported from code.google.com/p/opentyrian
GNU General Public License v2.0
0 stars 0 forks source link

Input error in titlescreen #63

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Start OpenTyrian Classic revision 865
2. In the titlescreen, while the logo is moving up, press Enter (Return) a
couple of times
3. Try to use any of the standard tyrian keys

What is the expected output? What do you see instead?
When I use any of the standard tyrian keys (up, down, Enter), I get no
response (that is, the menu selection doesn't go up, down, or get selected).
Mouse input (up, down, click) do work, and the OpenTyrian added keys
(Alt-Enter, Alt-x) do work; after using one of those, the standard tyrian
keys start working again as well.

What version of the product are you using? On what operating system?
Classic revision 865 on Windows Vista.

Please provide any additional information below.
This is _almost_ always reproducable, but sometimes the standard tyrian
keys do work even after following the procedure I described; this is a rare
occurence though. 

Original issue reported on code.google.com by a.h.vand...@gmail.com on 20 Feb 2009 at 6:00

GoogleCodeExporter commented 9 years ago
can't reproduce on Linux, maybe it's a Vista-only issue?

Original comment by mindless...@gmail.com on 26 Feb 2009 at 4:03

GoogleCodeExporter commented 9 years ago
I just tried, I can reproduce it on Linux (CRUX); in fact, it's even worse 
there:
even when I do not touch anything until the main menu appears, the arrow keys 
and
Enter won't work until after I move the mouse or press any of the OpenTyrian
keycombos. It seems that the input events are received correctly, but that only 
the
mouse and OpenTyrian special key events are handled. From the little code I've 
read,
I've learned that the OpenTyrian special keys are handled in a different place 
than
the mouse and standard key events, right? I've got the feeling that "newkey" 
plays a
role in this issue, but I can't back that up with facts yet... Any idea what 
could be
causing this and/or what may help tracking this down?

Original comment by a.h.vand...@gmail.com on 26 Feb 2009 at 6:21

GoogleCodeExporter commented 9 years ago
dunno, I would have said that perhaps SDL isn't sending key events, but that 
doesn't
explain why it works after using one of the keys that is actively polled

Original comment by mindless...@gmail.com on 2 Mar 2009 at 6:31

GoogleCodeExporter commented 9 years ago
Hi, today I finally took the time to dive into this again, and I managed to 
reproduce
(and fix, see attached patch) this. Here's the explanation:

This is reproducible when the game is started in fullscreen mode (that is, if 
you've
set it to fullscreen before and then start it again). This happens because:

- when the game is started fullscreen, "fullscreen_enabled" is set to true.
- hence, "input_grabbed" always gets set to "true" in "keyboard.c:input_grab()".
- however, since no "SDL_MOUSEMOTION" has occurred yet, "mouse_x" and "mouse_y" 
from
"keyboard.c" are still set to "0". This causes "setup.c:JE_textMenuWait()" to 
always
overwrite "lastkey_sym" with "SDLK_LEFT", which has no effect in the titlemenu.
- after the first "SDL_MOUSEMOTION", "mouse_x" and "mouse_y" are set to sensible
values, hence "setup.c:JE_textMenuWait()" doesn't everwrite "lastkey_sym" 
anymore,
hence keyboard input works again.

The reason all this doesn't happen in windowed mode is because
"setup.c:JE_textMenuWait()" doens't initially overwrite anything because
"input_grabbed" isn't set to true then until there is any mouse activity 
(which, once
it occurs, also sets "mouse_x" and "mouse_y").

The attached patch fixes this, by making sure that 
"keyboard.c:set_mouse_position()"
always sets "mouse_x" and "mouse_y" when "input_grabbed" is true. Since
"setup.c:JE_textMenuWait()" calls "keyboard.c:set_mouse_position()", this fixes 
the
problem.
Besides the fact that it fixes the problem, I believe it is the right thing to 
do
anyway, since after calling "keyboard.c:set_mouse_position()", "SDL_WarpMouse" 
has
changed the position of the mouse cursor, and "mouse_x" and "mouse_y" should 
always
reflect this.

The patch also removes the unused variables "mouse_xrel" and "mouse_yrel".

Greetings, Sander.

Original comment by a.h.vand...@gmail.com on 6 Jul 2009 at 7:09

Attachments:

GoogleCodeExporter commented 9 years ago
Sorry, I forgot keyboard.h in my first patch and messed style up, try this one 
instead.

Original comment by a.h.vand...@gmail.com on 6 Jul 2009 at 7:18

Attachments:

GoogleCodeExporter commented 9 years ago
ah, thanks for the patch :)

patch merged; fixed as of r951

Original comment by mindless...@gmail.com on 7 Jul 2009 at 2:27