Unthrottled AGI in ScummVM?
5 years ago
United States

Essentially the title. Noticed the new run by @ChuckGrody utilized unthrottled AGI in ScummVM and was wondering what this entails, exactly.

I tend to run all my dos games in dosbox and haven't especially dabbled in ScummVM so it'd be a big help understanding what it means and how it can be replicated. Thanks!

Edited by the author 5 years ago
Uusimaa, Finland

Let me stake out a few things here. This is based on all my work over the last several months improving the parity between ScummVM and native DOS.

There are two fundamental categories of SCI and AGI games; one's that have a "master speed" and one's that do not (they run unthrottled).

The way the wait function works is: (speed * 60 / 1000) - (currentTime - lastWaitTime).

It is self-calibrating in that it subtracts the execution time from the previous loop. If running on a slower system it will sleep less to compensate. Obviously, this is preferable since it unifies all possible systems and platforms (ScummVM, DOSBox, FreeDOS, native DOS. . . .)

Now, if the game has a master speed like this, and if the fastest speed is not unthrottled, then more obvious still; this speed should be allowed in the speedrun.

All SCI0 and some SCI1 games work like this. The in-game speed selector controls the actual engine speed variable and the fastest speed is 1 (60fps) and it goes down to 16 (1fps). This is unlike later games where the speed slider only controls the "move speed" of ego. Some SCI1 games run at a fixed speed 1 (60fps). King's Quest V as the lone exception runs at a fixed speed 2 (30fps). Later SCI1, SCI1.1 and SCI2 games are unthrottled. Still later SCI2 games started to move away from cycles based timers altogether, to time-based one's like modern video games.

SCI 1.1 or SCI 2.0 games that work well unthrottled are a point of contention.The King's Quest community does allow DOSBox max cycles, ScummVM unthrottled and native DOS for these games (KQ I - IV, and KQ VI), whereas for example Quest for Glory does not.

Some SCI 1.1 or SCI 2.0 games are too broken when played unthrottled on moderately fast hardware, and you are unable to complete the game on native DOS or ScummVM unthrottled, or even on DOSBox max cycles. It is an open question of what we should do about these games. For example, Laura Bow 2 is a game like this, where Bill ultimately preferred to play on ScummVM throttled.

Finally we get to AGI, which is a corner-case. First, some AGI games run at a fixed speed like Donald Duck's Playground. However, the vast majority of AGI games work much like QFG 1 EGA and QFG 2 for SCI, in that the speed selector controls the actual engine speed variable, but unlike other SCI0 games the fastest speed is 0, unthrottled. Likewise for AGI, only that speed 1 (normal) is what would be speed 3 in SCI0, that is 20 fps, and speed 2 (slow) is the equivalent to speed 6, 10fps.

I will say, since AGI unthrottled is so fast even on DOSBox max cycles, requiring the same "billiard ball" route as it does on native DOS, in that you will move in one direction and instantly arrive at your location (where you bumped into something), one might as well allow native DOS for those games. Even DOSBox 10.000 cycles is not that much slower and you will struggle to play the game casually at this speed, even though this is several times slower than even a 486, a system which many people will remember playing these games on in the 90's. I am definitely sympathetic to anyone who would like the speedrun to be at a more reasonable speed, but perhaps the ship has sailed on that now. Those "billiard ball" routes are so well developed for many games by now, and I know that some of the more prolific AGI runners like Chuck, Bill and Lumo all want to play it like this.

There are some question marks though: A significant minority, if not a majority of AGI games, cannot be completed on a fast native DOS system if ran wholly on "fastest". It breaks many cycles-based timers too badly.

Any platform where you can avoid turning the game to "fast" intermittently will almost inevitably be faster in practice. Such is the case with King's Quest I - III; DOSBox max cycles runs at a "Goldilocks speed" where it is very fast but it is not hopeless to stop your character manually, and the cycles-based timers are not completely broken like they are on native DOS or ScummVM unthrottled. However, there are many AGI and SCI games that are too broken even on DOSBox max cycles. It is an open question of what we should do about these games.

