DOSBox Feature Request Thread

General information and assistance with DOSBox.

Re: DOSBox Feature Request Thread

Postby junglemontana » 2019-10-08 @ 08:29

Kisai wrote:There is a feature in dosbox-x that should be backported to dosbox. OpenDML (AVI 2.0) avi support. I actually have a diff between r4000 and dosbox-x's files for that somewhere, but basically the issue is that if you're recording the video using the internal recording mechanism, if it hits the file size limit (2GB), the avi file is completely unusable. I originally worked around it just by having it stop and immediately restart the recording every X frames, which was more of a bandaid workaround than a true fix.

Unfortunately that diff is against an older version of dosbox, and not vanilla dosbox. Not a trivial change, but it touches the avi writer and wav writer in the process.


I agree that this would be useful. However, a modern format such as MKV would be even better.
junglemontana
Newbie
 
Posts: 39
Joined: 2019-2-16 @ 17:37

Re: DOSBox Feature Request Thread

Postby awgamer » 2019-10-08 @ 13:03

https://www.howtogeek.com/200736/what-i ... play-them/

>How Can I Play MKV Files?

>Because MKV isn’t an industry standard, not all media players support it..

Yeah, no.
awgamer
Oldbie
 
Posts: 568
Joined: 2014-7-26 @ 07:42

Re: DOSBox Feature Request Thread

Postby jmarsh » 2019-10-08 @ 13:44

Most DOSBox recordings need to be edited afterwards and there's not a lot of support for editing Matroska, plus the only way to store ZMBV data in it would be to use VFW codec mode which gives no benefits over AVI.
jmarsh
Member
 
Posts: 282
Joined: 2014-1-04 @ 09:17

Re: DOSBox Feature Request Thread

Postby Kisai » 2019-10-08 @ 15:58

jmarsh wrote:Most DOSBox recordings need to be edited afterwards and there's not a lot of support for editing Matroska, plus the only way to store ZMBV data in it would be to use VFW codec mode which gives no benefits over AVI.


I looked at this and other containers before and basically only VFW AVI is suitable to store dosbox data because it's frame-based. OpenDML just works-around the signed 32-bit file size (2GB) by just making additional indexes more or less. The dosbox-x code (at least 32-bit) seems to solve the "dosbox has overflowed the 2GB limit" by instead just making everything after 2GB quasi-playable (eg you can't seek to it, and ffmpeg can't read it past 2GB and assume it ends at 2GB.) Not really that much of an improvement, but better than the status quo which makes the entire video unusable the second it hits 2GB. So it's still buggy. I did however make an improvement to the original work around in this case

Note this is using the dosbox-x opendml code already applied, but this is essentially how I solve the file size limit
Code: Select all
      /* Everything went okay, set flag again for next frame */
      CaptureState |= CAPTURE_VIDEO;
      //Break AVI files at 1GB by resetting video stream
      //UINT64 maxvideosize = 0x3FF00000ULL;
       
      if ((uint64_t)capture.video.writer->riff->top->write_offset >= maxfilesizemb) {
         LOG_MSG("Reset of captured video due to over maximum video size.");
         goto skip_video;
      }
      
   }

   return;
skip_video:
   avi_writer_end_data(capture.video.writer);
   avi_writer_finish(capture.video.writer);
   avi_writer_close_file(capture.video.writer);
   capture.video.writer = avi_writer_destroy(capture.video.writer);
#endif
   return;
}


Basically telling dosbox to close the capture as soon as it's near 2GB (in this case I used 1GB just to make the file sizes more manageable) by a configuration variable. Because the flag isn't reset, Dosbox opens a new file at the next frame, thus no capture data is lost and is essentially identical to hitting the capture button twice at the end of the same frame.

Another thing that does need to happen, but this requires making a different change to dosbox that I haven't looked into, is to make sure that the video is properly closed when dosbox is closed, because that's the other reason why the video ends up unusable.
Kisai
Member
 
Posts: 126
Joined: 2010-5-05 @ 08:04

Re: DOSBox Feature Request Thread

Postby Akuma » 2019-10-16 @ 16:18

option (on/off) to automatically release the mouse cursor when entering debugger.
now i have to press, debugger hotkey and then ctrl+f10 to get my mouse back.

thank you :D
Akuma
Newbie
 
Posts: 55
Joined: 2019-7-24 @ 14:47

Re: DOSBox Feature Request Thread

Postby collector » 2019-10-16 @ 23:57

Or just set autolock to false.
User avatar
collector
l33t
 
Posts: 4384
Joined: 2003-1-15 @ 10:39

Re: DOSBox Feature Request Thread

Postby Akuma » 2019-10-17 @ 11:31

Yeee, fastest implementation yet :D
Akuma
Newbie
 
Posts: 55
Joined: 2019-7-24 @ 14:47

Previous

Return to DOSBox General

Who is online

Users browsing this forum: No registered users and 1 guest