Yes, it's possible, I just can't see the point.
As far as I know, Napalm capabilities were only leveraged by the Glide renderer addon written for Project64, nothing else.
(And even, support for "external glide wrapper" was ditched for P64 last time I checked.)

I got your point. I can see 3Dfx OpenGL ICD 734 (voodoo3+) is looking for PIXEXT and I just added all the Glide3x extensions support for QEMU Glide pass-through, but not SURFACE and GET_REGISTRY. I would like to see if I can use the OpenGL ICD to check out PIXEXT (grSstWinOpenExt) if the existing LFB mechanism can cope with it. Since the build is already available as 32-bit DLL, it should be included in 64-bit DLL, too, for completeness sake. 😀

Well, ok.
OGL ICD didn't come to my mind.
Btw, SURFACE and GETREGISTRY is not supported by dgvoodoo.

Apparently, MESA FX also looks for PIXEXT and COMBINE to provide support for certain OpenGL extensions. So with Napalm extensions, perhaps we can have better OpenGL compliance (up to 1.3) through MESA FX for QEMU for OpenGL games in the DirectX7~8 era.

BTW, when selecting "other_greater" configuration, dgVoodoo2 does not report Voodoo3/Voodoo4/Voodoo5 in the grGetString(GR_HARDWARE). Those strings are actually used in MESA FX in combination with the extensions to enable certain OpenGL extensions, and one of them is FXT1 texture support. I am aware that this is not supported in dgVoodoo2. I can check for further details if there are other implications.

According to the code, for grGetString(GR_HARDWARE) with 'Other, greater' dgVoodoo gives back 'dgVoodoo'. 😁
I could change that to 'Voodoo 3' or sg with Environment = QEmu.

kjliew wrote:

Those strings are actually used in MESA FX in combination with the extensions to enable certain OpenGL extensions, and one of them is FXT1 texture support. I am aware that this is not supported in dgVoodoo2. I can check for further details if there are other implications.

Yes, it's not supported. I wonder why ogl checks for that, since FXT1 isn't exactly the same as S3TC (maybe one of the compression methods).

This is the code snippet from MESA 6.2.1 showing the expected GR_HARDWARE string mapping to the hardware.

1      extension = grGetString(GR_HARDWARE);
2      if (strstr(extension, "Rush")) {
3         config->SSTs[i].type = GR_SSTTYPE_SST96;
4      } else if (strstr(extension, "Voodoo2")) {
5         config->SSTs[i].type = GR_SSTTYPE_Voodoo2;
6      } else if (strstr(extension, "Voodoo Banshee")) {
7         config->SSTs[i].type = GR_SSTTYPE_Banshee;
8      } else if (strstr(extension, "Voodoo3")) {
9         config->SSTs[i].type = GR_SSTTYPE_Voodoo3;
10      } else if (strstr(extension, "Voodoo4")) {
11         config->SSTs[i].type = GR_SSTTYPE_Voodoo4;
12      } else if (strstr(extension, "Voodoo5")) {
13         config->SSTs[i].type = GR_SSTTYPE_Voodoo5;
14      } else {
15         config->SSTs[i].type = GR_SSTTYPE_VOODOO;
16      }

I can dig further into the code to see how they are used before you commit the change. But, anytime 64-bit Napalm build is always welcome! 😁 I can always change the GR_HARDWARE string in the guest wrappers.

Voodoo4 enables the following OpenGL extensions

