High level 3dfx - significant progress with macOS

[almeath]

It is far too soon to declare a victory, but I can at least report on some significant progress in getting high level 3dfx (Glide passthrough) to work with DOSBox-X in macOS.

I am hoping that this progress might convince some other Mac users to help me out with additional testing and bug fixing.

At the outset, I just need to clarify that I am using Mojave (10.14.6) on an Intel Mac. I have intermittent access to Big Sur when I remember to bring my laptop home from work, but for now, all of these results are specific to Mojave. If you are regularly using Big Sur and/or Catalina, and would like to help out with testing, please let me know. The other thing I should mention is that by default I am compiling DOSBox-X from source, so I am currently on the 0.83.10 release. I only build with SDL1 because I can never get SDL2 to work very well, and I also understand it would preclude high level Glide passthrough from working at all?

All that aside, the first challenge was to get OpenGlide to compile successfully. Some changes made in October 2020 apparently broke support for macOS. I ended up having to patch it myself and fork it here:

https://github.com/almeath/openglide

Compilation instructions are provided in the read me. As mentioned above, I have built this in Mojave. I would be interested in receiving feedback on whether it works properly in later macOS releases.

Successful compilation results in the following files being installed:

usr/local/lib/libglide.so.2 usr/local/lib/libglide2x.0.dylib usr/local/lib/libglide2x.a usr/local/lib/libglide2x.dylib usr/local/lib/libglide2x.la

These can be left in the usr folder, or placed inside your resources folder if you package DOSBox-X in a native Mac app 'wrapper' as I do. It will find them in either location.

I confirmed that these are detected and working by starting DOSBox-X with glide = true and voodoo_card = auto (or opengl).

This results in two files being created:

OpenGLid.ini OpenGLid.log

In my app packages, these turn up in the resources folder. I would be interested to hear from others who just run DOSBox from one copy of the app .. I am not sure where these files would be deposited. I have not yet performed extensive testing, so I have not attempted to alter any of the settings in these files. These are the untouched default files:

logs.zip

The next step was to test Lands of Lore 2 (DOS) with the 1.30 patch that supports 3dfx. I have not yet considered whether Glide passthrough will work in Windows 9x. I think it is best to start with DOS and work my way up from there.

So, I installed the game, applied the patch and then generated the GLIDE2X.OVL using the instructions from the DOSBox-X wiki. I placed that file in the game's install directory.

Knowing that there is a current problem with 3dfx emulation on the Mac preventing full screen functionality, I used the fullscreen = false setting in the DOSBox-X preferences. When starting the game, lo and behold, I could see the hardware acceleration menu option appear:

Selecting that, the next screen provides the option to activate acceleration:

The acceleration is successfully activated, but the window re-sizes itself to what I assume is 640x400 or 640x480 and then my Mac mouse cursor becomes active and separate to the mouse cursor within the DOSBox-X window, so I re-capture it with control-F10.

I also see a separate small DOSBox-X window pop up:

From there, I can start and run the game. The performance is actually quite good at this stage. The audio stutters a bit and sometimes there is a bit of a slow down, but the frame rate seems surprisingly good overall. I am using dynamic_x86 core and max cycles.

Perhaps some further tweaks to the DOSBox config and the OpenGLid.ini will yield better results. I will paste a bunch of screen caps below, as for some reason I cannot get the AVI video capture to work for me in macOS and the other formats are greyed out.

Anyway, I am very excited about making this much progress on what I thought was a lost cause. I am hopeful that I can receive some support and advice to get this working better.

PS .. I will attach the OpenGLid.err file that was generated when I ran Lands of Lore 2. I think the graphical glitches displayed below are are result of a missing extension that I need to either enable or build into OpenGlide. I would be grateful for any suggestions! :-)

I will also include my conf file for reference.

OpenGLid.err.zip

dosbox.conf.zip

[almeath]

As mentioned above .. if anyone has suggestions on the err file and the graphical glitches below, that would be much appreciated.

Also note, I previously reported that 3dfx (low level) emulation only works in windowed mode in macOS, and it appears to be the same for high level. You cannot switch to full screen because control-f12 will not do anything when pass through is enabled. If you start in full screen mode, switch to pass through will make the whole screen go black. This is a known issue that the devs acknowledged. For now, we can only proceed with windowed mode.

Sometimes the animated figures are covered by black squares, and sometimes not..

Some missing textures in the next three:

[almeath]