Likewise it is an open question if these infamous NewRisingSun's script patches, or others like them, that might fix some of these timer issues, should be allowed. I would take the stance here that they shouldn't be. What muddies the water is that these patches were sometimes included even in the Steam or GOG releases of those games.

The final open question is if ScummVM unthrottled is significantly faster than a fast native DOS or FreeDOS system. I cannot definitively answer that right now. If that is the case then perhaps ScummVM unthrottled should not be allowed, and then I would say that perhaps native DOS should not be allowed either, since A. It is system-dependent like ScummVM unthrottled and B. native DOS is complicated to capture video on let alone stream from.

DOSBox max cycles is functionally just a high fixed cycles amount, and from what I can tell it is not system dependent, at least in practice among Windows systems. Hence DOSBox max cycles should provide an even playing field, hence I would say that at least DOSBox max cycles should be allowed for all games. Of course the speed is still wholly arbitrary and it could even change over time. ScummVM throttled would do that as well but the normal speedthrottler is much slower than DOSBox max cycles.

One more thing: Note that MS-DOS has no task scheduling like modern operating systems: All x86 processors from the 8086 onwards had the HLT instruction, but it was not used by MS-DOS prior to 6.0[2] and was not specifically designed to reduce power consumption until the release of the Intel DX4 processor in 1994 https://en.wikipedia.org/wiki/HLT_(x86_instruction)

No system that relies on OS scheduling will ever match the speed of native DOS exactly.

I won't go into all the technical details here but basically; DOSBox always has granular-enough sleep to where the OS scheduling problems are minimized. In ScummVM, the timing is engine-specific and so it depends on what the engine-developers did. Overall, this problem is accentuated by the fact that in ScummVM, the engine will run too slow, whereas in DOSBox the balance swings the other way; it will run too fast. For the SCUMM engine, it is something in the realm of one frame per second too fast on DOSBox, and 0.3 frames per second too slow on ScummVM. I haven't tested it this extensively for SCI or AGI but it should be similar.

We are still on the order of magnitude of a frame per second, but over a 20 minute run that already amounts to 20 seconds, a non-trivial amount of time in a speedrun.

Now that we have the option for the spinlock in ScummVM to avoid OS scheduling altogether (I could implement that for DOSBox as well in the future, if they will take my patch for it), it is effectively native DOS, FreeDOS and ScummVM that can exactly run at the master speed. This doesn't mean that DOSBox should be banned, especially since the screen transitions (that run in an internal loop) are not quite instantaneous even on DOSBox max cycles, like they are on native DOS or ScummVM unthrottled. That balances it out a bit, if not wholly making up for that one frame per second lost. I don't have experience with other emulators but from what I know, at least WinUAE is very accurate to real Amiga's, given the right settings. Finally, one should note that while ScummVM can play any platform of any game, it has no "lag emulation" like WinUAE or these home computer emulators, and so it is only accurate to emulating regular PC's (and arguably the FM-Towns), and hence ScummVM should NOT be allowed for playing anything other than DOS (and arguably the FM-Towns) game versions.

I realize I am far abreast of the original topic now, but I thought I should take the opportunity to address some of these things here.

Now, to address the original question: LSL1 is AGI2, on "fastest" the game runs completely unthrottled, and unlike many AGI games you can complete it on "fastest" on a fast system (native DOS, FreeDOS, or ScummVM unthrottled). I cannot yet give an ultimate verdict on the question of what should be allowed.

The option to disable the speedthrottler in ScummVM is not yet upstreamed. You can message me on Discord if you want my developmental build.

Edited by the author 5 years ago
United States

This sounds interesting! I really appreciate you taking the time to explain. If I had a passing interest in this kind of thing I'd ask for more information but I'm just here to play games fast.

That basically answers my main question though. As long as unthrottled ScummVM is basically the same as max cycles Dosbox, then it's fine by me. If it was faster though, I don't think it should be allowed seeing as it's not something that's reasonably-accessible.

