Opened 15 years ago
Closed 15 years ago
#4470 closed defect (fixed)
IPHONE: CRUISE: more problems with click event
| Reported by: | SF/bsauvage1 | Owned by: | vinterstum |
|---|---|---|---|
| Priority: | blocker | Component: | Engine: Cruise |
| Version: | Keywords: | ||
| Cc: | Game: | Cruise for a Corpse |
Description
Cruise (DOS/Floppy/French); iphone 3GS, firmware 3.0 Since the bugfix to register the click events on iphones, I can report the following: -first bugfix worked well and i was able to play -since the 2nd small part of the bugfix it doesn't work anymore:clicks are actually double-registered (touch and release seems to register 2 clicks). This is a problem for the copy protection screen, where clicking OK on the first page automatically registers anotehr click at the first question and always end up in the "Code Incorrect" message. Afterwards, I am able to select the objects, but it also seems, since this 2nd bug fix, that whatever combination i pick it doesnt recognise it and returns the "Code Incorrect" message. I have tried times and again and I own the original wheel of codes, so I am sure this is not a wrong manipulation from my side.
Ticket imported from: #2826876. Ticket imported from: bugs/4470.
Change History (7)
comment:1 by , 15 years ago
comment:2 by , 15 years ago
| Owner: | set to |
|---|---|
| Priority: | normal → blocker |
comment:3 by , 15 years ago
| Summary: | CRUISE: more problems with click event on iphone → IPHONE: CRUISE: more problems with click event |
|---|
comment:4 by , 15 years ago
I just tried the latest build (42826) as I see Dreammaster has made quite a few changes to the click handling. I think this is still work in progress as now it seems the click event is not even recognised anymore. (I manage to have one click registered, then nothing else; weird behaviour)
comment:5 by , 15 years ago
I just identified what might be the cause of both this issue and the player menu bug.
The event loop for Cruise has been modified so that any event other than a mouse move aborts event processing for the current frame - this is so events like mouse presses will always be processed, even if the mouse up comes immediately after. Unfortunately, my while loop first polled for an event before checking whether to abort for the current frame, which meant every time it aborted, it would effectively discard the event it had just polled from the backend.
Boy am I embarrassed.
comment:6 by , 15 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Raising priority. This is a release-critical bug.