Opened 7 years ago

Closed 7 months ago

#6193 closed defect (fixed)

SCI: SQ4 title screen skipping too quickly in EGA version

Reported by: misterhands Owned by: sluicebox
Priority: normal Component: Engine: SCI
Keywords: has-pull-request Cc:
Game: Space Quest 4

Description

Latest Win64 snapshot
SQ4 DOS EGA

That was a bug I previously reported for the VGA version (SCI: SQ4 Floppy DOS title screen skipping too quickly - ID: 3537232),
and commit 99de89c974fc24bf58b034842750e522d7d441d4 by md5 fixed it. But the bug is still present in the EGA version.

Unlike the VGA version, the EGA version has no palette cycling effect on the title screen (or when Roger travels through time), so it will require a different fix.

Ticket imported from: #3590813. Ticket imported from: bugs/6193.

Change History (13)

comment:1 by bluegr, 7 years ago

Thanks for the bug submission.

I just watched the introduction of the EGA version, and I believe that the Space Quest 4 screen behaves correctly, plus the music is heard at the right time.

In the VGA version, the Space Quest 4 screen disappeared very quickly before the fix, but in the EGA version it all works properly, as the game scripts don't take the palette cycling effect delay into account.

Thus, I don't see this problematic behavior in the EGA version, and I'm inclined to close this as "Works for me". Setting it to "Pending" for now, till there is more feedback from the original poster.

comment:2 by bluegr, 7 years ago

Owner: set to bluegr
Resolution: worksforme
Status: newpending

comment:3 by misterhands, 7 years ago

I just tried again, and in ScummVM on my desktop computer the title screen doesn't last longer than one short second, which is clearly too quick. So it really feels like the title screen is skipped, just like the VGA version before you fixed it.

In DOSBox, the title screen can last from less than 1 sec (like in ScummVM in my computer) to 10 seconds or more, depending on how the cycles are set.

So I think it is not a bug, simply something that happens when you have a modern, very powerful system. The number of cycles that determine the duration of the title screen can be processed in a split second.

This problem requires a workaround IMO. And the issue is sure to become worse and worse in the future as the power of machines keep increasing.
I feel that the normal time for the title screen would be 4 to 6 secs, like on the fixed VGA version.

comment:4 by bluegr, 7 years ago

Status: pendingnew

comment:5 by m-kiewitz, 5 years ago

Which title screen do you mean?

The Space Quest screen? Or the "Time Rippers" screen?

The "Time Rippers" screen delays internally for exactly 8 seconds. It doesn't use cycles.

Also do you have music enabled?

comment:6 by misterhands, 5 years ago

I mean the Space Quest title screen. It vanishes right after the copyright line shows up.
At that very moment there is a big CPU utilization spike in the ScummVM process, it looks like the cycles are processed as fast as possible.

The Time Rippers screen lasts 8s indeed. So this one's a little too long. (kidding)

The music setting does not seem to make a difference. I've tested with no music, adlib and mt32.

comment:7 by sev-, 4 years ago

Resolution: worksforme

comment:8 by csnover, 2 years ago

Keywords: script removed

comment:9 by sluicebox, 7 months ago

There are two things going on:

  1. The workaround in 99de89c974fc24bf58b034842750e522d7d441d4 isn't applied to EGA versions. It occurs at the end of kPaletteAnimate(), but that function starts with:
// Palette animation in non-VGA SCI1 games has been removed
if (g_sci->_gfxPalette16->getTotalColorCount() < 256)
	return s->r_acc;

Moving the SQ4 workaround ahead of this check causes it to be applied to the EGA version. But...

  1. Starting in the EGA version, Sierra changed the intro script to test how many colors are available and adjust the delay accordingly. If there are 16 colors or less then the while loop is increased from 200 iterations to 10000. Without the ScummVM workaround this increase doesn't make a difference, it goes too fast either way, but with the sleep(10) workaround applied, the title screen lasts almost 2 minutes!

I tested moving the workaround and patching the EGA script to use the normal delay and the result is that the intro runs in ScummVM with the same timing as the VGA version. It looks like the intro is the only script that added dynamic timing based on number of colors. The comments for the existing workaround list a number of rooms that benefit from it so I assume those are also going too fast right now in EGA.

I'm under the impression the Japanese version is also 16 colors, it might have the same issues.

Last edited 7 months ago by sluicebox (previous) (diff)

comment:10 by sluicebox, 7 months ago

Oh, and I suppose the intro on Amiga versions are also going too fast, since they're < 256 colors.

comment:11 by sluicebox, 7 months ago

Keywords: has-pull-request added

This applies the palette speed throttling workaround to all SQ4 floppy versions and makes all floppy intro/timepod/etc timings consistent:

https://github.com/scummvm/scummvm/pull/1539

comment:12 by Filippos Karapetis <bluegr@…>, 7 months ago

In a398d363:

SCI: Apply SQ4 timing workaround to non-VGA versions

Fixes bug #6193 by applying the SQ4 floppy kPaletteAnimation timing
workaround from 99de89c974fc24bf58b034842750e522d7d441d4 to versions
with less than 256 colors. This includes DOS EGA, PC-98, and Amiga.

This also patches out the intro script's workaround that uses different
timing in EGA mode, as this is incompatible with ours and makes the
intro screen last over 3 minutes instead of 5 seconds.

comment:13 by bluegr, 7 months ago

Owner: changed from bluegr to sluicebox
Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.