It is currently Sat Aug 30, 2014 8:31 pm



Reply to topic  [ 42 posts ]  Go to page 1, 2  Next
 Doom3 BFG Source Code released. Includes RIFT related code 
Author Message
One Eyed Hopeful

Joined: Sun Jun 24, 2012 5:55 pm
Posts: 21
https://github.com/id-Software/DOOM-3-BFG

A quick search finds mentions of the Rift in the source code.

I haven't looked any deeper yet.

Cheers, Adam.


Mon Nov 26, 2012 6:58 pm
Profile
Sharp Eyed Eagle!
User avatar

Joined: Tue Aug 21, 2012 6:51 am
Posts: 401
zdam wrote:
A quick search finds mentions of the Rift in the source code.

More specifically


Interesting comment:
Code:
// With the 7" displays, this will be less than half the screen width


Last edited by mahler on Mon Dec 03, 2012 12:40 am, edited 2 times in total.



Mon Nov 26, 2012 7:44 pm
Profile
3D Angel Eyes (Moderator)
User avatar

Joined: Sat Apr 12, 2008 8:18 pm
Posts: 10872
I'm really surprised that they released the source code so soon after release (the game just came out last month)!

However I hope that doesn't mean they are done supporting it. I'd hope they still release a patch for the final Rift dev kits (new tracker, etc.).

_________________
check my blog - cybereality.com


Mon Nov 26, 2012 7:54 pm
Profile
One Eyed Hopeful

Joined: Mon Aug 06, 2012 4:50 am
Posts: 49
John Carmack wrote yesterday in Twitter.
"... the head tracking code is not included, Oculus doesn't have the SDK sorted out yet. There will be another release later."


Tue Nov 27, 2012 2:16 am
Profile
Cross Eyed!
User avatar

Joined: Wed Feb 15, 2012 8:58 pm
Posts: 142
Just before the developer kits reach people, he releases his own code for them and he commits to a new release when the SDK is finished for the new tracker.
I love this man :)

_________________
Answers
Walking the thin line between Jobs and Kramer


Tue Nov 27, 2012 3:07 am
Profile
One Eyed Hopeful

Joined: Thu Jul 26, 2012 6:47 am
Posts: 49
donkaradiablo wrote:
Just before the developer kits reach people, he releases his own code for them and he commits to a new release when the SDK is finished for the new tracker.
I love this man :)


Seconded! That guy is my hero :D

_________________
"Creating the world's most immersive virtual reality erotic encounters @ http://www.wickedparadise.com"


Tue Nov 27, 2012 3:48 am
Profile
Binocular Vision CONFIRMED!
User avatar

Joined: Sun Sep 09, 2012 4:55 pm
Posts: 302
Still don't quite understand Carmack's decision to render as a square to give symmetrical fov.
Then again, who am I to question him. It might very well be less distracting.


Tue Nov 27, 2012 4:56 am
Profile
Certif-Eyable!

Joined: Tue Sep 18, 2012 10:32 pm
Posts: 1139
Now we just need to put Carmack's reverse back in, add an open source Bink player, render it with the full vertical FOV, renazify and restore the red crosses to Doom I and II, add Rift support to Doom 1 and Doom 2, and any other VR stuff we want.


Tue Nov 27, 2012 5:13 am
Profile
Cross Eyed!
User avatar

Joined: Mon May 18, 2009 2:54 am
Posts: 160
cybereality wrote:
I'm really surprised that they released the source code so soon after release (the game just came out last month)!

However I hope that doesn't mean they are done supporting it. I'd hope they still release a patch for the final Rift dev kits (new tracker, etc.).


If I had to guess this is an invitation from Carmack for people to play around with ideas for the Oculus Rift. No doubt he'll pay attention to the best ideas and maybe incorporate some into Doom 4.


Tue Nov 27, 2012 12:30 pm
Profile
Cross Eyed!
User avatar

Joined: Fri Aug 03, 2012 10:27 pm
Posts: 154
troffmo5 wrote:
John Carmack wrote yesterday in Twitter.
"... the head tracking code is not included, Oculus doesn't have the SDK sorted out yet. There will be another release later."


Has anyone here implemented or started working this for their own tracker using doom3 bfg source? Or if anyone is interested in collaborating on this contact me.


Sat Dec 01, 2012 2:53 am
Profile
Two Eyed Hopeful

