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/

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.

"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.

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.

Looking at your game footage, it doesn't look significantly slower overall but it does look significantly laggier. I assume it's not just frame drops. DOSBox is quite resource heavy so that's not surprising per se, but normally the chandelier or anything else animating should not slow you down on DOSBox max cycles (and it should be otherwise equal to native DOS, with exception to the screen transitions). Actually, now that I think about it your screen transitions are very slow even for DOSBox.

Is it better without recording? Are you able to try on a different computer?

Essentially, for SCI0 and early SCI1, any emulator and any speed in DOSBox should be allowed. All platforms will run the engine at the same speed anyway. There is also no point in banning ScummVM since you will not be able to tell a difference between it and native DOS, but especially not after I am done with it all my work on it :P (whereas DOSBox max cycles there are subtle tells for).

There are some things we take for granted in Speedy Adventures like not using the global menu (Ctrl + F5) in ScummVM to restore saved games, and enabling the original save / load menu's in Options -> Engine (also because the original menu is faster anyway....). Historically ScummVM has been so slow compared to DOSBox that things like this have been a non-issue, but from now on it's something to think about.

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 games; one's that have a "master speed" and one's that do not (they run unthrottled).

The way the wait function works in SCI 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 ScummVM unthrottled and native DOS for these games (KQ I - IV, and KQ VI), whereas for example Quest for Glory does not.

I will say, since AGI 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 happen to know that some of the more prolific AGI runners like Chuck, Bill and Lumo all want to play it like this.

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. Ironically, Laura Bow 2 is an example of game like this and in fact it's one of the most broken SCI games ever. For that game, Bill ultimately preferred to play on ScummVM throttled.

By the way, I will also take the stance here that these brutal script hacks (by NewRisingSun) that might fix some of these timing issues, but that fundamentally change how the whole game plays, cannot be allowed, but this is especially the case now that we have ScummVM that runs everything well and at a consistent FPS with the speedthrottler. I will even take the stance that these script hacks shouldn't be allowed even if, by ignorance, they were included in the Steam or GOG releases of those games, as sometimes was the case. Subtle script patches are okay, like hardcoding the benchmarking result in LSL3 so you don't have to do 100 of each exercise (although ScummVM fixes this as well, without script hacks).

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 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. 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 since @authorblues is a Content Mod and otherwise a mod of many games, so in case he needs to resolve something related to this in the future. . . .

Now, to address the original question: Colonel's Bequest is SCI0, and so any speed and any emulator should be allowed, and no extra categories are needed.

In general, I think we should be a bit careful with adding additional categories for these games that might have as few as zero active runners. In that case it seems a bit superfluous to add categories that pertain to the exact same route.

Actually, myself along with a few people from Speedy Adventures have been thinking about what would be a good standard leaderboard for these old point-and-click games. Based on El-Nino's setup for many of his games, we came up with adding an Emulator variable, for ScummVM, DOSBox, and other emulators like WinUAE if the game has an Amiga port, and so on. Other more obscure emulators can be added if a player requests it.

If you want to go with that for Colonel's Bequest then: Add an "Emulator" variable, and DOSBox, ScummVM, WinUAE as values (and add Amiga and AtariST as Platforms). Also if you can tick all current runs as Emulator. I realize that it's a bit but redundant if you add the Emulator variable, but that Emulator flag is hardcoded on speedrun.com and the only way to get rid of it is to "ban" emulators in Edit game.

@FutureFryArama That run is equivalent to several hundreds of thousands of cycles in DOSBox, or several million, although even DOSBox max cycles doesn't run at a fraction of that speed. I can see why you thought it was between 10.000 and 11.000 cycles though, since that is around the point where DOSBox runs fast enough to run the engine at speed 1 (60fps), at least if the cast list is not too long.

@frkypnt Ask here to be modded: https://www.speedrun.com/The_Site/thread/63nr7

You have my blessing.

Incidentally, we discussed the Amiga version of King's Quest VI a few months ago and concluded that it should actually be its own game page; it was developed independently of Sierra and does not even use the SCI engine. We'll set that up just for you! Congratulations on the world record! :P

