#6477 ANDROID : SCI QFG1 - Cursor Keys controls Mouse, rather than Ego

[Ben S.]

I'm trying to play QFG1 SCI0 EGA on Android (2012 Nexus 7, KitKat) ScummVM buildbot stable 1.6.0 with a bluetooth keyboard. Unfortunately, the arrow keys seem to move the mouse cursor around instead of directly controlling character movement. The latter behavior is more consistent with that of the original DOS SCI0 engine, so I would like to be able to configure ScummVM to behave in the same way.

[digitall]

Just tested this with my copy of QFG1 on Linux x86_64 with the latest git master.

I think you may be confused about the way the original behaviour worked.

If you have the "look" cursor active, the arrow keys move the eye cursor icon around the screen so you can look.

The behaviour you describe only occurs when you select the "walk" cursor, then instead of the cursor moving with the arrow keys, they directly control the Ego i.e. player character.

Closing as invalid.

[Ben S.]

I find it extremely frustrating that my ticket was closed without giving me chance to respond, as I believe that the misunderstanding is yours, due to a lack of knowledge about the various major revisions of Sierra's game engines:

SCI0 games such as the original Quest for Glory 1 (aka Hero's Quest) are closer in behavior to the previous-generation AGI games: they have a text parser, and the cursor does not have modes at all (let alone "walk" and "eye" modes). There is also no action bar at the top of the screen.

The way the mouse works in SCI0 games is as follows: clicking the left mouse button causes the player to move to the clicked location (similar to left-clicking the walk cursor in SCI1 games), while clicking the right mouse button is supposed to give a description of the clicked area of the screen (similar to left-clicking the eye cursor in SCI1 games).

In SCI0 games, the position of the cursor is controlled solely by the mouse, as the arrow keys can only be used to directly control movement of the character (as in AGI games which had no cursor at all). The fact that the Android port of ScummVM is not replicating the behavior of the arrow keys according to the actual behavior of the SCI0 engine is quite problematic for me, as I would like to play SCI0 games on Android using a Bluetooth keyboard in a way that replicates the original behavior as closely as possible.

[digitall]

SIGH I closed the ticket as generally most users don't bother to respond, especially when a ticket has gone 3 months from submission.

And as you see, I did not disable comments so that you had a chance to respond.

You are correct. I did test with the later SCI VGA version, but I have just retested with the EGA version (qfg1old) and the arrow keys work fine to move Ego.

I suggest that you attach a textfile attachment to this bug with file md5sums of your QFG1 EGA datafiles so we can be sure exactly which version you have.

If it is the same version, then the issue is likely to be in the Android backend code rather than the SCI engine code. Have you tried running this on your desktop machine i.e. Win32/OSX/Linux version of ScummVM with the same datafiles and see if you get the same behaviour with the arrow keys?

[digitall]

SIGH... I did a search on the Android forum section. This is a known issue with the Android backend:
http://forums.scummvm.org/viewtopic.php?t=12183&sid=4115af47d9a838e1bfde5eaf9a80a719

[digitall]

Ah. Have located the issue. The arrow keys generate JE_DPAD events, rather than JE_KEY events, which are then mapped to Mouse Movement:
https://github.com/scummvm/scummvm/blob/master/backends/platform/android/events.cpp#L508

If they do generate the JE_KEY events as well, these are disabled as they are mapped to Common::KEYCODE_INVALID:
https://github.com/scummvm/scummvm/blob/master/backends/platform/android/events.cpp#L164

Will need to work out if it is possible to distinguish the Phone DPAD from an external keyboard in the java code...

[digitall]

Hmm... doesn't look easy to do, which is not suprising as otherwise this would have been fixed by now:
https://github.com/scummvm/scummvm/blob/master/backends/platform/android/org/scummvm/scummvm/ScummVMEvents.java#L180

The problem is the same KeyEvent.KEYCODE_DPAD_UP etc. events arrive from both Directional Pad buttons and standard keyboards.

If I unconditionally change the code to send the events to keyboard arrow presses, then any phone which has a directional pad will be broken for navigation in the ScummVM GUI and other games... Either this has to detect that this is a full keyboard automatically or we will need to add an option.

[digitall]

@Ben: It would probably be a good idea for you to try the following keyboard test tool and see what events are sent by the external keyboard:
https://code.google.com/p/hackerskeyboard/downloads/detail?name=KeytestActivity-debug.apk

[Ben S.]

@digitall: Thanks, I will try to get you some data from that tool sometime this week.

Also, I came across that forum thread a while ago too. The "alternate" build linked there did work better for me.

[Ben S.]

Update: It appears that my keyboard produces only DPAD events when the arrow keys are pressed.

It's a minisuit nexus 7 61-key bluetooth keyboard+cover with tab key.

Edit: Hacker's Keyboard also sends only DPAD events.

[digitall]

Yes, this appears to be another Android annoyance.

I have looked through the relevant APIs and it is not clear to me how you detect if the input device is a full keyboard or just directional pad and/or detect if the input device is virtual or attached via bluetooth.

This makes switching the input event to triggering the arrow key codes problematic as I said before.

I will assign to one of the Android developers and see if they have any further view on this.