Opened 6 months ago

Closed 5 months ago

Last modified 5 months ago

#15126 closed defect (fixed)

AGI: KQ3: Intro Text Goes by Too Quickly

Reported by: ArthurWalden Owned by: eriktorbjorn
Priority: normal Component: Engine: AGI
Version: Keywords: kq3, introduction text, cycles
Cc: ArthurWalden Game: King's Quest 3

Description

I am using ScummVM version 2.8.1.

In King's Quest 3, I find it difficult to read the introduction's text within the time allotted. (This issue is even more acute for me personally because I like to read the text aloud when I'm alone in the room.) Another ScummVM user did some research and discovered that ScummVM has allotted too few cycles for the introductory text. I believe the user said that it's currently set to about 1 second=20 cycles, but that is far too brief a time for today's computers. I realize it's not easy to keep up with, as computers are always getting faster, but the KQ3 introduction runs by too quickly at this point.

I am playing the GOG English version of the game.

I am running the game on Windows 11 Home, version 23H2.

Attachments (1)

kq3speed.jpg (115.5 KB ) - added by m-kiewitz 6 months ago.
speed under DosBox is 2

Download all attachments as: .zip

Change History (17)

comment:1 by m-kiewitz, 6 months ago

actually AGI had hard-coded speed settings.
A cycle was meant to take 25 milliseconds.

"Fastest" was even supposed to be unlimited speed, this causes major problems, which is why we limit it to 40 fps
the setting after that was meant to run at 20 fps
After that 10 fps, etc.

So 20 fps is not unusual, or too fast. It's the highest speed setting (outside of Fastest) of the interpreter. I would have to look into the game to see what it's doing.

There may be "optimizations" or rather hacks in some games for situations where the original interpreter struggled, which in turn set the speed to unlimited. A known example is the Apple IIgs interpreter, which was hacked to run at unlimited speed, simply because the computer hardware was not able to handle the games. We had to reimplement proper speed settings for Apple IIgs way because of this.

Version 0, edited 6 months ago by m-kiewitz (next)

by m-kiewitz, 6 months ago

Attachment: kq3speed.jpg added

speed under DosBox is 2

comment:2 by m-kiewitz, 6 months ago

Okay, now this is weird.
I checked speed setting in ScummVM, and it's 1 aka 20 fps.
Under Dosbox speed setting is 2, aka 10 fps, as you can see in the screenshot.
That explains the different durations.

So my guess is the scripts may be trying to figure out how fast the computer is. We are speed throttling right from the start, the scripts may think they are running on a weak computer and thus hack the speed setting up to avoid issues. But right now that's just an assumption. SCI games loved to do this, and caused issues down the line for us too.

When the game is actually running (gameplay), the speed setting is 2 as well for ScummVM. It's just during the intro.

Last edited 6 months ago by m-kiewitz (previous) (diff)

comment:3 by eriktorbjorn, 6 months ago

I committed a fix yesterday which I hope fixes it:

https://github.com/scummvm/scummvm/commit/da8e500bd7ad6c7b72d1b7de68bf2908a5555344

If I'm correct, this is a regression from this commit:

https://github.com/scummvm/scummvm/commit/32ca051485d6bce0939d8fec0676a1fd5d537fc2

Which changed the engine from using 20 cycles per second to 40. But TextMgr::messageBox() still assumed it was 20 cycles per second, and that's what I've changed.

We're lucky in that the King's Quest III source code has been unofficially preserved at https://github.com/historicalsource/kings-quest-3 so we can see what the original intention was. In RM46.CG it states that the delays are "half-seconds message is displayed":

%define	message.1.seconds		31	[	half-seconds message is displayed
%define	message.2.seconds		26
%define	message.3.seconds		12
%define	message.4.seconds		42
%define	message.5.seconds		24

And these are the exact delays we see in the aforementioned messageBox() function. I tried timing it with my change, and I see delays of about 15.5, 13.0, 6.0, 21.0, and 12.0 seconds. So I figure my change does the right thing, even if someone later decides it was wrong. And it only affects the messageBox() function, so it shouldn't break anything.

At least not in King's Quest III. I don't know about other AGI games.

comment:4 by m-kiewitz, 6 months ago

Nice find, I still wonder why the game is running at speed 1 for ScummVM and speed 2 for DosBox, but this explains the message box itself.

But btw.

  • windowTimer = windowTimer * 10; 1 = 0.5 seconds

+ windowTimer = windowTimer * 20; 1 = 0.5 seconds (20 cycles)

Please fix the comment, it should say 1 = 0.5 seconds (ScummVM timer, which runs at 40 fps, instead of 20 fps like original AGI, normally this should have been multiplied by 10)

I changed it back then, so that we can throttle the speed 0 setting to 40 fps and that should stay. The original AGI wasn't doing that. Speed 0 meant as-fast-as-possible, which speed runners like, but which is unplayable.

Last edited 6 months ago by m-kiewitz (previous) (diff)

comment:5 by eriktorbjorn, 6 months ago

@m-kiewitz

Ok, I've expanded the comment a bit. Hopefully correctly.

Is the speed (1, 2, etc.) you're talking about the same thing as ScummVM's WM_VAR_TIME_DELAY? Because at least judging by the calls to AgiEngine::setVar(), that does get set to 1 during the initial animation, but to 2 when the story part of the intro (with the text boxes) begins.

comment:6 by m-kiewitz, 6 months ago

yes, it's variable 10 (hard-coded) for all AGI games.

It's really a shame, I should have implemented debug features back then in AGI, like return to debugger when variable X is set. Would have made analyzing this way easier. SCI debugger has things like that.

comment:7 by eriktorbjorn, 6 months ago

So maybe it's working the way it should now?

Looking at the AGI source code, RM45.CG and RM46.CG set animation.interval to fast and normal respectively, and to me it looks like this is what happens in ScummVM as well.

comment:8 by m-kiewitz, 6 months ago

weird, maybe I checked the credits in ScummVM and not the game intro.
If it's now consistent, then I guess this is solved.

Anyway, I really need to take some time and implement debugger features. Also that script patcher too.

comment:9 by antoniou79, 6 months ago

I am not 100% if related, but while checking the behavior reported in this ticket, I came across dilandau3000's playthrough of the game, from 13 years ago. He's using ScummVM to run the game, and, although I am not sure which version he used, ScummVM 1.3.0 has identical behavior on mine (Windows 10 x64).

Some noted difference during the intro (other than the now fixed quick auto text boxes) are:

  • Animations in the KQ3 logo seem slower (the random sparkles across the logo)
  • The text in the short intro credits (screen with Manannanan on the right side) goes by slower (and is more easily readable). On recent ScummVM (and on DosBox at 3000 cycles) that text goes by quite faster. Is this the new frame limiter at play here? Does it also need to be specifically timed like the automatic timed text boxes?
  • The loading icon (the hourglass) can be seen while loading the next screen; this is also noticable in the game proper while Gwydion moves from room to room. In recent ScummVM this is gone and the loading is pretty much instant.

Should I report these on a separate ticket?

comment:10 by m-kiewitz, 6 months ago

This specific timing bug for message boxes was introduced by me in October 2016, when I added a frame rate limiter to 40 fps for unlimited/run-as-fast-as-you-can mode. That happened because I changed the internal timer from 20 fps to 40 fps, and forgot to adjust the message timer calculation accordingly.

But I also rewrote basically all (most) of the AGI engine in January 2016.

The playthrough is from 2011, which means it used the quite problematic old engine code, that had all sorts of issues, which was the reason why I rewrote it.

So reporting that doesn't really make any sense.

Loading of new screens is as fast as possible. That's intentional. The original interpreter also worked like that. If you want a short delay, you can switch to Apple IIgs, to even get screen transition animations. This screen transition is throttled, otherwise you wouldn't see it. The frame rate limiter is only active when the game is playing, and even that's only changed in ScummVM for situations where the game asked for unlimited frame rate. Before that rewrite we had all sorts of issues in Gold Rush!

btw. since that rewrite, you can now run a DOS-AGI game in Apple IIgs mode, to get Apple IIgs screen change transition animation, as well as Apple IIgs font, or you can run it as if it was an Amiga game, with the Amiga font etc. That wasn't possible back then.

You can even run it in Hercules mode, where a hires font is used (AGI1+2 only), or just enable the pause-game-when-entering-text feature, which was if I remember correctly originally limited to Hercules graphics mode.

Last edited 6 months ago by m-kiewitz (previous) (diff)

comment:11 by antoniou79, 6 months ago

I see. Thanks for the thorough response.

To clarify: my question was not about restoring the old ScummVM behavior, but whether that old behavior, in particular with respect to the animations and text speed during the intro, was closer to the "original" experience. (I did play the original game back in 80s but I cannot reliably tell nowadays how fast/slow it used to play).

Your response covers the above. And thank you for your work on the engine!

comment:12 by eriktorbjorn, 5 months ago

Can this be closed now, then?

comment:13 by m-kiewitz, 5 months ago

I wanted to do that, but I don't know how to set this ticket to you.

comment:14 by m-kiewitz, 5 months ago

Owner: set to eriktorbjorn
Resolution: fixed
Status: newclosed

comment:15 by m-kiewitz, 5 months ago

Ah, it just works like that. Good. Closed now.

comment:16 by ArthurWalden, 5 months ago

Yes. Although I haven't tried KQ3 again, since I finished the game, it appears my original complaint is resolved.

Note: See TracTickets for help on using tickets.