Joined: Mon Aug 13, 2012 5:55 pm
Posts: 85
I think these are the actual vertex and fragment shaders for the warping:

Fragment
Vertex


Sat Dec 01, 2012 11:44 am
Profile
Cross Eyed!
User avatar

Joined: Fri Aug 03, 2012 10:27 pm
Posts: 154
While i wait on my parts arrive for a DIY rift. I'm doing a little software work so i'll have something to run the hardware against.

My goal is to try to get the Doom3 BFG E3 rift demo experience. As mentioned, the released D3BFG source has all the 3D and warping code but none of head tracking and minor control changes.

To start I've got the 3d with rift warping going and my XBox gamepad working using the wireless pc adapter. I've modified the code for the right analog so that it only modifies the yaw angle. And it looks like I should insert the head tracking in the void idUsercmdGenLocal::MakeCurrent() method.

I have two trackers on the way, the Hillcrest and YEI 3 space. I've never programmed my own fusion code using raw IMU data so i imagine initially I'll just be using what's provided by the track SDKs.

UPDATE:
I've just added Hillcrest tracker code integrated into DOOM3 (a slightly modified version of the code from article.) but still waiting on the hardware to test it.


Here's a screenshot at 1280x800 res with warping and gamepad. I'm tinkered a good bit with the first release of the DOOM3 source code so if your working on DOOM3 code and want some help i'm available.

Image


You do not have the required permissions to view the files attached to this post.


Sat Dec 01, 2012 6:54 pm
Profile
One Eyed Hopeful

Joined: Sun Jun 24, 2012 5:55 pm
Posts: 21
Fabien also has a great series of articles on the Doom 3 engine.

http://fabiensanglard.net/doom3/index.php

Cheers, Adam.


Sun Dec 02, 2012 11:47 pm
Profile
Cross Eyed!
User avatar

Joined: Fri Aug 03, 2012 10:27 pm
Posts: 154
zdam wrote:
Fabien also has a great series of articles on the Doom 3 engine.

http://fabiensanglard.net/doom3/index.php

Cheers, Adam.


Yes, his articles are great I've learned a lot from them.


Mon Dec 03, 2012 2:57 am
Profile
Certif-Eyable!

Joined: Tue Sep 18, 2012 10:32 pm
Posts: 1139
I fixed a couple of bugs in Doom 3 BFG edition.

I got the Xbox secret level of Doom 2 working.
Quote:
MAP33: Betray is a secret map exclusive to the Xbox version of Doom II, included with the Xbox Collector's Editions of Doom 3 and Doom 3: Resurrection of Evil. It can be accessed from MAP02: Underhalls, and contains SS Nazis for no apparent reason. It was originally a 1995 level designed by Michael Bukowski, a programmer for the Doom 3 port with Vicarious Visions.
...
Completing this level takes the player to MAP03: The Gantlet.

The Xbox 360 port of Doom II also contains Betray. However, it is not accessible due to the exit switch leading to the level being inoperable in MAP02 of the port.

That map is also (accidentally?) included in Doom 3 BFG Edition, except the code for it is missing, so the secret exit in MAP02 just takes you to MAP03. Also it doesn't load the resources for MAP33, which makes it crash. And it doesn't have the level name in the list, so when you save the game on that level, it gives the game the wrong name.

I fixed all those bugs in the source code, and I even fixed (in the source code) the bug with the broken teleporter that gets you trapped if you haven't got the yellow key yet. So now MAP33: Betray is fully working in Doom 3 BFG Edition (except the Nazi SS, which look like zombies but sound like Nazis).

I also fixed the level names for the normal secret levels (Wolfenstein, and Grosse), although I haven't fixed the graphics for the names.

Now I just need to work out a way to fix the Red Cross logo, and remove the censorship, from the source code without changing the wad files.

We'll probably have to completely replace their Doom classic implementation though, because it isn't in 3D, doesn't use the right aspect ratio and FOV, doesn't have head-tracking, and has ugly 8-bit palette effects. Maybe I'll swap in most of PRBoom+ since I've had the most luck getting that to compile and work.


Tue Dec 04, 2012 8:12 pm
Profile
Cross Eyed!
User avatar

