Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Bobboau on April 27, 2014, 11:43:13 pm
-
So I'm not really active here the last, like five years or so, but I figured I can still post highly controversial topics.
so lets throw this out there: **** the fixed function pipeline. seriously.
Now I know what you are thinking: "The hell are you on Bob?! We need that for backwards compatibility!"
to which I respond: "Compatibility with what?"
Seriously, this probably could have been done in 2007, it's twice that now, I think it's safe to mark the fixed function HT&L pipeline deprecated and focus squarely on the programmable shader utopia future.
Granted some work probably needs to be done in terms of making the shaders work for the few people who cannot use them now, but I think that would be less work in the long run than maintaining the old non-programmable option.
We did this with HT&L vs ST&L.
Why is making an active choice to do this good? why not just leave it there and maybe not give it as much attention?
The fixed function and programmable pipelines behave in massively different ways, maintaining the fixed function pipeline means you will forever be chained to having things organized the way it likes. dropping it would allow for major restructurings that could allow a vastly simpler and more flexible internal structure, which would translate directly into better features, developed faster and made more stable. With the policy of 'we must maintain the fixed function' in place no coder would ever be allowed to make these improvements.
So. Who's with me?
/*grabs pitch fork and torch*/
(also poll about if your graphics card is incapable of supporting freespace open in shader mode. lets see if I'm wrong about this.)
-
Hrmmm... well those remarkably popular Intel cards still have problems with FSO and standard support advice is to use "-no_glsl", which I believe means the fixed function renderer (aside: Intel HD Graphics 4000 is the most popular according to Steam (http://store.steampowered.com/hwsurvey/videocard/), and IIRC that's a buggy 4.0 implementation). Maybe in a few more years when Intel gets their OpenGL drivers into a better state (or should I say, when the latest cards+drivers become more widely used), and the older cards die via attrition?
Also, while my primary PC is perfectly happy with the full glory of shaders, my laptop, work PC, and VMs all hate them to varying degrees. And as far as testing multi goes (sure I could be doing more of it) I need those other options. (yes, this is an edge case)
(Edit: and some unity3D stats as well: http://stats.unity3d.com/pc/gpu.html)
-
A few things:
Cutting out the fixed function renderer won't happen. However, at the same time, no work will be done on it anymore. The current plan, such as it is, is to write a new, OpenGL 3 core profile renderer from scratch, and only invoke the fixed function one in cases where OpenGL 3 isn't available.
-
why won't it?
if you leave it there an disallow breaking it it limits what you can do.
-
Removing it doesn't gain us anything except a reduced userbase.
EDIT:
Your assertion that retaining the FF renderer would hold back this theoretical new renderer has no basis in reality, from where I'm sitting. We already have a renderer interface that we can plug stuff into, the actual nuts and bolts of OpenGL are pretty well isolated from the rest of the engine, so I don't quite see any difficulties in keeping the FF renderer around for the foreseeable future.
-
The current plan, such as it is, is to write a new, OpenGL 3 core profile renderer from scratch, and only invoke the fixed function one in cases where OpenGL 3 isn't available.
wat? O_O omg
-
AFAIK, the integrated Intel cards are not "buggy", they simply only support the core openGL profile, not the compatibility profile. A new openGL 3 core profile renderer would be awesome. Then the fixed function can die...
-
They do support it, they just aren't supporting it in the same way that AMD and Nvidia support it.
-
Removing it doesn't gain us anything except a reduced userbase.
EDIT:
Your assertion that retaining the FF renderer would hold back this theoretical new renderer has no basis in reality, from where I'm sitting. We already have a renderer interface that we can plug stuff into, the actual nuts and bolts of OpenGL are pretty well isolated from the rest of the engine, so I don't quite see any difficulties in keeping the FF renderer around for the foreseeable future.
Quoted for truth.
Additionally, Bobboau, there are a number of high priority outstanding bugs and feature requests that desperately need attention. Ignoring these to focus on Yet Another Grandiose Project is just a recipe for shooting ourselves in the foot.
-
I do wonder if throwing out the Fixed Function renderer means that users without graphics cards that support shaders will be unable to play FSO... :nervous:
-
i didnt know we were still using a fixed function pipe. thought that was killed off long ago.
-
I do wonder if throwing out the Fixed Function renderer means that users without graphics cards that support shaders will be unable to play FSO... :nervous:
As far as I know, if you need to use any of the Troubleshooting flags that include the word "shader" (and maybe some more besides) then yes, you wouldn't be able to run FSO.
-
I do wonder if throwing out the Fixed Function renderer means that users without graphics cards that support shaders will be unable to play FSO... :nervous:
That is exactly what it means. Which is why that's not going to be done.
-
I think fixed function still provides a good baseline for users with GPUs that have wonky shader compilers and extensions. That's why I'm not going to bother removing it when I start work on getting a Core Profile working.
Honestly, a lot of OpenGL 4.0 features would already be in the game if it wasn't for Apple insisting that OpenGL 3.2+ features only work in the Core profile. Other vendors in fact make the Compatibility profile their default GL implementation and actually build the Core profile on top of that. For them, the Core profile is just an extra validation layer and is in fact slower.
Fixed function hasn't really hampered us in that regard. A lot of the time when implementing all these features, I don't even think about how my implementation would affect the fixed function codepath. And for the most part, it seems to work out fine based on the times when my shaders break and I'm auto-dumped into the fixed function render path.
So yeah, blame Apple for why we haven't adopted new graphics features as fast as we'd like. Not the fixed function codepath.
-
i think they are all to blame. no one manufacturer should be allowed to bend a standard to suit their platform's needs at the time. apple may be the lastest offender, but its not like they all didnt do this at some point in time.
-
I do wonder if throwing out the Fixed Function renderer means that users without graphics cards that support shaders will be unable to play FSO... :nervous:
That is exactly what it means. Which is why that's not going to be done.
It also means all unicorns will be afflicted with testicular torsion.The $64,000 question is, however, "How many, if any, unicorns are there in existence to be afflicted?"
-
I do wonder if throwing out the Fixed Function renderer means that users without graphics cards that support shaders will be unable to play FSO... :nervous:
That is exactly what it means. Which is why that's not going to be done.
It also means all unicorns will be afflicted with testicular torsion.The $64,000 question is, however, "How many, if any, unicorns are there in existence to be afflicted?"
anyone with an intelgrated and no other option, for now.
-
It also means all unicorns will be afflicted with testicular torsion.The $64,000 question is, however, "How many, if any, unicorns are there in existence to be afflicted?"
You do know that you haven't put forward any convincing argument for your position, right? Can you actually point to the areas of the code that would make the plan we're currently pursuing impossible, or that would negatively affect those plans? Can you actually name a feature that would be impossible, or even appreciably more difficult to do if we leave the fixed function renderer in place as a fallback option?
Because if not, I gotta tell ya, I'm more inclined to believe Swifty's (or, for that matter, my own) judgment.
-
I am slightly confused by this (and so may be totally going the wrong way, so sorry in advance if I have) but; why would SCP need to change anything for you to try this non-compatibility Bob? If you want a build that breaks compatibility and allows more features, can't you just make it as a new build outside of pipeline and dev it yourself or with a team? Is that not what Inferno did for a while, WC Saga has, and what BP tried recently? You sound pretty confident that this change will bring great things, so I say prove it to us and to the coders; show us how it is better to back up your case. (or have I missed the point here?)
Some people may not want to use you special build for various reasons but *shrug* 'their loss' from your perspective; forcing them to change it would only peeve them off and make them drop FSO anyway.
Perhaps I'm misunderstanding the point of all this, but I dunno, worry this is a needless argument t'is all. "You must be the change you wish to see" [/random quotation]. If you feel it's a majorly good idea, my feelings would be 'prove it' and 'hope it goes well'.
-
and what BP tried recently?
Not really. The BP builds were a public test of a feature that was intended for trunk.
-
Yeah, BP didn't really branch out, but did include builds with cutting-edge features it needed, but that were not even stable enough for nightlies (at least in theory. I was using BP builds all the time, they were rather reliable). In fact, they were no different from test builds posed on this board, except for the more prompt update schedule and the fact they sometimes contained multiple unstable features at a time. It was something like Antipodes on steroids.
I think that here, branching is a bad idea. It adds a lot of overhead to manage yet another code branch, especially one that is not planned to be merged in at any point. Inferno was rather unproblematic, because the difference wasn't too drastic, and didn't affect key areas of the game like this one would.
-
We didn't need deferred lighting, we just wanted to give it a broad-base test so the SCP could get information on how it would affect end users.
-
In that case, yeah (perhaps I should have said "wanted" instead of "needed" :) ), though remember that this feature also did affect the development. Without it running on a BP build, we wouldn't be able to add glowpoint lighting as fast as we did. So in a way, it was needed, because we wanted lighting for glowpoints. Hardly anything that would hold up the release, but hey, BP1 was originally written on 3.6.9, IIRC. :) Shadows would probably be a better example, since they didn't involve any table changes (though TBH, once shadows were implemented, they were kind of needed for everything, because they are just that awesome).
-
Unfortunately the implementation isn't really ready for prime time. Glowpoint lighting and shadows are being stripped out for the next release and moved to an optional package because they caused so many performance problems.
-
Hopefully I'll do my best to optimize it. The current deferred lighting and soft shadows build already has some optimizations for deferred lighting but the soft shadows kind of eliminates that performance boost. The next test build for deferred lighting and soft shadows will definitely be faster.
-
So I have one of those dual laptop integrated with real card as well, and FSO (and some other games) refuse to see the second bin integrated card. I have to use noglsl (which is why I stopped trying to play, among other reasons).
-
Hopefully I'll do my best to optimize it. The current deferred lighting and soft shadows build already has some optimizations for deferred lighting but the soft shadows kind of eliminates that performance boost. The next test build for deferred lighting and soft shadows will definitely be faster.
Looking forward to it. Performance improvements are always welcome. I can hardly play without shadows now. :)
-
So I have one of those dual laptop integrated with real card as well, and FSO (and some other games) refuse to see the second bin integrated card. I have to use noglsl (which is why I stopped trying to play, among other reasons).
if its an optimus laptop, go to nvidia control panel, manage 3d settings, program settings, add the fso executable of the day and set it to run on that card...
-
I did. No dice. Something (FSO?) is ignoring that setting, which works for 99 % of all the other programs I run.
-
Sorry if this is "duh obvious", but you've got the fso release & debug .exes selected in the control panel, not the launcher?
-
:nod:
-
Yeah, that's a weird one then since as far as I know FSO doesn't know anything about selecting video cards, is just uses what it's given by the OS.
-
Could you try an antipodes build? The OpenGL context is created by SDL which might be different from what FSO currently does.
-
This gives me a reason to fix my laptop (hard disk dying, dog knocked it down while runnin).
I'll work on it.