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]

I have not yet tried installing Windows 98 SE on macOS. I wonder if this issue is specific to macOS?

[brunocastello]

If it is specific, I'd love to hear. I have noticed that DOSBox-X gives wrong IRQ, DMA and HDMA to the SB16 when I reach the Windows 98 Desktop. But fixing that issue did not fix my problem. Here's the thing:

I've set I7 D1 H5 for sb16 in dosbox.conf. yet when checking the assigned values from DOSBox sound menu, it's 2, 3 and 5 (I can't remember now, I'm at work, but basically it's not what I have assigned). Then I removed it from dosbox.conf and manually assigned them through Device Manager in Windows 98SE, as well as set the blaster environment in autoexec.bat. Now DOSBox-X reports the right configuration, however, the games still crash.

Since it crashes with both glide and software mode when sound is enabled, I already discarded any issue with OpenGlide; I have tried with both kjliew's and almeath's OpenGlide implementations as well.

Could it be a SDL audio issue? Does SDL even deal with it?

[Wengier]

@brunocastello It is interesting to hear that the sound menu shows a different IRQ than the one assigned in the config file. Does this issue happen when you are in DOSBox-X' integrated DOS? Or only when you boot to Windows 98 desktop?

As for SDL, it might be related. Have you tried the SDL2 build and see if there are any changes?

[brunocastello]

@Wengier happens when I boot to Windows 98. I haven’t checked when using integrated DOS, because I have never used. But shows correct one when I force them through Windows 98 Device Manager.

SDL: I didn’t even try SDL2 as far as booting into Windows 98, because the SDL2 build has 2 problems for me, the yellow screen (no matter what video driver I use, it is always yellow) and OpenGlide works only with SDL12. So without OpenGlide I couldn’t test these games in SDL2 build...

[Wengier]

@brunocastello The main purpose for trying the SDL build is not to actually use it as the main build, but to try to isolate the issue. Whether it works there may help us find out the cause of the problem. Similar for the IRQ assignment.

[brunocastello]

OK, I will try to find some time next night to try it out. I was out for dinner this night.

[brunocastello]

@Wengier compiling a SDL2 build to test as we speak... btw the compiler returned this message:
configure: WARNING: unrecognized options: --disable-video-x11-xv
Pretty sure something was overlooked there?

Okay, compiled. Let's see if it will let me play with sound on, despite of the yellowish screen desktop:

Edit: I tried both versions of Need For Speed II SE (NFS2SEN and NFS2SEA). Both crashed to desktop before race start.

[stephenbonar]

Ah, I'm having the same issue! I couldn't understand why so many games were crashing in Win98SE until I saw this issue. In my case, the games I was trying were not 3D accelerated (Heroes of Might and Magic II, Might and Magic VI), but as soon as I set sbtype=none, the games are stable. It did seem like certain sounds were possibly triggering the crashes. I just tried changing the config on the Apple M1 version of Dosbox-x (0.83.15), but I had the same problem on other platforms (Windows x86_64). I have yet to see if this fixes the crashes on the x86_64 builds.

[stephenbonar]

In the issue I linked to in my previous comment (#2621), the author discovered that changing the CPU type from pentium_mmx to pentium resolved the issue. Sure enough, I tried it on my M1 Mac and it indeed resolved the issue for me as well (I believe the author was on x86_64, but it resolved it on both platforms). @brunocastello I would try this and see if it fixes the issue with your games too. If it does, I would suspect there's an issue with sound involving the pentium_mmx cpu type. @Wengier , any thoughts on that possibility?

[brunocastello]

@stephenbonar actually I have tried it before, and no, it does not solve my issue. No matter what cpu I set for Windows 98SE, all games will crash if I attempt to play with sound on. Without sound I can play them all.

I have tried pentium mmx, pentium pro, pentium, 486, and even set it to auto. no luck.

[brunocastello]

The problem is still persistent with the most recent builds released, both SDL1 and SDL2.

[brunocastello]

Maybe it could be a problem between DOSBox-X and macOS coreaudio? I am yet to set up dosbox-x with an ubuntu linux x64 VMware machine to check it out, using the same Windows 98 image I am using for dosbox-x. But since three or four versions (for macos) ago, I am unable to play any game under Windows 98 SE with any sound card. When there is no sound, all games run without any problem.

[brunocastello]

@Wengier I think I have made some little progress. I went to dxdiag in Windows 98 SE and turned off Hardware sound acceleration. This time I was able to play for a couple of seconds before it crashed to the desktop again.

NFS2SE: I nearly managed to complete a lap before CTD
FIFA 98: Managed to score a goal after kick-off before CTD
FIFA 99: CTD right on kick-off (no change of behavior)

There is definitely a sound problem and it is related to the game's speed.

[brunocastello]

Version 0.83.17, still unable to game with sound on. Games crash on Windows 98SE when there is sound.

EDIT: Compiled latest code (0.83.18) without avcodec and fluidsynth, yet the situation persists. I have to set sbtype=none (no sound) to be able to play any games on it.

[brunocastello]

Anyone with any suggestion about what else I can do to work around this issue? It has been there since July

[Allofich]

One thing I would try is setting the SB16 IRQ to 5 in the .conf file (or set it to 0, in which case it DOSBox-X will automatically set it to the default value for the sound card, 5 in this case). As I understand, 5 was the default value used by SB16 cards, while 7 was for an earlier card.

If that doesn't fix it, above you wrote "DOSBox-X release version: SDL1.2 0.83.15 (The problem is persistent since several versions before)". Were you able to play those games without issue on some version in the past? If you have time to test, working back through the earlier versions one-by-one to find between which versions the issue first occurs would probably help in locating the issue.

On the other hand if no version works no matter how back you try, it might be an issue that was always there or a problem with your settings.

[rderooy]

The original soundblaster cards indeed defaulted to IRQ7, as on XT class machines IRQ5 may be used by the harddisk controller.

IRQ7 was always a problem as it conflicts with LPT1. But few DOS programs ever used the IRQ for parallel communication, so typically you were fine, and even if they did, you would normally not have sound at the same time.

The problems started with OS/2, as you could have sound and printing simultaneous (and later with Win95 and WinNT). I remember there was at one point an update to the OS/2 printing driver to (optionally) use pulling mode, which results in higher CPU load, to prevent issues with a sound card on IRQ7.

From what I recall, the change to IRQ5 happened at the time of the SB Pro 2.

[brunocastello]

The problem predates way long before, since 0.83.11. And yes, I have tried every version released after that (and before that) back when I first reported it.

I am using the exact same settings as seen in Windows 98 Wiki Guide. No fancy extra settings apart of voodoo glide high level pass through. Also tried both IRQ5 and IRQ7. Also tried all sorts of available cpus (auto, 486, pentium, pentium_mmx...).

No idea why, the games can only run when there is no sound blaster emulation. When there is, they all crash: FIFA 98 RTWC, FIFA 99, NFS2SE. I am at a complete total loss.

[brunocastello]

Tonight I tried the Windows version of DOSBox-X using a build from @Allofich (from another issue here) and in a Windows 10 Pro VMware Machine.

Turns out I have the same problem there: sbtype=sb16 and crashes, sbtype=none and I am able to play everything but without sound.

So the problem must be something with Sound Blaster inside Windows 98 that I cannot seem to debug nor find out why. I have the latest SB16 drivers as recommended from the Win98 Install Guide, as well as DirectX 9.0c.

[brunocastello]

Another night, another attempt. This time again on macOS SDL1 version with a fresh install of Windows 98 SE.

Post install: VBEMP 9x driver, DirectX 9.0c (DEC 2006) and last voodoo driver. Installed Need For Speed II SE and tried to run the 3Dfx version. Since it's a sound issue, I did not update the Sound Blaster 16 drivers this time to try and find out if the drivers are a part of the problem. Well, they're not. As soon as the race is about to start, the game crashes to the desktop.

Configuration file (renamed to .txt because GitHub wouldn't allow me to attach):
dosbox.txt

Third attempt trying with default S3Trio display driver instead of VBEMP: Same outcome

[brunocastello]

Running dxdiag to test the sound, after I have confirmed that I could hear all demo sounds, the dxdiag reported this to me:

Your sound card does not support hardware buffering. Sounds will only play back from software buffers.

No matter what I do, change, or try, I can only play the games without sound. Bummer. Even a clean Win98 install wouldn't allow me to play a clean NFS2SE install.

[brunocastello]

I've also noticed that I do not have the"SB16 MIDI OUT [330]" instrument listed on multimedia properties, only Creative Music Synth, "MPU 401 ..." and something like "Roland OPL3 Synth...". Don't think it has something to do, because NFS2SE, FIFA 9X aren't games with MIDI sounds AFAIK?

@Wengier I tried 0.83.10 (mentioned here #2260) this night, since it was around after this version or .12 when MMX and dynamic_x86 core improvements were put in place. However I had the same problems. It's not a core or cpu problem, I have tried them all in various combinations possible, and with or without 3dfx, I can only game when there is no sound card present. Sometimes in NFS2SE I can drive for a few seconds until I CTD.

I know it's not a problem with my Windows 98 SE install because in QEMU I can play them (without 3Dfx or using the overcomplicated kjliew's Glide Passthrough). So it's definitely a problem isolated to the sound card. I've tried sbtype=sb16 and sbtype=sb16vibra. IRQ, DMA, HDMA, all values are correct, sound is played. But something crashes the games.

[rderooy]

The names of the entries in Multipedia Properties is dependent on the exact Windows release (or SB driver version) installed.

"SB16 MIDI OUT [330]" and "MPU 401..." are equivalent. I don't know where this Roland OPL3 Synth entry is from. You must have installed something as I don't recall seeing it with my testing.

Did you ever try if you get crashes with other sound card options, like a SB Pro 2?

[brunocastello]

The names of the entries in Multipedia Properties is dependent on the exact Windows release (or SB driver version) installed.

Windows 98 SE fully updated.

"SB16 MIDI OUT [330]" and "MPU 401..." are equivalent. I don't know where this Roland OPL3 Synth entry is from. You must have installed something as I don't recall seeing it with my testing.

Well, I did not. I think this comes from the oplemu setting in configuration file? This device will probably disappear if i set oplemu to none, I think.

Did you ever try if you get crashes with other sound card options, like a SB Pro 2?

Now that you've said it... actually, no. Might try it tomorrow, it's late for me now and I haven't been sleeping well for weeks, staying late and trying to improve my QEMU/DOSBox VMs. However, I think that I need to repeat that the QEMU VM machine also has a SB16 installed, and does not have these issues. I just do not use that VM because only DOSBox-X has a proper 3Dfx emulation/Glide passthrough.

With that in mind, I'd politely ask for a revision on the SB16 card for DOSBox-x, to see if something wasn't missed or misinterpreted? Can we also check it? Because I have this issue since June/July builds.

[rderooy]

@brunocastello I do think there is a something missing in the SB16 emulation or a bug, which is causing these problems. Having said that, it requires someone with the technical knowhow, skills and time to fix it.

I'm not that person, and from what I have seen both @joncampbell123 and @Wengier have a lack of time right now.

[brunocastello]

@brunocastello I do think there is a something missing in the SB16 emulation or a bug, which is causing these problems. Having said that, it requires someone with the technical knowhow, skills and time to fix it.

I'm not that person, and from what I have seen both @joncampbell123 and @Wengier have a lack of time right now.

I just came here to add that even the Windows version had the same problem under a VMware Windows 10 virtual machine. I used the one from @Allofich , where he fixed another issue related to img mount.

[joncampbell123]

To explain the programming mistake, my code back then used DirectSound to record from the microphone at 44.1KHz 16-bit stereo. I was writing something to record radio shows and I had arranged a sound board to use two microphones side by side to pick up the voice in stereo.

It would have been a good test recording except that I found out too late the L and R channels constantly switched back and forth.

My code assumed the playback byte position reported would be aligned to a complete stereo sample in the buffer, but because the Windows 98 drivers reported directly from the DMA controller, the reported byte position was sometimes in the middle of the complete sample, meaning, since it was obviously using 16-bit DMA, sometimes the reported position would be right between the 16-bit L and R samples meaning the DMA had written L, but not yet R. I've been writing my code to round down the reported position by nBlockAlign since.

This would around 2001 or so with an old Pentium laptop running Windows 98 that had one of those "OPL3SAx" Sound Blaster Pro compatible WSS chipsets that they had obviously connected to the ISA bus internally.

[joncampbell123]

A quick check: Whatever it doesn't like about SB16 emulation it dislikes the ESS 688 AudioDrive emulation even more.

[casasfernando]

Just found this github issue after troubleshooting the problem for a few hours.
I’m using Dosbox-X flatpak latest version (2022.09.0 64bit sdl2) on Ubuntu 20.04 and indeed changing sbtype to none stops NFS2SE from crashing anymore (3dfx enabled).
I can also confirm that the same issue affect other NFS games like High Stakes.

Are there any debug logs or something that can be collected to help narrow down this issue?
Dosbox-x log didn’t show any information or error when the game crashes so it was very difficult to troubleshoot so far.

[grapeli]

Under dosbox-pure it is very similar. I suspect that if someone would test NFS2SE under dosbox-svn or dosbox-staging, of course, with the necessary patches extending the capabilities of these programs, the effect would be the same.

The error is hidden deep in the dosbox code.

I don't think it has anything to do with soundblaster. I tested NFS2SE under dosbox-x with GUS and it behaves the same as with soundblaster. There is a quick exit when the game starts.

With sbtype=sb16 and 3dfx I sometimes managed to complete the whole race (over 4 minutes), but most of the time the error occurred 15-30 seconds after the start of the race.

[casasfernando]

@grapeli Thanks for sharing this as testing GUS was my next step so I can skip it now.
I’m wondering how can this be debugged because certainly not from the game itself.
Maybe from DirectX if this is what for instance NFS2SE uses for sound?

[grapeli]

@casasfernando
As I thought this bug is not exclusive to DOSBox-X. It's the same with dosbox-staging. I tested on the latest version git with five patches from the ww/fat32-test-1 and ww/voodoo-3dfx-2 branches included.

In the recording, the exit to the desktop occurs very quickly. Other times it took about a minute and a half.

NFS2SE.dosbox-staging.webm

[casasfernando]

@grapeli in my case with none of the games I get that far, meaning race shows for a few seconds. For me, both NFS2SE and NFSHS exit one second or less after the race loading finishes and the "race environment" is displayed. Sometimes I get to see a a few frames of the car or the track, but it crashes almost right away..

Anyways, the problem is how to debug this issue. So far we only know the may be in the sound emulation code path because as soon as sound emulation is disabled the problem goes away.
I'm willing to help testing, collecting logs, etc. just need guidance on what information would be needed because I'm new to DOSBox in general and DOSBox-X in particular.

Thanks

[grapeli]

If this bug is so hard to diagnose with NFS2SE it might be worth a try with the Need for Speed High Stakes Demo, which behaves very similarly, except that exiting the game to the desktop ends with a detailed error message.

[grapeli]

The error EXCEPTION_ACCESS_VIOLATION: read attempted in High Stakes appeared on real hardware configurations.
The most common cause suggested is a problem with the graphics driver or the directx version.
You can find this information in the readme.txt file for this demo.

AUDIO PROBLEMS
In some cases, sound problems are caused by video drivers. Make sure you have the latest video drivers for your video card.

Of course, this demo with sbtype=none works perfectly fine. Except for one drawback - there is no sound.

[casasfernando]

@grapeli which DirectX version and graphics drivers are you using?
In my case I installed (maybe I shouldn’t) DirectX 9.0c and the Voodoo drivers are the one mentioned in the wiki for Win98. I can check the exact version later on and report back.

[grapeli]

@casasfernando
I posted a link to the win98se disk image a few posts above. I'm testing it on exactly the same.

[casasfernando]

@grapeli my setup is mostly the same except that I'm using the S3 emulated card with the OS driver. I'm wondering if it makes sense trying with an older version of DirectX. I was planning to create a new image anyway because wanted to switch Win98 to english (currently I'm using the spanish version) so when I do that I will try to test NFS2SE and NFSHS with whatever version comes with the game and check if it makes any difference but I'm not holding my breath.

[grapeli]

@casasfernando
I haven't noticed a difference in stability between the two drivers. Also in those games listed here.

The main and essential reason why I use the VBE driver is its much better performance.

Run Crystal Mark on both - CM09GDI and CM09D2D. You can read the results in ini files. While in GDI the difference is tiny, in 2D it is 50% in favor of VBE. Huge. This difference is also visible in other cases I tested.

[kcgen]

@grapeli ,

I understand Staging's Voodoo and FAT32 branches are ports of the DOSBox-X sources. Maybe Meson's Address and Undefined Behavior Sanitizer (UB+ASAN) build will reveal issues in the Voodoo or FAT32 code?

Setup:

meson setup \
  -Dbuildtype=debug \
  -Doptimization=0 \
  -Db_lundef=false \
  -Db_sanitize=address,undefined \
  -Dc_args=-fsanitize-recover=all \
  -Dcpp_args=-fsanitize-recover=all \
  -Dunit_tests=disabled \
  --native-file=.github/meson/native-clang.ini \
  build/clang-ubasan

Build:

meson compile -C build/clang-ubasan

Executable: build/clang-ubasan/dosbox

It will run slow, but it might help reveal issues at the moment the game cuts out back to Windows, which would be common to both projects. Atleast, if the code has problems at the host level (as opposed to emulation level).

[grapeli]

@kcgen
No chance to run Win98SE in dosbox-staging built with clang sanitizer (llvmorg-16-init-10467-g1239d37b-1).
Unless I'm doing something wrong.

Dosbox-staging terminates shortly after the win 98 desktop appears. There is still a long way to go before the system is fully loaded.
Log with core=dynamic.
dosbox-staging.clang-ubsan.core-dynamic.log
Log with core=normal.
dosbox-staging.clang-ubsan.core-normal.log

In the latter case, once the loading of the system stopped at this point.

[grapeli]

In dosbox-x compiled with clang (-fsanitize=undefined) NFS2SE it starts.
At the time of the error and when exiting the game in the logs I received this information.

voodoo_emu.cpp:2635:29: runtime error: index 768 out of bounds for type 'UINT32[9]' (aka 'unsigned int[9]')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior voodoo_emu.cpp:2635:29 in
mixer.cpp:359:62: runtime error: left shift of negative value -20066
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior mixer.cpp:359:62 in
voodoo_data.h:918:46: runtime error: left shift of negative value -3
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior voodoo_data.h:918:46 in
voodoo_opengl.cpp:226:31: runtime error: signed integer overflow: 163 * -9223372036854775807 cannot be represented in type 'INT64' (aka 'long')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior voodoo_opengl.cpp:226:31 in
voodoo_opengl.cpp:226:57: runtime error: signed integer overflow: -931 * -9223372036854775807 cannot be represented in type 'INT64' (aka 'long')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior voodoo_opengl.cpp:226:57 in
voodoo_opengl.cpp:245:35: runtime error: signed integer overflow: 163 * -9223372036854775807 cannot be represented in type 'INT64' (aka 'long')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior voodoo_opengl.cpp:245:35 in
voodoo_opengl.cpp:245:64: runtime error: signed integer overflow: -931 * -9223372036854775807 cannot be represented in type 'INT64' (aka 'long')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior voodoo_opengl.cpp:245:64 in
voodoo_data.h:918:46: runtime error: left shift of negative value -15
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior voodoo_data.h:918:46 in
voodoo_opengl.cpp:226:50: runtime error: signed integer overflow: -9223372036854775547 + -576460752303423280 cannot be represented in type 'INT64' (aka 'long')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior voodoo_opengl.cpp:226:50 in
voodoo_opengl.cpp:245:57: runtime error: signed integer overflow: -9223372036854775547 + -576460752303423280 cannot be represented in type 'INT64' (aka 'long')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior voodoo_opengl.cpp:245:57 in
voodoo_opengl.cpp:226:24: runtime error: signed integer overflow: -9223372036854775807 + -576460752303423234 cannot be represented in type 'INT64' (aka 'long')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior voodoo_opengl.cpp:226:24 in
voodoo_opengl.cpp:245:28: runtime error: signed integer overflow: -9223372036854775807 + -576460752303423234 cannot be represented in type 'INT64' (aka 'long')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior voodoo_opengl.cpp:245:28 in
LOG: VOODOO: OpenGL: quit
LOG: 2295202800 DEBUG MISC:GFX_SetSize 640x480 flags=0x14e scale=1.000x1.000
LOG: menuScale=1

I will mention that I previously tested NFS2SE in dosbox-x with both openglide and voodoo_card=opengl and voodoo_card=software. Same error everywhere. The worst is with openglide, because it freezes dosbox-x.

[casasfernando]

@grapeli the above looks like a very good lead on where in the code the problem may be.
What is a bit misleading is that only Voodoo emulation related code is mentioned while the issue seems to be triggered by sound emulation. I’m not familiar with the code so looking forward @joncampbell123 or other devs thoughts on this.

[grapeli]

@casasfernando
It's not so obvious. Please note that this instability also occurs in the non-3Dfx version (nfs2sen). This is not exclusive to the 3Dfx version.
I'm not a developer, I don't know what this clang tinkers with when running the code and whether these reports are false.

[grapeli]

@casasfernando
Regarding the non-accelerated version of NFS2SE, it is generally much more stable. Many times I finished the whole race lasting about 6-7 minutes.
I also tested its behavior in dosbox-staging now. I completed two full races totaling nearly 13 minutes. During the third, after about a minute, there was an unexpected end to the game.
Compared to the 3Dfx version, it is much more stable.

[kcgen]

Thanks for those build and test results, @grapeli.
This will be useful when @Wengier's voodoo branch is PR'ed and reviewed -- if we can make any improvements, no doubt we can try them in X and see if helps.

[maron2000]

According to @grapeli 's log, there is a left bit shift of a negative value in mixer.cpp, which its behavior is undefined if I understand correctly.
Maybe we should change the code not to use bit shift.

[grapeli]

@maron2000
With this setting (disable filtering=true), you don't get this mixer warning, and the game still doesn't work properly.

nfs2se demo
gcc 12.2.0 -O0 -fsanitize=address -fsanitize=undefined...

LOG: opengl: I am able to use OpenGL to emulate Voodoo graphics
voodoo_emu.cpp:1106:33: runtime error: signed integer overflow: -562949953421312 * -562949953421312 cannot be represented in type 'long int'
voodoo_emu.cpp:1106:83: runtime error: signed integer overflow: -562949953421312 * -562949953421312 cannot be represented in type 'long int'
voodoo_emu.cpp:1107:33: runtime error: signed integer overflow: -562949953421312 * -562949953421312 cannot be represented in type 'long int'
voodoo_emu.cpp:1107:83: runtime error: signed integer overflow: -562949953421312 * -562949953421312 cannot be represented in type 'long int'
voodoo_emu.cpp:1106:33: runtime error: signed integer overflow: -562949953421312 * -562949953421312 cannot be represented in type 'long int'
voodoo_emu.cpp:1106:83: runtime error: signed integer overflow: -562949953421312 * -562949953421312 cannot be represented in type 'long int'
voodoo_emu.cpp:1107:33: runtime error: signed integer overflow: -562949953421312 * -562949953421312 cannot be represented in type 'long int'
voodoo_emu.cpp:1107:83: runtime error: signed integer overflow: -562949953421312 * -562949953421312 cannot be represented in type 'long int'
voodoo_opengl.cpp:253:13: runtime error: signed integer overflow: 13129440 * -9223372036854775807 cannot be represented in type 'long int'
voodoo_opengl.cpp:254:13: runtime error: signed integer overflow: 13129440 * -9223372036854775807 cannot be represented in type 'long int'
voodoo_opengl.cpp:246:35: runtime error: signed integer overflow: 49 * -9223372036854775807 cannot be represented in type 'long int'
voodoo_opengl.cpp:246:28: runtime error: signed integer overflow: -9223372036854775807 + -576460752303423485 cannot be represented in type 'long int'
voodoo_opengl.cpp:246:64: runtime error: signed integer overflow: 451 * -9223372036854775807 cannot be represented in type 'long int'
voodoo_opengl.cpp:247:35: runtime error: signed integer overflow: 49 * -9223372036854775807 cannot be represented in type 'long int'
voodoo_opengl.cpp:247:28: runtime error: signed integer overflow: -9223372036854775807 + -576460752303423485 cannot be represented in type 'long int'
voodoo_opengl.cpp:247:64: runtime error: signed integer overflow: 451 * -9223372036854775807 cannot be represented in type 'long int'
voodoo_opengl.cpp:246:9: runtime error: signed integer overflow: -9223372036854775803 + -576460752303423462 cannot be represented in type 'long int'
voodoo_opengl.cpp:247:9: runtime error: signed integer overflow: -9223372036854775803 + -576460752303423462 cannot be represented in type 'long int'
voodoo_emu.cpp:2679:51: runtime error: index 256 out of bounds for type 'unsigned int [9]'
voodoo_opengl.cpp:221:57: runtime error: signed integer overflow: 372 * -5890867 cannot be represented in type 'int'
voodoo_opengl.cpp:222:57: runtime error: signed integer overflow: 372 * -5890867 cannot be represented in type 'int'
voodoo_opengl.cpp:223:57: runtime error: signed integer overflow: 372 * -5890867 cannot be represented in type 'int'
voodoo_emu.cpp:2635:51: runtime error: index 768 out of bounds for type 'unsigned int [9]'
voodoo_opengl.cpp:226:31: runtime error: signed integer overflow: 4022 * -9223372036854775807 cannot be represented in type 'long int'
voodoo_opengl.cpp:226:57: runtime error: signed integer overflow: 4130 * -9223372036854775807 cannot be represented in type 'long int'
voodoo_opengl.cpp:245:35: runtime error: signed integer overflow: 4022 * -9223372036854775807 cannot be represented in type 'long int'
voodoo_opengl.cpp:245:64: runtime error: signed integer overflow: 4130 * -9223372036854775807 cannot be represented in type 'long int'
voodoo_data.h:918:46: runtime error: left shift of negative value -15
voodoo_data.h:918:46: runtime error: left shift of negative value -3
LOG: VOODOO: OpenGL: quit

[maron2000]

@grapeli Thanks for testing. There are still bit shifting of negative values and out of bound indexs in the voodoo code, so they have to be fixed.
How about trying the build with fsanitize=... without voodoo since there has to be flaws without it as well?

[grapeli]

@maron2000
The Nfs2se demo is only in the 3dfx version.

I tried several times to run the non-accelerated full version of the game under dosbox-x compiled with clang and gcc (-fsanitize=....). Without success. The game starts, after loading the race route, it stops at some point. Most often there is an error in the dosbox-x logs - triple fault.

[grapeli]

@maron2000
With sbtype=none the demo runs under dosbox-x compiled with gcc (-fsanitize=...). Some of these runtime errors related to voodoo appear (mostly when the 3dfx logo shows up).
nfs2se-demo-gcc-fsanitize.log
My conclusion, this is not the essence of the problem.

[maron2000]

@grapeli
Thank you for sharg iyour research. Although it may not be the cause of this issue, it is a big implication to fix voodoo code.

[skipster1337]

On the issue above it's mentioned that disabling sound hardware acceleration supposedly fixes it, but I tried it in DOSBox-X and the game crashed in the middle of the race instead of in the beginning, and also the sound disappears when approaching tunnels. I hope it's possible to fix this issue since DOSBox-X runs games much faster than PCEm and 86Box.