![]() ![]() This might all be early optimization, but the benefits are documented and measurable, and in theory this should be pretty easy to add to CHD (if we decide that CHD is the best fit).ĬHD already has a versatile metadata facility, but i agree about the double compression gotcha. ![]() We'd also want CHD it to support zero-compression blocks, so our Opus and FLAC files aren't double-compressed (we already take a latency hit decoding the audio content we shouldn't have to take a second hit just to get the encoded data). To minimize block decompression latency, CHD should use ZStandard compression, which is typically 10-fold (or more) quicker than LZMA at decompression. "Show me Sierra-developed titles released before 1992 that supported VGA and MT32".ĬHD version 5 is certainly a solid option for this, however per-block LZMA decompression can add significant latency (for example, using CHDs with PS1 emulation on an RPi3 requires the smallest CHD block size because larger block sizes introduce too much latency that it causes frame and audio stuttering). This would allow database-like querying on sets of games as well. CDROM content, including audio tracks in FLAC and/or Opus formats or whatever future best-in-breed formats we add to DOSBox.This feature will avoid needing multiple ROMs just to support tiny configuration variations. For example: EGA or VGA Adlib, SB16, or MT32. Configuration permutations, one or more sets of pre-configured canned config files, each paired with a Hardware requirements ticket, allowing the game to be launched under various supported configurations.Hardware requirements ticket used to configure the emulator running the as-bundled game, such as CPU type and speed, video mode, sound-card and configuration, MIDI type and configuration, mixer volume adjustments, joystick support, and so on.This area will be extensible and versioned, as the initial content might be thin, but allows the community to incrementally grow the metadata inside each game. Metadata about the game: name of the game, release date, game developer, publisher, screenshots, package materials (front/back box art), documentation and quick reference sheets, SHA checksums, and so on. ![]() ![]() We haven't defined this yet, but here's an example of this reserved content: Like CHD, the desired format will be a compressed filesystem inside of which sits the games' files and directories, plus a pre-defined reserved set of "domain-specific" content. We discussed some of this tangentially under #99, and and I have chatted offline about this too. There is collective interest in a " DOS games-as-ROMs" format, where a game's installation directory and dependencies (such as CDROM data) is bundled into a tidy and immutable single-file runnable by DOSBox and other emulators. Overall, it would be an advantage since there is finally a standard for compressed, thank you for the suggestion and looking at how to include this. It would be great if Dosbox could use the compressed CHD format for CDRoms. I begin in cdr_image.cpp for a LoadCHD and give up with Readsektor in Loadimage Routine (drive_iso.cpp). I use and code only in MingW on Windows without Debug Features like Visual Studio. I tried it myself but my skill in C ++ is not really good enough for that. There are already a lot of emulators that read compressed CD-Roms (ISO, BIN, CUE with Audio) in CHD format Container and the use the standalone version. At Github there is a stand-alone version of MAME CHD for the formats v1-5 ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |