SHP Forums

It's been a while since I've played PQ3 but just tracked down my old copy today, which reminded me of a couple of things:

1. I got stuck on the day when you have to attend the fire - the game just kept looping. Was this a bug?

2. Before I bought the game I saw one of Sierra's demo disks (I think Willy Beamish may also have been on that disk). I can't remember what the exact differences were, but the opening scene of the crackhouse siege was different between the demo and the final game. Did anyone else notice this? Were these demos produced before the games had been completed?

Thanks,

Dodginess

Did you use the installer from here?

Thanks for the reply.

I played PQ3 when it was first released, so my problem probably predates the existence of any patch I do remember that I encountered the pentagram issue though, and there was also a problem with the photofit - I only encountered it once, but the face wouldn't match no matter which options I tried.

Going back to the looping problem on day 3 (I think I've got that right, it *was* 20 years ago after all) I wasn't sure if it was a real bug or just a result of the game design - not to criticise the original designers of course, but other PQ games had the same kind of problem where if you got the sequence wrong then you never got to the next day - the difference with the PQ3 problem was that the events on that day kept repeating as if they'd never happened.

Dodginess

Many bugs in the SCI1 games did not surface until the PCs got faster. This was the case, even when the games were still relatively new. The timer bugs manifested themselves in a variety of ways, from crashes with or without error messages to endless loops or events not being triggered. Sierra released patches for some of these errors, but some errors did not surface until PCs got fast enough to trigger them. The older the game was made it less likely that Sierra would release a patch. Often, older games that they still supported, only had save games as a work around. There are a handful of fan made patches to address some of the most infamous the timer bugs, but these sometime introduce new problems.

Playing the games in DOSBox addresses these timer issues. It can simulate a machine of the speed that the games were originally designed for. The new installers here are the best way to go to play the games on modern PCs.

http://sierrahelp.com/Patches-Updates/N ... llers.html

For the DOS games, they will automatically set the games up in DOSBox, apply all relevant patches and properly configure the game and DOSBox to optimal settings. The games can be started from a Windows shortcut (like any native Windows game) with a high res icon for Vista/Win7. The DOS games come with a configuration utility to make it easy to adjust DOSBox to your preferences.

The Windows games have even more issues. In general, the SCI Windows games were considerably buggier than their DOS counterparts. IN addition to the timer bugs, antiquated APIs create problems on newer versions of Windows. Many of these games were 16-bit and or came with 16-bit installers. Most 16-bit code will not run on 64-bit Windows. Only certain InstallShield 16-bit installers will run, and for the most part, Sierra did not use IS for their installers. Some 32-bit games shipped with 16-bit installers. Game that do not need much more than to be copied to the hard drive are easy to deal with, but many are more involved. Some of these I have reversed engineered to create new 32-bit replacement installers. Some have required compatibility fixes, too.

Try installing the game with the PQ3 installer and see if you still encounter the problem. Just keep in mind that you may have to start the game over. The save games are very version specific and those made with a bug can carry that bug over to the new game.

Thanks for that information - I do remember that the Windows installers were always a bit flaky. I'm on a Mac these days so DOSBox is my PC of choice now. I also have an ancient Toshiba laptop if I ever need any on-the-move Sierra gaming goodness.

Seeing as how you've been able to create your own patches, do you know why these kind of timing issues arose in the first place? I do remember that the arcade sections in Dynamic games were just designed to run as fast as the processor could handle them - is this also the case with the later Sierra games? The AGI games still seem to run fine, even ones like KQ3 that have an in-game timer.

Dodg

Often the timer bugs arose by programmers using CPU cycles instead of real time in their code. Games written when CPU clocks were 20 MHz would see as much as a 175 fold increase on modern machines. They did not always base timers on cycles. The most common era for the Sierra games to have them is the early VGA era. The only one that I am aware of in an AGI game is the cracked Gold Rush!, but this is not because a timer on too fast of a machine, but because the crack is a jump in the code to skip the CP code. This also skips a change in a timer.

As an example, the Sierra SoundBlaster driver initialization error first surfaced in the mid '90s when CPUs were only maybe around 3 or 4 times as fast. The driver queries the SB hardware as part of its initialization as the game is loading. It was designed to wait a certain amount of time for the hardware to respond. If there is no response, the wait times out and the driver assumes that the hardware is not present an throws the initialization error. On faster machines than the driver was designed for, what happens is that the reply from the SB hardware is returned so fast that the driver misses the response.

Another obvious example is the firecracker speed bug in KQ7. The game uses a timer to determine when to set off the firecracker. When the game was first released, the top of the line CPUs were 65–120 MHz. This represents as much as over 50 times faster on modern machines. The player has to move faster than the game will allow to place the firecracker before it blows. When the bug was first noticed, you could work past it by using the "Try again?" option, which started a little closer to the goal each time. The faster the PC became, to more tries it took as each "Try again" moved you by smaller and smaller amounts. On a modern machine, this work around no longer works.

By the way, you can use my installers on your laptop and move the game folder to your Mac. You would only need to edit the mounting in the autoexec section in the game's dosbox.conf and start you Mac port of DOSBox with that conf. This would ensure that the game is fully patched and properly configured.

Collector wrote:Often the timer bugs arose by programmers using CPU cycles instead of real time in their code.

Sorry if this is a dumb question, but by "real time" do you mean that actions in the game are scheduled with reference to the system clock instead of processor cycles? Not being particularly proficient at programming as I am, it would seem sensible that the developers could have used the system clock to time how many NOP cycles were completed within 1 second and that would at least have given a reasonable indication of how fast the computer was. But saying that, I don't know how easy or difficult it would be to implement something like the slow/normal/fast/fastest settings in AGI games.

Thanks for all your advice so far - I think I've probably used up my quota of questions for now or you'll never get time to answer anyone else's

Dodginess

real time - 1milsec=1milsec in the real world. Nothing to do with any narrative events in a game. The SCI0 games jad a speed adjust like that of the AGI. The SCI1 (VGA) games had the speed slider in the settings/save/load GUI. The speed adjust within a game would not necessarily affect all aspects of the game. Usually the animations' speed and sometimes (not always) the games narratives' time would be affected.