Support more glide resolutions

[Zeus]

Are resolutions from a) only for Voodoo Graphics/Rush?

Glide.dll supports resolutions from 0x0 to 0xB (All Voodoos)
Glide2x.dll supports resolutions from 0x0 to 0xF (All Voodoos)
Glide3x.dll supports resolutions from 0x0 to 0xF (All Voodoos except VSA-100)
Glide3x.dll (for VSA-100) supports resolutions from 0x0 to 0x17 <- existing 3x games don't recognize 0x10 to 0x17

Test30.exe for glide2x.dll and glide3x.dll checks resolutions from 0x0 to 0xF.

[Gamecollector]

Glide.dll supports resolutions from 0x0 to 0xB (All Voodoos)
Glide2x.dll supports resolutions from 0x0 to 0xF (All Voodoos)
Glide3x.dll supports resolutions from 0x0 to 0xF (All Voodoos except VSA-100)
Glide3x.dll (for VSA-100) supports resolutions from 0x0 to 0x17 <- existing 3x games don't recognize 0x10 to 0x17

Test30.exe for glide2x.dll and glide3x.dll checks resolutions from 0x0 to 0xF.

No, my question is different.
Test30.exe tries to set all these resolutions on a real Voodoo2. But 320x200, 320x240, 640x200, 640x350, 400x256 and 400x300 fail. So - the question is - is the Voodoo2 hardware itself supports these 6 resolutions at all?
P.S. By the way, I was wrong. 960x720 and 1024x768 work in Test30.exe on a single Voodoo2 with colorbuf=2 and auxbuf=0.

[Zeus]

is the Voodoo2 hardware itself supports these 6 resolutions at all?

No. Same for Voodoo Graphics.

[VEG]

Current work in progress.

5:4, 1280×1024

nfs_1280x1024.jpg (233.5 KiB) Viewed 15179 times

4:3, 1280×960

nfs3_1280x960.jpg (231.44 KiB) Viewed 15179 times

16:9, 1280×720

nfs3_1280x720.jpg (195.42 KiB) Viewed 15179 times

All resolutions with ratios between 16:9 and 5:4 (incl. 16:10) are supported. I've also patched split screen view.