Lastly, the next steps are:

1. Can anyone re-produce the above results on their own system?
2. Is there any interest in helping me test other Glide enabled DOS games?

[Wengier]

@almeath Great to hear the progress! Good to know that the Glide feature works on macOS too and you can actually run the 3dfx games smoothly there. I really appreciate your testing on this. Meanwhile, I run macOS only through VM, so I hope real macOS users can test this more.

As you said at this time low-level 3dfx emulation only works in windowed mode (in any OS), and for high-level 3dfx emulation this really depends on the Glide wrapper. For example, in Windows with nGlide 3dfx games will be played in full-screen mode but with dgVoodoo they may be played in windowed mode only. DOSBox-X itself cannot control this, but the Glide wrappers do. Hope to see more developments on the Glide wrapper so that 3dfx games will play even better.

Once again, thanks for the testing on macOS!

[almeath]

Further good news..

I have started to experiment with with the OpenGLid.ini file, and I discovered that changing the following setting to '1' (i.e. true) enables full screen mode!

InitFullScreen=1

I have attached my updated log files.

Performance in fullscreen does not appear to suffer in any way, subject to the glitches and issues I reported above.

One minor issue for now is that running in fullscreen causes the mouse cursor to act strangely. When starting the game, the DOS cursor is centered in the screen and the Mac cursor is active. You can only move the DOS cursor by first capturing it with control-f10, but doing that locks the Mac cursor in the middle of the screen.

If you then control-f10 again, there is a weird issue where both cursors appear, and if you move the Mac cursor the DOS cursor trails a bit behind it, but the DOS cursor cannot be moved outside of an invisible 'window' within the full screen. Once you hit the edge of that window, the DOS cursor stays behind while you can still move the Mac cursor freely. I cannot show it in a screen cap because command-shift-3 removes the Mac mouse cursor from screen shots.

This basically means that unless I find a way to hide the DOS cursor or disable it, the game can only run in full screen with either or both of the DOS and Mac cursors visible somewhere in the active gaming window.

I have attached updated log files.

logs 2.zip

[almeath]

I have resolved the OpenGlide error about "GL_EXT_packed_pixels extension". My forked source code for OpenGlide has been updated accordingly.

I no longer get an error log generated when running LOL2. However, the issue does not appear to be relevant to the missing textures, as they are still there.

Also, I switched back to starting DOSBox-X in full screen mode, and this avoids the mouse cursor issues I mentioned above.

The remaining issues with LOL2 are therefore:

• slightly stuttering sound
• missing textures

It is possible the sound issue can be fixed with conf file changes, so I will look into that. It might have nothing to do with OpenGlide.

[Wengier]

@almeath Thanks for the efforts, and I am glad to see there are now further progresses. @rderooy I noticed that the current 3dfx page in the DOSBox-X Wiki still says “In short, it seems there is no Glide implementation that works on modern macOS systems.” Fortunately, this is becoming a past thing and you may want to update the content accordingly as well shortly.

[almeath]

Thanks, I am happy to help, and acknowledge its a work in progress. The other thing is that I am not very familiar with OpenGlide, so it is possible some of the glitches I am reporting are known issues. Also, I realize that my OpenGlide compilation instructions need some adjustment to work with Big Sur, which I am looking into. I only have access to a Mojave machine at the moment.

[rderooy]

OpenGlide could certainly use some work, such as fixing it's lack of support for SDL2. And I'm sure some of the glitches that your seeing also happen on Linux.

I would suggest that you try to get your fixes merged with https://github.com/voyageur/openglide such that we have a minimum of forks to worry about.

I will update the wiki in a bit to reflect that macOS support is being worked on, and point to this issue. Once you feel it's ready, just send me some text to integrate in the wiki.

[almeath]

I tested my OpenGlide library in DOSBox SVN with the Glide patch provided in the fork (in the platform folder). It works exactly the same as in DOSBox-X, except that DOSBox SVN freezes up with a black screen when quitting Lands of Lore 2 (DOSBox-X closes properly). I had to use mission control to get back to the desktop and then force-quit the program. This is probably an SDL1 related bug, as SVN on the Mac has to be built with a mercurial build of SDL 1.2.x.

All the same graphical artifacts and glitches are present when playing in DOSBox SVN, so the issues must be inherent to OpenGlide itself (at least on Mac and/or Linux).