But that does make me ask, are max cycles typically allowed as Any% runs of adventure games? If the goal of a speedrun is to play a game as fast as possible emulating the original game and its fastest intended way to play, shouldn't acceleration methods like that be prohibited?

Uusimaa, Finland

"But that does make me ask, are max cycles typically allowed as Any% runs of adventure games? If the goal of a speedrun is to play a game as fast as possible emulating the original game and its fastest intended way to play, shouldn't acceleration methods like that be prohibited?"

@slantcarson The original games are unthrottled. There is no ceiling for how fast they run. In fact, DOSBox max cycles runs quite significantly slower than FreeDOS or native MS-DOS, not overwhelmingly so but significantly. For throttled games (which is to say most adventure games), they are the same barring some small caveats.

Just to clarify; I went off on a tangent at some point and that last point about OS scheduling and timing is not relevant to unthrottled games like LSL1. They run at "light speed". There is no timing.

In the future, the option to disable the speedthrottler will be in the stable ScummVM build, so accessibility is not an issue per se, but if ScummVM is banned, then it is an issue because even though anyone would be able to install FreeDOS on some machine (and that already takes a few hoops to jump through), recording or streaming stuff is not trivial. Hence why I said that if ScummVM is banned, FreeDOS and native DOS should probably be banned as well.

Up until recently, no one to my knowledge thought to play on anything other than DOSBox, and hence the discussion was more about if max cycles should be allowed or if we should decide on some arbitrary fixed cycles setting. As I talked about, I think the ship has sailed on that now. DOSBox max cycles should be allowed, in part because the DOSBox max cycles CPU equivalent is not significantly faster than even a 486. I haven't actually tested that but just looking at it with a trained eye. DOSBox dev's will tell you to fuck off if you ask them :P

Let me iterate again that all this is with the caveat that some significant minority if not a majority of all unthrottled AGI and SCI games are too broken to be played on native DOS or FreeDOS on a moderately fast PC, and some are too broken even on DOSBox max cycles.

Edited by the author 5 years ago
United States

Very interesting! Forgive me, I actually had no idea. I'm not tech-savvy so all my knowledge on the topic is anecdotal. You've explained things very well though, so my concern is alleviated. I'll probably try some LSL 1 runs with max DOSBox cycles then and report back. Thanks again!

Uusimaa, Finland

Some healthy concern should remain, since if we allow native DOS, which is faster than DOSBox, and if ScummVM unthrottled ends up being faster than any native DOS system is in practice, to where it should probably be banned, then accessibility would be especially bad. There would be no emulator to turn to.

Right now we are in this limbo where stock ScummVM is just slow as crap, hence people haven't really thought about that, and no one thought to play on FreeDOS or native DOS like Chuck. I also haven't yet been able to test FreeDOS on a fast PC to compared to ScummVM unthrottled. I had already assumed that both would simply run at that "light speed" and hence there would be no distinction to be made, but it remains to be seen. Chuck will gladly remove his ScummVM runs if that ends up being an issue so don't worry about that.

Edited by the author 5 years ago
Uusimaa, Finland

By the way, if you want you can link this page (Edit game -> Discord) to the sierra channel on the Speedy Adventures Discord: https://dicord.gg/kwfw5cj

I am trying to consolidate speedrunning discussion over there for these miscellaneous adventure games that don't have their own Discord (almost no one :P ). Simply mute the non-sierra channels if you want.

We also have a monthly speedrunning marathon! You should run Harvester sometime! :P More details in the Discord or at https://speedyadventures.tv/

Edited by the author 5 years ago
United States

Awesome, I'll throw up your Discord link on the side! It was missing an "s", though (I was wondering why it took me to an adware site lol).

And no problem! I feel like all my questions were more than answered and I have a much better understanding of how DOS games run, so it's all good! I'll definitely check you guys out.

Game stats
Followers
18
Runs
21
Players
9
Latest threads
Posted 4 years ago
0 replies