Joined: Wed Jan 11, 2012 1:06 pm
Posts: 194
Now that the source code is released, I don't suppose anyone could tell me why Carmack's Doom 3 engine always had such fantastically smooth mouse movement?

_________________
Metro 2033 3D screens - Mass Effect 1 3D scenery - High FoV 46" Sony 3DTV


Wed Dec 05, 2012 11:09 am
Profile
Cross Eyed!
User avatar

Joined: Mon May 18, 2009 2:54 am
Posts: 160
Libertine wrote:
Now that the source code is released, I don't suppose anyone could tell me why Carmack's Doom 3 engine always had such fantastically smooth mouse movement?


Carmack has always specialized in extremely fast 3D engines that produce smoother graphics and lower latencies using openGL which is better suited for the purpose than DirectX. Besides designing the engines from the start for smoother game play he goes back over the finished game and tweaks any rough spots that might lag. Unlike most developers he loves to talk about his work and you can find videos of him on youtube, but even John has to keep some of his specific techniques trade secrets. ;)


Wed Dec 05, 2012 5:47 pm
Profile
Cross Eyed!

Joined: Mon Aug 13, 2012 5:21 pm
Posts: 182
OpenGL isn't inherently better, he has said so himself. Both APIs do fundamentally the same things under the hood. What really matters is the application code that feeds the API. Carmack just cares more about the robustness of his code than most, and is in a position to dictate when its ready for release, while most professionals have to follow someone else's schedule.


Thu Dec 06, 2012 4:23 am
Profile
Diamond Eyed Freakazoid!
User avatar

Joined: Thu Oct 18, 2012 3:34 am
Posts: 733
Location: Brighton, UK
Plus many devs seem to think I want my mouse to have at least one of:
* Smoothing
* Acceleration
* Latency

I don't. :evil:
I think a big part of it is that a lot of games are built for consoles and their input code is designed to be used with a gamepad, then they jam mouse input through the same system instead of doing it properly. Good mouse control isn't a priority and it shows.

_________________
Sometimes I sits and thinks, and sometimes I just sits.


Thu Dec 06, 2012 8:10 am
Profile WWW
Cross Eyed!

Joined: Mon Aug 13, 2012 5:21 pm
Posts: 182
The other main issue is that latency and smooth rendering are at odds with each other. If you sacrifice response times you can draw more stuff and keep a more consistent framerate by rendering a frame or two behind the game logic. Many devs decide that this is worth the cost, especially since there are plenty of studies showing that the average gamer just isn't that sensitive to latency.


Thu Dec 06, 2012 12:07 pm
Profile
Diamond Eyed Freakazoid!
User avatar

Joined: Thu Oct 18, 2012 3:34 am
Posts: 733
Location: Brighton, UK
Owen wrote:
The other main issue is that latency and smooth rendering are at odds with each other. If you sacrifice response times you can draw more stuff and keep a more consistent framerate by rendering a frame or two behind the game logic. Many devs decide that this is worth the cost, especially since there are plenty of studies showing that the average gamer just isn't that sensitive to latency.

I'm more of a "vsync is the devil due to adding a small amount of lag" kind of guy :P I'm a bit of a mouse control nazi; I think I got too used to how nice it feels in some games with a good mouse and a 120hz screen, and when it goes wrong I really feel it. eg in Left 4 Dead +vsync I was completely unable to do the fancy stuff with the hunter that I normally could with ease.

_________________
Sometimes I sits and thinks, and sometimes I just sits.


Thu Dec 06, 2012 1:18 pm
Profile WWW
Cross Eyed!
User avatar

Joined: Mon May 18, 2009 2:54 am
Posts: 160
Owen wrote:
OpenGL isn't inherently better, he has said so himself. Both APIs do fundamentally the same things under the hood. What really matters is the application code that feeds the API. Carmack just cares more about the robustness of his code than most, and is in a position to dictate when its ready for release, while most professionals have to follow someone else's schedule.


Valve and others beg to differ:

http://www.extremetech.com/gaming/13382 ... on-windows

What I have heard Carmack say is that DirectX is pretty good these days, but that's not the same thing as saying it is as fast as openGL which gets closer to the metal.


Thu Dec 06, 2012 1:30 pm
Profile
Petrif-Eyed
User avatar

