Future Shock is infamous for its poor performance and instability. It can be a challenge getting it to run well in SVGA mode even in Dosbox. PCem is even slower, sadly. If your CPU is powerful enough, try picking a faster emulated CPU. Other than that, there is probably nothing you can do. I would recommend switching to Dosbox and turning up the cycles quite high (edit: actually, I think I used dynamic core and auto cycles), that's how I played it.

Pick a "slower" CPU. On my 5900X I toyed around with this months ago. The winchip2 CPUs do good. Also, disabling cache in the BIOS of the emulated computer and then picking a faster MHz CPU. These all seem like counter productive things but try them out.

Edit: basically you want to pick a emulated CPU that gets your CPU time on that machine stats page to not be at 99.99 or 100 while you are playing the game. For whatever reason Future shock and skynet both have this behavior with PCEM and 86box that I think has to do with the dynamic recompiler or has to do with whatever disabling the cache in the bios actually does, which I think is actually disabling the recompiler on hardware where you can't actually uncheck the box...

feda wrote on 2022-08-04, 07:06:

Future Shock is infamous for its poor performance and instability. It can be a challenge getting it to run well in SVGA mode even in Dosbox. PCem is even slower, sadly.

It's PCem itself that's slowing down. In the quake example that I mentioned, the frame rate is in single digits, practically unplayable, yet PCem stays at full speed, as expected.

Navjack27 wrote on 2022-08-05, 09:22:

For whatever reason Future shock and skynet both have this behavior with PCEM and 86box that I think has to do with the dynamic recompiler or has to do with whatever disabling the cache in the bios actually does, which I think is actually disabling the recompiler on hardware where you can't actually uncheck the box

Thanks; so it's not just me. I suppose it's some sort of a bug.

Out of curiosity, have you noticed this behavior with any other game?

EDIT:

As you pointed out, disabling the internal cache remedied the huge perf drop, however my 2600 is not able to handle a P 200 without it, so I had to drop it to a mobile Pmmx 133; now it stays at 100% with occasional small dips when picking some stuff, which isn't a major issue.

eddman wrote on 2022-08-12, 05:12:

Out of curiosity, have you noticed this behavior with any other game?

Not that I can really remember maybe... Ok maybe Ultima 9 exhibits this behavior but then there are also a whole lot of other variables that get introduced when you are testing something in Windows 98.

But sticking to dos things.
I think I've also observed this with dos menu applications. Certain menu applications can have a behavior where in dosbox and in PCeM and in 86box where just sitting in the menu, and we're talking one of those blue background gray text kind of menu applications, where you could just be sitting in the menu and for whatever reason it's just knocking your real time percentage down to like 50 or 70%. Like it's just not picking up the idle loop or something correctly.

Edit: I might have encountered it with other games but I might not have made any note of it so I might have forgotten. Going through something like a dos collection to test random games takes time 😂 but I boot up a disk image every so often and try more out.

You'll basically encounter this every so often and when you do just try to do what I recommended.

I ran PCEM the other day, for sound card testing, running i5 10400, slight bump on the BCLK so around 4.3Ghz. Used Pentium II at 233Mhz, 100% through setup, general driver installation, Doom running in DOS mode with SB16 NukedOPL3, all fine, same for Doom 2, but Monkey Island, either through OPL3 or Monkey.exe r, CPU down to 75%, lag. Exit the game, back to desktop, lag until restart.

Set to Pentium 166 MMX, all fine, no lag, Monkey at 100% consistent.