I enlisted the support of a VOGONS member to test out the compilation process on macOS 11 (Big Sur) and it does work. I just do not have access to an Apple Silicon Mac at this stage, but I presume it will work via Rosetta 2.

Therefore, I consider that my instructions can be used as the only current and verified way to get Glide pass-through working on 64-bit macOS operating systems. It is not perfect of course, but that is more up to the development of OpenGlide. It is too bad that nGlide and DGVoodoo2 are not Mac-compatible.

I am happy to write something up - where should it be sent?

As mentioned above, I welcome anyone to test other games and share results that can be fed back to the OpenGlide devs, as I will be doing myself.

[rderooy]

You can put the text here and myself or Wengier can integrate it with the wiki.

[almeath]

Install the OpenGlide dependencies

1. Install Xcode command-line tools:

You need Xcode command-line tools from Apple in order to install Home Brew. You can install Xcode from the App Store or run the following Terminal command:

xcode-select --install

Alternatively, when you run the Home Brew install script (see below), it will install the command-line tools for you.

2. Install Home Brew:

Home Brew is the package manager for macOS that makes it easy to install the required packages needed for OpenGlide to compile successfully. You can get it from https://brew.sh or run the following command from a Terminal shell:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

3. Install the required Homebrew packages needed by OpenGlide:

Run the following Terminal command:

brew install SDL1

Build the OpenGlide libraries

1. Download the source code from this fork of OpenGlide, which has been patched to work on macOS Mojave or higher:

https://github.com/almeath/openglide

2. Unzip the downloaded folder to your desktop and then navigate to the folder using Terminal:

cd $HOME/Desktop/openglide-master

3. Run the following commands, in order:

./bootstrap

./configure

make install

Note: on macOS 11 (Big Sur) you may need to change the final command to:

sudo make install

Note: if the make command fails with an error about a missing "features.h" file, you can create one in the correct location with the following commands:

cd /usr/local/include/

touch features.h

Then go back to the OpenGlide folder as detailed above, run make again, and it should then work. This features.h file is not needed directly by OpenGlide but sometimes the macOS command line tools require it for the build script to complete successfully.

If the build is successful, the resulting libraries are installed to usr/local/lib/:

libglide.so.2 libglide2x.0.dylib libglide2x.a libglide2x.dylib libglide2x.la

Note: libglide.so.2 is an alias file that has no 'original'. It appears to be a remnant of the Linux based build, and can probably be deleted or otherwise ignored. The macOS dynamic (dlylib) and static (a/la) files are the key components.

These files can remain in your library folder and will be automatically detected by DOSBox-X.

Alternatively, you can place them inside your DOSBox-X application package (/Contents/Resources) and they should be recognized in there first, before falling back to the system level files if required.

Test for detection of the OpenGlide libraries

A good way to test the functionality of your OpenGlide library is to download DOSBox-X and enable glide within the configuration/settings in accordance with the DOSBox-X Wiki.

If the OpenGlide library is successfully detected, when you run DOSBox-X it will generate two output files called OpenGLid.ini and OpenGLid.log (the former providing options to adjust the OpenGlide settings). These should be located in the place as your DOSBox-X application or executable binary.

Optimize the OpenGLid.ini settings

The following settings are recommended (with InitFullScreen=1 to commence in fullscreen mode)

[Options] WrapperPriority=2 CreateWindow=0 InitFullScreen=1 Resolution=0.0 EnableMipMaps=0 IgnorePaletteChange=0 Wrap565to5551=1 EnablePrecisionFix=1 EnableMultiTextureEXT=1 EnablePaletteEXT=1 EnableVertexArrayEXT=0 TextureMemorySize=32 FrameBufferMemorySize=16 NoSplash=1

[almeath]

@rderooy , can you please double-check my instructions to ensure I have not overlooked anything or made any mistakes?

One thing I am not clear on - where will DOSBox-X put the OpenGLid.ini and OpenGLid.log files by default?

I use cutom wrappers, so mine always get generated inside the wrapper directly, but I understand that is not compliant with modern macOS guidelines

[rderooy]

@almeath on the OpenGLid.* files, they seem to get generated on my Linux system in the directory from where dosbox-x is started (working directory). I also don't think they get generated by DOSBox-X itself, but rather by the OpenGlide wrapper.

On the "empty" file, if it is really empty, you can (at least on Linux), easily create it by running:

touch features.h

[almeath]

Yes, I realize it is the wrapper that creates them. So starting DOSBox-X activates the wrapper, which in turn generates the files and confirms the successful installation of OpenGlide.

