[blackhole]

Hmmm. Well i'd go ahead and just make the openGL only, at least for now. There's got to be a way of doing it with D3D, but it would be better to wait until the D3D API doesn't suck and i've had a chance to implement a bunch of features for it.

That said, we're going to continue having D3D support? Does that mean i'm the SCP directX coder?

[WMCoolmon]

I was being optimistic about you completing the code and being able to maintain it...I did not mean to imply that a permanent decision had been made by anyone.

[blackhole]

awwwwwww

Oh well, i'll just have to keep on chugging.

[Nuke]

d3d is why i cant play 50% of the games that i bought. howd you ever convince taylor to let you guys put it back in? it seems like more of a hassel that its worth. all the games that use open libratys seem to still work, the ones that use proprietary libs, dont. you think the game industry would have learned by now.

[taylor]

d3d is why i cant play 50% of the games that i bought. howd you ever convince taylor to let you guys put it back in?

It's not back in yet.

I had said in earlier dev discussions about this same thing, that if we don't get someone dedicated to keeping D3D up-to-date, the code needed to be removed.  It's still going to remain disabled for a while yet, but if someone works on it then it could be enabled again.  The rub is that nothing regarding D3D is acceptable if it messes with OpenGL in any way.  Since FSO is not a full blown cross-platform game engine, anything that doesn't further the goal of cross-platform use will get minimal consideration at best.  OpenGL is the primary graphics API in FSO from now on, so it has to always work, without exception.

The D3D code needs a lot of work before it's re-enabled, so you really won't have to deal with it for a while still.  And there is still the possibility that I'll eventually convince the others to drop multi-API support completely for graphics, get rid of a lot of middle layers, and finally take full advantage of OpenGL.  But I agreed to not broach that subject seriously until next year, if D3D wasn't up to 100% again by that time.


I wouldn't worry about it much either way though.  I've got so much planned for making the OpenGL stuff better that it's not even funny.  Performance and compatibility are going to expand considerably by the end of the year, just as features will.  Plus, I've got a few nice surprises in store for everyone with 3.6.10.

[blackhole]

Well come on, will you guys make up your mind? Do you want DirectX or not? I'm willing to work on it and make it work, but not if it might end up getting taken out anyway because you don't want 2 APIs. I think my time would be better spent writing up GLSL shaders, or heck, learning openGL and helping you there.

I've shown that i can at least get basic functionality but if there are people who don't want DirectX regardless of how well it works... Um....... Yeah....

[WMCoolmon]

Well let's cut right to the core of the matter, then: What benefit does having DirectX in addition to OpenGL have?

I haven't heard anyone definitively answer this question yet.

[blackhole]

I'm going to tell you straight out that OpenGL and directX are almost equal. OpenGL is cross platform, but directX does have some advantages over it in other areas. I feel they are equal.

But in perfect honesty, Drop DX.

I'm serious, just drop directX. Freespace 2 isn't made for directX, and i can see that its goals are cut out for openGL. So take it from me, just drop directX. Its not worth it. The fact that you want to be cross-platform... just drop the whole stinkin API for directX. You will not suffer from it. And you have everything to gain, because its obvious that you have an openGL genious here. Take advantage of him.

[Bobboau]

well the advantages are basically, DX runs better on some hardware, and it's nice to have an alternative API available.

not that I'm trying to justify keeping DX.

I know I'm basically on hiatus until everyone else makes up there minds about this and implements something based on this determination.

[blackhole]

Yes, those are the advantages to DX. But then you have to compare that to the advantages of openGL. Its cross-platform and your main programmer is an openGL guru.

Drawing on my very limited project managing experience, if this is hindering the project, KILL IT! DirectX is OBVIOUSLY hindering this project, big time. KILL IT!

[taylor]

