Hey Raziel, I found a new bug!  Although, I'm assuming this exact game issue hasn't been brought up yet, so if it has, then, uh, I guess nobody's released a fix yet despite it already being brought up.

My Config: Evolution 1.01.16 set, on a V5 5500, in Win9x.

The name of the game is Star Trek:Bridge Commander.  If I use 2xFSAA or noFSAA mode, I have support for the "Enhanced Glows" feature of the game, and it works well.  HOWEVER, if I try to use the "High Color" mode in the options and play the game, I get this:

Image Insert:

64.2 KB

And yes, it'll do that even if I enable Force 32bit Rendering in the 3dfx Tools.

But.....if I run the game with 4xFSAA on I lose support for the "Enhanced Glows", but the "High Color" mode works as it is supposed to:

Image Insert:

75.41 KB

First:

ROFL @ the art in here.  Keep it up guys. Seriously.

Second:

I'm pretty sure it was already mentioned in the MesaFX thread by someone else, but let me just give a big THANK YOU to Dborca for getting HomeWorld2 working in-game now.  Aside from the first mission's panoramic shots (slide-show CITY!!!), the game is surprisingly playable, even on a V5 at 800x600x32 with FSAA (if only a 2x, though.  4x starts to cross the line at times).

I've got no complaints. LOL.

QuoteOriginally posted by kaneda-san


all evo's drivers are for 9x based system .

Ok, then.  Time to install....

However, my question regarding FF7pc/Duck Trumotion codec still stands.

Alright, possible stupid questions here:

What version of windows is this update for?  Win9x or WinNT/2k/XP?

Secondly, I'm curious if you can do anything for adding support for FF7pc into the drivers in some way without compromising anything.  Or, heck, maybe just support for having the Duck Truemotion codec run (in a DirectShow5 context, mind you).

