[Thread moved to DOSBox General Section]

So, I just wonder, how difficult would it be to port the existing code for the Voodoo 2 and IDE emulation from jDosBox to a normal build of DosBox? Like you mentioned before, this would open the doors for running all sorts of different games.

One thing I would like to point out though, DosBox does not actually ship with FreeDOS. I believe the emulated version of DOS in DosBox has some of its sources derived from FreeDOS, but it's primarily its own thing.

Another thing too, there are a LOT of Windows games that don't work properly on NT-based operating systems, so even if ReactOS were included, it still wouldn't be of much help for most Windows users such as myself. What I think we need is some sort of open-source Win9x replacement that could potentially be designed with DosBox's emulated hardware in mind.

You've got some great ideas though, and I would love to see them implemented in a future build of DosBox.

mr_bigmouth_502 wrote:

Another thing too, there are a LOT of Windows games that don't work properly on NT-based operating systems

I've tested quite a few and haven't found as many, I'm curious to see some examples. I've also found that usually the problem doesn't really lie with the NT kernel itself, but the game's installer or the video card and its drivers, along with the way the game accesses CD audio playback (usually solvable with _inmm).

AFAIK there's no separate V2 code, it's all in kekko's patch...however it might not be enabled by default.
The same goes for IDE code, it's the same code as in ykhwong's version except for the part where the IDE device does not work in Win9x. If you can find the bug, you're welcome to post a fix (the post here would suggest that the problem is in BIOS code and jDosBox has solved it by loading BOCH's bios).

It would be SO typical that whatever I do to hack old games to work on new systems, dosbox does better a few years afterwards..

truth5678 wrote:

There are the two major emulators with robust DirectX support for gaming, VirtualBox and VMware.

There is much enthusiastic support for Wine, particularly in Linux, but I also seem to be reading a lot of success stories about using the WineD3D DLLs to get older Windows games running.

By my measure, VMware is the best emulator for Windows gaming, but it is not open source, not portable, and there is no guarantee it will support future operating systems. This solution is not tailored for gaming, significantly more difficult to setup and maintain than DosBox, and requires a license for a supported Windows operating system.

Do you think running Win9x in DOSBox does not require a license for a "supported" Windows operating system? That is advantage of Wine.

well, in my test builds I boosted v1 memory up to 12mb (4mb front buffer, 4mb x 2 texture units).
Voodoo1 never mounted so much memory, but architecture and drivers (shared with v2+ cards) supported these figures.
I ran flawlessly 1999 games like quake3 and unreal tournament in 800x600 with texture quality at max;
I guess it would even run 2001 games like serious sam, but I never fixed my mmx patch.

I can vouch for Wine in Linux. It plays a hell of a lot of games you mention fine and even windows Xp/7/8 struggles to run without major patches/ACT fixes. Star Trek New Worlds/Wipeout/Exreme XG2 are games that spring to mind

kekko wrote:

well, in my test builds I boosted v1 memory up to 12mb (4mb front buffer, 4mb x 2 texture units). Voodoo1 never mounted so much […]
Show full quote

well, in my test builds I boosted v1 memory up to 12mb (4mb front buffer, 4mb x 2 texture units).
Voodoo1 never mounted so much memory, but architecture and drivers (shared with v2+ cards) supported these figures.
I ran flawlessly 1999 games like quake3 and unreal tournament in 800x600 with texture quality at max;
I guess it would even run 2001 games like serious sam, but I never fixed my mmx patch.

Wow, that would be a perfect Windows 98 setup since the texture memory would increase by 3-fold along with the higher resolution. Even without the fully implemented MMX extension, it was enough to bypass the check in installing DirectX8. I don't recall any MMX check for DirectX7. It does constrain certain DosBox compatibility to about year 2000 for the non-glide, non-opengl 3d games. I am also optimistic for other titles running since Quake3 requires an MMX CPU and 16mb of video RAM, yet it runs without error. If you pick up the MMX project again, however, please let me know if I am able (and capable) to help in debugging.

Your work is brilliant. And thank you for the helpful information! I will recompile with the proper parameter value.