I have no problem with FSO having D3D support, so long as it's supported.  And it hasn't actually been supported in years.  But it's never going to be considered the primary graphics API again, so it can't get any sort of preferential treatment like it sometimes has in the past.  If someone wants to work on it, and seriously support it, then we'll keep it.  If it's just a passing thing, then we won't.  I'm indifferent either way really, since I don't use Windows and therefore have absolutely no use for the D3D code.  The only time that I have a problem with D3D support in the engine is when no one is willing to spend the required time to maintain it, sort out all of the bugs in it, and when code changes are made which are more beneficial to D3D than OpenGL (ie, it wouldn't be the best way to do it in OpenGL, which then can hurt performance).

I'm certainly no OpenGL guru though, there simply isn't anyone else to do it.  Someone had to step up and do the work, and I simply got tired of waiting for somebody else to do it.  If OpenGL breaks then I can't play the game any longer, so there is a real incentive for me to help keep it working in top form.

If you want to support D3D, blackhole, then feel free.  But just do it seriously, since your interest in it would be the only thing preventing us from completely removing the code.  If you don't have the time or energy to really support it, and eventually just vanish, then we will be right back where we are now, for the 3rd or 4th time.  I, personally, refuse to go through all of this yet again, so if you don't want to take on the responsibility then please say so now.


And for the record, DX9 support was do 2 years ago, but the guy never put the code in CVS, and then vanished.  The DX9 SDK had already been added to CVS, and the Launcher had already been modified to handle DX9, but the game code never materialized.  Since then, no serious work has been done on the D3D code.  The stagnant D3D code has since held up the OpenGL code, since without anyone to keep the D3D code working the changes to OpenGL had to be regulated to prevent code breaks.  My Xt builds no longer support D3D, and in the past couple of months more advances and progress have been made in the OpenGL code than all of last year.  So much progress in fact, that I've had to put a serious halt on the changes so that I don't get the code too far ahead of what 3.6.10 is supposed to be.

[blackhole]

I don't personally feel that i could maintain support for directX9 for an extended period of time. Over this summer, maybe, but by the start of the next school year i'd be far too busy to do anything.

[jr2]

Hmm, I'm not a programmer, so this may be absolute bunk, but, what if blackhole implements DX9, in a modular <-is this the right term? fashion, so that if no one keeps it up, that part of the code can be easily removed.  Then, in the future, if someone fixes it again (maybe next summer when blackhole comes back with gobs of time on his hands ), it can be plugged right back in?  IDK.

[Topgun]

Hmm, I'm not a programmer, so this may be absolute bunk, but, what if blackhole implements DX9, in a modular <-is this the right term? fashion, so that if no one keeps it up, that part of the code can be easily removed.  Then, in the future, if someone fixes it again (maybe next summer when blackhole comes back with gobs of time on his hands ), it can be plugged right back in?  IDK.

That might be very hard to do but, I don't know anything about graphics or FSO code, so it might work.

[blackhole]

That would be simple if everything was object oriented *cough* but it isn't, so its actually very very difficult to do. The advantage that taylor is pointing out is that he can annihilate the entire middle-area that mediates between the two APIs, allowing for faster and more direct control. That would make it essentially impossible to have directX as an optional API.

[taylor]

Hmm, I'm not a programmer, so this may be absolute bunk, but, what if blackhole implements DX9, in a modular <-is this the right term? fashion, so that if no one keeps it up, that part of the code can be easily removed.  Then, in the future, if someone fixes it again (maybe next summer when blackhole comes back with gobs of time on his hands ), it can be plugged right back in?  IDK.

The D3D code is already #ifdef'd, so it's easy to compile out (required for cross-platform support anyway).  But that doesn't really solve the problem, since even if it were fixed now, it would just break again in a couple of months.  That's the problem with fixing it, the code just isn't going to stay working, and we will once again be in the same position of being forced to disable the code.  Simply fixing it now will do little more than waste the time of everyone involved which makes the prospect of D3D support entirely futile.

If no one is going to be able to constantly maintain the code, then we will have little choice but to rip it out.