There left some small glitches. These indicators (I'm planning to fix it):



And a little misaligned HUD as you can see in the previous screenshots (I'll try fix it also). What is interesting, even in 1280×960 (4:3) original HUD looks not perfect.

BTW, I'm planning to patch Future Cop L.A.P.D. in the future.

For non-standard resolutions we can use ids from 0x80 to 0xFF.

I would rather use this approach, but like I said earlier let's not talk about it now, it's too early.

Can we talk about it now? I can provide example why predefined list of resolutions (with corresponding constants) isn't good idea. I think you know resolution 1366x768. But there is also less popular, but existent resolution 1360x768. I think user will be unhappy if he couldn't use his native resolution.

It would be nice if nGlide will allow to use any resolution that IDirectDraw7::EnumDisplayModes reports. Array of structures {width, height} will be very easy readable from assembler code.

I'm not planning to remove current code of reading resolutions. I'm planning to left it as a fallback, if glide3x.dll doesn't support this extended mode.

Hm... Maybe it's even better to introduce new exported function for it (e.g. grEnumResolutionsEx). It will be easy for check if glide3x.dll supports extended mode. LoadLibrary, GetProcAddress... and that's all. If it returns 0 it means that this is not extended glide3x.dll and the game have to use default reading resolutions code.

I would like to say that it will be better, if this API extension will be easier to use from assembler code. What you can easily do in C, often you can't easily do in your patches for already compiled games.

It's better to think how to add this extension in a more natural way, so that could be supported by other wrappers without changes.

Something with callback function like IDirectDraw7::EnumDisplayModes also usable. But continuous array is easier to read and walk through.

P.S. Sorry for my English. It isn't my native language.

[VEG]

I've fixed most problems with widescreen support. Now it looks good. There is some problems with 5:4 resolutions (it is not widescreen and it is higher than 4:3, initially the game doesn't support 5:4), but I'm planning to fix it also.

hfs3wide1.jpg (286.02 KiB) Viewed 15141 times

nfs3wide2.jpg (266.54 KiB) Viewed 15141 times

[Stiletto]

I assume the checkerboard in the rear view mirror is another glitch?

[VEG]

I assume the checkerboard in the rear view mirror is another glitch?

Nope. It is start/finish of the track

[Zeus]

Current work in progress.

It looks great. Keep going! Was it hard to change the FOV?

Can we talk about it now?

I generally don't like the idea of adding unofficial stuff to Glide library. During 6 years of nGlide development I added only one such feature called "stipple patterns" for Glide64.

This time however you're proposing something with real value, you can deliver it, and for me it will be a matter of adding couple lines of code. It won't also cause any negative impact on compatibility with games. That's why I'm willing to make an exception.

The question is now, how we implement this feature. IMO the simpler, faster and intuitive it will be to implement and use, the better.

Here's my proposition:

USING EXTENDED RESOLUTIONS

- grSstWinOpen( resolution<=0xFF, refresh<=0xFF ) - original behavior using predefined constants
- grSstWinOpen( resolution=(xres<<16)|yres, refresh=(ref<<16) ) - resolution and refresh parameters in an extended format (both greater than 0xFF)

Original format example:
grSstWinOpen( resolution=7, refresh=0 ) - inits 640x480x60

Extended format example:
grSstWinOpen( resolution=0x028001E0, refresh=0x003C0000 ) - inits 640x480x60

LISTING EXTENDED RESOLUTIONS

- grQueryResolutions( resTemplate.resolution=0xFFFFFFFF and resTemplate.refresh=0xFFFFFFFF, NULL ) -
get the structure size (extended format)
- grQueryResolutions( resTemplate.resolution=0xFFFFFFFF and resTemplate.refresh=0xFFFFFFFF, pointer ) -
get resolutions list in a GrResolution format, the difference is we will use (xres<<16)|yres for .resolution and
(ref<<16) for .refresh fields instead of predefined constants

Original format example:
output[n].resolution = GR_RESOLUTION_640x480; // 7
output[n].refresh = GR_REFRESH_60Hz; // 0

Extended format example:
output[n].resolution = 0x028001E0; // 640x480
output[n].refresh = 0x003C0000; // 60

If you have any questions, let me know.

IDirectDraw7::EnumDisplayModes

DX7 is obsolete and nGlide uses DX9. I will use IDirect3D9::EnumAdapterModes (not that it's important for you but just saying).

that could be supported by other wrappers without changes.

It's impossible. Otherwise I also would not have to modify nGlide in order to make extended resolutions supported.

BTW, I'm planning to patch Future Cop L.A.P.D. in the future.

Glide 2.4 does not implement grQueryResolutions. So you'll either have to use LoadLibrary(glide3x)/GetProcAddress() or I'll have to add the function also for glide.dll and glide2x.dll.
BTW, any chance for NFS4 and NFS5?

[Sammy75]

wow great work...

if you need beta testers i am very interested

[VEG]

Was it hard to change the FOV?

Nope, I've done it in a day or two. More time (in addition to this two days) I've spent to fix other small bugs caused by widescreen or 5:4 resolutions. Besides this, I've also done some other interesting changes. I'm not simply changing few bytes. I'm completely rewriting some procedures in machine code. For this moment I've written more than 2500 lines of assembly code for this project.

Also I've tried to fix hangs during loading on multicore systems. But I don't have enough experience in finding deadlocks and I've spent a day for it without any result. As a temporary “solution” I've added SetProcessAffinityMask(GetCurrentProcess(), 1) call to main and corresponding option to ini file. ... And yes, I've added support of ini file. It replaces registry and now NFS3 doesn't require to import any reg files into system. I've made these changes for portability. Just copy NFSIII folder and it will work without any additional movements

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.

It's impossible. Otherwise I also would not have to modify nGlide in order to make extended resolutions supported.

I'm sorry, I've said incorrectly. My English isn't good enough. It isn't my native language.
I would like to say that if any other glide3x wrapper will implement this API extension, NFS3 with support of this API extension (my patch) will work without changes in code of NFS3.

Glide 2.4 do not implement grQueryResolutions. So you'll either have to use LoadLibrary(glide3x)/GetProcAddress() or I'll have to add the function also for glide.dll and glide2x.dll.

voodoo2a.dll from Future Cop uses glide3x.dll. I have even more to say. I'm using this library in my patch for NFSIII Original voodoo2a.dll from Need For Speed CD uses glide2x.dll and it doesn't have grQueryResolutions. And this is one of the reasons why I'm using another library. Official voodoo2a.dll update for NFS3 (which uses glide3x.dll) is not fully compatible with NFS3. There is no fog and it is disgusting. This dll is rather intended for NFS4.
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.

BTW, any chance for NFS4 and NFS5?

Maybe in the future. NFS4+ were compiled by Visual C++. NFS3 was compiled by Watcom C++. Different compilers produce very different machine code. It means that porting will be harder for this reason.

Code: Select all

USING EXTENDED RESOLUTIONS
- grSstWinOpen( resolution<=0xFF, refresh<=0xFF ) - original behavior using predefined constants
- grSstWinOpen( resolution=(xres<<16)|yres, refresh=(ref<<16) ) - resolution and refresh parameters in an extended format (both greater than 0xFF)
Original format example:
grSstWinOpen( resolution=7, refresh=0 ) - inits 640x480x60
Extended format example:
grSstWinOpen( resolution=0x028001E0, refresh=0x003C0000 ) - inits 640x480x60

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

Code: Select all

grSstWinOpen( resolution=xres|(yres<<16), refresh=(ref<<16) ) - resolution and refresh parameters in an extended format (both greater than 0xFF)

The reason: in memory bytes of integers are reversed. In your case this int32 could be treated as a struct {int16 yres, int16 xres}. In my case this struct will be {int16 xres, int16 yres} which seems a little better IMHO

In C code you even may define this kind of union for clearness (it's pseudocode):

Code: Select all

union
{
    uint32 resolution_id;
    struct
    {
        int16 width;
        int16 height;
    }
}

In asm code you may simply read word [esi+0] for width and word [esi+2] for height (where esi is pointer to this structure). In your case it will be word [esi+2] for width and word [esi+0] for height. Not much difference. But my perfectionism bother me in this case

Code: Select all

LISTING EXTENDED RESOLUTIONS
- grQueryResolutions( resTemplate.resolution=0xFFFFFFFF and resTemplate.refresh=0xFFFFFFFF, NULL ) -
get the structure size (extended format)
- grQueryResolutions( resTemplate.resolution=0xFFFFFFFF and resTemplate.refresh=0xFFFFFFFF, pointer ) -
get resolutions list in a GrResolution format, the difference is we will use (xres<<16)|yres for .resolution and
(ref<<16) for .refresh fields instead of predefined constants

Hm. I'm confused. An example from Glide 3x reference:

Code: Select all

GrResolution	query;
GrResolution	*list;
Int	listSize;

/* find all possible modes that include a z-buffer */
query.resolution	= GR_QUERY_ANY;
query.refresh	= GR_QUERY_ANY;
query.numColorBuffers	= GR_QUERY_ANY;
query.numAuxBuffers	= 1;

listSize = grQueryResolutions( &query, NULL );
list = malloc( listSize );
grQueryResolutions( &query, list );

glide.h defines GR_QUERY_ANY:

Code: Select all

#define GR_QUERY_ANY ((FxU32)(~0))

It means that GR_QUERY_ANY is 0xFFFFFFFF. How do you planning to detect which type of output is needed: standard or extended? Do you mean that I have to zero query.numColorBuffers and query.numAuxBuffers and it will be a signal to use extended output? Maybe it is better to choose a little more complicated magic number (e.g. 0x7FFF7FFF which means two maximum values in structure {int16 width, int16 height} with signed integers) to avoid unexpected problems with existing games?

Also it will be nice to think about how to detect from game if glide3x.dll supports extended list of resolutions.
What do you think about this algorithm:

Code: Select all

bool is_extended = true;
GrResolution	query;
GrResolution	*list;
Int	listSize;

query.resolution	= GR_QUERY_ANY;
query.refresh	= GR_QUERY_ANY;
query.numColorBuffers	= 0; // extended query?
query.numAuxBuffers	= 0; // extended query?

listSize = grQueryResolutions( &query, NULL );
if (!listSize)
{
	// standard query
	is_extended = false;
	query.numColorBuffers	= GR_QUERY_ANY;
	query.numAuxBuffers	= 1;
	listSize = grQueryResolutions( &query, NULL );
}
list = malloc( listSize );
grQueryResolutions( &query, list );

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.