It appears that all display drivers that are newer than version 4.12.01.0543 have some incompatibility with either FF7pc or Duck Truemotion that causes me to get only the audio track of the Eidos Logo movie (It's impossible to get the game to ignore trying to play the movie, so I can't tell if the problem's with the codec or the game) with a black screen, followed by a hard lock.  The codec works fine when used outside of the game (i.e., ran from windows media player).

Furthermore:  the same thing happens in software mode! Which is why I think it might be occuring in the portion of the drivers responsible for DirectDraw itself, and not merely the Direct3D portion.

I should also mention that even your Evolution Driver (ver. 1.00.09 for Win9x) is not immune to this, either.  I haven't tried 1.00.16 yet, but I'm hoping that it somewhow works.

QuoteOriginally posted by dborca

@Ragnarok72
All envvars are kept in HKCU\Environment, which is the standard for 2k/XP, but means nothing for Win9x. Now, I am an adept of KISS principle. So I (and Koolsmoky) tried to make it work just the same, regardless of the OS. At the next startup, Win98 does not read HKCU\Environment. By "Register"ing CPAN, you... ehm... register "PATH_TO_CPAN\cpan.exe /silent" command at startup, which reads what is stored in HKCU\Environment and injects all envvars into the master environment. After that, MesaCpan exits (that is, it does not remain resident).

Ah, so the settings ARE ultimately stored in the registry....for a while there I thought you were going the complicated route by having to set the envvars manually right before running the game instead of having MesaFX just try to look for the settings to be defined in, say, HKLM\System\CurrentControlSet\Services\Class\Display\0000\Glide\ each time it starts up.

On the other hand, I suppose if you were going to put them there, you'd have to make an INF, then package MesaFX in something other than just a self-extractor, then get it to install the inf, etc.

But I digress.  If I understand you right then just running "cpan.exe \silent" at startup will get the job done, right?

If so, then perhaps a good idea would be to include some sort of script that finds the path of where cpan.exe is, copies that path, and lists it in win.ini's "Run=" line, so that it'll run without needing to go make a shortcut to it on the "C:\Windows\Start Menu\Programs\Startup\" folder, etc.

On the other hand, doing that same idea, but with the "HKLM\Software\Microsoft\Windows\CurrentVersion\Run\" key, which should make it run invisibly regardless of OS...the only question is whether or not you or Kool want to spend the time to make such an install script to automate it (for idiot-proofing purposes )....

QuoteOriginally posted by dborca

Hail to Voodoo's linear fogging, right? It seems I need to work again the "workaround". However, try and test ONI with other cards. I believe there was meant to be some kind of greyish fog, anyway. Is the whole game greyish, or only the intro screen?

As for the other games, the envvars _should_ work. Well, if they don't, use a .BAT! The CPan was never meant to be a sound project anyway (it eats my time, when it could be used for Mesa itself).

Speaking of that Control Panel -- I just checked it out.  Looks great, it looks as if it can mesh perfectly with the rest of the 3Dfx Tools.

I have yet another question, though:  What in blazes do you mean when you say that we need to "register" the control panel stuff?!  Yes, the fact that I'm asking about this obviously means I'm using MesaFX on Win98SE, thank you very much.

QuoteOriginally posted by patience


This is probably easier to start and run a game under Win9x than under Win2k and under XP.
But indeed, if a game has problems under Win9x and Win2k/XP and if the problem can be fixed under Win2k/XP, so would be interesting to try to fix it under Win9x, using the same way but without forgotting that the kernel, the driver, the gfx card are or can be different.

True....and it bugs me that everything nowadays is for XP, XP, XP.  

While I am glad that SFFT and Amigamerlin have been able to kick-start the WinXP driver development to get to the state it is at now, we should still not totally forget that they could still raise compatibility up even further on the Win9x side -- largely because you don't need to use 3DAnalyze to emulate TnL.  I figure that if someone like SFFT would take a crack at updating the Geometry Assist code for the Win9x core so that it would be stable under DX8 games, we'd probably get a boatload of games from 2002-2003 to run/run better.

Well, it is certainly great to hear that someone is taking matters into their own hands and working on DX8 support.  But....

WARNING: POSSIBLE STUPID QUESTION(s) ALERT!

Can these drivers in their current state function properly on Win9x?  Now, by "function properly", I mean "install without windows screaming bloody murder because the driver was written with Win2k/XP in mind".

If not, then is Win9x support planned?

QuoteOriginally posted by del42sa


I think Quantum 3D used this idea in AAlchemy, they calling it "Performance Trilinear"

The Enable Performance Trilinear (PT) option uses special Quantum3D-developed
hardware functionality that enables rendering 2 pixels per clock rather than just one, while still
performing trilinear texture blending. Without Performance Trilinear, you would have to
choose between 2 pixels per clock operation and trilinear mipmapping. Using Performance
Trilinear will automatically force the maximum color depth to be 22 bits per pixel, but will
increase your fill rate. Applications that require the maximum fill rate should use this feature.

"On previous AAlchemy systems, enabling trilinear filtering forced the 3dfx VSA-100
chips on board into a single-pixel-per-clock mode of operation. By modifying the
Parallel Rendering Architecture FPGA and driver software in these new AAlchemy
models, we've enabled the 3dfx VSA-100 chips to provide trilinear filtering while
concurrently operating in a two-pixel-per-clock or 'Performance Trilinear' mode,"
stated Ross Q. Smith, Founder and VP of Sales & Marketing at Quantum3D. "With
Performance Trilinear, we've effectively doubled the fill rate performance on these
new models. AAlchemy was already the performance and price/performance leader
in the industry—now we've opened the gap between the competition and us even
further."

http://www.quantum3d.com/press/pdf/archive/pr_11-27-00-2x.pdf

The AA5™ family of advanced realtime 3D graphics subsystems is available exclusively for deployment in the Quantum3D® AAlchemy™ family of scaleable, open architecture PC-based Image Generators (PC-IGs). AA5 subsystems feature Quantum3D's Parallel Rendering Architecture that combines the power of 8 or 16 3dfx VSA-100 graphics chips. The AA5 supports Quantum3D's unique Performance Trilinear™ technology which enables 2-pixel per clock trilinear rendering, 0, 2, 4 and 8-way Scan Line Interleaving (SLI) and 4 or 8-sample T-buffer™ full scene anti-aliasing to enable vis-sim integrators to "fine tune" the PC-IG for desired performance and image quality levels.

Hmm....they very well may have.  Not to mention, if they are still only maxing out at 8x FSAA mode when they are using 8 or 16 chips, then it sounds like those extra 4 or 8 chips are probably only there so that their TMUs can be hijacked while the other chips are running in SLI....

QuoteOriginally posted by dborca
@Ragnarok72
I AM part of the 3dfxzone team. As I said, many vendors advertise a certain OpenGL version even if it's not fully implemented. So stop bitching!

Ok, fair enough.  I suppose if I'm to complain about it, I might as well go pester ATi and nVidia about it as well.

QuoteBTW, games that require HW T&L in OpenGL must refer to speed only. Otherwise, it's OpenGL's duty to emulate everything.

Ah....that explains A LOT.  Not only does it at least partially explain why the TNT could theorectially get away with running the game, but it would explain why there doesn't seem to be any OpenGL extention made specifically for recognizing the HW TnL "ability" of a card, for lack of a better term.

QuoteOriginally posted by dborca

Do not quote anything that is not my own words. Period.

Alright, fair enough.  It was probably my mistake, but I had assumed that since you appear to be working closely with the people at 3dfxzone.it and therefore had to approve of whatever description of MesaFX that they were writing before those pages went online, so that this type of misunderstanding wouldn't show up.  I suppose that whoever wrote that page I quoted wrote that on their own without checking with you first?

QuoteFYI, many OpenGL implementations advertise a certain version, even it's not fully supported. Many, but not Mesa. However, this is not the point here, as bumping the version number won't fix the HomeWorld2 bugs.

Agreed, HW2 would NOT be fixed by simply bumping the version number.  However, it still counts as an error message.  Then again, the fact that MesaFX will at least run everything in HW2 except the game's 3D engine, even without the 3dfx-modified driverConfig.lua file, could mean that maybe the message is really just that -- a complaint about having to run using an older OpenGL driver version that it would prefer not to run with, but still be able to if it passed everything else.

Besides, this was only supposed to be a nitpick.

QuoteI'm using SciTE, thanks.

Ok, spill the beans:  What is SciTE?!

QuoteAnyway, you have been uploaded a similar hack around page 11 of this thread. I was using it, but without any success.

I know....I'm not sure if you caught the edited part of the message, but I had ment to upload the non-modified one, and somehow got the wrong one uploaded. (I should've checked the file first, LOL.)