I'm eager to see if the glitches in Rainbow Six are solely caused by low memory; also, there is a small possibility that Warcraft 3 will run without a previously observed error.

Notwithstanding the boundaries of emulation in terms of speed and memory, I believe the Windows gaming compatibility list with an expanded Voodoo1 will be very encompassing.

gulikoza wrote:

The same goes for IDE code, it's the same code as in ykhwong's version except for the part where the IDE device does not work in Win9x. If you can find the bug, you're welcome to post a fix (the post here would suggest that the problem is in BIOS code and jDosBox has solved it by loading BOCH's bios).

That appears to be a straightforward fix, thank you for replying and for your insight! I will look further into this problem.

kekko wrote:

well, in my test builds I boosted v1 memory up to 12mb (4mb front buffer, 4mb x 2 texture units).
Voodoo1 never mounted so much memory, but architecture and drivers (shared with v2+ cards) supported these figures.

Those are the specs of the Quantum3D Obsidian 50-4440.

truth5678 wrote:

Wow, that would be a perfect Windows 98 setup since the texture memory would increase by 3-fold along with the higher resolution […]
Show full quote

kekko wrote:

well, in my test builds I boosted v1 memory up to 12mb (4mb front buffer, 4mb x 2 texture units). Voodoo1 never mounted so much […]
Show full quote

well, in my test builds I boosted v1 memory up to 12mb (4mb front buffer, 4mb x 2 texture units).
Voodoo1 never mounted so much memory, but architecture and drivers (shared with v2+ cards) supported these figures.
I ran flawlessly 1999 games like quake3 and unreal tournament in 800x600 with texture quality at max;
I guess it would even run 2001 games like serious sam, but I never fixed my mmx patch.

Wow, that would be a perfect Windows 98 setup since the texture memory would increase by 3-fold along with the higher resolution. Even without the fully implemented MMX extension, it was enough to bypass the check in installing DirectX8. I don't recall any MMX check for DirectX7. It does constrain certain DosBox compatibility to about year 2000 for the non-glide, non-opengl 3d games. I am also optimistic for other titles running since Quake3 requires an MMX CPU and 16mb of video RAM, yet it runs without error. If you pick up the MMX project again, however, please let me know if I am able (and capable) to help in debugging.

Your work is brilliant. And thank you for the helpful information! I will recompile with the proper parameter value.

I'm eager to see if the glitches in Rainbow Six are solely caused by low memory; also, there is a small possibility that Warcraft 3 will run without a previously observed error.

Notwithstanding the boundaries of emulation in terms of speed and memory, I believe the Windows gaming compatibility list with an expanded Voodoo1 will be very encompassing.

gulikoza wrote:

The same goes for IDE code, it's the same code as in ykhwong's version except for the part where the IDE device does not work in Win9x. If you can find the bug, you're welcome to post a fix (the post here would suggest that the problem is in BIOS code and jDosBox has solved it by loading BOCH's bios).

That appears to be a straightforward fix, thank you for replying and for your insight! I will look further into this problem.

Quake III only requires 4mb of video ram. I actually used to run it on a 266MHz Pentium II with a Riva 128. It didn't run as well as I would've liked, but it was definitely playable.

Q3A patch 1.30+ does demand more vram though because it precaches a LOAD of new crappy explosion textures you don't even normally see.

leileilol wrote:

Q3A patch 1.30+ does demand more vram though because it precaches a LOAD of new crappy explosion textures you don't even normally see.

I never knew that, but yeah, the only version of Q3 I ran on that box before I upgraded the video card was the test demo. I probably should've clarified that.

That explains why it stopped working on a PII I was using after a format, I decided to patch it but never thought of that.

bloodbat wrote:

mr_bigmouth_502 wrote:

Another thing too, there are a LOT of Windows games that don't work properly on NT-based operating systems

I've tested quite a few and haven't found as many, I'm curious to see some examples. I've also found that usually the problem doesn't really lie with the NT kernel itself, but the game's installer or the video card and its drivers, along with the way the game accesses CD audio playback (usually solvable with _inmm).

