Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#4408 closed defect (fixed)

CRUISE: Inactive cursor click in Cruise

Reported by: SF/bsauvage1 Owned by: dreammaster
Priority: high Component: Engine: Cruise
Version: Keywords:
Cc: Game: Cruise for a Corpse

Description

scummvm v. 1.0.0, iphone 3GS Cruise for a Corpse French DOS Floppy. Touch controls not working (I can move the cursor around but it doesn't answer to clicks). Symptom: in the ontro screen (the Delphine Software Cinematique letters appearing in 3D), I have to wait to get to the end of it (there's no sound by the way, is it normal?). And problem becomes in the next screen, the copy protection explanation, I'm supposed to click OK but I can't.

Bug report submitted.

Thank you in advance for looking into this!!!

I can't believe Cruise is finally there ... so happy!

Thank you to the whole ScummVM team.

Ticket imported from: #2821214. Ticket imported from: bugs/4408.

Change History (10)

comment:1 by fingolfin, 15 years ago

Owner: set to dreammaster
Summary: Inactive cursor click in Cruise on iphone 3GS scummvm 1.0.0CRUISE: Inactive cursor click in Cruise

comment:2 by dreammaster, 15 years ago

If I can separate this into seperate issues..

Firstly, for the Delphine Software startup screen, there isn't meant to be any sound, so there's nothing wrong there. I am a bit unsure what you say about the screen.. are you saying that tapping on the screen during the display doesn't do anything at all? i.e. as opposed to going to the copy protection screen.

As for the 'Ok' button, one possible reason for this is that Cruise has always (i.e. including the original interpreter) been a bit demanding about the position of the cursor for it to become the square 'action' cursor. People running the game on the PC can see this by rolling the mouse cursor over the Ok button - you need to move the cursor to near the bottom of 'OK' before the cursor changes.

This is therefore like to be an issue with stylus-based systems where you don't have a 'mouse move' action. Not just for the Ok button, but for the game overall. Finding the evidence in the first room, for example, can be a bit of an exercise in frustration even with a mouse.. it's likely to be even harder with a stylus.

I'll have a look into the engine to see if I can fiddle with the sensitivity, or bounds, or something - maybe I can improve for it for touch-based systems.

comment:3 by SF/bsauvage1, 15 years ago

Thanks for the very quick reply! OK here are my clarifications: 1 - startup screen: yes if I tap anywhere the screen still continues to show the letters and doesn't move on to the protection screen. 2 - I remember the tricky positionning to get cursor change so i'm playing the game in touchpad mode. I can then position cursor precisely on the 'filled' partf of the OK so that it becomes a square cursor. I then do a tap to activate the command but it doesn't do anything. 3-now i just managed to pass this point by using in mouse drag&drop mode and clicking exactly on the right spot.

Conclusion: it seems the drag-and-drop works fine (so does Cruise) but the touchpad mode seems to have a small issue ?

comment:4 by sev-, 15 years ago

Probably it reacts to MOUSE_UP instead of MOUSE_DOWN event? Would be nice to get fixed before the release.

comment:5 by sev-, 15 years ago

Priority: normalhigh

comment:6 by SF/bsauvage1, 15 years ago

More on this bug. sev might be on the right track: when I move the cursor somewhere it doesn't quite easily register the clicks. I need to play with touchpad and drag&drop on/off and I still haven't found the correct logic to make it work (I'm now stuck at the copy protection page: I can roll through the choices but selecting them is a major pain as the click never seems to register). To give you an idea on other games that I have player, the easy thing to do is to use touchpad mode to move on to the correct place on the screen, then tap once anywhere to activate the left mouse click on that specifically selected point.

comment:7 by dreammaster, 15 years ago

I think I've tracked down the issue. The engine was implemented similar to the original, in that events were tracked to set the mouse x, y, and mouse button variables, and those variables were then used for processing only once for every game frame (every 100ms). I think the problem may be that if the mouse and/or stylus was incredibly quick, it was possible for a mouse down and then mouse up to be processed in quick succession before the main input processing occurred, so it thought that the mouse button wasn't down.

I've applied a fix to make sure any mouse button and/or keypress events break the event processing loop, and will force the processing to be down before processing any further events. This should be an easy fix to ensure that the mouse processing is done before the mouse up events get processed.

If I can get you to test this bsauvage1, and see if it fixes your problems.

comment:8 by SF/bsauvage1, 15 years ago

Great! Very happy to help test it. I've sent you a p.m.

comment:9 by SF/bsauvage1, 15 years ago

The fix is working in the latest iphone build! Thank you

comment:10 by SF/bsauvage1, 15 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.