Privateer 2 The Darkening (Special Edition) (1996)

Python-Exoproject commented 3 years ago

There is a speed problem with this game. Here is the conversation so far:

Python Yesterday at 13:58

Been looking into the speed issue with Privateer 2 (Gameplay runs normal at 15000 cycles, but when a planet is in front of you in space it needs 175000 cycles.). I was thinking of it as the planets slow the game down but krc pointed out that for the era of the game (1996) its more likely that the game should be 175000 cycles and the majority of the gameplay is running too fast. He had a look and discovered that its a game issue, not a dosbox issue and that it has been patched previously by two different fan patches. The problem is that the fan-patches are for the windows version only.

The better of the two patches by HCL does a number of other things as well like deinterlace, fix mouse etc. In regards to DOS version he has said:

"Adapting these fixes to the DOS version would be possible, but technically would be more complicated due to DOS extender issues. It might be easier to tie the DOS EXE hacks to a specially modified DOSBox (been entertaining a few ideas on that regard).

So, short answer, right now these fixes are specific to the Windows version, but maybe there will be port to the DOS EXE sometime in the future."

The other patch is focused on the speed issue and gives some info on the problem:

"To all you hackers out there, this is how P2 works. It ran fine on my Pentium 200MHz back in '97, but is way to fast on any modern computer, so slowing down each frame is needed to make it playable. Hacking in a call to Sleep() at the end of each frame does the trick.

It uses DirectDraw, but only copies directly to the front buffer. There are three functions that do this: one for movies, one for the UI, and one for space combat. Movies already work because of the strict timing required. The rest of the game is typical of a DOS program...

The UI function copies the whole screen at once, so adding a call to the end of this function fixes it perfectly (the sound is fixed too!)

Space combat is different. The function only copies a small part of the screen, so the call to Sleep() had to be added to the main loop.

If it is too fast or too slow, try tweaking the values at 87D79h (UI, default 20ms) and 87D8Dh (space, default 30ms)."

Do you think kudgel that its something you could adapt to the DOS exe? Or maybe we can pass this off to ripsaw eXo and see what he thinks?

Heres HCL patch: p2_patch_test3.zip

Heres the other one: priv2_slowdownpatch.zip

kudgel Today at 02:38

This is probably something not too hard to fix If you guys think it can't be fixed with a cycle patch I can probably dig into some ways to make it frame-lock

krc Today at 02:39

My guess is there's a bunch of math-intensive code that's activated when the planet is in view; and it needs to run for every frame.

Also, the closer you are to the planet, the slower the frame-rate, so it's likely that the math code does even more work the closer you are: they probably have for-loops that fill in the textures.. and the closer you are, the bigger the area to fill in. The patch author tackled it from the angle assuming you're running on modern hardware (ie: who care about that slow math - you've got a faster modern system), as opposed to actually speeding up that math (which would be much harder to solve). On modern hardware, it rips through that bloated planet math - so the slow down isn't as apparent (which is similar to what we see in DOSBox going from 17k -> 175k cycles).

However, the game itself seems to run unthrottled (or somewhat unthrottled?), so that's why the patch author inserted the 30ms wait per frame. It throttles all aspects of game-play down to ~30 FPS. I suspect the delay has to be inserted inside the game's code itself.

I think if you can frame-lock the game itself (to 30 FPS or so), that would solve it. We would then be able to crank up the game's cycles on the dosbox side so the heavy planet code can also run at ~30 FPS, without any fear of other parts of game play going too fast (because they're locked at 30 FPS). Kind of like running an engine at 7000 RPM.. and riding the clutch and brakes as needed to never exceed 100 km/hr. Not the most efficient, but gets the job done!