Joined: Sat Jan 09, 2010 2:06 pm
Posts: 2249
Location: Perpignan, France
wuliheron wrote:
This article seems to be quite a stretch from reality, in the original blog post at Valve they only said that the speed difference was due to a few additional microseconds overhead per batch, not because OpenGL has a "smoother, more efficient pipeline" like it is said in the article. In the blog post they even said that now that they are aware of the hardware capabilities, they'll try to figure out how to mitigate this effect under Direct3D.

So it's very much possible that in the end they'll get exactly the same performance with either OpenGL and Direct3D. Also note that this is an analysis of a single game with a specific engine, it can't be extended to the general case. The fact that they think they'll be able to mitigate the problem shows that's it's related to their specific engine implementation, not to Direct3D itself (over which they have absolutely no control).
wuliheron wrote:
What I have heard Carmack say is that DirectX is pretty good these days, but that's not the same thing as saying it is as fast as openGL which gets closer to the metal.
OpenGL is not closer to the metal, the two APIs are calling exactly the same functions on the GPUs, only in a different way.

And I don't say that to defend Direct3D, I'm basically an OpenGL guy programming on Linux. It's just that I don't like wrong information being propagated, just like it was the case some decades ago against OpenGL.


Thu Dec 06, 2012 2:22 pm
Profile WWW
Cross Eyed!
User avatar

Joined: Mon May 18, 2009 2:54 am
Posts: 160
Fredz wrote:
wuliheron wrote:
This article seems to be quite a stretch from reality, in the original blog post at Valve they only said that the speed difference was due to a few additional microseconds overhead per batch, not because OpenGL has a "smoother, more efficient pipeline" like it is said in the article. In the blog post they even said that now that they are aware of the hardware capabilities, they'll try to figure out how to mitigate this effect under Direct3D.

So it's very much possible that in the end they'll get exactly the same performance with either OpenGL and Direct3D. Also note that this is an analysis of a single game with a specific engine, it can't be extended to the general case. The fact that they think they'll be able to mitigate the problem shows that's it's related to their specific engine implementation, not to Direct3D itself (over which they have absolutely no control).
wuliheron wrote:
What I have heard Carmack say is that DirectX is pretty good these days, but that's not the same thing as saying it is as fast as openGL which gets closer to the metal.
OpenGL is not closer to the metal, the two APIs are calling exactly the same functions on the GPUs, only in a different way.

And I don't say that to defend Direct3D, I'm basically an OpenGL guy programming on Linux. It's just that I don't like wrong information being propagated, just like it was the case some decades ago against OpenGL.


A different article suggests the difference is more like 6% which is far from being a stretch of the imagination:

http://www.i-programmer.info/news/144-g ... is-it.html

For hardcore gaming speed freaks who push their rigs to produce 180+ fps just to get the competitive edge those little differences count and add up. When talking about 120fps for the Rift that's an extra 8fps and nothing to sneeze at.


Thu Dec 06, 2012 2:58 pm
Profile
Petrif-Eyed
User avatar

Joined: Sat Jan 09, 2010 2:06 pm
Posts: 2249
Location: Perpignan, France
wuliheron wrote:
A different article suggests the difference is more like 6% which is far from being a stretch of the imagination:
http://www.i-programmer.info/news/144-g ... is-it.html
This article doesn't bring anything new to the subject, it basically rehashed what Valve said without giving additional details. Which is not surprising per se because none of these "journalists" know better than Valve on this subject.

They also don't say that there is an inherent problem with Direct3D, pretty much the contrary actually :

Harry Fairhead wrote:
So the problem with Direct3D isn't something deep and structural, but a small overhead on each graphics operation that adds up. As the Valve blog says, given that the problem is now identified there might be something that can be done to speed up DirectX to run faster. This isn't quite as damning as some news reports suggest.


wuliheron wrote:
When talking about 120fps for the Rift that's an extra 8fps and nothing to sneeze at.
Ah, the Rift has a 120Hz screen now ? Last I heard it still used a 60Hz screen, I must have missed this new important information.

Also as I said before, the speed difference concerns only one game and may very well be related only to the L4D2 engine implementation. So at this point there is no reason to think that this performance penalty does exist in other games.

And it's not like people had a choice here, there is only a handful of games supporting OpenGL on Windows at this time and there is no reason to think that it'll change in the future. So that supposedly enhanced performance would have absolutely no incidence on Windows gamers.