The only specific examples I can think of is in regards to copy protection or 8-bit color depth requirements.

Ultima 9 (retail, not gog.com) copy-protection scheme that fails to work on all versions of Windows NT. I believe this was some version of safedisc. (Here's you main argument against DRM 😀) Likewise some games if played on Win95 OSR2/Win98 would fail disc-based copy protection tests that passed on Win95.

As for color-depth problems, I know this does show up with Starcraft. You're pretty much unable to play the game without some registry tweaking, and even then you're unable to window it without additional hacky tools. There are also other win98-era games that do work on Windows NT, but are unable to cope with some fancy driver settings (QFG5 is unplayable with Morphological filtering enabled, but can be fixed.)

The only other reason I could think for trying to emulate win95/98 with dosbox is specifically play or record a 256 color game while having access to their host operating system. Old versions of VMWare used to be able to emulate a win9x class machine, and no longer do so.

If the game works in 16-bit or 32-bit color mode, there's usually no reason for it not to work.

I do remember playing U9 on Windows XP but that could have been with the last inofficial patch that did away with the protection.

Discworld Noir is another game that refuse to work on NT Windowses, it only works on 9x, because of DRM. Very annoying. Hope ResidualVM will support the game at some point in the future.

gulikoza wrote:

kekko wrote:

Thank you again for the guidance. I compiled your code via Daum's build along with your enhanced Voodoo1! It was amazing to behold - the 800x600 resolution looked great in both OpenGL and Direct3D games. There is also a slight speedup if GLQuake is any measure of the difference between the regular and enhanced Voodoo. I did notice a significant speedup in NOLF and Rainbow Six, even at higher resolution. I had no such luck with Warcraft 3, but that difficulty likely lies elsewhere in the DosBox code base. However, it is no small feat to run Unreal Tournament and Quake 3 in DosBox, too! Also, the 2d games run without issue, such as Starcraft and Warlords3, and I have yet to find a game that doesn't from their cohort. As an additional advantage, there appears to be no mouse lag in these games under DosBox which is experienced in other methods of emulation. It's now apparent, as you kindly revealed earlier, that the Direct3D8 games will not yield easily; this for many reasons, including speed, CPU extensions, memory, and DirectX compatibility.

NOLF and Rainbow Six had higher framerates and resolution. But NOLF was still missing textures from the environment and Rainbow Six had vertical lines across the right side of the screen. There are reports of these problems from the physical Voodoo1 card, but I am hopeful that these may be easily fixed via the code base. NOLF represents the Lithtech 3d engine and Rainbow Six's is also used in Rogue Spear and the many expansion packs. At least it is now confirmed that these issues are not related to texture memory size. 😀

I am hopeful that there is source code for the glide2x_emu.ovl file, and wondering whether it is crucial for the video hardware acceleration. If it is available, then that is good news because it shows that this code base will always be portable. The early Windows games, arguably more valuable than the current batch which largely favor graphics over sophisticated gameplay, would last in perpetuity (and hopefully, too, the large manuals accompanying games like Falcon3 and Fallout). Otherwise, we would be left to luck on whether future operating systems are fully compatible with older games; and also that the companies supporting VMware and VirtualBox continue to thrive. This has been mentioned in other posts and is an important lesson in the history of technology, that of unplanned (and perhaps occasionally planned) obsolescence.

On dozens of attempts to compile Daum's build of DosBox, I learnt the wisdom of the words by "wd". Using many dependencies or ones that are dependent on other libraries leads to difficulty in maintaining an important software project. Even from the perspective of a single operating system, the versions of the dependencies and the compilers change over time. As these difficulties compound, then the number of possible ways to solve them becomes very large and uncertain. If anyone has difficulty in compiling the major versions of DosBox, then I can try to answer in this thread while my memory is fresh from these experiences.

I used the freely available Visual Studio 2010 Express Edition without much difficulty, although the recommended version for Daum's is 2012. It did require a change to the sln file to reflect version 11 instead of 12. Likewise, the platform setting inside the compiler must be set to 100 instead of 110. I'll enumerate the larger stumbling blocks on compiling Daum's build, although these emerged for the most part from the dependencies and not the dosbox code itself. I removed the fluidsynth library and set the appropriate config.h setting to "0". I used SourceForge's 3.4 version of pdcurses and not another source which is found by google, since the latter resulted in linker errors. I also did not patch SDL with the openglhq patch, but I did edit the appropriate section of code to allow openglhq to know the full screen resolution. This method allowed use of the ready made SDL libraries for Windows. The other libraries were compiled by various ways as documented by their developers: tbb, gthread/glib, zlib, png, pdcurses, freetype, physfs, sdl_sound, and openglide; wpcap and sdl_net were available as already compiled versions. The DirectX headers and libraries were available through the DirectX SDK version June 2010, from Microsoft. The directory location to all these libraries and headers were entered into the Visual Studio project settings for recognition by the compiler. Also, I compiled any libraries in Visual Studio by the MD method and not MT (MT statically links with the C runtime library). There is advice to use MT instead, but in either case, both require consistency in the library type. Since the default is MD in Visual Studio, many of the publicly available compiled versions are probably compiled by this method. To finally compile Daum's build of DosBox, I excluded libcmt.lib and msvcrtd.lib from the linker. I don't know whether the necessity of this exclusion was from inadvertent use of mixed library types, but practically, it led to a compiled and working executable.

Two libraries which can commonly cause linker problems are zlib and libpng. These are available as already compiled versions, but if you have trouble, try compiling zlib 1.2.5 and libpng 1.6.2. Zlib requires using an assembler to initially compile code, by an accompanying batch: bld_ml32.bat. Once the compiling step is complete, then look for zlibstat.lib. Some of the png code is dependent on this library. Also, if there are errors related to dirent.h, just the header file is required and available via a google search. The only other error I recall is the linker error via external symbol __nhandle. I resolved this by editing dos_network2.h from: extern "C" int variable_name to int variable_name. The compiler should recognize "extern", but it caused a linker error under all tried conditions. Perhaps the 2012 version resolved this? One last note, remember to change the library names in the linker section of Visual Studio to the names of libraries actually compiled or downloaded, not the default names given by the Daum build.

My compiled copy of Daum's build is just a tad slower than the official one, perhaps this was caused by dynamically linking additional libraries, or another possibility is optimizations in the 2012 version of Visual Studio. However, I didn't test all functions, but I'm confident it was worthwhile as the enhanced Voodoo1 is fully working in Windows 98. This enhanced version has added features and this is the result of the diligent efforts by kekko. Since this 8 or 12mb version of the Voodoo 1/2 card is actually available in Windows 98 via Daum's DosBox, there should be no reason to consider installing a Windows NT class system in DosBox; apart from the ability to install ReactOS for a no cost installation (at least for personal use). A downside of ReactOS is it's dependency on Wine for gaming and therefore why is it any better than using another Wine supported OS, such as the Linux variants?

Lastly, since Windows 98 is compatible with this enhanced Voodoo1, is it necessary to incorporate a virtual IDE controller? I've read that the DOS compatibility mode of disk access is not error prone, and in the design of emulation, would the IDE controller lead to faster disk access than otherwise in the case of running Windows 9x?

truth5678 wrote:

I am hopeful that there is source code for the glide2x_emu.ovl file, and wondering whether it is crucial for the video hardware acceleration.

glide2x_emu.ovl in Daum build is the original 3dfx glide2x.ovl from the voodoo(2?) driver package. It is not used by DOSBox (the program itself) but by the game running inside (and DOS titles only). The file is loaded from the DOSBox directory and put onto internal Z: drive. This allows the patched dosbox to switch between glide wrapper emulation and 3dfx hadware emulation (simply by switching the ovl file that is available on the z: drive).

If it is available, then that is good news because it shows that this code base will always be portable.

There's not reason for it to be portable as it is only needed inside the emulated dos environment. But probably most of the sources are inside the Glide repository on Sourceforge (no idea if that builds into a usable file though).