Opened 10 years ago

Closed 4 years ago

#6477 closed defect (fixed)

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

Reported by: SF/benshadwick Owned by: ccawley2011
Priority: normal Component: Port: Android
Version: Keywords:
Cc: Game: Quest for Glory 1

Description

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.

Ticket imported from: bugs/6477.

Change History (18)

comment:1 by digitall, 10 years ago

Summary: Problematic arrow key mapping for Android bluetooth keyboardSCI / ANDROID : QFG1 - Cursor Keys controls Mouse, rather than Ego

comment:2 by digitall, 10 years ago

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.

comment:3 by digitall, 10 years ago

Resolution: invalid
Status: newclosed

comment:4 by SF/benshadwick, 10 years ago

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.

comment:5 by digitall, 10 years ago

Resolution: invalid
Status: closednew

comment:6 by digitall, 10 years ago

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?

comment:7 by digitall, 10 years ago

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

comment:8 by digitall, 10 years ago

Summary: SCI / ANDROID : QFG1 - Cursor Keys controls Mouse, rather than EgoANDROID : SCI QFG1 - Cursor Keys controls Mouse, rather than Ego

comment:9 by digitall, 10 years ago

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...

comment:10 by digitall, 10 years ago

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.

comment:11 by digitall, 10 years ago

@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

comment:12 by SF/benshadwick, 10 years ago

@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.

comment:13 by SF/benshadwick, 10 years ago

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.

comment:14 by digitall, 10 years ago

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.

comment:15 by digitall, 10 years ago

Owner: set to fuzzie

comment:16 by ccawley2011, 5 years ago

Component: Engine: SCIPort: Android

comment:17 by ccawley2011, 5 years ago

Owner: changed from fuzzie to ccawley2011
Resolution: fixed
Status: newpending

comment:18 by ccawley2011, 4 years ago

Status: pendingclosed
Note: See TracTickets for help on using tickets.