Can't game on Windows 98 SE unless sbtype = none

[brunocastello]

Describe the bug I cannot run any game at all on Windows 98 SE, unless I set sbtype to "none". FIFA 98 RTWC, FIFA 99, Need For Speed II SE, all them cannot run with sound on, even when I try to play them in software mode instead of glide pass-through.

NFS2SE with both software and 3dfx crashes when the race is about to start, during the intro flying into the player's car. FIFA 98 RTWC and FIFA 99 both crash when the match kick-off is about to start, no matter if 3dfx is enabled or not.

When I set sbtype = none, without any sound at all, I can play all three games without issues (but without sound as well).

To Reproduce Play any of the three games above (a demo is enough) under Windows 98 SE, using sbtype = sb16 or sb16vibra.

Expected behavior Games to run flawlessly with sound enabled.

Environment (please complete the following information):

• Operating system: macOS 11.4 Big Sur [Intel]
• DOSBox-X release version: SDL1.2 0.83.15 (The problem is persistent since several versions before)
• Used configuration: attached below

Additional context I am running a build without avcodec and fluidsynth. I do not want all the 93893 dependencies both require to run. In a Mac where hard disk space is a premium, this is needed. I just need networking and the gaming features; I do not want extra sound features (fluidsynth) or to do any screen recording (avcodec) stuff. However, even using the standard build with them, the problem persists.

The computer has this configuration and has been upgraded to 16GB RAM at the time of purchase.

Attached is my dosbox configuration file, pretty similar to the one from the wiki guide for Windows 98 installation. dosbox.txt

[Wengier]

@joncampbell123 Wow, you are adding ARM64 macOS CI target. There is no workflow posted for this target, but for the standard macOS target you can see the CI output easily, just from the build window:

Or you can view the raw CI output (in plain text) by clicking "View raw logs" option in the top-right:

Then the complete CI output will be shown there.

[joncampbell123]

I didn't add the ARM64 CI target, it was there when I checked it. GitHub emailed me to notify me which CI steps failed.

[Wengier]

@joncampbell123 Where did you find the ARM64 macOS CI target? Is there a link to it so I can see as well?

[joncampbell123]

This is what I see and---Oh. Never mind, false alarm. :laughing:

GitHub notifies me whenever DOSBox staging does some things.

[joncampbell123]

It looks like the guys over at DOSBox staging figured it out. Let's ask them how they did it.

This is what GitHub emailed me:

https://github.com/joncampbell123/dosbox-staging/actions/runs/1533104791

[Wengier]

It is from the DOSBox Staging project then. It is probably self-hosted, rather than provided by GitHub.

[Wengier]

Yes, it is indeed self-hosted:

[brunocastello]

Ouch! Let me know if you want me to build one here, but without fluidsynth and avcodec. My M1 Air does have a build environment, I had to have it so I could build QEMU-3dfx... even if it fails, my output log might help to decipher what's going on...

[joncampbell123]

@brunocastello You're free to try... though you might get the same error message.

[brunocastello]

I actually did try it last week, and it eventually failed. Can't remember why now.

[grapeli]

@brunocastello I confirm with sbtype=none Need For Speed II SE in the demo version (and full) it works fine (as much as).

https://user-images.githubusercontent.com/452325/144729323-e9105e99-6d34-40a3-a9e3-ccdc2496c424.mp4

With sbtype=sb16 you exit the game after ~ 10 seconds.

https://user-images.githubusercontent.com/452325/144729338-52100860-c700-4f29-9ad1-35e063ed467c.mp4

Of course, this does not apply to the performance of my 2010 laptop with Intel Core Westmere clocked at 2.4 GHz (with turbo 2.6). Please do not suggest yourself.

edit:By the way, under linux, for running Windows games, I recommend first of all - wine (and only). Works great with old titles like fifa, nfs, f1, etc.

[brunocastello]

Wine sucked for nearly all games I tested on my M1. IMHO, dosbox-x should be the best solution for mac users.

