Opened 2 months ago
Last modified 5 days ago
#15363 new defect
SCI: SQ3: Text Boxes at Death Scenes Clear the Screen Too Quickly
Reported by: | ArthurWalden | Owned by: | |
---|---|---|---|
Priority: | low | 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 (11)
by , 2 months ago
follow-up: 2 comment:1 by , 2 months ago
comment:2 by , 2 months 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 , 8 weeks 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 , 8 weeks 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 , 8 weeks 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 , 8 weeks 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 , 8 weeks 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.
comment:8 by , 5 weeks ago
Assuming that the pattern to look for in the scripts is
(cls) (EgoDead ...)
which I interpret as the game explicitly clearing the text message before actually killing the player, rather than relying on the user to dismiss it, it's found in these spots in the game:
- rm009.sc: "You stepped off the rail! You're dead again. Way to go. Haven't we taught you anything?"
- rm10.sc: "You stepped off the rail! You're dead again. Way to go. Haven't we taught you anything?"
- rm10.sc: "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."
- rm11.sc: "You stepped off the rail! You're dead again. Way to go. Haven't we taught you anything?"
- rm11.sc: "You step on a part of the track which is extremely narrow and greasy. It obviously wasn't designed for human foot travel. It's a quick drop to the unforgiving surface below."
- rm012.sc: "You stepped off the rail! You're dead again. Way to go. Haven't we taught you anything?"
- rm013.sc: "You stepped off the rail! You're dead again. Way to go. Haven't we taught you anything?"
And the two messages in rm11.sc are handled by the same script, it just displays two different messages depending on some variable. So maybe it's just six cases.
comment:10 by , 5 days ago
Priority: | high → low |
---|
If this were a high priority bug then an SCI dev would have set it to high priority. We are not shy.
I have reopened this ticket on a higher priority. Please close this particular ticket as a duplicate.