In the end, though, I had found that my "hack" had largely done nothing.  MesaFX will launch the game without the modified file.

Anyway, when I uploaded it this time, the intent was not to actually use it with the game, but to use it as a resource to check the game's workaround methods to what would be acceptible for MesaFX to do.

And speaking of workarounds -- I'd like to direct your attention to this section of the file:

(This is from the last set of if-then statements made under the "if( GL_isVendor("nvidia") == 1 )" part)


-- smooth lines and clip plane are emulated
-- disable shadows if they will be emulated because you're using a nv1x or TNT
if( GL_isRenderer( "geforce 256" ) == 1 or GL_isRenderer( "geforce2" ) == 1 or GL_isRenderer( "geforce4 mx" )
== 1 [b]or GL_isRenderer( "tnt" ) == 1 )[/b] then
GL_setEmulated( eCanLineSmooth, 1 );
GL_setEmulated( eCanClipPlane, 1 );
[b]if( GL_getOpenGLVersion() > 1.3 and GL_haveExtension("GL_ARB_shadow") == 0 )[/b] then
GL_setCan( eCanShadowBuffer, 0 );
GL_disabledEmulatedFeatures();

Notice that it appears they have some built-in workarounds for the RivaTNT card, which according to the system requirements on the game's box, shouldn't be able to run the game at all, because it doesn't have hardware TnL, doesn't do more than 2-Textures-per-pass, and doesn't have Pixel/Vertex shaders -- yet these are the very same things the game cites as reasons why the V5 can't run the games engine.

This is what I was trying to do with my hack.  Adapt those workaround methods to apply them to the V5, as it seems it is in the same boat as the RivaTNT is.

Furthermore, notice that it seems to be looking for GL_ARB_Shadow...perhaps that extention is the key to getting the 3D engine to run?  Again, I'm just grasping at straws here.....

