[taylor]

Found the thruster problem.  There is a special work around I had as part of the new texture replacement code in the Xt tree, but since I'm not going to commit that new code, I skipped over it.  What I forgot though is that the work around also fixed a texture page-in problem for late arrivals (ship classes that aren't initially in the mission at start), which included the thruster bitmaps and reduced slowdowns from texture paging when a ship warps in.  I'll go ahead and commit to SVN a cut down version of the same fix, but I'm not going to release a new build for it.

So if there are any reproducible issues with this build which are NOT related to missing thrusters then let me know.

[Fenrir]

But if I understand the first post correctly, normal mapping will be in the trunk builds soon, right?

[taylor]

But if I understand the first post correctly, normal mapping will be in the trunk builds soon, right?

Yeah.  If no serious problems are reported then I'll commit it Tuesday night.

[captain-custard]

ok its tuesday night , ive just noticed this build ive been waiting for this for ever and as kara said i am a graphics whore but now my favourite game that will save stats , and have normal maps... i cant wait , do i download it play and have a cold shower or do i download it have a cold shower then play.....

taylor i think i love you ........


in a freindly non touchy manly sort of way 

[castor]

but now my favourite game that will save stats , and have normal maps... i cant wait , do i download it play and have a cold shower or do i download it have a cold shower then play.....

Umm.. Sorry to rain in your parade, but IIRC getting the stats to save requires the MVPs to be finished/approved on FS2netD server side, which is not yet to take place (as far as I know?).

[captain-custard]

but if this build is svn then it saves stats wether or not it has normal maps ?

[Shade]

No, stats saving has nothing to do with SVN and everything to do with whether or not the tables/missions you are using are validated.

[Edit]

It seems like Shade is playing the Main FS2 campaign.

Err... I'm what? I haven't even posted in this thread before now

[Stormkeeper]

.. Oops. I meant SF-Junky. See what you get when you post with out paying attention.

[MP-Ryan]

So does this build require the shader files from the Xt builds as well?

[taylor]

So does this build require the shader files from the Xt builds as well?

Yes.

[DaBrain]

I gave it a try yesterday and it worked fine for me, even though I didn't have enough time for some proper tests.

[MP-Ryan]

So does this build require the shader files from the Xt builds as well?

Yes.

And to clarify, which shader files exactly do we need?  The entire 1119 set, just one of them, or is there a better set?

[taylor]

And to clarify, which shader files exactly do we need?  The entire 1119 set, just one of them, or is there a better set?

It's only different versions of the same files, so just get the plain 1119 one.  The others had lighting differences to try and work out some bugs with some cards/drivers, but are feature deficient because of that.  Just ignore them in other words, and get 1119.  And there haven't been any shader updates since that set in Novemeber.

I'm going to remove them all and rename the 1119 set as "shaders.vp" at some point tomorrow (and move it to warpcore) to make it a bit easier on everyone.

[Echelon9]

taylor,

I just updated to the 4707 commit from SVN, and I *think* there are some files missing.

In graphics/gropengltnl.cpp you've now added an #include to graphics/gropengldraw.h yet the gropengldraw.h header file is not in the repository.

Are you able to point out something I've done by mistake (certainly possible) or is a missed file from the commit?

[chief1983]

Yeah I seem to be having the same problem.  Still with a commit that big, it's bound to happen sometimes.  Also, for some time now HerraTohtori has been recommending that shader 1119 be used in conjunction with I believe 1112, because for some reason that seems to solve a bunch of issues.  Perhaps that should be addressed before making 1119 the primary?

[taylor]

In graphics/gropengltnl.cpp you've now added an #include to graphics/gropengldraw.h yet the gropengldraw.h header file is not in the repository.

Yep, forgot to add those files.  Should work now though.

Also, for some time now HerraTohtori has been recommending that shader 1119 be used in conjunction with I believe 1112, because for some reason that seems to solve a bunch of issues.  Perhaps that should be addressed before making 1119 the primary?

1112 had numerous lighting problems, so 1119 is a fix for that.  If anyone thinks that 1112 has fewer problems then they obviously aren't looking closely enough.  I'm not going to change it in other words.  But you are always free to change the shaders yourself though.

[Echelon9]

In graphics/gropengltnl.cpp you've now added an #include to graphics/gropengldraw.h yet the gropengldraw.h header file is not in the repository.

Yep, forgot to add those files.  Should work now though.

I've added those new OpenGL files to the Mac Xcode project file, so that they can be compiled in successfully. I've tested that r4708 now compiles on my 10.5.4 with the patch, but I'll let others more robustly test the shader support in-game on a variety of hardware before proposing it to be committed to SVN.

[attachment deleted by admin]

[Herra Tohtori]

Also, for some time now HerraTohtori has been recommending that shader 1119 be used in conjunction with I believe 1112, because for some reason that seems to solve a bunch of issues.  Perhaps that should be addressed before making 1119 the primary?

1112 had numerous lighting problems, so 1119 is a fix for that.  If anyone thinks that 1112 has fewer problems then they obviously aren't looking closely enough.  I'm not going to change it in other words.  But you are always free to change the shaders yourself though.

sdr1119.vp package causes nameplates to render wrong; sdr1112.vp doesn't... the last time I checked anyway.

Zacam has been cross-referencing the files to determine which file change causes the nameplate rendering issues so that it wouldn't be necessary to brute-force a solution by either using the 1112 shader set, or jamming both 1112 and 1119 shaders into use simultaneously; obviously that's not how they were planned to be used. It would be better to just have the older, more correctly working files responsible for the nameplates' problems in new version and have the other files as new versions, but I haven't mentioned this in IRC in a while and neither has Zacam...

However, the fact of the matter is that while using only the 1119 shaders, all nameplates suffer some insidious rendering problems (at least with 0314Xt; haven't actually checked that with this new build) and those are in regular FS2 actually pretty much most visible as far as lighting problems go. So for the time being I'll likely continue brute-forcing the solution by running both shader files so that the older files in 1112 override the newer ones with same name on the 1119 - I know it is a far cry from an ideal solution and instead of blindly doing this, I'd recommend people to try 1119, 1112 and both simultaneously before settling to a solution. What works on someone, might not work for another. BtRL ships for example don't have nameplates yet (as far as I can see) so if someone wants to dick around with single player normal maps and stuff for it, they can do it with 1119 shader set.

[karajorma]

IIRC nameplates (in fact all texture replacement) has a bug whereby it doesn't use the glowmaps etc for the replaced texture. The bug you're seeing could be the result of that and not a bug in the 1119 shaders.

[taylor]

The 1112 shaders don't handle lighting and transparency correctly.  It will cause some partially transparent textures to be fully opaque or you won't get any lighting effects on things like cockpit glass.  They are broken.  Period.

The nameplate issue is known, but completely irrelevant.  Adding a spec map for the nameplate should pretty much get rid of the problem.  But the only way to properly fix it is with a material system.