VOGONS

Common searches


First post, by kraileth

User metadata
Rank Newbie
Rank
Newbie

Hi everybody!

I've been recording quite some videos lately using dosbox so I might well say thanks for providing this feature at all! Apart from the occasional graphic glitches it all works fine. At least for low resolution games. But I ran into a problem with higher resolutions. Now I wondered if there's perhaps a way to optimize things? The wiki article about video recording is not too detailed to say the least and I also didn't find a topic about what I'm looking for in the forum, so I thought I'd start a new one. Please don't bash me just now - I already did apply standard conf optimizations and stuff. 😁

What this thread is about is collecting ideas of what could be possible. If somebody knows of a nice way to help me improve performance now, I'd of course be happy, but I've become interested in how things could be improved in theory, too.

Now the thing is, when I try to record a game in 640x480 mode - let's say any build engine game like duke3d - the performance is really low and the game becomes laggy. Playing in 800x600 while recording is totally unplayable.

I'm on a Intel i7 2.8GHz machine with 8GB or ram running Ubuntu maverick 64-Bit. Now this pc should be strong enough to properly emulate dosgames and record videos in resolutions higher than 320x200/240 but with only one core used, it isn't. What could be done about that? I had a few ideas of what could be tried but I'd really like some thoughts on it be people who know more about it...

1) Coding in virtualization to speed up emulation on the same platform. Yeah, I know, this is a "if you want it, do it yourself"-type thingy and it's not going to happen anytime soon. But I wanted to list it, too, because it is rather obvious. And apart from it not being in dosbox - can anybody estimate how much of a boost this would actually be on a pc platform? I'm just curious.

2) Adding multithreading support to dosbox so that the recording could have it's own core. Same thing as for 1), I guess. Won't happen but would be of great help in this case as the game runs fine without recording, wouldn't it?

3) I'm not a person with coding skills reaching above doing a lot of quickbasic and a little pascal with DOS 6. But as far as I know dosbox uses a zip-like codec to keep the videos a bit smaller. I've read somewhere that a well known recording software for windows (forgot the name, though) saves it's videos uncompressed. Now as disk space is usually not an issue today, I thought about disabling compression for the dosbox videos. And while I don't know if this is possible with dosbox at all, I wonder if it would increase performance. Does anybody have an idea how cpu intensive dosbox's video codec is and how much of a difference it would make to record uncompressed? The increased amount of data (it's only 800x600 or 1024x786 and not 1600x1200 or something) to be written on the disk should not be a problem with todays harddrives, should it?

4) I created a dual-boot on my machine with a second os just for my recording. The idea was to get rid of any process that I don't need to give dosbox as much cpu as possible. Now I wonder: Is there any os "best fit" for dosbox? That it's a cross-platform program doesn't mean that it runs equally fast on each system. Or am I wrong here? If no: What system should be recommended to gain the best performance possible?

5) If linux is not a bad choice (see 4)), could performance be improved by using some special means like using a low latency kernel? Could it be worth the effort to compile dosbox yourself, say on a Gentoo system, optimizing everything for your machine?

6) Forgetting about the possibility to speed up programs by compiling them for your specific machine, what about creating a live-cd "emu-os" that's totally optimized for dosbox purposes? Can anybody think of any optimizations on system level that would make this possible (or rather reasonable)?

Now this is just some random thoughts. Please feel free to add anything you can think of about this topic. It doesn't need to be "practical" right now or in the near future. Some dreaming also doesn't hurt anybody and sometimes can be inspiring to somebody else.

Reply 1 of 13, by Mau1wurf1977

User metadata
Rank l33t++
Rank
l33t++

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

Reply 2 of 13, by kraileth

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 3 of 13, by Mau1wurf1977

User metadata
Rank l33t++
Rank
l33t++

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.

Reply 4 of 13, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

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...

http://www.si-gamer.net/gulikoza

Reply 5 of 13, by Mau1wurf1977

User metadata
Rank l33t++
Rank
l33t++

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.

My website with reviews, demos, drivers, tutorials and more...
My YouTube channel

Reply 6 of 13, by kraileth

User metadata
Rank Newbie
Rank
Newbie

@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.

Reply 7 of 13, by kraileth

User metadata
Rank Newbie
Rank
Newbie
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).

Reply 8 of 13, by kekko

User metadata
Rank Member
Rank
Member

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.

Attachments

  • Filename
    hardware.cpp
    File size
    28.7 KiB
    Downloads
    94 downloads
    File license
    Fair use/fair dealing exception

Reply 9 of 13, by kraileth

User metadata
Rank Newbie
Rank
Newbie

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:

make[4]: Betrete Verzeichnis '/home/michael/Downloads/dosbox/src/hardware'
g++ -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
hardware.cpp: In function ‘FILE* OpenCaptureFile(const char*, const char*)’:
hardware.cpp:155: warning: format ‘%03d’ expects type ‘int’, but argument 6 has type ‘Bitu’
hardware.cpp: In function ‘int CAPTURE_VideoCompressFrame(video_capture_t*, video_chunk_t)’:
hardware.cpp:364: error: ‘TRUE’ was not declared in this scope
hardware.cpp:407: error: ‘TRUE’ was not declared in this scope
hardware.cpp: In function ‘void CAPTURE_AddImage(Bitu, Bitu, Bitu, Bitu, Bitu, float, Bit8u*, Bit8u*)’:
hardware.cpp:618: error: ‘TRUE’ was not declared in this scope
hardware.cpp:626: error: ‘TRUE’ was not declared in this scope
hardware.cpp:631: error: ‘TRUE’ was not declared in this scope
hardware.cpp:635: error: ‘TRUE’ was not declared in this scope
hardware.cpp:641: error: ‘TRUE’ was not declared in this scope
hardware.cpp:646: error: ‘TRUE’ was not declared in this scope
make[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.

Reply 11 of 13, by kraileth

User metadata
Rank Newbie
Rank
Newbie

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. 😀

Reply 12 of 13, by Good Ol' TarviS

User metadata
Rank Newbie
Rank
Newbie

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.