Does OS in the emulator pickup on CD audio in this case? Last time I messed with these things I remember only data getting through.

UCyborg wrote on 2025-05-14, 07:19:

Does OS in the emulator pickup on CD audio in this case? Last time I messed with these things I remember only data getting through.

Yes

OK, so CDs with music in PCem or 86Box aren't a problem. Additionally, there is native support for mounting CUE.

I wonder though, did this game really run that horrible on a real 133 MHz Pentium at 640x480 resolution, high detail, software renderer? Feels like 5 - 10 FPS. 86Box emulation speed hovers between 99% and 102%. Using Sound Blaster 16 for sound card and Voodoo Banshee for GPU.

I played it on real 133 MHz Pentium back then, but don't remember how it felt like or what settings were used.

UCyborg wrote on 2025-05-16, 12:53:

OK, so CDs with music in PCem or 86Box aren't a problem. Additionally, there is native support for mounting CUE.

I wonder though, did this game really run that horrible on a real 133 MHz Pentium at 640x480 resolution, high detail, software renderer? Feels like 5 - 10 FPS. 86Box emulation speed hovers between 99% and 102%. Using Sound Blaster 16 for sound card and Voodoo Banshee for GPU.

I played it on real 133 MHz Pentium back then, but don't remember how it felt like or what settings were used.

Yes this game runs unrealistically slow in emulation. It looks like the speed percent is not correct, and using WinXP on PCem, 90% speed felt comparatively slower than what I should expect.

Btw I recall your patch had registry to disable the shim. How did you figure that out?

Regarding registry setting disabling shim, it's what Compatibility Administrator (32-bit) can help with. You get it with Windows 10 ADK. When you disable an entry in system database, the entry's GUID is written under that key with value 0x77. Re-enabling an entry sets value to 0x00.

I was testing another workaround yesterday, making the game use separate heap where it normally uses process heap. That seems to help with stability, on playthrough with default, music would eventually stop, though DxWnd was showing as still playing, but time didn't advance and game ended up crashing in glide2x.dll a bit later. I got tired, music didn't stop and didn't crash with the workaround, may just take longer.

Though there are bigger memory leaks related to that heap, grows in megabytes as levels are loaded / unloaded. I wish it was as simple to just HeapDestroy and HeapCreate it to get rid of the leaks as the heap just keeps growing, but there are some persistent allocations on that heap that are needed when a level is loaded and shouldn't be just cleared on unload. Identifying all the correct places that reference it is pretty time consuming and I'm tired of all screwing around with this game as it is.

My impression regarding emulation is general is that it's more of a luxurious thing and incredibly wasteful.

UCyborg wrote on 2025-05-23, 09:03:

My impression regarding emulation is general is that it's more of a luxurious thing and incredibly wasteful.

Wrong thread? i think it's supposed to be in the 1996-1999 emulation thread 😀

Btw I76 has another problem that I never mentioned. If you use sharangad's RReady wrapper, the ddraw.dll loading can't hook into Verite.dll or Rendition.dll most of the times.

Well, the emulation rant is a bit related in the context of the game we're talking about. I wonder if there'd be any noticeable speedup using HEAP_NO_SERIALIZE flag for the heaps the game uses when running it in emulators. The one leaky heap I mentioned previously is constantly accessed during gameplay. The flag makes sense considering single-threaded nature of the game.

I actually made some progress and seemingly successfully implemented the idea destroying and recreating the heap (where process heap was used before) with big memory leaks. I found a pretty good spot to intercept and destroy and re-create it. There was one pointer in the way, but could just zero it so subsequent code wouldn't proceed to free the block that was already freed by heap being destroyed before. And another place that was allocating a small 16 byte block using process heap using HeapAlloc, I changed to use standard malloc/free. Should try out if multiplayer is still OK.

Can you link RReady wrapper? Never heard of it.

Current DirectDraw usage is pretty buggy, I wonder if we could get anywhere by tweaking some calls' parameters. Software renderered DirectDraw fails to init and even in Glide mode + DXWnd where it's just used for menus, game's screen always blacks out when Windows changes desktop background, the picture is back when part or all of it is redrawn.

UCyborg wrote on 2025-05-24, 16:58:

Can you link RReady wrapper? Never heard of it.

Current DirectDraw usage is pretty buggy, I wonder if we could get anywhere by tweaking some calls' parameters. Software renderered DirectDraw fails to init and even in Glide mode + DXWnd where it's just used for menus, game's screen always blacks out when Windows changes desktop background, the picture is back when part or all of it is redrawn.

It is just across this sub-forum: Re: RReady (Rendition Verite wrapper) Test Build (Alpha 1)

GLide works for me well. Has always worked well. Although I use nGlide because DX9 hook is generally better in DxWnd than DX10/11.

Oh, never experimented with accelerated renderers besides Glide and D3D. Other APIs must have been pretty obscure. nGlide plays well with I76, no fuss with configuration, no flashing textures.

The sound just died on me (besides music), attached debugger to the game and DirectSound calls are failing with DSERR_BUFFERLOST (I searched "hresult 88780096"). I usually use ALchemy with the game, but forgot to rename the DLL so it would be used. I don't have MS' debug symbol downloading DLL anywhere handy, so can't see with OllyDbg what the game is calling.

Maybe it always happens if you put PC to sleep and don't suspend game process. Other than that, it's stable.

Edit: Managed to restore sound by switching to another audio device in Windows' sound settings and back. Digging with debugger, it was IDirectSound:CreateSoundBuffer that was failing with that code.