Thanks for the suggestion about features.h - that is a much easier way to do it. I have updated the instructions accordingly. I really do not know how prevalent a missing features.h file is across different versions of XCode, but I will leave this in for those that get stuck.

I am happy with the above instructions, if you would like to place them on the Wiki in a suitable format. I really appreciate your help with that.

[rderooy]

@almeath I have added your text with a few small adjustments to the draft wiki. Please have a look. https://github.com/Wengier/dosbox-x-wiki/wiki/Guide%3ASetting-up-3dfx-Voodoo-in-DOSBox%E2%80%90X#macos-host-installing-libglide2x-dylib

I consolidated your "cd" and "touch" command into one, and added a sudo in front, as at least on Linux the command would otherwise fail.

Also for the "make install", that would likewise always require a sudo on Linux, unless it's installing into a users directory. If it is installing into system directories like /usr or /lib it would fail without sudo.

[almeath]

@rderooy , thanks for making those improvements.

I have got too used to running everything as admin on my system.

Should we just remove the line with the specific reference to Big Sur and make that last command above it sudo make install? That should then work on any system.

Also, there is one small typo at the bottom where it should read "These should be located in the same place as your DOSBox-X application or executable binary."

[rderooy]

@almeath done.

[rderooy]

I added the same warning as for the Linux version, that OpenGlide is not compatible with SDL2.

[almeath]

@rderooy , brilliant - I like the way you formatted it. Very clear and easy to read.

Now I suppose the last step is for this information to make its way onto the DOSBox-X website, which is still referencing this issue.

[Wengier]

@almeath The DOSBox-X Wiki on the DOSBox-X website is updated each month. There can be further improvements to the page(s), but the main DOSBox-X Wiki will be updated once things are stabilized.

[brunocastello]

Hi, just tested latest iteration of DOSBox-X with openglide. I compiled openglide as per instructions.

• First attempt with the files inside /Contents/Resources of the application - no go. Glide does not kickstart.
• Second attempt with them in their original location /usr/local/lib, Glide kickstarts, but:

FIFA 98 RTWC - Black screen and can't get out of this. FIFA 99 - Segmentation fault.

System: macOS Big Sur 11.2.3 [Intel Mac]

[Wengier]

@brunocastello Are you using the SDL1 build for this?

[Wengier]

@rderooy and @almeath The updated content already appears on the Wiki page of the DOSBox-X website by now:

https://dosbox-x.com/wiki/Guide%3ASetting-up-3dfx-Voodoo-in-DOSBox%E2%80%90X

[brunocastello]

@brunocastello Are you using the SDL1 build for this?

Yes, forgot to mention this. It's the SDL1 build.

[brunocastello]

I've made some progress. I ditched my WIn98 Dosbox-X install, and used a QEMU Win98 harddisk instead, because I couldn't bother reinstalling everything. I just had to convert it from qcow2 to raw, then update some drivers, and install voodoo drivers. This is part of the catch.

First things first, FIFA 99 does segfault because it apparently does not like something in dosbox's pentium emulation (while it works fine with pentium 3 on QEMU). When changing the cputype to auto and starting the game, it runs fine with the updated voodoo drivers (3.01.00) from philscomputerlab. Forgot to mention that I've also added the "special" glide2x.dll into windows/system folder before running the game.

However FIFA 98 did not run. It does the same thing your game above did (two windows) and just blank screen. However I have FIFA 98 CD imaged, it has some voodoo drivers specifically for the game. I've installed them (it probably overwrote something from updated voodoo drivers, including the glide2x.dll) and hey presto, FIFA 98 was running in full 3dfx glory! And no more two windows! This certainly happens because of something in glide2x.dll

I had to try out FIFA 99 again - it probably was screwed. My fear is that I wouldnt be able to run both with 3Dfx. FIFA 99 ran flawlessly as before.

So that's it, I finally have 2 of my favorite games with 3Dfx support after three years of attempts, thank you so much john, wengier and almeath for the openglide library! Just a recap:

• These games did not like the pentium emulation for some reason. cputype=auto fixes this.
• Certain games like FIFA 98 may require a certain voodoo drivers version to run well. 9/10 times it will be the same version that's shipped with the game.

I now have just a few stuff to work out before calling it my perfect dosbox-x vintage machine:

