I was using the recording feature for a while, but when you record from an external source (Roland MT-32), the sound goes out of sync. Something to do with how DOSBox does the recording.

I tried fraps (output has to be openglnb), but with this method you get sound stuttering. Nothing to do with PC performance, a game that runs in Full HD is no issue for fraps.

In the end I use the S-Video output from my Retro PC and record it via a S-Video to USB capture device. That way you have zero performance issues, even for SVGA games and you don't get any "music plays slower" slowdown effects.

Plus there is a real need for more "real vintage PC" recordings in YouTube 😁

Another thing you can do is play on one PC and use a HDMI frame capture card and capture DOSBox output onto that other machine.

Here is a S-Video > USB recording of Duke Nukem 3D in 640 x 480:

http://www.youtube.com/watch?v=wza5eXhKF4M

The Quality is average, but it's authentic (no emulation) and doesn't put any strain on the recording PC. It's MPEG2, so any P4 machine and later will handle it just fine.

And here are some 320 x 200 recordings:

http://www.youtube.com/watch?v=rOz3P3fZHq8

That's an interesting method, Maulwurf! Thanks for bringing it to my attention. And now that you mentioned it, I think it was this fraps that I meant by "some windows capture program". I haven't used windows as an operating system for a while and so I never tried out this program.

And you're totally right that YT could need a few more good recordings of dos games. I'm just done with my Witchaven video walkthrough there and it was really annoying that it often lagged badly...

Still I'm curious what others say about optimizing the dosbox part of recording.

Also there might be other versions / builds of DOSBox better suited for video recording with more demanding settings.

If found recording in 320 x 200 and with Sound Blaster option very reliable though.

If the lagging issue with fraps could be resolved, that would be great.

Because fraps has a lot of nice options, for example you can include the recording from an external sound source. E.g. commentary if you are doing a "let's play" video or from an external MT-32 module. It even has a push-talk function like on a walkie talkie, which can be handy for commentary.

There's an experimental multithread patch for recording here on the forum somewhere. As for recording uncompressed - a 1600x1200x8bit frame is roughly somewhat less than 2MB. Doing 24fps would mean 48MB/s...not impossible but big strain on the hard drives...

True, but AFAIK DOSBox uses some form of video compression. So the actual throughput requirements should be lower.

Another tip is to make sure your capture file is on another drive. E.g. if C is your main Windows drive, make sure the capture file is on D.

It's not recommended to capture with just a single HDD.

@Mau1wurf1977: I guess I'll have to find the build you mentioned and try to get it compiled then. I'm curious if it works well.

320x200 works extremely well, yes. I didn't notice any decrease in speed. Of course recording to a second drive is the way to go to split hdd access.

@gulikoza: Thanks! I'll be looking for it this evening. And 1600x1200 was just an example what I don't think anybody needs right now. But 640x480 or 800x600 would surely be nice.

gulikoza wrote:

There's an experimental multithread patch for recording here on the forum somewhere.

First I didn't find it as there are many threads here that contain keywords that fit my search, but I think I got it now. Should be this thread, shouldn't it?

Now that I read through it, I can only say that it's a cool thing and probably exactly what I was looking for. But the code has already been collecting a bit of dust since 2009 and I'm no coder myself. I'm using the SVN-build of dosbox which I can compile myself, but that's about all of what I can do. If anybody could point me to what I need to do to add its functionallity to my build? I don't think that just overwriting the hardware.cpp file of the current SVN source with the changed one from 2009 is a good idea, is it? And what about these changes that xcomcmdr did to it again? I'm a bit confused here. If somebody could lend me a hand on that, I'd be really happy. Don't want to ask kekko for help since he didn't participate in the thread for about one year and has obviously moved on (being occupied with voodoo chip emulation).

hi, this is my last version of hardware.cpp I could find.
Maybe it also contain some "unpublished" changes and I don't remember if they were stable enough or not.
There's only one way to find out.

You should be able to just replace current version of the file and rebuild dosbox.
I don't know what the modified versions on original thread do, though.

Thanks a lot, kekko! I'm glad that you still care for this patch as it is a true gift for those who want to record the oldies in high resolution.

I downloaded your hardware.cpp and replaced the original one with this version. Then I tried to compile the source again. Make gives me these errors however:

1make[4]: Betrete Verzeichnis '/home/michael/Downloads/dosbox/src/hardware'
2g++ -DHAVE_CONFIG_H -I. -I../..  -I../../include -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT  -g -O2  -MT hardware.o -MD -MP -MF .deps/hardware.Tpo -c -o hardware.o hardware.cpp
3hardware.cpp: In function ‘FILE* OpenCaptureFile(const char*, const char*)’:
4hardware.cpp:155: warning: format ‘%03d’ expects type ‘int’, but argument 6 has type ‘Bitu’
5hardware.cpp: In function ‘int CAPTURE_VideoCompressFrame(video_capture_t*, video_chunk_t)’:
6hardware.cpp:364: error: ‘TRUE’ was not declared in this scope
7hardware.cpp:407: error: ‘TRUE’ was not declared in this scope
8hardware.cpp: In function ‘void CAPTURE_AddImage(Bitu, Bitu, Bitu, Bitu, Bitu, float, Bit8u*, Bit8u*)’:
9hardware.cpp:618: error: ‘TRUE’ was not declared in this scope
10hardware.cpp:626: error: ‘TRUE’ was not declared in this scope
11hardware.cpp:631: error: ‘TRUE’ was not declared in this scope
12hardware.cpp:635: error: ‘TRUE’ was not declared in this scope
13hardware.cpp:641: error: ‘TRUE’ was not declared in this scope
14hardware.cpp:646: error: ‘TRUE’ was not declared in this scope
15make[4]: *** [hardware.o] Fehler 1

Ignoring the warning, I guess that the errors come from something that has changed in dosbox code in the meanwhile. Unfortunately I'm not familiar with cpp at all and don't even know what a 'scope' actually is. So if anybody could explain it to me or even knows a way to fix this, it would be great of course.

Try changing TRUE to true (lowercase) 😀

Thanks, gulikoza, this did the job! Didn't expect that it could be solved that easily... Guess it's the old problem of the windows platform being case-insensitive and the*nix one being sensitive. Annoying but I'm very happy that it compiled fine now.

And thank you very much, kekko, for this miracle patch... All my recording problems are history now and it seems that there are absolutely no desires left unfulfilled with it. Recording in 640x480 worked perfectly - and just so did recording in 800x600. There's absolutely no difference in how well the game runs (tested it with Blood). I'm quite sure that even higher resolutions are possible with this but I don't have any game at hand that supports them right now. 😀

Hey Kekko - looks like Taewoong liked your patch and put it into his SVN builds (with credit). http://ykhwong.x-y.net/

Works very well, even in non-Build games. Before I couldn't record System Shock in fullscreen mode at 640x480 without considerable framerate drop, but now it performs more or less as good as playing does.

Put DOSBox and game on ramdrive and capture on ramdrive avoiding hard drive as much as possible.