BES just suspends and resumes the process on regular intervals, which means iterating through its threads and suspending them one by one calling SuspendThread. Limiting FPS usually work by calling Sleep from the main thread, which is where the most interesting things happen, effectively suspending it for the specified time.

Either way, you're not really throttling CPU speed with BES. What you're seeing in Prince of Persia 3D sounds like an interesting phenomenon, I could never influence the behavior of my games with BES that way.

Dege wrote:

Since rewriting the code by changing the float in question to a double would take too much time, I experimented with a stub WINMM.DLL where timeGetTime returns a value having the highest 8 bits masked out, to keep only the lower 24.
And voila, XG-2 ran at 34 FPS again.
😎

Cool ! Could you share this stub WINMM ? 😀

I think I have a similar problem with MechWarrior 2 : Ghost Bear Legacy (Win32 version). On Windows 10 it calls timeGetTime and then crashes (the crash doesn't happen on Windows 7 and lower).

A stub re-implementing timeGeTime would be a good starting point ! 😀

Jorpho wrote:

That sounds strangely familiar. […]
Show full quote

That sounds strangely familiar.

A quick search reveals that similar problems were reported with UT99.
Re: How do you fix the timing glitch on Unreal Tournament '99?

Will this fix be pushed to the Steam version?

Yes. 😀

xcomcmdr wrote:

Cool ! Could you share this stub WINMM ? :) […]
Show full quote

Dege wrote:

Since rewriting the code by changing the float in question to a double would take too much time, I experimented with a stub WINMM.DLL where timeGetTime returns a value having the highest 8 bits masked out, to keep only the lower 24.
And voila, XG-2 ran at 34 FPS again.
😎

Cool ! Could you share this stub WINMM ? 😀

I think I have a similar problem with MechWarrior 2 : Ghost Bear Legacy (Win32 version). On Windows 10 it calls timeGetTime and then crashes (the crash doesn't happen on Windows 7 and lower).

A stub re-implementing timeGeTime would be a good starting point ! 😀

Well, that stub wasn't a complete WINMM implementation because WINMM has 100+ functions and I didn't want to reimplement all of them.
I just whipped up a very minimal one that was enough for XG-2.

Dege wrote:

Well, that stub wasn't a complete WINMM implementation because WINMM has 100+ functions and I didn't want to reimplement all of them.
I just whipped up a very minimal one that was enough for XG-2.

Couldn't you just add it here:
https://github.com/rkkoszewski/ogg-winmm/

That winmm is used to emulate CD audio and passes all other functions to Windows' native winmm.dll.

Jorpho wrote on 2017-05-10, 13:06:

That sounds strangely familiar. […]
Show full quote

That sounds strangely familiar.

A quick search reveals that similar problems were reported with UT99.
Re: How do you fix the timing glitch on Unreal Tournament '99?

Will this fix be pushed to the Steam version?

There are a lot of bugs in the reimplimentation of opengl with the xg2 steam release, for example the select bike menu didn't have proper texturing as in the retail version Edit it does, the ddraw files don't have same texture config/support as the retail cd --some people have text errors; An AI 4k texture pack might be fun, the original had 4:3 aspect ratio but can be altered to 21:9 etc. They may have applied the windows xp fix for the xg2pc.exe executable. I was trying to look up commands to pass to the exe, like -l, couldn't seem to. The exe may have supported config files...
I wonder if Forsaken used similiar code, or a slowdown parameter is in xg2 already? affinity is set to one processor for me.

it gets better with updates... thanks for giving them permission dege.

Nice necro. According to pc gaming wiki and to this thread game initially is Direct3D 5 then dgvoodoo2 makes it as Direct3D11-12. PC gaming wiki doesn't say a single word about opengl. And dgvoodoo doesn't work for opengl at all.