The "emulators banned" is a quirk of the current Leaderboard setup we have for King's Quest. Emulators are indeed allowed.

I would tentatively give you the green light to play on whatever Amiga emulator you use. You can actually play the Amiga version on ScummVM as well if you want.

Many of these LucasArts games have Amiga versions, though not all of them have it listed as a platform. Most notably, the Monkey Island 2 Amiga version is significantly faster and so it is used for the speedrun.

Just a couple of very minor typo fixes:

In Edit game -> Extra variables/subcategories -> Options

"User Defined" changed to "User-defined" "Values obsolete eachother" changed to "Values obsolete each other"

Update Discord link plox. You need to set it to never expire, if that was the issue.

For IL's, kind of a non-issue but anything goes obviously, including setup from previous levels? Police Station is affected primarily, but perhaps there are some more subtle one's :P

I think Nvidia Inspector might not work properly for Freedom Fighters, but EnableVSync in freedom.ini should work.

Change DisableVSync to EnableVSync basically.

Yeah, there is no Steam or GOG release, though it is highly requested on the community wishlist there. The problem is, the physical copy, like many old PC games, has some ancient DRM scheme that outright will not work on Windows 10. Meaning there is not even a work-around, you cannot install it from the CD.

Not sure if it's against the speedrun.com terms of service to condone piracy but I'm just stating the fact that it is physically impossible to get the game to run without a no-cd crack. A Windows 7 machine should work with the physical copy though, if that is possible for you.

Several of the skips require precise jump or grap inputs. It will take some time to get consistent at some of them but nowadays there is nothing too bad.

Now, I personally use free scrolling mouse wheel for jump, but no one who came after me does since the route where that was needed in Naval Base has been obsoleted. The Fort Jay skip (or both of them) are helped by mouse wheel for jump but runners after me have another setup for that which seems to be trivial to get or at least does not require the spammed grap input. I have no personal experience with normal jump, but from what I have heard the Fire Station skip is harder with mouse wheel, not to mention the janky controls throughout the whole game.

To a large part the run is just optimized movement; GoldenEye is perhaps good experience there :P

There is actually another new route in Naval Base. It's kind of insane and is not documented anywhere (it's not the yolo molotov throw that is also not documented and no one has done in a run).

If you actually start running I will catch your stream at some point and tell you about that or anything else you need.

I would request Warhammer 40,000: Dawn of War II: https://www.speedrun.com/Warhammer_40000_Dawn_of_War_II to be added to the Warhammer 40,000 series: https://www.speedrun.com/wh40k

"No glitches, No exploits"

So only Let's Play's allowed basically? :P

At the very least only ban specific glitches, or at the very least define what an exploit or glitch is.

The game is called "Discworld".

The date for the World Record should be 05.07 2007.

Indeed.

This is actually relevant for a somewhat "consistent" Any% route with Ascendant Divine where you can more or less consistently start with a Terraform spell or cycle for one (there are like 6 in total), terraform the Portal of Power and then have about a 10% chance to traverse the Mines or Crypt even with base stats. More if you also terraform the Warlock's Cave and so on. Slightly slower than Dungeon or Eagle King so not necessarily for a real speedrun.

One thing though; once Cataclysm is released there is a low-key OP spell "Blink", where, unless they deliberately implement it wrong like with Scribe in the City, you can actually Blink past the Mines or Crypt (no other spell does anything like that). This route would actually be consistent to the point of being "viable" in an online game (mostly with CoC ending though). I guess you can also just open the Portal manually, so you only need Blink and a Talisman (and you start in the Middle Region close to the Warlock's Cave), but then maybe a real spell-cycler like Warlock is better.

The choosing of a Warlock's Quest is not a bug actually: https://images-cdn.fantasyflightgames.com/ffg_content/Talisman/reaper%20rules.pdf

"When playing with the Warlock Quest Cards, when a character lands on the Warlock’s Cave space, that player chooses freely one of the available Warlock Quest Cards from among those available in the Warlock Quest Card deck, instead of rolling a die to determine which quest he is assigned."