question about this fork

[EhanMMMZET]

does this fork of dosbox-svn use openglide? i am using the sdl2 version of openglide and i would like to know if openglide is supported in this fork, i moved the openglide files to the resources folder in the application and it still doesnt generate any log or cfg files

[almeath]

I removed the experimental OpenGlide patch a couple of years ago, because firstly it was unstable and barely worked. I had to customize a build of OpenGlide to allow compilation into DOSBox, and even then there was not a single game where I could get it to function properly, i.e. to be "playable".

For example, in Lands of Lore 2, large black boxes appeared all over the place, and other games would exhibit banding or black-screen behavior or simply crash outright. Secondly, my build of DOSBox is based on the standard SVN release, which only supports SDL1. Anything requiring SDL2 will not work at all.

For these reasons, I instead decided to incorporate the DOSBox Pure implementation of the software-based 3dfx patch. After extensive testing, I found that performance of this patch was superior to earlier software patches (at least on my Core i9 reference system) and provided roughly 80-100% compatibility with the range of games I tested, including Lands of Lore 2, Need for Speed 2, Mask of Eternity, F/A-18 Falcon, Tomb Raider etc.

I might have an earlier build archived somewhere if you wanted to test OpenGlide under SDL1, but it comes with all the provisos I mentioned above. I would highly recommend you focus on the 3dfx software patch - and this is the same version of the patch that made its way into DOSBox Staging, probably for the same reasons I have described.

[EhanMMMZET]

oh thanks for the swift reply once again, and removing your openglide patch from the fork is fine

[EhanMMMZET]

hi, i have a second question which is if i could upscale the 3dfx rendering, i dont really like the pixelations on games like tomb raider when i increase the resolution

[almeath]

I think that is an inherent limitation of the patch itself, and possibly the original hardware it is designed to emulate. For example, the patch essentially emulates an original 3dfx 'Voodoo' card (i.e. "Voodoo 1") with either 4MB or 12MB of RAM. If you go with the higher RAM allocation, you probably want to increase your DOS memory to at least 64MB.

In either case, your DOS or Win9x game will be limited to the maximum resolution with which the original game was compatible. Most "Voodoo 1" era games were likely to max out at around 800x600 or possibly 1024x768 at most. So that will look kind of chunky in any case.

The emulated 3dfx card will run at the maximum resolution the specific game supports, also limited by your configured DOSBox screen resolution. For example, I have Mask of Eternity running in a Windows 98 installation within DOSBox. It defaults to 640x480, but within the game I can set the resolution to 800x600, and it seems to perform just as well (in terms of framerate) as the lower resolution.

In summary, the limitations of DOSBox and the fact it is designed to faithfully emulate original hardware is going to prevent you from being able to upscale or modify the rendering.

If you want to go down the path of using external 3dfx emulation wrappers (i.e. DgVoodoo2) these can do all sorts of fancy modern things not supported by the original hardware, like additional graphical effects and running very high resolutions that were not available at the time, i.e. 1080p, 1440p etc.

The downside, is that these wrappers are well supported on Windows, but I am not aware of any Mac-compatible versions.

If you want to follow the cutting edge of 3dfx support in DOSBox, I recommend you check out the DOSBox Staging discussions on GitHub. As mentioned, my patch is the same as the one used in Staging, but that team is likely to continue enhancing the 3dfx capabilities over time.

[almeath]

You could also try using different GLSL DOSBox shaders to help modify the look of the game, even while it is running with the 3dfx emulation. For example, I use a CRT shader in conjunction with all my games. It helps reduce the jagged and pixelated look that you get from modern LCD / nearest neighbor scaling.

[EhanMMMZET]

great explanation, i might try running games at higher resolutions with higher ram for both the card and the actual dos machine itself!

[EhanMMMZET]

alright, now i have yet another question which is how do i install windows 9x? i tried making a hdd with dosbox-x but when i try mounting it on the dosbox svn fork it cant guess the geometry of the img and when i try running the setup.exe with the c drive being the harddisk folder inside of the app itself, the setup is stuck on checking the drive

[almeath]

That is a complex issue, because DOSBox-X includes customizations that automatically detect drive geometry. That feature does not exist in SVN or DOSBox Staging. You have to manually calculate and specify the drive geometry settings in the conf, like this:

[autoexec]
# Lines in this section will be run at startup.
@echo off
cls
imgmount 2 harddisk\hdd.img -size 512,63,16,1023 -t hdd -fs none
imgmount 3 harddisk\hdd2.img -size 512,63,32,711 -t hdd -fs none
boot -l c
cls

That will mount two drives, one being your boot disk (C) and one is an additional drive (D) for installing games onto. If you do not want a D drive, just leave that second line out.

However, using two drives is preferable, because you can maintain a basic install of Win9x on a C drive that you never have to alter, but then add drives of different sizes to your various wrappers, which allows you to place your CD images onto the D drive and mount them using software such as Daemon Tools or Virtual Clone Drive. This is essential because, unlike DOSBox-X, there is no emulation of the IDE drivers needed for CDs to mount within the Win9x environment. By using various sizes of D drive, you can accommodate the number of CDs your game requires.

As for knowing which drive geometry settings to use, there are calculators available online. I have attached an image that shows you pre-calculated geometry for some common HDD image sizes.

For Win9x you will also want the following in your conf:

memsize = 380 core = dynamic cputype = pentium_slow cycles = max sbtype = sb16

If your host CPU is not fast enough, you may get sound stuttering in Win9x which means you have to reduce your cycles until it stops. Sometimes that is around the 90,000 to 120,000 range, sometimes less.

If you try to load a Win9x install from DOSBox-X you will find that driver installation may have to be re-done, so you will also want to ensure you have a Windows CD image or drivers available on one of your mounted drives. I personally recommend doing a clean install for Win9x for use with SVN.

[almeath]

It may be easier to show you all this by giving you access to a couple of wrappers:

https://1drv.ms/f/s!Ai-bwF6Vi1fvkZssOPRANGYLGwj7Cw?e=9WLqwT

One of these is a standard Win9x game and one uses 3dfx.

Make sure you set the resolution to your native screen size in the conf. Also, I have a CRT shader enabled here by default, which you might not want.

Also, I stripped these of their custom attributes, but you may have to redo the "xattr -cr" in terminal if they won't launch.

[almeath]

Closing this off, as there has been no further comment and there are no technical issues with the performance of the build.