I have been using qemu-3dfx but I am not happy with it either. It’s a half baked solution, I have glide but not mesa passthrough. Needs specially patched wined3d libraries for that.

a cross compiled build of PCem for mac works, but voodoo emulation is broken.

So it leaves us with dosbox-x as the best possible option available at the moment.

[grapeli]

@brunocastello I am convinced that most of the titles you mentioned in this thread work under wine with gold or platinium status. Of course, you have to know how to handle wine. It also has regressions. It is worth having wine in different versions (from 1.8.x, 3.0.x to the latest 6.23). This NFSIISE demo should be run like this: taskset -c 0 wine NFS2SEA.EXE For wine, they didn't work well for me: -Big Red Racing (requires 256 color spaces) - looks awful under wine -Freddy Pharkas: Frontier Pharmacist (version under Win 3.11) - was launched partially.

Using wine is pure pleasure compared to the torment of installing Windows 98. Enough of wine.

I am curious how Formula 1 Demo 3DFx (Psygnosis) with sbtype=sb16 works for you under DOSBox-X. https://archive.org/download/Formel1/Formel1.zip It works for me (graphic artifacts are a bit annoying).

https://user-images.githubusercontent.com/452325/144743289-ceb905d8-3695-4194-a7ee-2612df58db46.mp4

[grapeli]

After disabling acceleration support for sb16 audio playback in Win98, NFSIISE works fine (except for unwanted graphics artifacts that appear).

https://user-images.githubusercontent.com/452325/144752896-01f8fb1e-d920-4a50-93e9-b347a3f1e373.mp4

[brunocastello]

I also tried disabling hw accel support for sb16 in win98. Didn’t help much other than giving me more minutes before another freeze.

As for Wine, I don’t use linux, the options in a M1 MB Air are limited to crossover and wineskin winery on macOS, both don’t work too good. I only managed to run Grand Prix 4 and Counter Strike 1.6. However, I cannot use it; after a long period of play, the mac is overheating more than my previous Intel MB Pro did. That’s because these two games are demanding a lot from emulation, and I am concerned with battery health, so I stopped using it.

I never had problems with dosbox and qemu other than this sound issue on dosbox. M1 temperature remains pretty stable, it does heat a bit but nothing much different to the 2nd gen iPad Pro I previously owned and sold later.

M1’s thermal temperature works amazingly well, even when I have a 8 hour work on Adobe XD it remains colder than a winter in Spain…

@grapeli try dxdiag and run the sound tests. you’ll see it fail, but the outcome might help us to find more about this problem.

[grapeli]

Passes this test.

https://user-images.githubusercontent.com/452325/144758457-97c80371-8e8d-4483-8d2b-01340a509f63.mp4

Defect after pressing "Exit" from dxdiag, an error occurs, dosbox-x exits with the following message: E_Exit: RET from illegal descriptor type 0.

[grapeli]

Premature hurrayoptimism - changing disabling hw accel only extends the stability in NFSIISE up to 2 minutes (not enough).

