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)

sq3.003 (14.1 KB ) - added by ArthurWalden 10 days ago.

Download all attachments as: .zip

Change History (8)

by ArthurWalden, 10 days ago

Attachment: sq3.003 added

comment:1 by ArthurWalden, 9 days 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, 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 eriktorbjorn, 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 ArthurWalden, 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 eriktorbjorn, 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 ArthurWalden, 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 eriktorbjorn, 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.

Note: See TracTickets for help on using tickets.