Support more glide resolutions

[Zeus]

As a temporary solution I've added SetProcessAffinityMask(GetCurrentProcess(), 1) call

That's exactly what my patch from nGlide's compatibility list do. I think it should be enough.

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.

So.. you're not satisfied with SetProcessAffinityMask solution?

voodoo2a.dll from Future Cop uses glide3x.dll.

The problem is Future Cop doesn't use it. The game only utilizes internal glide2x code from exe file.

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.

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.

I have a small suggestion here: maybe it's better to swap xres and yres

No problem.

Hm. I'm confused. An example from Glide 3x reference:
It means that GR_QUERY_ANY is 0xFFFFFFFF.

You're right. For some reason I thought GR_QUERY_ANY was 0x000000FF.

Ok, let's use 0x7FFF7FFF then. Using this magic number will be enough. No need to use numColorBuffers=0/numAuxBuffers=0.

Also it will be nice to think about how to detect from game if glide3x.dll supports extended list of resolutions.

I see two possible scenarios with different original Glide drivers/different wrappers:

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[0].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[0].resolution <=? 0xFF.

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.

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.

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[0].resolution <= 0xFF with resTemplate.resolution=0x7FFF7FFF + resTemplate.refresh=0x7FFF7FFF + output=pointer.

P.S. Stop worrying about your English. Mine isn't any better.

[VEG]

So.. you're not satisfied with SetProcessAffinityMask solution?

No. It just hides problem, not solves it. Even in this case hangs are possible. It is just very rare case on one core. But now when I'm heavily testing the game I've caught this bug once even on one core. BTW, I'm going to try to enable all cores when gameplay is already started and enable only one core only when any loading process (+changing resolution process) is initiated. It seems that this bug affects only loading process and maybe gameplay will be a little better when all cores are enabled.

Also it seems that game heavily uses own memory allocator which sometimes crashes the game with error “reservememadr - OUT OF MEMORY requested '': 4915218 available: 2435304. type 0000”, especially when people use high-res packs of textures or own sounds, but with default graphics it is also possible: when I'm trying to take a screenshot by pressing Alt+P (NFS3 uses this keystroke for taking screenshots) and when current screen resolution is big (e.g. 1920×1200) the game is always crashed with this error. It means that this memory allocator couldn't allocate huge memory chunks or have critical bug that doesn't allows to him to allocate big chunks of data. Unfortunately, I've not investigated how it works for this moment. Maybe it will be better to replace it to Win32 HeapAlloc/HeapFree. This allocator also heavily uses EnterCriticalSection/LeaveCriticalSection and there is a little chance that it will fix the previous problem

The problem is Future Cop doesn't use it. The game only utilizes internal glide2x code from exe file.

Wow. It seems that the engine code is very similar in these games. NFS3 also has own statically-linked voodoo2a library with glide2x, but NFS3 replaces addresses (it is just pointers) of “3hrash” procedures to ones from dynamically loaded dll. Maybe it is a part of standard code of this engine. But you can't start NFS3 without external 3hrash dll because developers written a little strange code which synthetically requires external library. But it seems that it is easy to remove this requirement. Code of the engine automatically uses pointers to statically linked library if external library is not loaded. The developers simply added forced exception in this case in the code outside the engine.

The dll from the Future Cop L.A.P.D. works good and it uses Glide3x API I've tested many 3hrash dlls and many other libraries not fully compartible with NFS3 which leads to some graphical glitches. voodoo2a.dll from nGlide's compatibility list also works good. But this file is taken from “GALAHs Fifa WC98 3D Patch” (unofficial of course), but the author of this patch hadn't written what is the source of this file and what exactly he is patched in it specially for Fifa WC98. Maybe some of this patches may some side effects on NFS3 and I've decided to make my own patch on the base of original file from EA.

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.

I will read whole message before reply.
I will read whole message before reply.
I will read whole message before reply.
I will read whole message before reply.
...
Wow. It is cool if Galah written this driver from scratch. Maybe I have to see this library closely.

