don't be a fool

Dosdox 0.61 emulates 80486

Pivateer 2 The Darkening needs Pentium 60

you might get it runable, but it won't be playable yet!
I understand you, I've tried it too, because its a great Game
I've tried on 2600 xp with 20000 cycles! The intro (video) crashed every time!
🙁
Sorry, I hope in Future it will be playable

Actually IIRC Privateer II requires 80 Mhz not 60 which makes it even more of a streatch for DosBox.

However, more importantly Privateer II can be run in Windows 95/98/ME/XP. You need the windows patch that can be found at http://www.wcnews.com/files.shtml. I have the Deluxe Edition which is a windows version but suffers from speed issues and it runs fine with the speed patch (also on wcnews).

the patch doesn't work, if tried it before

I'v searched alittle more

http://originalthp.solsector.net/privateer2win95/

Try this!

It works perfect! 😁 😁

Hmm, if I checked the readme correctly from the patch at wcnews files section, the link you gave is the homeptach for that patch 😖
The only diff is: at the homepage you get a detailed instruction on how to use it and what to do if things go wrong...

I know this thread is from the stone age, but it comes up when I searched for a solution for this game not running in dosbox, and now that I found the solution I thought I'd post it here in case anyone else also lands here through a web search:

The dynamic core does not work with this game, even though it's a "modern" protected mode DOS game from 1996. The game needs:

1core = normal
2cycles = fixed 15000

Unfortunately, the 2D sections of the game run too fast if you set cycles too high. 20.000 is already a bit too fast. But the 3D sections can need more cycles. This game requires a Pentium 60 as minimum and recommends a Pentium 90. Normally that would mean you'd use a cycle count somewhere between 70.000 and 100.000. But that would make the 2D parts and most 3D parts completely unplayable.

I remember playing this game back when it came out on my Pentium 133, but I don't think it had this issue. Seems to be a dosbox problem?

Sounds like the common problem with games that mix 2D and 3D modes, due to the instruction timings not being very accurate (all instructions are treated as taking one cycle, no matter what they do). Syndicate Wars is another game with the same problem (map/mission screens too fast, gameplay too slow).

What build did you use to test the dynamic core? If it was SVN I can investigate to see why it's failing (and may give better 3D performance with lower cycle counts).

The game works for me with default settings (auto-switch to dynamic core in protected mode), and with the core=dynamic setting, in DOSBox 0.74-3 and SVN. Tested with installed game version 16.0 and 17.0e patch. I am using Windows, so perhaps any issue with dynamic core is specific to certain platforms.

The game has noticeable framerate irregularities depending on what is being displayed. In 3D flight the framerate varies considerably between empty space and a planet in view. From what I can tell, the irregular framerate is caused by the absence of any form of stable limiting. For example, the 2D interface would have virtually perfect speed if the game simply waited for retrace before flipping the display page, but there is no such limiting. It seems that frames are always displayed as quickly as possible, with the only limit being the speed of the system, which is of course not a stable limiter. Unfortunately, framerate limiting has to be baked into the 3D engine and cannot be imposed externally with satisfactory results.

ripsaw8080 wrote on 2022-06-13, 12:03:

The game works for me with default settings (auto-switch to dynamic core in protected mode), and with the core=dynamic setting, in DOSBox 0.74-3 and SVN. Tested with installed game version 16.0 and 17.0e patch. I am using Windows, so perhaps any issue with dynamic core is specific to certain platforms.

Yeah, I'm on Linux. I just tested the Windows version of DOSBox (svn) and it works fine. It's only Linux that hangs (with 100% CPU load.)

The speed issue is just weird, especially since the game itself really recommends a Pentium 90, and I *think* I remember it running fine on my P133. But since that was 25 years ago, I might also be tripping. Need to find someone who still has access to an actual MS-DOS machine of that time.

I just noticed that the game does actually do something related to vblank. If you increase vertical total in src/hardware/vga_draw.cpp, like force it to a fixed value with:

1- fps=(double)clock/(vtotal*htotal);
2+ fps=50;

The game behaves a bit more normal. For example the animation speed in the start of the game where that dude is banging his head against the wall stays almost the same regardless of whether you hover the mouse obove the laser beams or not. Normally, the animation slows down a lot when the mouse is on the lasers and speeds up a lot when moving the mouse away.

In games that don't do vsync, increasing vtotal does nothing. But here it clearly has an effect, so it appears this game actually does something that's tied to the vblank period.

The attached DOS TSR program forces waiting for retrace before page flips. When used in DOSBox it makes the game's 2D interface speed pretty much what you'd expect -- note in particular the map screen with the animated mouse pointer and how the animation spins sedately instead of wildly. It also limits the 3D flight framerate to the refresh rate, but this is suboptimal and causes jerky motion because it *wastes* CPU cycles waiting for retrace when the game should be spending those cycles in rendering further frames, which goes back to my previous comment about how framerate limiting has to be integral to the game engine and can't achieve satisfactory results when done externally.

Yep, thanks. TSR works exactly as you described. Even with the 3D choppiness, It's an improvement overall, I think.

ripsaw8080 wrote on 2022-06-13, 18:16:

The attached DOS TSR program forces waiting for retrace before page flips.

I just tested this TSR with Screamer 2 (which also doesn't vsync) and it works there as well! This is pretty great. What does the TSR do exactly?

I'm gonna find some other games that don't vsync and see in how many of them it works.

This real-mode VBE function is used by some games for page flipping: http://www.delorie.com/djgpp/doc/rbinter/id/83/2.html
The TSR watches for "top of window A" calls, waiting for retrace before letting them proceed -- a feature that VBE does not provide.
In theory it would work for any game that uses the specific function (SkyNET, Tie Fighter CD-ROM, et al.) However, there are other VBE functions that can be used for page flipping, and they have a built-in feature to wait for retrace.

i have the same speed issues in space

here smb suggested to change the vmemdelay value (with dosbox-x)
Privateer 2 slow down in space

it helped a bit.
with pcem it runs without the slow downs in space

K.A.R.R. wrote on 2022-06-18, 17:17:

with pcem it runs without the slow downs in space

I just installed it in PCem with an emulated Pentium 133MHz (which is the machine I originally played it on back then.) It doesn't have any of the issues there. The 2D animations don't suffer any speedup whatsoever, and the pace of the 3D rendering is way better. This is pretty much how I remember this game running.

So this game appears to be very sensitive to exact hardware timing.

wonder why it runs perfect with pcem but has some issues with dosbox

i have to do some more testings with the vm settings in dosbox-x
to see if it can be improved

https://github.com/joncampbell123/dosbox-x/wi … OSBox%E2%80%90X