• adjust resolution for full screen goodness (I am still on windowed because I am scared of being unable to exit or kill the app if something goes wrong (it happened to me a couple of times before!)
• Try out Grand Prix 3 (I will probably have zero luck with this game, because GP3 probably requires Pentium II for a fluid experience) Not gonna work, it's slower than my own Ford New Fiesta... GP3 requires PII 266 MHz and a 3D compatible video card, it supposedly works with Voodoo 3 but has some caveheats;
• Try out NBA Live 97 (this game does not have 3D acceleration but works fine. NBA Live 98 was the first to provide 3Dfx support, I have to try it out later
• little internal dosbox-x configuration file adjustments for minor tweaks.

Again, thank you guys. Massive great work there.

[Wengier]

@brunocastello Great to hear the progress you have made!

For the cputype issue you have mentioned, it is possible that the issue is related to Issue #2422 regarding dynamic MMX emulation. Can you check out the new code and see if it works? Thanks!

[brunocastello]

@Wengier OK, I'll try to do that this weekend, after tomorrow, for both this issue and the slirp issue.

[brunocastello]

@Wengier no luck with the changes for dynamic MMX emulation. Same behavior. FIFA 99 goes past 3dfx animation, then kicks me back to the desktop. FIFA RTWC 98 just black screen.

cputype = auto lets me into the start of a match on FIFA 99, before being kicked out to desktop. But also note, the emulation became a LOT slower now.

It seems that we now have a regression. Hmmmm

[brunocastello]

I got confused, a lot, so I decided to redo my steps from last night (including reusing the same QEMU win98 image after conversion from qcow2 to raw) to find out the culprit. I probably messed up something after the tests when I tried to improve video resolution and stuff. Will report back.

[brunocastello]

I've found the culprit for my problem. It's the sound. The sound can't keep up with the emulation speed somehow and dosbox throws an error, crashes, whatever. Heres the thing:

When I have sb16 or sb16vibra working with correct IRQ (7) on both dosbox.conf and Windows device manager, both FIFA games crash at random times. It's a hit and miss, probably last night I was luck to have a shot at playing with sound working, or my memory is so dumb that I probably forgot it worked without sound last time.

When I have IRQ set incorrectly (5 on dosbox.conf, 7 on Windows) there is no sound going on, and I am able to play both games fine without sound. I did two full matches on both games without any issue.

Both tests were done with a slightly modified version of the dosbox.conf available on the first post of this issue here. And cputype = auto. Games still crash when using pentium_mmx. But for my issue with FIFA, it's definitely the sound emulation here the problem. No idea of what is happening under the hood for this to fail.

[brunocastello]

I have tested the latest release (0.83.13) right now with my current settings (And a stripped down configuration file with only the wanted/required settings) and I can still confirm that both FIFA games won't run without a crash if I disable the sound.

I used the default configuration file settings as per wiki page on Windows 98, with the addition of a few settings that do not affect the issue at all.

When I am using the correct sound settings, there is sound on Windows and as soon as I am about to start a match (kick-off moment) the whole system hangs on and I have to quit DOSBox-X.

When I am using an incorrect sound setting (like, incorrect IRQ port or sbtype) there is no sound at all and I can play an entire full match without issues.

Clearly, when analyzing the results of my tests with the last three or four releases, I can only see one conclusion, that DOSBox-X SB16 emulation cannot keep up with the game speed, hence why it crashes. It probably requires a more fine/specific sound emulation settings for better performance, maybe?

3Dfx Glide Pass-Through with SDL1 & OpenGlide are working as intended. I just cannot play the game with sound at all.

Another issue (unrelated, though) is that I still do not have network working when I use SLIRP instead of PCAP. Windows 98 goes straight to the desktop instead of asking for my network logon credentials, which indicates that there is no network at all.

EDIT: I can confirm that both games are playable with high level 3dfx through OpenGlide on MacOS, but only with sound disabled (sbtype = none). Something in sound emulation (I cannot pinpoint what exactly it is) clearly is causing both games to crash. When sbtype is sb16 or sb16vibra, both games crash and have sound struggling to perform/keep up with the game speed (ie. stuttering and skipping).

This is the only issue remaining for a perfect Win98 gaming machine on DOSBox-X.

[rderooy]

As far as I know the macOS builds don't have SLIRP at this time.

[brunocastello]

Hi, just came back to bring some more feedback. I decided to recompile OpenGlide and added the generated libraries to the /Contents/Resources folder inside the application (brew complains about unbrewed files inside my /usr/local/..., so I took this approach and it works) as mentioned on your win 98 wiki. I am using the latest DOSBox-X build 0.83.14 SDL1, still on macOS Big Sur. And using the dynamic core, cycles = max, cputype = auto (I could use pentium but game crashes, and 486 it gets slower).

Then I proceeded to replacing the Glide2x.dll to use the version recommended on your wiki for Win 98. I tested three games: FIFA 98 RTWC, FIFA 99, NFS II SE. All three crash and sound is stuttering a lot (video animations as well).

So again I confirmed my conclusions above by setting sbtype = none (was sb16vibra) and ran it again. All three games ran well (FIFA 98 RTWC ran much better and faster; FIFA 99 video animations still stutter a bit) but this is only possible when I have no sound. Same conclusions can be seen using different cputypes.

It's clear that there is a problem with sound not being able to keep up with the speed of the game. For example, FIFA 99. Stutters when intro video animations are on, Menus are a bit slow, Stadium intro animation are stuttering, and when I am in the game, when the players are entering the pitch and I hear the commentary, sometimes its OK and proceeds to match kick-off, but sometimes not and the game crashes. When I get to the match kick-off, sound is off, game freezes, and from nowhere, the sound commentary continues for a bit and stops. All I hear from now is the crowd.

Without sound, zero problems and FIFA 99 is just a tad slower. Apparently, there is work to be done to improve sound speed.

[brunocastello]

Back here to report that the sound issue above described persists with latest build as of today (July 1st, 2021, build 0.83.15).

[brunocastello]

How do I tell DOSBox-X to log what's happening under the hood when I try to play the game? I really really need to know why the game crashes when SB16 is on and why it doesn't when SB16 isn't. I have already discarded any relationship with OpenGlide, 3dfx, game even crashes when I try the game software mode. It's practically the same FIFA 9x files played on both QEMU and VMware machines.

That does not happen when I run my QEMU Win98SE VM and play FIFA 98 or 99, both in software mode. Also doesn't happen when I use my WinXP VM on VMware Fusion. I'm baffled.

Everything points to a problem with the sound emulation. I need to dig deeper to find out why. Because as of now, it is the only thing between me and a perfect Win 98 virtual gaming machine.

[Wengier]

@brunocastello Please take a look at the [log] section of the config file (dosbox-x.conf). Specify the log file name via logfile option, and you can enable various logging components there. Or from the DOSBox-X Configuration Tool, check "Show Advanced Options", and then click "Log" button to set them up. The logs will be saved to the specified log file. Hope this helps.

[brunocastello]

@brunocastello Please take a look at the [log] section of the config file (dosbox-x.conf). Specify the log file name via logfile option, and you can enable various logging components there. Or from the DOSBox-X Configuration Tool, check "Show Advanced Options", and then click "Log" button to set them up. The logs will be saved to the specified log file. Hope this helps.

The last message before the whole system hangs out when starting a match on FIFA 98 RTWC is:

tx irq retrigger

Actually the message appears every time sound/video playback is stuttering. For example, Game intros and match intros as well as the match kick-off scene.

[ndbroadbent]

Hi everyone, I'm trying to Redline Racer running in Windows 95 OSR2 using the high-level glide passthrough. I'm running DOSBox-X 0.83.16 (SDL1, 64-bit), on macOS Big Sur. I've compiled and installed openglide.

I'm following the "Glide pass-through" section in the dosbox-x Installing Windows 95 guide, so I downloaded this patched GLIDE2X.DLL (glide2x-win9x.zip), and copied it into the game directory. When I start the game, it just shows red with a blinking black square in the bottom left (the sounds work though):

dosbox-x logs show: LOG: Glide:LFB access: read-write (no aux), and Z:\SYSTEM\GLIDE2X.OVL is present.

Glide passthrough is checked in the options:

I'm using core=dynamic_x86 for the CPU, and the [voodoo] section just contains glide=true.

My full win95.conf:

[sdl]
autolock=true

[dosbox]
title=Windows 95
memsize=256

[video]
vmemsize=8
vesa modelist width limit=0
vesa modelist height limit=0

[dos]
# Set 'ver=7.1' if using Win95 OSR2 (95B) or later
ver=7.1
hard drive data rate limit=0

[cpu]
cputype=pentium_mmx
#core=normal
core=dynamic_x86

[voodoo]
glide=true

[sblaster]
sbtype=sb16vibra

[fdc, primary]
int13fakev86io=true

[ide, primary]
enable=true
int13fakeio=true
int13fakev86io=true

[ide, secondary]
enable=true
int13fakeio=true
int13fakev86io=true
cd-rom insertion delay=4000

[render]
scaler=none
glshader=none

[ne2000]
ne2000=true
nicirq=10
backend=slirp

[autoexec]
IMGMOUNT C hdd.img -t hdd -ide 1m
IMGMOUNT D ~/dosbox-x/win95_shared.iso -t iso -fs iso -ide 2m
BOOT C:

I'm also using the recommended config in OpenGLid.ini:

Version=0.09rc9

[Options]
WrapperPriority=2
CreateWindow=0
InitFullScreen=0
Resolution=0.0
EnableMipMaps=0
IgnorePaletteChange=0
Wrap565to5551=1
EnablePrecisionFix=1
EnableMultiTextureEXT=1
EnablePaletteEXT=1
EnableVertexArrayEXT=0
TextureMemorySize=32
FrameBufferMemorySize=16
NoSplash=1

(Disabled full screen for now, since it made it very difficult to quit dosbox-x when something went wrong.)

Any suggestions for what I could try? Thanks!

---

UPDATE: I got it working with:

[voodoo]
voodoo_card=opengl

Redline Racer runs very smoothly, although there's a bug with the rendering (something similar to this issue), and the game also crashes as soon as you fall off the bike. And sometimes you will spin around and then float in random directions through the ground. But otherwise it's sort of playable.

I just tried core=normal for [cpu], and it runs super slow, but maybe a little more accurately. At least until it crashes with an error:

Age of Empires I works great with no issues though. I know this Redline Racer game is super obscure, so I probably won't worry about it! Happy to get this far at least.

---

UPDATE 2: Thanks for Jon Taylor for this comment in the Jan 1999 issue of Maximum PC:

Apparently the nasty display bugs are caused by Direct X 6.0, which was installed with Age of Empires. It's so awesome that Google Books is indexing old magazine articles with OCR. (Sorry to spam this thread with unrelated info, but I thought others might find it interesting!)

[almeath]

I haven't looked into 3dfx support in DOSBox-X (in macOS) for a while now, as I found that OpenGlide was just too unstable and glitchy to be a viable solution. Likewise, I found that with both kekko's 3dfx patch in DOSBox SVN, as well as the in-built 3dfx support in DOSBox-X, I was experiencing the same crashes and buggy performance across the board. I baselined against three games; Mask of Eternity (Win98), F/A-18 Falcon (Win95) and Lands of Lore 2 (DOS).

Recently, a member on Vogons (Psyraven) ported an implementation of 3dfx support in DOSBox Pure (within the libretro core) into an SVN-compatible patch.

https://www.vogons.org/viewtopic.php?f=41&t=41853&p=1101146#p1101146

I have applied this patch to my custom DOSBox SVN, and as I described in the above post, it has resulting in stable and bug free performance in the aforementioned games. Yes, some games definitely continue to be bugged and unplayable, such as Need for Speed 2, but so far it has worked very well, all things considered. I originally posted this topic based on testing within Lands of Lore 2. This patch allows me to play it glitch-free in Windows 98 in full screen mode, without any artifacts and with a frame rate at least as good as what I was achieving with OpenGlide.

I do not run tests in Windows builds of DOSBox, so it is quite possible that Windows users may not notice such big improvement from this patch.

Would there be any consideration to testing this alternative 3dfx code within a DOSBox-X branch? I could look into it myself, but I can't promise that will be a quick process, as all my patching experience is with SVN.

[Sethur]

I just tried to manually integrate the DOSBox SVN patch into the doxbox-x codebase, but compared to the SVN version, there is already a src/hardware/voodoo.cpp which presumably handles the low level 3dfx emulation in single-threaded manner and probably needs to be replaced (alongside some accompanying files) with the contents of the patch. It also seems like there have been some major framework changes in dosbox-x compared to SVN, so I guess the integration is not straightforward for someone with little knowledge of the codebase.

[almeath]

I attempted to cross-apply patches intended for SVN and DOSBox Staging with DOSBox-X and ran into the same issues. There are major differences in the underlying frameworks, so it usually gets nowhere and ends in grief.

A few months back a user on VOGONS developed a patch to implement the DOSBox Pure (i.e. Retroarch DOSBox) 3dfx patch into SVN. I was skeptical, but I found I was able to get it to work with some minor adjustments. The result is that I patched it into my own unofficial fork of SVN. I have since found that it works exceptionally well, at least on my Intel Mac. Games that crashed out in DOSBox-X or displayed 3dfx games only in a tiny box of a window (or displayed artifacts with OpenGlide), now work perfectly in both DOS or Win9x environments in full screen mode. Examples include Lands of Lore 2, Silent Thunder, F/A-18 Hornet, Kings Quest Mask of Eternity, Test Drive 4, Shadows of the Empire, FIFA 98 etc.. Note that this is a software-only 3dfx implementation, not for use with OpenGlide.

If you want to test it, it is available in standalone or self-contained (ie. game wrapper) versions. I also provide a link of it to download, pre-compiled.

https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS

What I would really like to try, is getting the DOSBox Pure patch to apply to DOSBox-X. The reason is that I cannot get mixed-mode CDs with CD audio soundtracks to work properly in Win9x in DOSBox SVN. This is because SVN lacks IDE emulation within a Win98x environment, and it seems that none of the available virtual disk mounting utilities can get the BIN/CUE images to work properly with CD audio. So my choice is either playing in software-only mode with CD music under DOSBox-X, or no music with 3dfx under SVN.

Anyone who is interested, feel free to check out the patches in my repository. The Voodoo.cpp will be completely different to DOSBox-X:

https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS/commit/1d0d67af0bf4b4ad41b08a20b44448bd05986c7e

[Sethur]

@almeath From your experience it seems definitely worthwhile to implement the SVN patch into DOSBox-X, but I fear we need one of the experienced core developers to get this done.

PS: Can you reupload the precompiled DMG to your DOSBox-SVN fork? It seems the file was deleted on your Dropbox.

[almeath]

PS: Can you reupload the precompiled DMG to your DOSBox-SVN fork? It seems the file was deleted on your Dropbox.

Sorry, it is fixed now.

Despite the issue noted above (i.e. how much DOSBox-X has diverged from SVN) I am willing to look into it myself. If I have any degree of success I will certainly report back here.

[almeath]

Looks like the DOSBox Staging crew have either implemented the DOSBox Pure version of the 3dfx patch, or something very similar to it, based on the config layout in the latest alpha builds of Staging. I have not tested this on the Mac yet, but in Windows it performs just as well (and is just as stable) as the 3dfx patch I implemented in my custom SVN build for macOS.

I am hoping there might still be some consideration of implementing this version of the 3dfx patch, which I daresay appears to be superior to the older 3dfx software patch (kekko?), which I believe still forms the basis of the functionality in DOSBox-X?

[sofakng]

@almeath - are you still able to build openglide from your GitHub repo on the latest macOS? (ie. Sonoma 14.x)

I'm trying build it can't find glx.h and gl.h. I've solved this by including Xquartz (/opt/X11/include) which I'm not sure is correct but it fails during linking with a bunch of undefined symbols (_XCloseDisplay, _glXChooseVisual, etc).

[almeath]

@sofakng, I have not tried a fresh compilation since Mojave and Catalina. I am also no longer regularly developing on the Mac platform because I do not want to make the long term transition to Apple Silicon. I did however log into a Sonoma system to try my original compilation instructions, and I can get all the way to 'make install' only to have it fail with similar 'undefined symbol' errors.

I should point out that on my old Mojave system, I upgraded to Sonoma and was still able to compile and run my DOSBox SVN fork using the OpenGlide library which had been brought across during the upgrade from Mojave. The OpenGlide dylib statically built into my standalone DOSBox package and continued to work in that context, so I do not think it is important what version of the MacOS you compile the dylib on - only that you have a properly built dylib to start with before compiling DOSBox.

Therefore, it would help if I can better understand what you are trying to do. Are you just wanting to access the pre-built dylib? Because I could probably extract those from my Mojave system, zip them and link to them here.

Alternatively, have you tried using my pre-compiled 'standalone' DOSBox SVN package? The OpenGlide dylib and support files are already contained inside that package, and it is confirmed to run properly on MacOS Sonoma. Yes, it is compiled for Intel Macs, but in theory Rosetta should translate everything to run on Apple Silicon, even the static libraries. One thing I would point out however, is that the best OpenGlide performance was achieved in a Win9x environment within DOSBox, and I do know that Win9x will just not work at all in Apple Silicon, so you would be limited to DOS 3dfx games only.