Thu Dec 06, 2012 3:33 pm
Profile WWW
Cross Eyed!

Joined: Mon Aug 13, 2012 5:21 pm
Posts: 182
The source engine is ancient, possibly the oldest engine still used by a major developer. It was initially built around DirectX 7. Despite having fancy physics and animation tech, until very recently it had a really primitive renderer, and I would bet that the new features they have tacked on since are not optimal for their architecture. I wouldn't trust their numbers as representative, it won't be bottlenecked in the same places as more modern engines.

And Carmack didn't just say it was pretty good, he said that he is using OpenGL due to momentum at this point, that there is no technical reason he is sticking with it.

In any case, when you are looking at differences in overhead that small, it mostly comes down to drivers and vendor specific API implementations. Its going to vary by more than that.


Thu Dec 06, 2012 4:08 pm
Profile
Cross Eyed!
User avatar

Joined: Mon May 18, 2009 2:54 am
Posts: 160
Fredz wrote:
This article doesn't bring anything new to the subject, it basically rehashed what Valve said without giving additional details. Which is not surprising per se because none of these "journalists" know better than Valve on this subject.

They also don't say that there is an inherent problem with Direct3D, pretty much the contrary actually :

Harry Fairhead wrote:
So the problem with Direct3D isn't something deep and structural, but a small overhead on each graphics operation that adds up. As the Valve blog says, given that the problem is now identified there might be something that can be done to speed up DirectX to run faster. This isn't quite as damning as some news reports suggest.


I don't suppose you know what a "red herring" argument is? I never said there was anything inherently wrong with Direct3D and you are arguing with yourself. All I said is openGL is faster.

Fredz wrote:
Ah, the Rift has a 120Hz screen now ? Last I heard it still used a 60Hz screen, I must have missed this new important information.


Palmer has stated many times he wants 120hz screen. You might actually try to cut the sarcasm and pay more attention instead.

Fredz wrote:
Also as I said before, the speed difference concerns only one game and may very well be related only to the L4D2 engine implementation. So at this point there is no reason to think that this performance penalty does exist in other games.

And it's not like people had a choice here, there is only a handful of games supporting OpenGL on Windows at this time and there is no reason to think that it'll change in the future. So that supposedly enhanced performance would have absolutely no incidence on Windows gamers.


Again, nobody, but nobody ever said anything different and you might as well be arguing with yourself.


Thu Dec 06, 2012 5:48 pm
Profile
Cross Eyed!
User avatar

Joined: Mon May 18, 2009 2:54 am
Posts: 160
Owen wrote:
The source engine is ancient, possibly the oldest engine still used by a major developer. It was initially built around DirectX 7. Despite having fancy physics and animation tech, until very recently it had a really primitive renderer, and I would bet that the new features they have tacked on since are not optimal for their architecture. I wouldn't trust their numbers as representative, it won't be bottlenecked in the same places as more modern engines.

And Carmack didn't just say it was pretty good, he said that he is using OpenGL due to momentum at this point, that there is no technical reason he is sticking with it.

In any case, when you are looking at differences in overhead that small, it mostly comes down to drivers and vendor specific API implementations. Its going to vary by more than that.


Carmack lamented the fact he stuck with openGL because for a few years it fell behind DirectX in adding new features and, no doubt, after the 4 month long driver fiasco with Rage he's even more sorry for sticking with openGL because it is notoriously more difficult to write drivers for. However, none of that addresses the issue on the table that openGL is and has always been slightly faster than Dx and Carmack specializes in the fastest cutting edge engines.


Thu Dec 06, 2012 5:57 pm
Profile
3D Angel Eyes (Moderator)
User avatar

Joined: Sat Apr 12, 2008 8:18 pm
Posts: 10872
Even Carmack himself has said in interviews that DirectX is better today. The main reason he's stuck with it is because all their tools are built around OpenGL and it wouldn't be worth it to port all that stuff over.

I also question the assumptions Value has made on their L4D Linux port. Yes, it ran faster. But its running on a different graphics API, on a different operating-system, with different device drivers. And I'm sure they had to change a few things with the engine code to get it to compile. Its not an apples-to-apples comparison. Plus, as Fredz noted, its on one specific game. If they did the comparison on 10 different games with different engines, OK, fine. I just don't think it proves anything besides that Linux can be a competitive platform.

