Most SCI games keep track of CPU speed. They do this at startup in a room commonly known as speedTest, and save the recorded speed in a global variable commonly known as machineSpeed.
Initially, there was no upper limit. This leads to bugs in Leisure Suit Larry 3.
In the exercise room, the amount of exercise you needed to become fit depends on your computer's speed; the slower your system, the less exercise required. At the time of release, this was reasonable, but as computers grew faster, it became practically impossible to get past this.
At the hotel lobby, the slower your computer, the less time it takes for the elevator to arrive. On faster computers, the elevator never arrives, leading to another bug that makes the unwinnable.
Fortunately, the developers soon realized this, and added the howFast global. This is set at the speed tester, based on the machineSpeed value. It has only a few values that determine the approximate speed, and has an upper limit if the speed is any higher than specified. This helped ensure that the same problem wouldn't happen again... or would it?
In the SCI1 days, changes to the system and interpreter led to speed bugs happening again. This particularly happens with cycle-based timers. This is actually why the CD-ROM version of SQ4 has numerous speed bugs that didn't occur in the floppy disk version.
This wasn't just a scripting issue; the interpreter and drivers had the same problem. This is the reason newer computers tended to have trouble initializing digital audio - the CPU worked too fast for the driver to keep up. Various patches, both official and unofficial, were created to address this.
On the interpreter side of things, the show styles soon became too fast, and changes had to be made to make them draw slower, specifically for 486 support.
The lesson here? Try not to use cycles for timing and speed, since things get too fast.
Initially, there was no upper limit. This leads to bugs in Leisure Suit Larry 3.
In the exercise room, the amount of exercise you needed to become fit depends on your computer's speed; the slower your system, the less exercise required. At the time of release, this was reasonable, but as computers grew faster, it became practically impossible to get past this.
At the hotel lobby, the slower your computer, the less time it takes for the elevator to arrive. On faster computers, the elevator never arrives, leading to another bug that makes the unwinnable.
Fortunately, the developers soon realized this, and added the howFast global. This is set at the speed tester, based on the machineSpeed value. It has only a few values that determine the approximate speed, and has an upper limit if the speed is any higher than specified. This helped ensure that the same problem wouldn't happen again... or would it?
In the SCI1 days, changes to the system and interpreter led to speed bugs happening again. This particularly happens with cycle-based timers. This is actually why the CD-ROM version of SQ4 has numerous speed bugs that didn't occur in the floppy disk version.
This wasn't just a scripting issue; the interpreter and drivers had the same problem. This is the reason newer computers tended to have trouble initializing digital audio - the CPU worked too fast for the driver to keep up. Various patches, both official and unofficial, were created to address this.
On the interpreter side of things, the show styles soon became too fast, and changes had to be made to make them draw slower, specifically for 486 support.
The lesson here? Try not to use cycles for timing and speed, since things get too fast.