1   if (fxMesa->type >= GR_SSTTYPE_Voodoo4) {
2      _mesa_enable_extension(ctx, "GL_ARB_texture_compression");
3      _mesa_enable_extension(ctx, "GL_3DFX_texture_compression_FXT1");
4      _mesa_enable_extension(ctx, "GL_EXT_texture_compression_s3tc");
5      _mesa_enable_extension(ctx, "GL_S3_s3tc");
6      _mesa_enable_extension(ctx, "GL_NV_blend_square");
7   } else {

And, it also set the "isNapalm" flag which is used in the blendFunc setup. So I think for Napalm build, "other_greater" should really return "Voodoo4".

Ok, I'll modify the string for 'Voodoo4' for QEmu environment, but regarding that compressed textures are unsupported, it may causes problems for ogl renderers (if it works with dgVoodoo at all 😁 ).

Using the build from WIP66, the Napalm build has rendering issues even when not opting for Napalm extensions by selecting "voodoo_2" in the configuration. I have prints that confirmed only voodoo_2 supported extensions were reported, but the sky rendering in Quake3 was messed up with 3Dfx OpenGL stand-alone ICD 1.0.0.508.

3Dfx OpenGL ICD 1.0.0.734 does not want to load with Napalm extensions, probably this is not a stand-alone ICD. MESA FX 6.4.2 detected Napalm extensions, invoked grSstWinOpenExt() but textures were all messed up and seemed to run slower (about half the FPS) of MESA FX 5.0.2 compiled to use Glide2x. Not sure if the textures were due to FXT1/S3TC compression.

It seems that when "voodoo_banshee" was selected in configuration, the NumberOfTMUs was still being honored and resulted in a 2-TMU "Frankenstein" Banshee. 3Dfx OpenGL ICD 1.0.0.508 and MESA FX do not seem to handle such case well. Changing the NumberOfTMUs to 1 in the configuration fixed the issue with both of them. Perhaps, the configuration should take "voodoo_3" instead of "voodoo_banshee", and if NumberOfTMUs is 1, then it becomes Voodoo Banshee. The final 3Dfx reference Win9x drivers for Voodoo2 and Banshee shipped with the same 1.0.0.508 ICD.

BTW, why did you even need to report SURFACE and GET_REGISTRY extension if those additional functions were mere stub functions?

Ok, then I won't include this in the package (for the time being).

Not sure if the textures were due to FXT1/S3TC compression.

You can check the function call log from the spec release version (grTexSource and such).

What about plain Glide3x? Does it have the same problems with MESA?

BTW, why did you even need to report SURFACE and GET_REGISTRY extension if those additional functions were mere stub functions?

Can't remember. I might had been about on implementing them later, or sg like that.

The Napalm Glide3x seems to have issue with textures. I suspect that this is due to TEXFMT and PIXEXT but I haven't tried out the experiment of filtering out these 2 on Napalm built to see if that works.

For the regular Glide3x, I would like to suggest that it should be reporting "Voodoo3" for "other_greater" instead of "Voodoo4" due to missing of PIXEXT. Without PIXEXT, there is no 32-bit rendering and MESA FX 6.2.1 wglCreateContext will fail when the OpenGL game selected 32-bit PFD in wglSetPixelFormat. I am not sure why the game would do that but when I forced reporting as "Voodoo3" the call to wglSetPixelFormat would then select 565 16-bit PFD. The game tested was BloodRayne1 with its OpenGL 1.2 renderer through MESA FX.

1 if (fxMesa->HavePixExt) {
2    fxMesa->glideContext = Glide->grSstWinOpenExt((FxU32)win, res, ref,
3                                                  GR_COLORFORMAT_ABGR, GR_ORIGIN_LOWER_LEFT,
4                                                  pixFmt,
5                                                  2, aux);
6 } else if (pixFmt == GR_PIXFMT_RGB_565) {
7    fxMesa->glideContext = grSstWinOpen((FxU32)win, res, ref,
8                                        GR_COLORFORMAT_ABGR, GR_ORIGIN_LOWER_LEFT,
9                                        2, aux);
10 } else {
11    fxMesa->glideContext = 0;
12 }

By forcing "Voodoo3", I was able to get Quake2, Quake3 and BloodRayne1 working with MESA FX 6.2.1 with "other_greater" and 2-TMU configuration. However, BloodRayne1 was too slow to be playable and it needs MESA_FX_MAXLOD to do software downscale of textures. The same MESA FX 6.2.1 when running with Napalm build Glide3x without forcing "Voodoo3", all 3 games tested have texture errors.

BTW, how did you checkout 32-bit texture and large texture support for Napalm build?
Obviously, none of the native Glide3x games seem to be doing this. The extensions seem to be only used by 3Dfx OpenGL ICD and MESA FX for OpenGL games.