[Bobboau]

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.)

[niffiwan]

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, 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)

[The E]

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.

[Bobboau]

why won't it?
if you leave it there an disallow breaking it it limits what you can do.

[The E]

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.

[Luis Dias]

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

[EvidenceOfFault]

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...

[The E]

They do support it, they just aren't supporting it in the same way that AMD and Nvidia support it.

[Goober5000]

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.

[Talon 1024]

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...

[Nuke]

i didnt know we were still using a fixed function pipe. thought that was killed off long ago.

[niffiwan]

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...

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.

[The E]

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...

That is exactly what it means. Which is why that's not going to be done.

[Swifty]

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.

[Nuke]

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.

[Bobboau]

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...

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?"

[pecenipicek]

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...

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.

[The E]

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.

[T-Man]

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'.

[General Battuta]

and what BP tried recently?

Not really. The BP builds were a public test of a feature that was intended for trunk.