That's exactly what my patch from nGlide's compatibility list do. I think it should be enough.VEG wrote:As a temporary solution I've added SetProcessAffinityMask(GetCurrentProcess(), 1) call
So.. you're not satisfied with SetProcessAffinityMask solution?VEG wrote:If anyone good in deadlock debugging and know how to find which critical section (NFS3 heavily uses EnterCriticalSection/LeaveCriticalSection) blocks two (or more) threads (and which threads)... write to me... I'm good at patching when I definitely know what I have to change. We could overcome the problem together.
The problem is Future Cop doesn't use it. The game only utilizes internal glide2x code from exe file.VEG wrote:voodoo2a.dll from Future Cop uses glide3x.dll.
I'm using Galah's version (also included in patch), but if Future Cops' version works as good as Galah's I see no problem of using it for the patched version. Galah is a guy from Australia who unofficially rewrote EA thrash drivers completely, so now they compatible with XP and later.VEG wrote:Future Cop and NFSIII were released in almost same time. Versions of their voodoo2a.dll libraries almost the same. It seems like voodoo2a.dll is a little updated version of voodoo2a.dll from NFS3, with Glide3x API instead of Glide2x API. As I can see they are fully compatible.
No problem.VEG wrote:I have a small suggestion here: maybe it's better to swap xres and yres
You're right. For some reason I thought GR_QUERY_ANY was 0x000000FF.VEG wrote:Hm. I'm confused. An example from Glide 3x reference:
It means that GR_QUERY_ANY is 0xFFFFFFFF.
Ok, let's use 0x7FFF7FFF then. Using this magic number will be enough. No need to use numColorBuffers=0/numAuxBuffers=0.
I see two possible scenarios with different original Glide drivers/different wrappers:VEG wrote:Also it will be nice to think about how to detect from game if glide3x.dll supports extended list of resolutions.
1) query with resTemplate.resolution=0x7FFF7FFF + resTemplate.refresh=0x7FFF7FFF + output=NULL returns 0
2) query with resTemplate.resolution=0x7FFF7FFF + resTemplate.refresh=0x7FFF7FFF + output=NULL doesn't return 0, but after passing a pointer to it - query.resolution will be less than/equal to 0xFF.
This means it will be safe for you to have a two-pass check. First check the structure size. If it's 0 stop the process. Otherwise, check query.resolution <=? 0xFF.
Yes, we can test some of them, but we won't test all of them / future wrappers. That's why it will be safe to use a two-pass check system.VEG wrote:It is better to test what original glide3x.dll reports to these extended queries. I would like to save compatibility with original drivers and do a fallback if glide3x.dll doesn't support extended display modes.
In other words, to confirm extended resolution list support:
Glide library cannot return 0 with resTemplate.resolution=0x7FFF7FFF + resTemplate.refresh=0x7FFF7FFF + output=NULL
- AND -
the library cannot return query.resolution <= 0xFF with resTemplate.resolution=0x7FFF7FFF + resTemplate.refresh=0x7FFF7FFF + output=pointer.
P.S. Stop worrying about your English. Mine isn't any better.