BTW, in case of “3D patch” for the Fifa 99 this author uses the voodoo2z.dll from the Need For Speed 5.

Original voodoo2z.dll from NFS5 and GALAH's voodoo2a.dll from FIFA 99 3D patch:


If you compare these files you will see that all sections (with the exception of resources section .rsrc) are completely same. It means that it is simply voodoo2z.dll from NFS5 with modified version information. I thought that in other cases the author did the same operation. But maybe I'm wrong.

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[0].resolution <=? 0xFF.

Nice idea. I'm agreed with you.

Now It's time to code

UPD.

Galah is a guy from Australia who unofficially rewrote EA thrash drivers completely, so now they compatible with XP and later.

Are you sure?

The voodoo2a.dll from Fifa WC98 3D patch also looks suspiciously for written from scratch 3hrash driver. For example, it has TimeDateStamp 0x3679B3B5 (in exe header) which means that this file was compiled on Fri, 18 Dec 1998 01:45:25 UTC+0. It seems that this file is based on a file from some other old game from 1998-1999. I've tried to find the source but it seems I don't have it. Maybe it is taken from demo version of some game which has different version of voodoo2a.dll.

For comparison:
Original voodoo2a.dll from NFS3 CD has timestamp 0x35C1F947 which means Fri, 31 Jul 1998 17:05:11 UTC+0.
Original voodoo2a.dll from Future Cop CD has timestamp 0x35F8D437 which means Fri, 11 Sep 1998 07:41:43 UTC+0.

It seems that all of these files are from the same period of time and that's why they are compatible. Also it seems that EA prefer to make release builds on Fridays

So.. you're not satisfied with SetProcessAffinityMask solution?

In addition... AFAIK many old EA games have similar problem. I think that the problem is in some common code that EA had used in its games. And when it will be found and fixed in one game it will be much easier to fix it in other EA games. The problem with “out of memory” also is common. For example, someone complains about it in Fifa 99: http://www.soccergaming.com/forums/showthread.php?t=448

UPD2.



I don't remember this glitch in early 2000's (good old times). Maybe I was totally blind to this because I was impressed by marvellous graphics. It seems that it is neighbour pixels from used texture. On higher resolutions this problem become appeared in more places. But this dialog has the glitch even in 640×480. Could somebody tell me if this problem occurs in other hardware or it's a problem of my hardware?

[Gamecollector]

1) You not need registry editing for NFS3. Use "nfs3.exe -?", it shows command line keys.
"Nfs3.exe -voodoo2" uses voodoo2(a|d|z).dll thrash driver, "nfs3.exe -voodoo" uses voodoo(a|d|z).dll.

2) These thin lines are standard issues if you use sprites for 640x480 and Voodoo resolutions above 640x480. Another example is in-game menu buttons (Contunue/Restart/Quit), there is vertical white line right to a button if the resolution is 800x600 or above.
And yes, these glitches are present on a real hardware too (Voodoo2). The only difference is - "Restart" dialog is affected, "Quit" dialog - isn't.
Seriously, the only way to correctly detect "it is a wrapper bug" from "it is a game feature" is testing on a real 3dfx hardware.
As the example of a reversed issue - many old OGL titles now have thin black lines on sprites in high resolutions. Because the default clamping method for old cards was renamed to GL_CLAMP_TO_EDGE from GL_CLAMP.

[VEG]

1) You not need registry editing for NFS3. Use "nfs3.exe -?", it shows command line keys.
"Nfs3.exe -voodoo2" uses voodoo2(a|d|z).dll thrash driver, "nfs3.exe -voodoo" uses voodoo(a|d|z).dll.

NFS3 always uses voodoo2a.dll, this name is hardcoded. And adding additional arguments isn't good enough way I think that ini file is better and easier to use.

Current settings is:

Code: Select all

[NFS3]
Language=English
VideoDriver=D3D
VideoDeviceId=0
SingleProcAffinity=1
NoErrorReporting=0
NoMovie=1
RemoteOnly=0

