Why not use the Windows version ? It is in SVGA, while the DOS executable shows lesser graphics (same quality as for C&C 1). Unless you have some reason to use DOSBox. I have Command & Conquer : The First Decade, and the 1.03 Unofficial patch fixes all the bugs : http://www.gamershell.com/download_ …

Well, with no more crashes and no more long full-queues-stops (frames waiting to be recorded >= 400), it's 99% fixed. I'll keep frameskip for the little unexplained (CPU usage != 100% or even 80%) little stops that happen when playing and recording at the same time. Thanks. 😉

that's an option to use if the emulation is too slow, isn't it ? Not my case. ;) My problem was a double one : video recording was in the same thread as emulation - second CPU core unused - (hence this thread that I found). And I had to use AviSynth to process the recorded videos with "ChangeFPS(10 …

Thanks wd. ^^ But don't mind my previous "fix". Crashes occured after a while if the player was actually playing, not staring. :D Besides, that "if(videohandle->q.size()>0)" was useless 'cause the loop says "while (!videohandle->q.empty())" However, I don't know how it made me record for so long . …

I *think* I have finally squashed that ever lasting crash bug that affected (since the beginning) my builds of your patch, kekko, if you allow me to say so ( ^^ ), with that if statement: int CAPTURE_VideoThread(void *videohandleptr){ [...] if(videohandle->q.size()>0) { free(videohandle->q.front(). …

Thanks Kekko for your patch, I will try that right away ('cause in fact, compiling with VS 2010 changed nearly nothing, despites my first few tests wich were unbelievably crash free) @Kisai : try 3D games (or even 3D fast racing games, like Screamer 1, 2, or Screamer Rally).

If someone has the same problem, wich is : PS : I am unable, in fact, to run multithreaded video capturing (let's name it MVC)-patched DOSBox I produced with VS 2008 SP1 without a crash soon after I started recording... =( [...] Somehow, compiling DOSBox with the multithreaded hardware.cpp patch and …

I was hoping to detect it fast enough (memory compare with rowPointer in hardware.cpp, or something). But all I did was garbage. Someone more qualified may find a way. Because, 2D games only use 10 FPS, or 15 for most recent 3D ones (Quake, Screamer Rally...). I don't want to change DOSBox 70 FPS …

that's fast with 320x200 games sure. But not that much with 3D games. Even with the multithreaded video capturing patch by kekko, 3D games (especially thoses in 640x400 / SVGA) hit the 400 waiting frames limit quite often during a recording (wich, every time, stops emulation for a few seconds). At …

zmbv already uses difference-encoding, so how much would additionally checking for unchanged frames help? mhh, it stills deflates (compress) it. Avoid compression and simply copy once again the previous same compressed frame (keept in memory), is the idea. Would it not speed up things ? It may have …

As we know, DOSBox outputs 70 FPS, in wich second there is a lot of frame that are the same, and follow each other. I have tried to avoid compressing the frame if it was the same as the previous frame (if it is, just use the old compressed frame). In order to achieve this, I have tried to keep the …

Thank you very much! A wonderful patch indeed! I had tried to hack it myself before checking back this thread, but I'm new to threads and DOSBox's source code, so it was very hard for me... Thank you again. =)

Thank you very much. =) I'm sorry I didn't see this thread when I searched multiple times if it had been already discussed. Was there some advance by the OP of the other thread since ? Anyway, I downloaded the OP's version of hardware.cpp, that makes it a starting point. 😁 Thank you again. 😉

Hello, :happy: Could it be possible to run the capture thread of DOSBox on the second CPU on dual core systems ? This isn't a request for multithreaded emulation, nor running video output on a second thread (wich would be, as I read it "a big pain"), but only for running the ZMBV + PCM capture …