Opened 2 months ago

Last modified 2 weeks 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)

sq3.003 (14.1 KB ) - added by ArthurWalden 2 months ago.

Download all attachments as: .zip

Change History (11)

by ArthurWalden, 2 months ago

Attachment: sq3.003 added

comment:1 by ArthurWalden, 2 months ago

I have reopened this ticket on a higher priority. Please close this particular ticket as a duplicate.

in reply to:  1 comment:2 by antoniou79, 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 eriktorbjorn, 2 months 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 ArthurWalden, 2 months 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 eriktorbjorn, 2 months 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 ArthurWalden, 2 months 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 eriktorbjorn, 2 months 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 eriktorbjorn, 6 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:9 by somaen, 2 weeks ago

Priority: normalhigh

Would be good to look into this for 2.9.0

comment:10 by sluicebox, 2 weeks ago

Priority: highlow

If this were a high priority bug then an SCI dev would have set it to high priority. We are not shy.

Note: See TracTickets for help on using tickets.