_________________
check my blog - cybereality.com


Thu Dec 06, 2012 6:02 pm
Profile
Sharp Eyed Eagle!

Joined: Sat Dec 22, 2007 3:38 am
Posts: 425
wuliheron wrote:
I never said there was anything inherently wrong with Direct3D [...] All I said is openGL is faster.
I'm not even sure I need to say anything here.
wuliheron wrote:
Palmer has stated many times he wants 120hz screen.
He's also stated he wants a higher resolution panel. And positional head-tracking. And etcetera. Doesn't mean those are actually available though.
wuliheron wrote:
Again, nobody, but nobody ever said anything different and you might as well be arguing with yourself.
Erm...
wuliheron wrote:
Valve and others beg to differ


Finally:
wuliheron wrote:
openGL is and has always been slightly faster than Dx
Do you have any basis for this claim? Until the release of OpenGL 4.x (and OpenGL ES 3.0), there was feature disparity between OGL and DirectX (e.g. compute shaders, standardised texture compression, etc), and a lot of self-admitted legacy cruft holding back OpenGL in some cases, as well as disparity between OpenGL and OpenGL ES making coding for one or the other a chore. D3D 11.1 hasn't added much beyond stereo3D support in the API, so there's time for OGL to catchup, but it can hardly be called 'always slightly faster'.


Thu Dec 06, 2012 6:32 pm
Profile
Cross Eyed!

Joined: Mon Aug 13, 2012 5:21 pm
Posts: 182
It isn't faster though. Even qualitatively Direct3D gives you tools that don't exist at all on OpenGL which allow you to do things like buffer your shader constants into a single API call and separate out draw calls across threads. How quickly DrawPrimitive() executes is not the whole picture, not by a long shot.

Sure, you can find specific cases where OpenGL is a little faster, but those are generally within the error margins, or in the case of source not really relevant at all. Who cares how fast TF2 runs? I wonder if you can still buy a PC that won't play it at 60fps.


Thu Dec 06, 2012 6:36 pm
Profile
One Eyed Hopeful

Joined: Fri Sep 21, 2012 5:35 am
Posts: 48
RE: needing to render at 120hz for rift ...

Isn't it the case that because an engine will have to render 2 views to create the stereoscopic image,
this will mean that the engine will have to effectively run at 120hz to output 60hz to the rift ?
or am I'm getting this all wrong.

Hewster


Fri Dec 07, 2012 3:03 am
Profile
Cross Eyed!
User avatar

Joined: Fri Aug 03, 2012 10:27 pm
Posts: 154
Hewster wrote:
RE: needing to render at 120hz for rift ...

Isn't it the case that because an engine will have to render 2 views to create the stereoscopic image,
this will mean that the engine will have to effectively run at 120hz to output 60hz to the rift ?
or am I'm getting this all wrong.

Hewster



Most 3D tvs need to be 120hz to produce a 60hz 3D image because it interleaves left eye frames with right eye frames. The rift shoots both left and right eye out at once side by side. So even a 60hz panel gives you 60hz per eye. The trade off is that the TV example gives you full screen resolution per eye where the Rift example gives you half screen resolution per eye.


Fri Dec 07, 2012 5:17 am
Profile
Cross Eyed!
User avatar

Joined: Fri Aug 03, 2012 10:27 pm
Posts: 154
If you have the doom3 bfg source code and 5x loupe lenses or similar in your rig read this post!

viewtopic.php?p=89765#p89765


Fri Dec 07, 2012 5:19 am
Profile
Sharp Eyed Eagle!

Joined: Sat Dec 22, 2007 3:38 am
Posts: 425
Hewster wrote:
RE: needing to render at 120hz for rift ...

Isn't it the case that because an engine will have to render 2 views to create the stereoscopic image,
this will mean that the engine will have to effectively run at 120hz to output 60hz to the rift ?
or am I'm getting this all wrong.

Hewster
If you're hacking 3D support into an existing engine, you are essentially rendering two seperate frames for every displayed stereo frames, so 60fps displayed requires 120fps rendered.
If you have access to nvidia's 3D solution, or build your engine with the intention of stereo 3D, then you can duplicate some of the work between left and right frames. When you look at benchmarks of mono vs stereo at the same resolution the performance is not perfectly halved, but still pretty close.


