Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: WMCoolmon on August 06, 2008, 05:33:42 pm
-
These are based off of sdr1119.vp - they're functionally identical, except for being able to run at a slightly lower OpenGL version.
For most people, what this means is you can now run shaders with NVIDIA cards on Windows 2000, possibly lower.
http://fs2source.warpcore.org/exes/latest/sdr003.zip
On the technical side, these do this by getting rid of conditional returns. Basically, any return (whether it returns a value or not) inside a conditional statement will bump the required version of a shader file up. It looks like you need at least OpenGL 2.1 for that to work. You can work around this just by designating a return variable and returning that at the end of the function.
Bad:
if(i > n_lights) {
return 0;
}
//...
return 1;
Good:
int rtn_value = 0;
if(i <= n_lights)
{
//...
rtn_value = 1;
}
return rtn_value;
-
Conditional returns are bad practice anyway :P
-
buh?
-
I used to have a teacher who complained about conditional returns. Basically, you should set a var and return that at the end of a function, and not have returns completely scattered throughout it. So instead of:
function blah()
{
if(something)
{
return False;
}
else
{
return True;
}
}
You have:
function blah()
{
$returnVal;
if(something)
{
$returnVal = False;
}
else
{
$returnVal = True;
}
return $returnVal;
}
WMC is saying that doing it with the former method requires newer hardware and OpenGL versions than doing it with the latter method. So he's updated the 1119 shaders, and they should run on more hardware/OS combinations now. Thanks WMC. I don't think I improved on his description much, but maybe hearing it slightly differently cleared things up a bit for you Galemp.
-
I used to have a teacher who complained about conditional returns. Basically, you should set a var and return that at the end of a function, and not have returns completely scattered throughout it.
That's a rather controversial topic actually. I've seen flame wars over the subject. :D
Both methods have pros and cons and I personally tend to use whichever makes more sense at the time rather than picking one and dogmatically sticking to it against all reason. For instance suppose you have code like this
boolean foo()
{
if (Certain conditions under which the answer will always be false)
return false;
....100 lines of code to determine the answer....
}
Makes a hell of a lot more sense than this
boolean foo()
{
boolean result;
if (Certain conditions under which the answer will always be false)
result = false;
else {
....100 lines of code to determine the answer....
}
return result;
}
For a start I've had to nest everything one level deeper. Furthermore if I screw up the nesting just once I run the risk of changing the value of result after I set it correctly.
The whole reason some people like the idea of a single exit point is to make the code more readable. Ask yourself this, which example is more readable if I'd actually written out those 100 lines of code?
-
wouldn't using many returns be faster than the other way? I mean the program won't have to check all the other conditions right?
-
It'll never check the "else" if the "if" condition is true, so it doesn't really matter.
-
buh?
It's a programming thing...
I'd say more on the subject but karajorma has already pretty much said what I'd say. In school, they may teach things a certain way because they think it's easier to learn or because there's less chance of you to screw up if you try to do that all the time, and they figure you'll learn when to adapt with time & experience.
On the other hand, if you're going into, say, Nuclear Engineering, you really ought to do what they tell you.
-
Yeah, really they try to teach you what they think are best practices, when they really need to impose the importance of just adhering to any practice at all, consistently.
-
I can't remember my intro to programming classes ever warning against using conditional returns; in fact, my professors used them all the time. At least from my perspective, the alternative method seems overly convoluted. Assigning a needless dummy variable that only gets used at the final function return seems like a waste of so many bits, and it also seems like it philosophically counteracts the whole fundamental purpose of if/then statements. If you've reached your desired state in a repeating/branching function, then you're generally dumped right out of that function. Do not pass Go, do not collect $200. Putting the function return right where the dumping occurs seems much more logical than having to slog through a bunch of lines that don't even get looked at if that condition has been met.
-
not to mention what you may have to do to make sure those lines don't get looked at.
-
Yeah, really they try to teach you what they think are best practices, when they really need to impose the importance of just adhering to any practice at all, consistently.
My last programming teacher was great, he tought us that we can do this sort of thing any way we like, as long as we do it consistently- but don't be afraid to use something different if it suits the task better.
It's like the difference between using "if...else" and "? :" for single operation conditionals, some stick with "if...else" for scalability and personal readability but I use "? :" a lot of the time because it compresses my code down and as long as you know the syntax is just as readable. I've seen arguments over where to put opening and closing brackets :ick:
-
This shows the same problem with nameplate rendering where the alpha section glosses into black.
Jpeg Mediafire Large Shot: http://www.mediafire.com/imageview.php?quickkey=f6rihlpgytd&thumb=5
PNG Save File Download: http://www.mediafire.com/?sharekey=41b2114aa47820817069484bded33bcdda6b0fa7a540e4bb
I've narrowed it down to this bit of code:
final_color.a = (gl_Color.a * c_base.a) + (dot(gl_SecondaryColor, gl_SecondaryColor) * 0.3);
final_color.rgb = gl_Color.rgb * c_base.rgb;
As contained in:
lb-f.sdr
lbg-f.sdr
lbgs-f.sdr
lbs-f.sdr
Replacing the above mentioned files with their 1112 counter parts removes the problem.
However, I don't know if this (replacing the files) would be a viable "fix" or if it would break things beyond my knowledge.
Edit:
1112 and earlier used:
final_color = gl_Color * c_base;
Edit2:
Making the code look like this:
final_color.a = (gl_Color.a * c_base.a) + (dot(gl_SecondaryColor, gl_SecondaryColor) * 0.3);
final_color = gl_Color * c_base;
or like this: (however, this makes things noticeably 'clunky' feeling)
final_color.a = (gl_Color.a * c_base.a) + (dot(gl_SecondaryColor, gl_SecondaryColor) * 0.3);
final_color.rgb = gl_Color.rgb * c_base.rgb;
final_color = gl_Color * c_base;
Resolves the problem. But again, I don't know if it is breaking any thing. But it does have to populate across all files.
-
This shows the same problem with nameplate rendering where the alpha section glosses into black.
The 1112 shaders are broken with how they handle transparency. It might fix the nameplate issue, but it breaks most everything else. The proper way to handle it is with a simple data fix: add a spec map for the nameplates.
Oh, and the reason that the reference shaders use a conditional return is that it tested much faster. With more complex models, using other, correct methods, you would get *****-slapped with a 40-60% performance hit. Compatibility was sacrificed for the sake of speed. Remember that the reference shaders were in development and testing for over 6 months. They were rewritten from scratch 4 times, with over a hundred iterations in between. Each and every single change was tested for instruction count, compatibility, visual quality, and performance.
The way of handling lights is simple wrong no matter how you look at it, but there is no clean way to fix it in the current code, it's simply too old/slow. The most compatible way to do it is to render once for each light. The problem there is that the engine design/setup is simply to inefficient to allow us to do that in a way that doesn't completely kill frame rate. I already tried the same changes that WMCoolmon made, plus more than a dozen other ways of getting it to work, but a conditional return was simply the best way to do it. The reference shaders I released are intended to be changed/modified, so everyone is free to do whatever they want there, but realize that every single line in those shaders is there for a specific reason. You can't blindly apply general knowledge about GLSL to our case because you have to account for the inherent design problems in the engine. Most all GLSL related info applies to a current generation engine, but when you get right down to it, FSO is in NO WAY a current generation engine, we just make it look that way.
-
Taylor has spoken! As so it is written, as so it is done!
Long live Taylor, the scp king!
-
I just ran the OpenGL Extensions Viewer in an effort to determine what version of OpenGL I have.
It says: Renderer: ATI Radeon X600 XT OpenGL Engine
Vendor: ATI Technologies Inc.
Memory: 128 MB
Version: 1.5 ATI-1.4.18
Shading language version: 1.10
Max number of light sources: 8
Max viewport size: 2656 x 2656
Max texture size: 2048 x 2048
Max anisotropy: 16
Max samples: 0
Max draw buffers: 0
Max texture coordinates: 8
Max vertex texture image units: 0
It passed benchmarks up to OpenGL version 2.1.
Should I be able to use this new shader for normal maps? Do I need to provide more information?
(I'm on an OS X Tiger iMac from about 2005.)
-
this shader should work on opengl2 but apparently not as fast as the regular shader would.
try the regular one and, if it works, use it, if not use this one.
-
The 1112 shaders are broken with how they handle transparency. It might fix the nameplate issue, but it breaks most everything else. The proper way to handle it is with a simple data fix: add a spec map for the nameplates.
Okay. What kind of shinemap? Black, white or grey? With or without alpha channel? Transparent or opaque, if alpha channel should be there?
The thing is, with the obvious solution (black shinemap with black alpha), the issue is still there with the exception that the nameplate text is not as clearly visible, but the dark box is still visible at certain angle (it seems to me that light reflecting in 45 degree angle will cause the box syndrome to surface).
With a white shinemap with black alpha, the text is brighter and the black box becomes white.
With a gray shinemap with black alpha, the text is medium bright and the black box becomes gray.
White or no alpha channel makes the nameplate face act as a mirror. Opaque text and transparent background makes the text act as mirror and background will have the box appearing at certain angles.
There seems to be no way around making the nameplate face becoming opaque at some shade of gray, varying from black (no shinemap or black shinemap) to white (white shinemap).
By the way, even if certain kind of shinemap could be used to fix the issue (which doesn't seem to be happening according to my experimentation, since all combinations of shinemaps result in opaque box around text at some form or another), what kind of backward compatibility issues would be caused for those who dont, or can't, use GLSL and use fixed render pipeline instead?
Also, what kind of examples of handling transparency do those four shaders actually affect? I tried to look at any changes in fighter cockpits (since that's the most prominent usage of transparency in models) but I could see no changes compared between sdr1119[003] and a mod folder with other shaders from sdr1119[003] and the four shaders copied from sdr1112. Everything seems to work similarly, except the nameplates work correctly.
Oh, and the reason that the reference shaders use a conditional return is that it tested much faster. With more complex models, using other, correct methods, you would get *****-slapped with a 40-60% performance hit. Compatibility was sacrificed for the sake of speed. Remember that the reference shaders were in development and testing for over 6 months. They were rewritten from scratch 4 times, with over a hundred iterations in between. Each and every single change was tested for instruction count, compatibility, visual quality, and performance.
Very well, I trust you know what you're talking about as far as technological detail goes, but as long as I do not see how exactly the older shaders break transparency otherwhere at least as spectacularly as the newer version breaks nameplates, I'm going to use the older four shaders even if they cause performance issues, and if trouble rises it's ugly head I know where the problem could be. The nameplates have, thus far, been the only visible issue I have noticed with the shader system, and even though I'm sure there are others, it doesn't really matter if I don't notice them... :nervous:
-
(I'm on an OS X Tiger iMac from about 2005.)
Unfortunately, I don't think that I've heard a single person on a Mac report any success in getting shaders to work. There always seems to be rendering issues at the least. My Mac is too old and doesn't have the hardware needed for shader support, so I was never able to test properly and figure out what was going on. The problem is either in the code itself or the shaders, but I'm pretty confident that it's the code that's at fault. The same code works on Windows and Linux, so it means we have yet another Mac-only rendering problem on our hands. There really isn't a lot I can do about that though, it will take someone with a Mac that has the problem to go through the code and try and work out where the problem is hiding.
By the way, even if certain kind of shinemap could be used to fix the issue (which doesn't seem to be happening according to my experimentation, since all combinations of shinemaps result in opaque box around text at some form or another), what kind of backward compatibility issues would be caused for those who dont, or can't, use GLSL and use fixed render pipeline instead?
Don't know really. I only gave it a quick test with a completely transparent spec map when I was trying to figure out that problem last year. The completely transparent spec map simply nullifies the lighting contribution that causes the problem. I don't think there will be a compatibility issue with fixed-pipeline rendering in that case at least but I didn't test it well enough to say that for sure.
But there is the chance that the spec map fix might not even work any longer. I had originally tested it with an older shader set, and I'm not 100% sure that the current shaders make the exact same calculations that fix this. It should be possible to adapt it to work though, if it doesn't now.
Also, what kind of examples of handling transparency do those four shaders actually affect? I tried to look at any changes in fighter cockpits (since that's the most prominent usage of transparency in models) but I could see no changes compared between sdr1119[003] and a mod folder with other shaders from sdr1119[003] and the four shaders copied from sdr1112. Everything seems to work similarly, except the nameplates work correctly.
The change in question was to actually fix cockpits, because otherwise you wouldn't get any lighting affects against the "glass" like you do with the fixed pipeline. I did manage to fix this at one point in a way that allows the "glass" effects to be there (I think that as the 1112 set), but that ended up causing semi-transparent textures to end up totally opaque, again breaking fixed pipeline compatibility. And so I ended up with the fixes in 1119, which addressed every problem except for the nameplates. I still see no way to fix the nameplate issue properly (I consider the spec map fix a hack) without a material system.
I did have access to special models, as well and various unreleased mod models, for testing all of this though. Rendering of all of those models was compared with the fixed pipeline and any deviation was either considered a break or a bug in the fixed pipeline (with several fixed pipeline rendering bugs being fixed because of that). The nameplate rendering problem was quickly noticed as soon as it was introduced, since it do look rather bad. But with all of the data at hand, the nameplate bug was definitely the lesser of two evils.
But like I said, these are just the reference shaders and you can change them however you like to distribute with your own mod or whatever. The reference set was designed to work as well as possible with everything I could throw at it. Very few people will actually have such requirements in real like however, so you can change things as you see fit to work best with your own data.
And for the curious, I'm attaching a diff of the 1112 and 1119 shaders (minus the new/removed files).
[attachment deleted by admin]
-
Also, what kind of examples of handling transparency do those four shaders actually affect? I tried to look at any changes in fighter cockpits (since that's the most prominent usage of transparency in models) but I could see no changes compared between sdr1119[003] and a mod folder with other shaders from sdr1119[003] and the four shaders copied from sdr1112. Everything seems to work similarly, except the nameplates work correctly.
The change in question was to actually fix cockpits, because otherwise you wouldn't get any lighting affects against the "glass" like you do with the fixed pipeline. I did manage to fix this at one point in a way that allows the "glass" effects to be there (I think that as the 1112 set), but that ended up causing semi-transparent textures to end up totally opaque, again breaking fixed pipeline compatibility. And so I ended up with the fixes in 1119, which addressed every problem except for the nameplates. I still see no way to fix the nameplate issue properly (I consider the spec map fix a hack) without a material system.
Huh, that's strange...
With a shader set where most shaders came from sdr003 set (functionally from 1119, obviously), and the four specified by Zacam coming from sdr1112 set, I am getting all the glass effects that should be there, plus semi-transparent textures (like cockpit glass texture, I presume?) are just as semi-transparent as they should be. I am seeing into the cockpits, and the glass has appropriate reflections, so I don't know what's going on now. :nervous: Mayhaps the transparency problems only surface at specific hardware/driver combination or something, I don't know... All I know is that things seem to work fine on my end with mixed shaderset.
And yeah, fully transparent shinemap (whole map at RGBA#00000000) didn't remove the black box issue, but darkened the text itself slightly. I guess that fix doesn't just work with the 1119 set. At any rate the material system fixing the issue(s) good and proper sounds re-assuring.
I did have access to special models, as well and various unreleased mod models, for testing all of this though. Rendering of all of those models was compared with the fixed pipeline and any deviation was either considered a break or a bug in the fixed pipeline (with several fixed pipeline rendering bugs being fixed because of that). The nameplate rendering problem was quickly noticed as soon as it was introduced, since it do look rather bad. But with all of the data at hand, the nameplate bug was definitely the lesser of two evils.
But like I said, these are just the reference shaders and you can change them however you like to distribute with your own mod or whatever. The reference set was designed to work as well as possible with everything I could throw at it. Very few people will actually have such requirements in real like however, so you can change things as you see fit to work best with your own data.
And for the curious, I'm attaching a diff of the 1112 and 1119 shaders (minus the new/removed files).
The extensiveness of the testing makes me wonder even more what's going on by the way, since obviously things seem to be working differently on your end and my end, assuming I have comprehended the description of transparency issues correctly.
Also, if the shaders are to be considered media rather than parts of engine, should this conversation be in SCP forum in the first place?
-
Mayhaps the transparency problems only surface at specific hardware/driver combination or something
I considered the same thing while I was writing my previous response but discarded the idea since it really wouldn't matter for the reference shaders one way or the other. The 1112 and 1119 shader sets are part of the same "family" of sorts, the shader rewrite that was in part specifically done to fix the transparency problems. The difference could be hardware/driver related, but I really doubt it. Most likely is is simply due to the difference in test data, where what you have works but if I was to go through my test suite again it would still have the problem.
But I'll have a look at the spec map issue next week and see if I can't work out a shader fix that solves it.
Also, if the shaders are to be considered media rather than parts of engine, should this conversation be in SCP forum in the first place?
Going strictly by the original topic, no. But technically it's a 50-50 thing, where it is part data and part code/engine. I'd say it's just as valid to have this discussion here as it would be in the modding or upgrade forums.
-
There really isn't a lot I can do about that though, it will take someone with a Mac that has the problem to go through the code and try and work out where the problem is hiding.
Or a hardware donation to Taylor ;7
-
Unfortunately, I don't think that I've heard a single person on a Mac report any success in getting shaders to work. There always seems to be rendering issues at the least. My Mac is too old and doesn't have the hardware needed for shader support, so I was never able to test properly and figure out what was going on. The problem is either in the code itself or the shaders, but I'm pretty confident that it's the code that's at fault. The same code works on Windows and Linux, so it means we have yet another Mac-only rendering problem on our hands. There really isn't a lot I can do about that though, it will take someone with a Mac that has the problem to go through the code and try and work out where the problem is hiding.
Actually, shaders seem to work fine in window mode on OSX, although environmental mapping is decidedly borked...
EDIT: see here (http://www.game-warden.com/earthdefence/staff_files/blowfish/stuff/borkedenvmapping.jpg)
-
Strange, I just reported a bug (http://scp.indiegames.us/mantis/view.php?id=1747) the other day about environment mapping, it's actually a crash bug. Somewhat complicated to reproduce though.
-
[OFFTOPIC]
Speaking about shaders.
Heigh maps (ie Uly) look worse in this new shader version (1119 or 003) than in the very first version Taylor made. There are more displacement artifacts arround the edges.
Maybe, now that shaders are fully public, some bored coder can improve the parallax shader / map ;)
(Although, I myself consider heigh maps a complete luxury. Normal mapping is really shown in-game, but parallax mapping... I doubt anyone will REALLY notice it while playing)
[/OFFTOPIC]
-
Heigh maps (ie Uly) look worse in this new shader version (1119 or 003) than in the very first version Taylor made. There are more displacement artifacts arround the edges.
It was changed by request. The art folks liked it better the current way.
It's easy enough to change to the old way though. Just open up one of the respective "h" shaders in a text editor and look for the "h_offset" line, this is where it determines how much to offset. You can change it by modifying the last value, the "0.02". Lower values have less offset, higher values have more offset. It was "0.01" previously, so you can just change it to that if you liked the old way better. :)
-
I'm going to have to make note of that, it could easily be something we want to tweak for FotG since we'll be making heavy use of those maps. Also, that env map bug I was talking about is fixed now. Not sure if it could be responsible for other env-related bugs or not.
-
pics or it didn't happen.
/sorry