Hi all and a big thanks to
Codeholio for working on DosBox-X all these years.
I'm in process of migrating from old DosBox-Daum builds to DosBox-X and am a bit confused regarding the proper ways to do it. Looks like documentation on DosBox-X is scarse (except for source code) so some things end up not that clear for a newcomer.
I'm a linux system engineer and devops but my main home gaming PC runs Windows 10 as that's the only way to get Steamlink and nVIDIA Shield streaming to work properly. Thus I'm forced to use windows build of DosBox-X - which there are many.
Quick looks reveals what appears to be all possible permutations between MSVC++ vs MinGW, 32bit vs 64bit and SDL1 vs SDL2 with additional "twists" to mingw builds having "lowend" and "sdldraw" flavours.
This brings us to my first set of questions:
- Are there any major differences between 32bit and 64bit builds? I believe I’ve read somewhere that 32bit builds might be somewhat faster due to smaller memory footprint resulting in smaller active set having more chances to stay in CPU cache. Is that the case?
- I’ve heard that it is impossible to use dynamic core with 64bit build for DPMI/VCPI guest programs while for 32bit build dynamic core is OK to use with DPMI or VCPI guest processes as long as they are not messing up with virtual memory and do not use paging. Is it true?
- As for SDL1 vs SDL2 builds: am I correct that SDL2 build it considered to be experimental and is still under heavy development so it is not a good idea to use it unless one want to participate in beta testing? What about the general direction of DosBox-X development, is it going to move to SDL2 as a main supported backend and move SDL1 into deprecated/obsolete status?
- What are “lowend” and “sdldraw” builds for? Am I correct that “lowend” build lacks mt32 emulation and Direct3D 9 output backend? As for “sdldraw” - I’ve got no idea what differs here compared to “normal” MinGW build.
- Comparing MSVC builds vs MinGW I can see that a file named “FREECG98.bmp” is included with MSVC builds but is missing from MinGW builds. Is it expected? What is this file being used for?
- I had compared available output backends for all available MSVC and MinGW builds. It looks like for SDL2-based builds the only options available are “surface”, “overlay” and “ddraw”. For “sdldraw” build “opengl”, “openglnb” and “openglhq” join the available club. Same list of six variants is available for all other MinGW builds and lastly in SDL1 MSVC build “direct3d” joins the club. Is it an expected situation when Direct3D output backend is only available in MSVC builds?
Now, to a more fun part of configuring and using DosBox-X.
- Vsync mysteries. Looking at the generated “all options” config I can see a section named “vsync”. I presume that this section controls emulations of vertical retrace notification for the guest system. There is a remark in comments about “calibration with dosbox” - what is this about? What calibration? For what vsync mode? Then, what’s the difference between the modes? What does “force” mode do? Talking about vsync I really have got a “testing bonanza” with my setup. My main monitor is a G-SYNC enabled 144Hz flat panel and quick testing using “teartest.exe” utility reveals all kinds of weird DosBox behavior depending on the output backend (OpenGL vs D3D), G-SYNC state, active monitor refresh rate and the state of the “vertical retrace” setting in nVIDIA control panel. Testing all permutations here is a huge separate topic by itself so I would probably start up a separate thread for that. Still I’d like to know more about what’s actually happening under the DosBox-X hood depending on the “vsync” option state.
- 3dfx support. From what I see I assume that “voodoo” equal to “software” enables software emulation of the SST-1 chip – one that Kekko initially had been working on. It seems to be working more or less fine (tested with DOS version of GTA1 + original glide2x.ovl from 3dfx) but compared to what was available in DosBox-Daum build it seems to be lacking “voodoomem” option which allowed to select what card to emulate – original Voodoo Graphics or Voodoo2 with 12MB VRAM and 2TMUs. Am I correct that this option hadn’t been implemented (or had been dropped) in DosBox-X?
- 3dfx support – again. Setting “voodoo” to “opengl” seems to do something strange. In DosBox-Daum version “opengl” value enabled what was know as “gulikoza’s patch” allowing to pass all glide2x calls from guest to host system using special glide2x.ovl version. On host glide2x calls could be handled either by the real 3dfx hardware or by any available glide wrapper. For DosBox-X it seems to be different. Gulikoza’s glide2x.ovl does not work with DosBox-X – games fail to detect 3dfx hardware. Drive Z does not contain any glide2x.ovl to be used with the game. Providing the game with original 3dfx’s overlay binary results in game working but for GTA rendering seems to be broken a bit – parts of UI and text messages are rendered as single color outlines. What is going on? Am I correct with a speculation that “voodoo=opengl” mode in DosBox-X is essentially the same as “voodoo=software” mode with both using SST-1/2 emulator by Aaron Giles with the only difference being that for “opengl” original DosBox rendering contex is being passed to emulator to speedup rendering?
Thanks once again for working on DosBox-X and thanks in advance for answering my questions above.