Fri Dec 07, 2012 9:35 am
Profile
Cross Eyed!
User avatar

Joined: Mon May 18, 2009 2:54 am
Posts: 160
EdZ wrote:
Finally:
wuliheron wrote:
openGL is and has always been slightly faster than Dx
Do you have any basis for this claim? Until the release of OpenGL 4.x (and OpenGL ES 3.0), there was feature disparity between OGL and DirectX (e.g. compute shaders, standardised texture compression, etc), and a lot of self-admitted legacy cruft holding back OpenGL in some cases, as well as disparity between OpenGL and OpenGL ES making coding for one or the other a chore. D3D 11.1 hasn't added much beyond stereo3D support in the API, so there's time for OGL to catchup, but it can hardly be called 'always slightly faster'.


http://en.wikipedia.org/wiki/Comparison ... Windows.29

It's not a secret and never has been. DirectX is Microsoft's more programmer friendly API, but it sacrifices flexibility. Which one is "better" then just depends on what your goals are. Considering openGL might be only 6% faster if that in some applications, is notoriously difficult to program drivers for, MS is a virtual monopoly, etc. it's no small wonder video game developers these days overwhelmingly prefer DirectX. However, openGL remains the more popular for just about everything else having the huge advantage is FREE and opensource.


Fri Dec 07, 2012 9:55 am
Profile
Cross Eyed!

Joined: Mon Aug 13, 2012 5:21 pm
Posts: 182
Actually OpenGL is much much easier to use than Direct3D if you just want to put some triangles on the screen. That is why its popular for non gaming applications where visual fidelity isn't a concern.

But when you want to do more sophisticated rendering OpenGL quickly becomes cumbersome because you have to work with all sorts of extensions and often vendor specific plugins to make anything work, often requiring lots of duplicated effort for different chipsets.

And exactly how is Direct3D not free?


Fri Dec 07, 2012 10:53 am
Profile
Cross Eyed!
User avatar

Joined: Mon May 18, 2009 2:54 am
Posts: 160
Owen wrote:
Actually OpenGL is much much easier to use than Direct3D if you just want to put some triangles on the screen. That is why its popular for non gaming applications where visual fidelity isn't a concern.

But when you want to do more sophisticated rendering OpenGL quickly becomes cumbersome because you have to work with all sorts of extensions and often vendor specific plugins to make anything work, often requiring lots of duplicated effort for different chipsets.

And exactly how is Direct3D not free?


It's proprietary which means it has all the pains in the butt that come with proprietary systems. Both might be free, but openGL not being proprietary means also that programmers can have more influence on how it is implemented.

Carmack has described himself as good at applied mathematics. Algebra, geometry, some trig, and basic calculus are things that often look obvious to him. He's not a math wiz so much as a math talent that just happens to suit the particular need for faster graphics engines capable of pushing more pixels. He has other talents, but that's why openGL is better suited to his work because his mind is already up to the challenge and it can provide at least modest increases in speed.


Sat Dec 08, 2012 9:29 pm
Profile
Cross Eyed!

Joined: Mon Aug 13, 2012 5:21 pm
Posts: 182
In practice thats just not true. OpenGL has always lagged behind, and has completely failed to adapt to change, with its core API virtually the same as it was 15 years ago despite massive shifts in technology because nobody is willing to make breaking changes. The only advantage to it being open is that its on other platforms. But for PC (and xbox) developers that doesn't matter.

DirectX on he other hand is constantly being developed in collaboration with chipset makers so that the latest advancements are made accessible to developers.


Sun Dec 09, 2012 12:04 pm
Profile
Binocular Vision CONFIRMED!
User avatar

Joined: Wed Oct 06, 2010 10:51 am
Posts: 304
Location: UK
Owen wrote:
DirectX on he other hand is constantly being developed in collaboration with chipset makers so that the latest advancements are made accessible to developers.

...you could argue that many of the rendering techniques we rely on today would never even have been implemented in hardware had they not been part of the OpenGL fallback / reference (T&L etc). Look at the depressing lack of innovation in recent years, we can't just blame the console refresh cycle. Just my 2p's/worth, I have a feeling this debate is going to run and run. ;)


Sun Dec 09, 2012 12:34 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 42 posts ]  Go to page 1, 2  Next

Who is online

Users browsing this forum: No registered users and 11 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by STSoftware.