We've tried the "just keep it working" approach for nearly two years now, and it's caused a drastic slowdown in new features.  I mean, general shader support was added for OpenGL a year ago by wolf, but it causes serious problems with D3D support and so it has been put on hold ever since as I have tried to work out all of the various issues.  Making generic rendering significantly faster, even giving a massive speed boost to non-HTL mode, is easily possible for OpenGL, if we didn't have to keep D3D working in the process.  That's really what my Xt builds have been about, but even they have progressed further and faster than I had planned, since I am temporarily holding features back simply for the sake of 3.6.10.

Many people seem to want D3D support, but no one is willing to make the sacrifices needed to keep it all working, like I had to do with OpenGL support.  So we just keep running around in circles, with us keeping the current D3D code in place in case someone decides to work on it, and all the while it's getting more and more unusable.  By the end of the year it will need almost a complete rewrite in order to be compatible with the OpenGL changes.

[Fabian]

Many people seem to want D3D support, but no one is willing to make the sacrifices needed to keep it all working, like I had to do with OpenGL support.  So we just keep running around in circles, with us keeping the current D3D code in place in case someone decides to work on it, and all the while it's getting more and more unusable.  By the end of the year it will need almost a complete rewrite in order to be compatible with the OpenGL changes.

How do big commercial projects like Doom 3 or Unreal Tournament 2004 (2007?) do it? Do they use D3D for Windows (DX10 left beside now of course ...) and OpenGL for the rest?

Why do those people want D3D anyway? What advantage does it have?

Many games using D3D run with wine get translated to OpenGL calls just fine and on the same speed as their windows counterparts ... So it can't be a performance issue ...

Then I seriously do not understand what advantage D3D has ...

cu

Fabian

[Mehrpack]

How do big commercial projects like Doom 3 or Unreal Tournament 2004 (2007?) do it? Do they use D3D for Windows (DX10 left beside now of course ...) and OpenGL for the rest?

Why do those people want D3D anyway? What advantage does it have?

Many games using D3D run with wine get translated to OpenGL calls just fine and on the same speed as their windows counterparts ... So it can't be a performance issue ...

Then I seriously do not understand what advantage D3D has ...

cu

Fabian

hi,
the problem was the OpenGL committee, as far i had hear it in the forums, if people discuss about the situation over OpenGL.
Microsoft blocked over many years the work in it, slow it really down and tried many Years that OpenGL and Direct3D melt together.
so there was a lot of work that doesnt done and OpenGL doesnt have Support out of the Box so many feature like Direct 3D.
after the left of Microsoft the committee, now its going on and the most people hope, that OpenGL will catch up what it miss.

the next thing is, that writing the code/functions with Direct 3D is easier compared with OpenGL, but im not a programmer and i cant say it excatly.

the other thing is, the most people have Windows as OS, they buy complett PC in a shop and doesnt intereset in PC Hardware and Software.
i think the most people on the planet doesnt know what DirectX eactly is, only that is cool and needed, more not.
i know the problem with Direct 3D 10.
many people had think that Direct 3D 10 = DirectX 10 is.

so you have an API that have a good and contemporary featureset, that often neat, that is installed on all PC that of your customers and that is, maybe, easier to write the code and features.


the only thing that i see for FSO is, that maybe i the future, if OpenGL doesnt have a revial, the manufacturer of graficcards maybe someday will drop thiere support for OpenGL in the driver for gamecards.
today the OpenGL driver of AMD/ATI doesnt so good and cause a lot problems and nvidia is in the moment under vista not so good too, if the reports are correct that i read.


i hope thats understandable, i try my best to write it in english *g*.

Mehrpack

[blackhole]

Actually Nvidia fixed their openGL problem.

[Nuke]

well i for one refuse to buy a vid card without opengl support. and if open gl ever becomes obsolete, it had best have another open api right behind it. i have never had a single problem with open gl, ever.

How do big commercial projects like Doom 3 or Unreal Tournament 2004 (2007?) do it? Do they use D3D for Windows (DX10 left beside now of course ...) and OpenGL for the rest?

they write really strong abstraction layers and insert hardware specific optimizations anywhere possible. often they can forgo device drivers and the apis all together with really low level code written in assembly for such operations. or at least thats what i read. killing a single multiply in a function called hundreds of times a frame can have a signifficant impact on performance.