Screamer Rally random freezes

[GoukiKain]

I'm experiencing random freezes in the game Screamer Rally. I'm using the version from the latest {REDACTED} (Admin: removed reference to piracy) compilation. The freezes don't happen immediately but after a while, during the second or third race, seemingly at random. Retroarch doesn't crash, the game just freezes, including the music, and stays there forever. Sometimes Retroarch returns this message "DOS crash: unimplemented XGA MMIO". I'm not able to finish a championship. I completed League 1 only by bruteforcing through the crashes using savestates. I tried changing a couple of settings with no real effect: RAM size from 16 to 32-64 MB; CPU from AUTO to "Pentium slow" or "486 slow". 486 slow is apparently better as sometimes the game recovers from the freeze but not very long after another one happens. I'm on Windows 10, i7-8750H, GTX 1070, Retroarch v1.9.8, core v0.15.

Your emulator is awesome BTW. Really simplifies the use of dosbox, controller implementation is spot on and allows the user to manage games as simple "roms". It worked out of the box with nearly everything I tried until now.

[GoukiKain]

I should have mentioned that this happens with gl or vulkan renderer regardless. I tried Screamer 2, that supposedly is made with the same engine. I completed 2 championships in a row and the game never froze on me.

[PoloniumRain]

Try the latest version 0.16.

Your problem sounds similar to a bug with the first Screamer, as that game randomly crashes roughly 70% of the time on one particular track, especially in Championship, but that has always happened on real hardware as well and it also happens in the GOG version. So it might just be Screamer Rally having a very similar bug.

And i haven't played SR much with DOSBox Pure but it's been fine for me so far. My settings are a Pentium III 600MHz with 32MB RAM, and i run the game in high resolution mode (by running START65H.EXE). That CPU setting will be overkill for low res mode but for high res the game will run smoothly at its intended speed. I've found it runs a little too fast with AUTO.

[GoukiKain]

You are right.

I did more testing running START65L.EXE, STARTH.EXE, STARTL.EXE in DOSBox 0.73-3, DOSBox-X, also the 3DFX version running STRT3FX.EXE in DOSBox ECE and DOSBox 0.74G with nglide wrapper: always the same behavior. If anything Pure seems to be slightly more stable and the regular version upscaled with shaders in Retroarch looks better than the 3DFX version IMO. The 3DFX version run too fast so I capped the framerate at 55-60 fps in Nvidia GPU drivers.

Now I'm curios to see how the game runs in real DOS... too bad a don't have a machine to test. Anyways stability in Pure is exactly the same as regular DOSBox.

[Xenphor]

I've noticed periodic pauses in Quake 1 as well. It will be running extremely smoothly, pause for a second, and go back to running smoothly.

Things I've tried: Using default core options
Running without CD Audio a Pentium III fixed cycle count

It's hard to test against Dosbox 0.73-3 because I can't get it running as smoothly as Dosbox pure. It might be a Dosbox issue.

[schellingb]

I've done some optimization to the rendering and emulation timing of DOSBox in our variant. Original DOSBox spends a fair amount of effort every frame to be able to slowly scale the output image in software and to be able to draw only changed lines to the output screen. Stuff that is very irrelevant when running as a libretro core. So in my testing with raw benchmarks like Quake's timedemo console command DOSBox Pure can be 20% or so faster than other variants.

But seemingly one time freezes in games do happen when loading from compressed ZIP files. Ever since the release of this core the README contained the paragraph Store ZIP seek index into save file under "Features not yet implemented". So let's say you load a game from a ZIP file that has a very big file in it - very common with CD images. So now if the DOS game wants access to a file that exists at the very end of the CD image, DOSBox Pure needs to "seek" to near the very end of the CD image, which means it basically has to uncompress the entire file. It does so just in RAM without unpacking the ZIP file onto disk or anything silly like that. But it's still a heavy process. Now once it has done seeking to the end of that big file it remembers an index. So the second time the DOS game wants to read in some random location it uses that index to quicker get to the requested data. So the plan was (and still is) to store that index into the save file so it won't have to re-do the seeking every time the content gets loaded again (and get the same hitch again).

Though that assumes the reported issue here is related to seeking in a large file inside a ZIP file. Could be something else I'm not aware of.

[Xenphor]

So far I can't reproduce the issue. When playing Duke Nukem 3D, I heard my external hard drive (containing Retroarch and game files) access something and a stutter happened at the same time. However, an additional stutter happened later, and I did not hear the external drive. I could try putting the files on an SSD, but if things are loaded into ram then I don't know if that would help.

My specs are: Windows 10 8700K 32 gb of ram at 3200mhz 1050 ti

I tried doing nothing in the game for some time and did not notice any stutters. I use both RTSS and the core's performance options as well as my eyes to detect them.

So far it seems to be later era DOS games where I have noticed this happen. I played Commander Keen for quite awhile and never saw anything.