The Colonel's Bequest: A Laura Bow Mystery - Forums - Real Hardware

I honestly don't know how to compare real hardware to DOSBox (I barely know how to compare DOSBox to DOSBox), but @ChuckGrody has submitted a run on an actual DOS PC and it cuts the WR time down by 60%.

I don't know enough to know how to handle this. Where do we go from here? Limiting cycles on DOSBox was an easy way to handle things before, but should the restriction just be lifted so that hardware can be supported? Looking for some guidance here.

The run in question: https://www.speedrun.com/colonelsbequest/run/mk9pwg1z

I think it's best to have 2 categories here: DOSBox and DOS. Many other games have different categories for different platforms.

I fiddled with my DOSBox cycles, and it looks like the run by @ChuckGrody ran somewhere between 10,000 and 11,000 DOSBox cycles. But trying to endlessly match DOSBox CPU cycles to actual DOS hardware is a futile task, so I think 2 categories is the way to go.

With that said, I got a 12:30 yesterday on DOSBox () so seeing it done so quickly on a different platform is kind of demoralizing :)

Edited by the author 5 years ago

UrQuan 5 years ago

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.

Edited by the author 5 years ago

Thanks for chiming in with your expertise @UrQuan. I'm just beginning to learn about the inner workings of these DOS games, and your post was quite informative. I think you summarized this whole issue very well by saying:

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

The more I think about this, the more I agree with that statement. It's no fun to run a category by yourself, and splitting a game that's ran so infrequently into multiple categories seems like a bad idea.

@authorblues As a compromise, what do you think about doing away with the 3000 cycle rule for DOSBox, and letting us set cycles=max? If I'm reading the information provided by @UrQuan correctly, this would put DOSBox more on par with the master speed of SCI0 games running on DOS.

Again, I'm far from an expert in all of this, so if anything I just said is factually incorrect, please correct me.

UrQuan 5 years ago

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.

I would suggest ScummVM as it foregoes what we call the "input buffer overload" where if you are holding down a key and release it you will have trailing inputs of that key until the queue for them has run out. I am sure you both are aware of this because it is on full blast with 3k cycles. I should note that is primarily exhibited on DosBox and is dependent on what keyboard connection you are using for native (Ps/2, USB, or a built in keyboard for a laptop).

Playing on native is more of a meme especially when it isn't a machine with native sound hardware (hence the PC speaker beeps recorded with my headset up next to them DarksydePhil style). It just isn't viable for everyone, and, as Quan said, emulators are about equal (my setup is so jank with it too it isn't even funny). That being said if my Any% run is to be denied for that, then I have no problem. Like I said above I can easily get that time, and more than likely a better one, with ScummVM using my experience and route. Another nice thing that you can do with ScummVM, and this is more of a convenience to us, is that you can make a save at the beginning of the game and directly load the game from there bypassing the copy protection. I've been doing this with other games like King's Quest IV which has similar copy protection or KQVI which has a long unskippable opening sequence.

Edited by the author 5 years ago

I have removed the requirement for cycles=3000 on DOSBox. I will verify the run in question.

Another thing I should mention that I came across: there are distributions of this game on various websites that have the copy protection sorted to always be Celie. While this sounds like a nice convenience (and trust me it is), it comes with the caveat of having the RNG (cane location, cigar location, elevator position, etc) completely sorted to one position. A tell for this version is if the chandelier never stops shaking as it is only supposed to shake a bit and stop signifying it as a death trap. As there is only one version of the game running on one version of the engine (0.000.631 Colonel's Bequest 1.000.046) we can determine that this was simply a modification done by a fan at one point and then widely distributed throughout the internet. I have not determined if the paid for distributions (GOG, Steam, etc) have this modification, but I know a lot of websites that offer a free download do.

So the question: should this be allowed in speedruns? I personally consider any kind of RNG apart of the experience and a factor of speedruns so I say ban it.

That's a good point. I'm using a copy that you're referring to. I was wondering why the chandelier in my game always shook, but didn't in other runs I watched. The one time save that I'm doing in my runs that I'm not seeing in any others is using the elevator towards the end of Act VII to go to the second floor. See here: ()

If the elevator being there is an RNG manipulation, then I think that's the only manipulation usable in the Any Ending category. On the other hand, when the chandelier shakes nonstop, the framerate noticeably drops, which loses a bit of time each time you enter the balcony. These two things seem to even each other out. I also noticed that you were able to start Act V outside of Celie's cabin. In my game I need to go to the hedge garden entrance, which takes a second or two longer.

I've been running this game with max cycles on DOSBox for a few days now, and it doesn't run nearly as fast as your run on native DOS. My goal is to finish the game in under 5 minutes, and I'll be happy with that. I don't think that I'll get anywhere near your time.

If the elevator at the end of Act VII is an RNG manipulation, I'll stop using it in my runs. My opinion is that this copy of the game shouldn't be banned, at least for the Any Ending, because the number of opportunities to exploit RNG is minimal there. If there were more people running this game, then all of these intricate details would probably matter more.

Edited by the author 5 years ago

UrQuan 5 years ago

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?

Edited by the author 5 years ago

I hadn't thought about that Fry, and I agree with it. Super Sleuth is indeed the only route that has RNG come into play so it would need that as a factor, but any% is fine without it. I say lets do that. If it is unanimous, then we can add a clause to the rules and a forum post explaining the difference and possibly where to acquire each distribution?

@ChuckGrody I've added you as a mod to the game if you would like to look into implementing these rules. I've been away from this game too long, so I'd prefer to leave it in more capable hands.

@authorblues Would love to man. I know you got a lot of stuff to manage and I'm experienced with this genre of speedgames.