edit: With sbtype=none the game is stable (I didn't test for more than 8 minutes). Unwanted graphic artifacts do not appear. What is this merit? Better performance (definitely higher framerate) or no sb16 support.

[brunocastello]

Mine didn't pass the dxdiag tests. I was gifted with a message about only software modes being supported, no sb16 hardware acceleration at all. Even though I have tried with both hw acceleration enabled and disabled.

[grapeli]

Passing the test = I can hear the correct playback of individual sound samples.

You sound card does not support hardware buffering. Sounds will only play back from software buffers. This message does nothing to pass the test in my opinion.

[brunocastello]

Yup, I know. This was the exact same message I got here.

With QEMU-3dfx I made the same test and it passed the tests, no unexpected messages until the end.

[joncampbell123]

Muahaha... good news, I finished an in-tree tool to patch dylib references in Mach-O dylib and executable files.

I am able to make .app bundles for ARM Mac OS X again, by using my own custom tool instead of install_name_tool.

https://github.com/joncampbell123/dosbox-x/blob/master/src/tool/mach-o-matic.cpp

[brunocastello]

@joncampbell123 I compiled the latest code and noticed one thing:

The dynamic_x86 option is not available anymore. Only dynamic_rec if I want to use a dynamic core. Is it proposital?

EDIT: dynamic_x86 in previous builds was lightning fast on M1. Meanwhile, I tried to run NFS2SE on this new build and got the same results as above from my tests and from grapeli's tests. I ran these tests twice, with and without glide passthrough.

[grapeli]

The sound problems are rather related to NFSIISE. The included readme.txt file contains the following information.

SOUND CARDS WITHOUT DIRECTX SUPPORT

If you are using a sound card, Need For Speed II SE requires that it be supported by DirectX drivers. If your sound card drivers do not have DirectX support, you may experience delayed sound, stuttering, or sound drop out. In addition, you may experience some difficulties maneuvering in the menus with your joystick, if it is attached to the sound card's game port. If this is the case, you can maneuver in the menus with your mouse or keyboard.

I tested a few other games and there was no similar sound problem with them.

edit: Another such observation. It is stable for max 120 seconds with sbtype=sb16 and cputype=pentium_ii only. With pentium_mmx, you exit the game as soon as the track location is loaded.

[joncampbell123]

@brunocastello dynamic_x86 and dynamic_rec availability is chosen at compile time.

[brunocastello]

The sound problems are rather related to NFSIISE. The included readme.txt file contains the following information.

SOUND CARDS WITHOUT DIRECTX SUPPORT

If you are using a sound card, Need For Speed II SE requires that it be supported by DirectX drivers. If your sound card drivers do not have DirectX support, you may experience delayed sound, stuttering, or sound drop out. In addition, you may experience some difficulties maneuvering in the menus with your joystick, if it is attached to the sound card's game port. If this is the case, you can maneuver in the menus with your mouse or keyboard.

I tested a few other games and there was no similar sound problem with them.

edit: Another such observation. It is stable for max 120 seconds with sbtype=sb16 and cputype=pentium_ii only. With pentium_mmx, you exit the game as soon as the track location is loaded.

@grapeli I wouldn't put it all down to NFS2SE when there are other 3 or 4 similar issues I mentioned in this thread with other games plus more two games I tried (FIFA 98 RTWC and FIFA 99) and they presented the same problem to me. Let me find them to comment here for reference.

QEMU (vanilla build) has SB16 emulation too, and does not present the same problem with the three games (NFS2SE, FIFA 98 RTWC, FIFA 99). In fact, they all run flawlessly there, albeit without 3dfx. But With the QEMU-3dfx fork, I can run them with sound and 3dfx also flawlessly. So I find it difficult to think that it is all down to directx sound support in a game, when the same sound card emulated in another emulator does not present a such problem.

EDIT: Here are them https://github.com/joncampbell123/dosbox-x/issues/2689#issuecomment-944844853

[brunocastello]

@brunocastello dynamic_x86 and dynamic_rec availability is chosen at compile time.

@joncampbell123 How do I choose it? I tried when I first managed to compile your new code this afternoon, but looks like I did something wrong. I basically edited build-macosx to build an ARM version without avcodec and libfluidsynth (until then I was using the release builds) and tried to enable dynamic_x86. I might have missed something. However it compiled successfully, and worked, but without this cpu core option.

[Wengier]

@brunocastello The dynamic_x86 core is available when the code is compiled on x86 and x64 computers, but not if the code is compiled on ARM computers. It is probably unavailable if you build the code on an ARM64 computer.

[brunocastello]

Hmmm... if I understood it correctly, if I cross compile for M1 on my old Intel MBPro, it won't make any difference at all? Bummer... because the dynamic core on M1 is somewhat slower with the dynamic_rec, but OK.

[joncampbell123]

dynamic_x86 is more x86-oriented, by it's name :)

[brunocastello]

Well, I plan this weekend to try out a Win 95 install on both DOSBox-X and DOSBox vanilla, to see if the sb16 problem still persists

[grapeli]

The NFS2SE version without 3dfx with sb16 is clearly more stable for me. At first I got the impression that it was completely. The first attempt with a race lasting over 5 minutes was completely successful (I did not want to play longer).

During this recording, I quit the game unexpectedly. The audio lag is significant.

https://user-images.githubusercontent.com/452325/145673828-4f765b2d-dd3f-4466-a918-1ffdf110436c.mp4

[rderooy]

As I mentioned, after starting Win98SE I can play NFS2SE just fine with sound (I tried 2 races in a row), it is only after I quit the game and re-launch it that it crashes back to the win98 desktop.

But when I messed with the graphics options in NFS2SE and turned everything up to max, after starting the race after a few seconds it dropped me to the desktop.

This is on my Linux system (AMD Ryzen 5600X)

[brunocastello]

You can try out Need For Speed II SE and FIFA 99.

If you can race without a crash to desktop several times, and if you can play a match without the game screen freezing on match kick-off while the commentary is still going on, then you've found the gold.

Don't forget to share the configuration in case you manage it. I've been trying that since 2020 without much success.

And I don't think I can do it now that I am on a M1 MacBook Air and the dynamic core doesn't work as well as it does on intel.

Edit: Just tested the latest ARM version for M1 and while it does perform better under Windows 98, Gaming issues previously described here still persists.

[grapeli]

@brunocastello Wine is a first-class platform for running games under linux. I suspect that it also works well under macOS. Only on Windows it does not work well, but when microsoft refines accelerated video output to a linux virtual machine, then it will call it something WSL3, then Windows users will be able to use wine.

https://user-images.githubusercontent.com/452325/152619181-313dea50-ec1c-4b80-b291-a5265d43e295.mp4

NFSIISE works very well under wine. Also in the 3DFx version (maybe even better). In the latter case, a cross-platform wrapper can also be used. https://github.com/zaps166/NFSIISE

[brunocastello]

@grapeli Thank you, I appreciate your suggestion, but my problem here is more than just one game in particular. There are other games like FIFA 9x, Grand Prix 3 and NBA Live 98 in the same situation, and I have collected a few reported issues from other users here with a similar problem, and these issues may be pointing the finger to some SB16 emulation issues; when there is no sound device being emulated, these games can run.

I chose to go with a qemu fork with glide passthrough support. Works fine for glide games. Not so well for MESA GL passthrough since I cannot find a proper WineD3D library to do it. And the full screen support is lackluster.

But anyway, it runs nearly all of my games so I am kinda satisfied: https://github.com/kjliew/qemu-3dfx

I know WINE, I am forced to use CrossOver for more modern games like Grand Prix 4, but it's not what I want; I want a full classic windows environment and old games for nostalgia purposes. Running a classic game under a modern environment is not exactly my goal here. DOSBox and QEMU are my only alternatives to do that on my M1 Mac.

[brunocastello]

So... has anyone else tried to investigate the problem further?

[brunocastello]

As of the latest release .23, the issue still remains persistent. Gaming is only possible with sbtype=none.

[brunocastello]

Right, anyone knows how can I investigate by myself the issue, and/or why it can't let me game with sound on? Since 2020 I can't do it on both Intel Mac (2013 Intel rMBP 13") and M1 Mac (2020 M1 MBA "13). Two different architectures, yet the same problem is presented to me.

I have no custom sound setup whatsoever on my mac. I can't figure out what is causing the issue for me and this is driving me nuts. I don't even know if something from homebrew or xquartz or whatever has something to do with it. I have a custom OpenGlide built for QEMU-3Dfx, but DOSBox-X is not using glide passthrough by default, so this can't be the cause of the issue too. Do I have to run it as root? Any ideas? Because I've tried nearly all I could think of in the last two years.

I simply start any game, for example Need For Speed II SE for 3Dfx, and as soon as I get to the starting grid with the lights countdown, the game crashes me back to Windows 98 desktop. I've even tried creating a brand new Win 98 install from scratch and no luck.

Games run just fine if I set sbtype=none (but then I have no sound for my games).

[brunocastello]

I have just created today a brand new Win 98 install using a different ISO image than I had used previously, and following the same instructions provided by @rderooy and I still cannot game. I installed Need For Speed II SE to test. I can only play the game when sbtype=none, otherwise game crashes back to win 98 desktop when the race starts. I have the latest DX9, latest Voodoo and latest SB drivers.

I am having trouble to diagnose why I have that problem since 2020 on both Intel and M1 Macs, even though I have not done any special stuff on my environment that could cause it. I could only isolate the problem and it is totally related to Sound Blaster emulation within games.

[Wengier]

@brunocastello Perhaps you can actually post your installed Windows 98 image for others to test?

[brunocastello]

@brunocastello Perhaps you can actually post your installed Windows 98 image for others to test?

Its a 16gb disk image. I could upload it to WeTransfer but I’m in Spain with an limited internet. I’ll be back to Rio in May.

Same install files I used for this one works 100% when I use qemu-3dfx, but it’s not practical.

[grapeli]

Very small win98se image, 146MB compressed, 400MB unpacked. https://drive.google.com/file/d/1bu4562Qkj_JKug_0ESrBMSLZOUBCIHPp/view?usp=sharing Includes three demos - NFS2SE, NBA 98Live, and F1 Formula (Psygnosis). All with 3DFx support.

I run like this. dosbox-x -fastlaunch -set "log logfile=dosbox-x.log" -set "log vga=debug" -set "log vgagfx=debug" -set "log vgamisc=debug" -set "log int10=debug" -set "log dma_control=debug" -set "log fpu=debug" -set "log cpu=debug" -set "log paging=debug" -set "log fcb=debug" -set "log files=debug" -set "log ioctl=debug" -set "log exec=debug" -set "log dosmisc=debug" -set "log pit=debug" -set "log keyboard=debug" -set "log pic=debug" -set "log bios=debug" -set "log misc=debug" -set "log io=debug" -set "log pci=debug" -set "log sst=debug" -set "log int21=true" -set "log fileio=true" -set aspect=true -set "dos lfn=true" -set "dos ver=7.10" -set "dosbox quit warning=false" -set "dos hard drive data rate limit=0" -set memsize=128 -set showmenu=false -set char9=false -set scaler=none -set cputype=pentium -set core=dynamic_x86 -set output=opengl -set voodoo_card=opengl -set cycles="max 105%" -set "ide, primary int13fakeio=true" -set "ide, primary int13fakev86io=true" -c "@imgmount c win98se.img >NUL" -c "boot c:"

NFS2SE is very unstable (sbtype=sb16 sound enabled). Works from 1s to 4 minutes correctly. Stability definitely decreases with cputype=pentium_ii. Run with cputype 486 or pentium.

Unfortunately, there are some unwanted graphic artifacts in each of the demos. The menu on nba98live is sluggish. In the F1, they are visible in front of the car's hood practically all the time.

edit: I tested these demos under wine 7.6. They work well, and maybe very well. With a small exception in NBA 98Live, similar artifacts appear in the menu of this game (only in the 3dfx version). The menu is slow.

What distinguishes NFS2SE in operation under dosbox-x and wine (apart from performance)? No sound under dosbox-x when driving into the mine, tunnel (if someone gets there). You should hear a pseudo-spatial sound, reverberation. It's quiet.

[brunocastello]

I just compiled the latest source code (0.83.25) with the PR 3428 to test the SDL2 yellow tinted windows fix.

The yellow tinted windows was fixed. However, when I try to run a 3dfx game (like NFS II SE) DOSBox-X crashes and closes.

I tried the non-3dfx version of NFS II SE and it does run.

[brunocastello]

@joncampbell123 as we spoke on Discord yesterday, I ran a few tests. I haven't tested a build compiled without FFMPEG yet. But last build from 2 days ago had --disable-libfluidsynth and --disable-avcodec. So I think this test has been done before, right?

Anyway, the latest tests. I installed Win 98 SE fresh, updated drivers (both sb16 and voodoo, and installed VBEMP 9x drivers for higher resolutions*). And installed Need For Speed II SE as usual. Then I proceed to test the 3Dfx version of the game, the reason why I want to run it on dosbox-x.

0.83.25 and 0.83.24 = NFS II SE crashes dosbox-x and closes it when I attempt to run the game 0.83.23 and 0.83.22 = I can start the game, go through RACE menu, and as soon as I get to the track, the game crashes back to Win 98 desktop. Subsequent attempts to run the game again have the same fate.

I am yet to try out without sound and to try out without FFMPEG. I have a barbecue to go now, in a few hours I'll be back to run the remaining tests.

One thing to note, is that when I get to the main menu, there are a few graphics glitches up and down. When I attempted to use a ready-made Win 98 install from QEMU, this did not happen, however I couldn't race too. That install had nothing different, same drivers, same files.

• = I had even tested without that VBEMP driver before, and the problem persisted.

[brunocastello]

I had a few minutes to test without sound (sbtype=none) before going out.

0.83.21: game runs just fine without sound. 0.83.23: game runs just fine without sound. 0.83.24: (current release, April 1) game crashes when attempt to run it. This release is also missing the SDL2 yellow screen fix that I tested a few days ago. 0.83.25: (latest release, 1h ago) game crashes when attempt to run it.

Next when I'm back is to test compiling a SDL2 build without FFMPEG (--disable-avcodec, right?) However, I don't expect it to be the problem, because I have compiled with that flag since the past year and the problem persisted.

Update: All the above tests were done and results still stands. Something in the last two releases is preventing the games to start. Meanwhile, the previous releases can start the games, but the old problem of this issue still stands.

Tried with/without sound, different cpu types (486, pentium, pentium_ii, pentium_iii) but no go.

[maron2000]

NFS2SE runs fine but without sound & Voodoo on 0.83.25 Windows x64 SDL1/SDL2 Visual studio build. I finished a two laps race. CPU is Dynamic core / auto.

[brunocastello]

Yeah, macOS version of Dosbox-X has a problem on 0.83.25. The emulator just crashes whenever I run the game.

Attached the dosbox-x.conf I am using (had to save as txt to be able to upload): dosbox-x.txt

I want to run certain settings to be able to run things like Netscape 9 (heaps of memory) and some certain games, not just NFSIISE.

[grapeli]

Linux DOSBox-X 0.83.25 SDL2. Works fine with 3dfx without sound. There are no unwanted graphic artifacts. It is fully stable.

double speed of the video

https://user-images.githubusercontent.com/452325/166226760-434cc34b-5f41-4e72-b519-f869539cdde3.mp4

With sbtype=sb16 it is unstable. Unwanted graphic artifacts appear. Audio delay is up to 20 seconds (after leaving the tunnel).

https://user-images.githubusercontent.com/452325/166226869-17466df9-feae-4d89-81d7-9c8036274dd7.mp4

There is no difference in operation between the demo and the full game. Both versions behave identically.

[brunocastello]

@joncampbell123 this is the macOS error report generated when I try to run NFS2SE with a 0.83.25 build and it crashes.

report.txt

I've just compiled now this build with --disable-libfluidsynth (because the build script installs fluid-synth from brew with some other dependencies) and --disable-avcodec (because you wanted to see something about FFMPEG).

[joncampbell123]

@joncampbell123 this is the macOS error report generated when I try to run NFS2SE with a 0.83.25 build and it crashes.

report.txt

I've just compiled now this build with --disable-libfluidsynth (because the build script installs fluid-synth from brew with some other dependencies) and --disable-avcodec (because you wanted to see something about FFMPEG).

It crashed in glViewport? Figures. I had to make other adjustments some time ago when calling glFinish before starting a frame would crash the Mac OS X OpenGL library if no prior frame had been started.

There is already a flag to track that for that reason, perhaps that flag needs to be used in the Voodoo emulation as well, not to call certain functions until a proper frame has been started.