Opened 10 days ago
Last modified 5 hours ago
#15363 new defect
SCI: SQ3: Text Boxes at Death Scenes Clear the Screen Too Quickly
Reported by: | ArthurWalden | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | Engine: SCI |
Version: | Keywords: | sq3, text speed | |
Cc: | ArthurWalden | Game: | Space Quest 3 |
Description
I am using ScummVM version 2.9.0git5777-g4283632831d.
Whenever I die in Space Quest 3, the initial text box (the one before the death box where you can restore, restart, or quit) displays for only a couple of seconds and then clears and is replaced by the aforementioned death box.
I am playing the English GOG version of the game.
I am running the game on Windows 10 Home, version 2H22.
Attachments (1)
Change History (8)
by , 10 days ago
follow-up: 2 comment:1 by , 9 days ago
comment:2 by , 8 days ago
Replying to ArthurWalden:
I have reopened this ticket on a higher priority. Please close this particular ticket as a duplicate.
Hello! Please don't do this -- don't create a duplicate ticket (with higher priority or otherwise). It results in unnecessary overhead for the team.
Also, the priority is typically managed by the developers of the project. It helps prioritize tasks especially when a new release is closing in. Please avoid using "high priority" for a ticket or feature request.
comment:3 by , 15 hours ago
Looking at sluicebox's decompiled scripts, this seems to be the code responsible for displaying the message:
(4 (= local2 (Print 10 18 #dispose)) ; "Shredded like an Iran-Contra document, your many independent parts flutter to the bottom of the hopper. This is of little importance to you, what with your being dead and all." (= seconds 6) ) (5 (cls) (EgoDead 901 0 3 4) )
(For reference, I'm looking at rm10.sc of sq3-dos-1.018.)
I think the #dispose
thing means that the message does not stay up indefinitely, and setting seconds
to 6 presumably means that the system clock has to change the current second six times. Which should take anywhere between 5 and 6 seconds. (Because the measurement doesn't start at the beginning of a second, it starts at wherever it is at the moment, i.e. the first change in second could come almost instantly.)
At least that's how I read this bit in Interface.sc:
(method (check &tmp thisSeconds) (if seconds (= thisSeconds (GetTime 1)) ; SysTime12 (if (!= lastSeconds thisSeconds) (= lastSeconds thisSeconds) (if (not (-- seconds)) (self cue:) ) ) ) )
When I tried to measure how long the message stayed up I always seemed to get between 5 and 6 seconds. (It would be great if someone could double-check that!) If so, it appears to work as designed? It seems to me that it should be easy enough to change this behavior, if we really want to, but it would have to be on a case-by-case basis.
comment:4 by , 15 hours ago
By "case-by-case basis," do you mean changing only one game, such as SQ3, and not changing all of ScummVM for all games?
comment:5 by , 9 hours ago
Yes, because - as I understand it - that specific 5-6 second delay is for that specific text box only. There's probably no global "text box delay factor" knob to adjust.
comment:6 by , 7 hours ago
So, you would have to adjust the delay manually for ALL death scenes in SQ3, because I've had this problem with every death scene I've tried so far. (Specifically, I also tried falling off the rail, including at the corner, and getting shot by the control robot.)
comment:7 by , 5 hours ago
Not all, as far as I can tell. Some (e.g. picking up the sharp metal "south" of the first room) don't time out at all, so you have to dismiss them manually. So actually, it may not be that many. I don't know why the behavior is inconsistent like that. Possibly because there were at least four different programmers working on the game?
What - if anything - to do about it is a decision I'll happily leave to those who maintain and understand the engine, though.
I have reopened this ticket on a higher priority. Please close this particular ticket as a duplicate.