I've moved here Language and RemoteOnly settings from install.win (this file isn't required anymore). VideoDriver and VideoDeviceId is intended to replace corresponding registry keys. SingleProcAffinity enables workaround against game hangs on multicore systems (and you don't need to install sdb file). NoErrorReporting allows to enable default suppression of critical errors. I don't know why developers of NFS3 added this code, but this code prevents displaying Windows Error Reporting window when game is crashed. But this window allows to debug this crashed process and it is useful sometimes. That's why I've added ability to skip this code.

2) These thin lines are standard issues if you use sprites for 640x480 and Voodoo resolutions above 640x480.

I've taken this screenshot on 640×480

I'm simply trying to understand what game does incorrectly and what I have to change to avoid this glitch

I've rewritten all code that renders loading screen in NFS3. By default this code draws image by chunks 32×32 pixels. It causes very ugly overall result because upscaling works only for this small chunks and ugly lines are appeared between them:



First time I've changed it to use 160×160 chunks. It was easy because 640 and 480 easily divided by 160 without remainder. It works in D3D mode, but doesn't works in Voodo2 mode. As it turned out Glide3x supports only textures with sizes of power of 2 and up to 256×256. First time I've rewritten this code to this algorithm: 1) set clipping window; 2) draw image by 256×256 chunks; 3) restore clipping window to default. I had expected that clipping will prevent from rendering a garbage when main code tries to render 513-768 pixels (when width of original image is only 640 pixels). But the problem of displaying neighbour pixels on the edge of clipping is appeared here: a thin line of garbage was drawn at the edge of clipping box. It seems that system firstly scales texture and only after it clips it.
To solve this problem in this case I've completely rewritten this code. Now it renders by 256×256 chunks, but when it is the last row or column of chunks, it generates texture from offset (640-256, y*256) or (x*256, 480-256) or (640-256, 480-256) instead of offset (x*256, y*256) and this completely solved this problem.

Also I've rewritten code that draws progress bar. Now it displays progress of loading more smoothly. By default this progress bar goes slow firstly and very fast after 50%. I've investigated the code and could say that cause of this is not contemporary hardware. For example, the game jumps between 64% and 70% without any work. Also 93% jumps to 101% (yes, 101%) by condition if (progress >= 93) progress = 101 Now on my two systems this progress bar goes almost absolutely smoothly. The most time takes loading of track data (≈70% of time), but for some reason default code assigns only 15% of progress meter for it. Other values I've also changed, but this one is most significant.

BTW, first time I've thought to automatically extend original image to widescreen resolutions like this:



But it is not always works good (especially for slides with selected track when non-default car is used). That's why I've just inscribed this image in 4:3 rectangle with black areas on the sides:

As the example of reversed issue - many old OGL titles now have thin black lines on sprites in high resolutions. Because the default clamping method for old cards was renamed to GL_CLAMP_TO_EDGE from GL_CLAMP.

Is there any flag for Glide3x which will enable scaling only after clipping? This problem is appeared in D3D mode also.

I know that I may fix the problem by increasing free space between sprites in textures (with corresponding code changes). But I hope it could be fixed without changing of resource files.

[VEG]

For API fullness I propose to add colors field also:

Code: Select all

grSstWinOpen( resolution=width|(height<<16), refresh=colors|(ref<<16) )

nGlide could always ignore this field in grSstWinOpen, but have to set colors in grQueryResolutions extended output to 32 (because it really uses this color mode).

Maybe any other author of one of Glide wrappers would like to implement this API extension, and maybe his wrapper could work in 16-bit mode... Also it will allow to program to know which color mode is used for displaying it correctly in game options interface.

Also I think it would be good if second argument of grSstWinOpen is 0 this function will simply use default values (nGlide for example could use 32 bit colors and 60Hz refresh rate or so).

[Stiletto]

Clued in Dege, Glidos and gulikoza as to the discussion here. So possibly whatever solution Zeus and VEG agree to as to Glide extensions will be supported by dgVoodoo at least since that is still actively developed.

Reminder that Glide itself is open-source at http://sourceforge.net/projects/glide/ though it has not been touched in years and I don't know how you'd get commit access, better to upload a patch to their discussion boards/mailing list/bug tracker/whatever...