QuoteOriginally posted by dborca
You're not pulling my leg, now are you? If you show me where I advertised 1.3 anywhere on my situ, I'll eat the geocities harddisks.

Alright, I'll admit that you may not be saying it in the situ, however, I was more refering to the fact that there are some places on 3Dfxzone.it that say it is a 1.3, and I quote :

QuoteThis new graphics library is OpenGL 1.3 compliant and supports 3dfx Voodoo Banshee, Velocity 100/200, Voodoo3, Voodoo4, Voodoo5 boards. MesaFX works fine with Amigamerlin drivers series allowing a better execution of OpenGL 1.3 recent games, like Call of Duty. Besides, running older titles, like Quake 3 Arena, MOHAA, Serious Sam The Second Encounter, you can get both higher frame rates and better hardware performance with 32bit of color depth (this one by cards with VSA-100 chip-sets only).

Source: https://www.3dfxzone.it/dir/3dfx/common_files/index.htm

QuoteOriginally posted by dborca

I finally took a look at it last night.
Pretty sh!tty, cos the texturing artifacts exhibit on a random basis. Unfortunately, the MesaSW renderer crashed, so I couldn't tell it's a core problem or a driver issue.

Dborca, I suggest you have a look at the "driverConfig.lua" file in notepad.  It appears to be written in if-then statements containing possible workarrounds for various drivers, mostly for problems with Radeon and Geforce cards -- However, I wouldn't be surprised if those workarounds can be adapted for use with MesaFX/Mesa in general.

Maybe its grasping at straws, but it's better than having to work on it from scratch.

I've attached it in a zip file.  Remember, you can use notepad on it, you don't need any fancy-pants specialized programs to read the file, thank God.

-edit-
Doh!  Uploaded the wrong version of the file.  The one that got uploaded contains my (admittantly bad) attempt to get it to recognize 3Dfx cards.  I stopped work on it when I found that I didn't need it to launch the game....but still, the only changes were that I added that 3Dfx entry -- everything else pertaining to Radeon/Geforce workarounds are still there.

Download Attachment: HomeWorld2--driverConfig_lua.zip
2.12 KB

QuoteOriginally posted by dborca

I can't bump the version number. There are some extensions required for 1.3 that cannot be done. Advertising 1.3 would be a lie. Is this such a major issue? I never tested HomeWorld2.

Ah, but we're ALREADY advertising it on the site, that MesaFX is a 1.3 driver.  That's why I'm nitpicking about it.

As for it being a issue in regards to HomeWorld2, it is my understanding that even IF we were to get the other functions faked somehow, it would still pick up the fact MesaFX is identifiying itself as a 1.2 driver, and may refuse to run it's 3D engine ON THAT POINT ALONE.

And yes, it certainly does complain about what version a given OpenGL driver identifies itself as.

Alright, now I know this is still a minor nitpick, but....

..when are you going to change the version string (I might be wrong, but isn't it GL_Version or something?) so MesaFX will identify itself as a 1.3-compatible driver?

Games like HomeWorld2 are still identifying it as an OpenGL1.2-compatible driver, and are needlessly complaining (I.E. actual error messages) about it.

QuoteOriginally posted by dborca

QuoteOriginally posted by mcmagostini

Hi folks.

Why is that in Quake3 , for instance, i get 138 FPS with the 3dfx
OGL ICD and "just" 114 with the Mesa one at the same configuration
driver-wise and game wise?

Quake has no notion of FXT1 texture compression. The 3dfx ICD maps S3TC (that quake uses) to FXT1, as opposed to Mesa, which does FXT1 for FXT1 and S3TC for S3TC. Therefore, Quake doesn't use texture compression with Mesa. Actually, Kool wrote a patch to cheat S3TC with FXT1 in Mesa, but it's not embedded into the public releases.

I think that might explain the weird slowdown problem I get with MesaFX and RtCW, since that's a Quake-engine based game.  I'm even more sure of it because both the 3Dfx .0761 ICD and the WGL one included with the game don't have the slowdowns, and in both cases I have S3TC enabled in the options.