DOSBox is single-threaded, and with heavy games like Build Engine at higher resolutions the speed tends to suffer when you add the load of video capture.

Some tinkering was done to move video capture into a separate thread, but I'm not sure about the current usability of any patches because they aren't actively maintained.

Multithreaded video capturing
Lightweight multithreaded video capturing patch (was: dynamic core crashes video recording)

By latest version of DOSBox do you mean 0.74-2?
Monitor your cpu usage while recording.
Post your .conf

I'd recommend using a dedicated capture tool instead.

ripsaw8080 wrote:

DOSBox is single-threaded, and with heavy games like Build Engine at higher resolutions the speed tends to suffer when you add the load of video capture.

Thanks Ripsaw. That's helped me make sense of what might be going on here. I'm still going through your links.

DosFreak wrote:

By latest version of DOSBox do you mean 0.74-2?
Monitor your cpu usage while recording.
Post your .conf

So far I've tried DOSBox 0.74-2, 0.74 and an older version just to make sure there wasn't anything strange going on with the newer releases. I had the same result for all versions. I've looked at my CPU usage and it doesn't appear strained from what I can tell.

Please find my .conf (in this case for Blood) attached. Hopefully you spot something obvious. I'm not a wizard when it comes to .conf files.

realnc wrote:

I'd recommend using a dedicated capture tool instead.

It may yet come to that, but it's nice that I get the raw videos from recording in DOSBox, so I want to give this a fair chance before I fall back to another solution.

Thanks for all your help so far!

Silent Supporter wrote:

I've looked at my CPU usage and it doesn't appear strained from what I can tell.

Sorry if you're already doing this, just wanted to make sure that you're looking correctly at CPU usage: As per ripsaw8080's comment you should check if a single core-logical CPU gets near 100% usage. I mean, if you have 10 "CPUs" and 1 is at 100%, you'll see a 10% usage when you open task manager, thinking that you are nowhere limits. You don't need any special tool to check this, in task manager go to "performance tab", right click on the CPU graph and instead of the "overall utilization" select "logical processors". Again sorry if I'm just wasting your time reading this

Thanks Konc. I couldn't find exactly the option when right-clicking. Is it maybe a Windows 8 or 10 feature? I'm on Windows 7 64-bit.

Regardless, this might be useless, but I took three separate screenshots. The one on the far left is while 'idle', the one in the middle is while DOSBox is open and the third is during recording.

Note that I do have a browser and some work related things open at this time, though the slowdowns and such I've encountered have taken place while I've closed all non-essential programs.

Thanks again, let me know if I've completely misunderstood you here.

Here's a video showing the drop in performance. Note the frame rate at the top right. Warning: the file's about 38 megabytes:

https://we.tl/t-cMyAGEF5eg

The irony isn't lost on me that I'm using a third party recording tool to show the loss of frames while using DOSBox's internal recording.

I need to step out for a moment, but will continue reading and catch up when I return.

Silent Supporter wrote:

Specifically, I am encountering tremendous loss of performance when I try to record in Shadow Warrior and Blood, both Build Engine FPS games, when I set their resolutions to 800x600. They play perfectly well if I record at 320x200, and play very well at 800x600 when I'm not recording.

If you set it to 800x600, it will record 60fps directly to the video file because that's the mode it's in. You should probably use a Windows port of build engine if you want to capture video using a dedicated capture tool or something like OBS. If you play a game in 320x200, it will record at 320x200 even if the dosbox window is set to any other size. The problem is ZLIB is slow, and can not be threaded, since all lossless codecs can't "skip" frames, lose a bit of data, and the entire video is hosed.

Dosbox's capture frame-cycle is more or less perfect. If you set a game to 800x600 and it ends up with a frame rate of 15fps, it may still have a 60fps video in the output. The trouble is that a game will more or less be unplayable if it is not drawing at 60fps. I've done a lot of tests with ZMBV with youtube and video editors, and essentially ZMBV is unseekable (see the data loss issue above) when used as a recompression codec. Only the data that comes out of dosbox ZMBV (in 8 bit color) retains the original compression. I modified Dosbox several different ways to tweak the compression before and there's really nothing that can be done within dosbox for video capture unless your intent is to capture a cycle-accurate video (Eg demoscene stuff) and even then dosbox does not emulate a cycle-accurate machine, it emulates a DOS environment without any regard for cycle accuracy. That is good enough for all but the earliest PC games since CPU power was highly variable after the 286.

If you're hellbent on using the built in dosbox zmbv compression, you're going go want to get a CPU with high single-thread performance like a Intel Core i9-9900K or Intel Core i7-8086K and unfortunately there's not enough performance gap to warrant a CPU upgrade just for dosbox, at most, upgrading from a 3-5 year old Haswell system with DDR3 gets you 10-15% more CPU power with a current generation CPU and DDR4 memory.

I'd suggest using either nVidia's built in video game DVR tools or straight up use OBS and go with the lossy compression if you're doing any "3D" gaming. 2D content often compresses super-well with ZMBV because most of the screen doesn't change, where as a 3D game does, and that's why the performance tanks.