[Zeus]

It just hides problem, not solves it.

I disagree. There is nothing wrong with adaptation. That's exactly how most of the shims work in Windows. Also, the game was never developed to be compatible with multicore processors.
But hey, if you insist, no problem, try fixing it internally. Try catching differences in debugger with different affinity settings and display cs objects in windbg with !cs command.

author of this patch hadn't written what is the source of this file and what exactly he is patched in it specially for Fifa WC98

I never analyzed his drivers and because of that I was always convinced he rewrote them. But it looks like that's not the case and the only thing he did was some modifications (at least in WC98 driver case).

I know that I may fix the problem by increasing free space between sprites in textures (with corresponding code changes). But I hope it could be fixed without changing of resource files.

When it comes to Glide, your only options are grTexClampMode and grTexFilterMode. Other than that you can try to adjust s,t coordinates.

For API fullness I propose to add colors field also:

Code: Select all

grSstWinOpen( resolution=width|(height<<16), refresh=colors|(ref<<16) )

nGlide could always ignore this field in grSstWinOpen, but have to set colors in grQueryResolutions extended output to 32 (because it really uses this color mode).

Maybe any other author of one of Glide wrappers would like to implement this API extension, and maybe his wrapper could work in 16-bit mode... Also it will allow to program to know which color mode is used for displaying it correctly in game options interface.

Also I think it would be good if second argument of grSstWinOpen is 0 this function will simply use default values (nGlide for example could use 32 bit colors and 60Hz refresh rate or so).

No need to do that here. Modern wrappers do 16->32-bit conversion on the fly. If one day some author decides to add (fake) 16-bit mode he can add the setting to wrapper's configurator. FYI, true 16-bit modes in XP/7 are broken for long time now and in Windows 8 they have been completely removed (emulation is incomplete and buggy as hell).

[VEG]

No need to do that here. Modern wrappers do 16->32-bit conversion on the fly. If one day some author decides to add (fake) 16-bit mode he can add the setting to wrapper's configurator. FYI, true 16-bit modes in XP/7 are broken for long time now and in Windows 8 they have been completely removed (emulation is incomplete and buggy as hell).

As I said, it is only for API fullness. Maybe someone would like to run updated NFS3 on some old system with other wrapper that supports 16 bit mode (and hypothetically supports extended mode). Or maybe someone will decide to add support of extended API to original Glide3x library As I said before, you could simply ignore color field in grSstWinOpen (and always treat it as 32 bit), it is not a problem. But for API fullness it would be nice if grQueryResolutions will report colors (and of course it will be always 32 for nGlide). It will be compatible with other possible realizations of this extension if someone would like to add 16 bit mode also.

[Zeus]

Ok, I'll ask differently. How many games you are going to patch? All 300?

Let's say you're a wrapper author and you want to support additional color modes. What would you do? Would you add the support only for 3 modified games and ignore other 297? Of course not. You would add the option to configurator to support all games. Why? Because you can. You can do this without touching any game files (contrary to modern widescreen resolutions).

This is why adding color option to grSstWinOpen will be redundant. It will also be inellegant for 2 reasons:
-placing bpp modes (16,32) between refresh rate modes (0-8) and (255).
-using bpp in grSstWinOpen which is not designed for that, while ignoring grSstWinOpenExt from Glide 3.0 PIXEXT extension which accepts bpp modes (however using grSstWinOpenExt would raise another problems).

VEG, if you're wondering what to display on items labels in game menu resolutions list, display refresh rate as the third number (you would still have to do that anyway).

Maybe someone would like to run updated NFS3 on some old system with other wrapper that supports 16 bit mode (and hypothetically supports extended mode)

Then one will still be able to do that (see option in configurator). Or even without the configurator if the author decides to use 16-bit color as default.

Or maybe someone will decide to add support of extended API to original Glide3x library

What would be the point? Voodoo hardware doesn't support modern widescreen resolutions.

[VEG]

Okay You've made me change my mind. Maybe you're right.