Macromedia/Quicktime Games Cause Slowdown

[CryptidWorks]

Okay, I know I'm a serial complainer I do apologize for that but I think I actually found something interesting. Games that are built with heavy use of Quicktime and/or Macromedia seem to cause horrible emulation slowdown unrelated to the actual speed of the host CPU when faster chips are emulated, at least on Windows 98SE. You can see it here in this real time testing clip of Mummy: Tomb of the Pharaoh where PCEM is having a stroke with a 233 but working fine if I drop it clear down to a Pentium 75 (It's a windows 3.1 era game that recommends a 486/33 so it doesn't take much). I also observed it with a sampler application for a Playschool game that was built with Macromedia/Quicktime.

https://www.youtube.com/watch?v=Khomu6KrSU0


This is on a host system that can run Blood II, The War in Heaven, Shogo, and Qauke II on a Pentium 233 and Voodoo 2 with zero slowdown

Video might take a few minutes to process full quality

[CryptidWorks]

I accidentally make the video private instead of unlisted, that has now been fixed and the video is viewable

[SarahWalker]

Can you take a screenshot of the status window when the slowdown is happening? It has useful performance-related information.

[CryptidWorks]

Can you take a screenshot of the status window when the slowdown is happening? It has useful performance-related information.

You mean the machine window? Sure.





As you can also see even on the point showing the highest usage I'm not even using half of the CPU core doing the work so it seems to not be a physical bottleneck

[CryptidWorks]

For comparasion here's a 3D Accelerated game from 1999 hammering the system with zero slow-down



Blood 2 at high detail, which is basically torture for a Pentium 233 and using even more host CPU than The Mummy but with 0 slowdown

[CryptidWorks]

Upon further experiments chips as slow as the Pentium 90 even show this behavior for brief moments when transitioning between areas. This is bit lower quality because I had to save a Shadowplay video and screenshot from that to catch it happening

[CryptidWorks]

May have gone overboard but I hope I've managed to provide some interesting data to work with

[SarahWalker]

What are you using for CD support - the built-in ISO loader? A virtual CD drive? God forbid, a real CD drive?

Basically your top two screenshots confirm PCem is massively slowing down, and if it's not actually using CPU time then it's probably blocked on IO, and CD emulation is a not infrequent cause of this.

[CryptidWorks]

What are you using for CD support - the built-in ISO loader? A virtual CD drive? God forbid, a real CD drive?

Basically your top two screenshots confirm PCem is massively slowing down, and if it's not actually using CPU time then it's probably blocked on IO, and CD emulation is a not infrequent cause of this.

I'm just using an ISO directly mounted into PCEM with the drive speed set to the default 24x.

I figured out pretty quick passing through the real drive is something PCEM doesn't really like at this stage and just tanks it when it's accessing the disc

Can also confirm from that Afterburner read-out that my CPU isn't even coming close to tapping out and I verified with Blood 2, which pushes that 233 to nearly max load but causes zero slow-down in PCEM and doesn't even load the core that's taking the brute to 70%.

If it's an issue with the CD emulation jamming it up is there some kind of work-around? This is a Macromedia point-and-click that's likely streaming heavily from the CD so that could very well be the cause.

[SarahWalker]

You could try using a virtual drive like Daemon Tools to see if that performs any better.

[CryptidWorks]

You could try using a virtual drive like Daemon Tools to see if that performs any better.

Tried both both Daemon Tools and the Windows 10 built-in function AND playing with the drive speed. Nothing worked. There's seem to just inherently a weird bottleneck caused by the disc drive emulation.

[CryptidWorks]

Tested something with a problem app I was able to rip from the disc to remove the CD drive from the equation and nope. It seems like Macromedia based apps are causing some kind of runaway leak in CPU usage that doesn't happen any other time the emulated CPU is under full load.

Problem can be worked around by running just those apps with a weaker CPU (dropping to an MMX 166 seems to fix 90% of the issue) but it's still really odd

[Xanarki]

I can confirm it happens on other games too. I tried 5 a Day Adventures (1995), and it's slow n skips on higher speeds. Drop it down, and it's alright. The game heavily utilizes QuickTime 2.1 I believe. At the time, I tried both PowerISO and the built-in drive. I just didn't think anything of it, until this topic popped up..

[CryptidWorks]

I can confirm it happens on other games too. I tried 5 a Day Adventures (1995), and it's slow n skips on higher speeds. Drop it down, and it's alright. The game heavily utilizes QuickTime 2.1 I believe. At the time, I tried both PowerISO and the built-in drive. I just didn't think anything of it, until this topic popped up..

Yeah. It really does seem to be some weird issue directly linked to Quicktime because on my end no other games that pushes the emulated CPU to full load causes slowdown.

[CryptidWorks]

https://www.youtube.com/watch?v=bZfXygXLHqY

I just wanted to necro my own thread to say it's been fixed in PCEM v17. Now I can run Quicktime content on a PCEM system with a full-on Pentium II/233 and have zero slowdown.

Would be interesting to know what the culprit was and how it was fixed

[SarahWalker]

At a guess, probably the same issue as viewtopic.php?f=3&t=3577

[CryptidWorks]

Update again

It is not fixed

However with the fact it doesn't happen on the Pentium II/233 I can confirm it's a specifically with the MMX CPUs on Socket 7.

[CryptidWorks]

At a guess, probably the same issue as viewtopic.php?f=3&t=3577

So I've done some testing and confirmed it's a problem with the faster Socket 7 CPUs.

The Pentium II/233 works flawlessly in Quicktime content.

The Pentium MMX 233 has noticeable slowdown in the same content regardless of motherboard emulated.

Pentium 200 and Pentium MMX 200 are fine with speeds never dropping below 99%.

Pentium 166Mhz or lower is pretty much a locked 100%