Even now that the Cold War has finished there are any number of threats to people in every country that are dealt with by intelligence services all the time without people even realising it. And if these agencies cannot access information when it is required then they cannot do their jobs, and the chances of say, a terrorist bomb attack, goes up dramatically.
Have you ever personally seen a terrorist? Anyone here at Slashdot ever met a real live terrorist? I doubt it. There just aren't that many of them. "Anti-terrorism" is just the cover story, folks. Most governments in the world (including those of nations who claim to be free countries) are very much interested in destroying their citizens' privacy. If you know every little detail about millions of people, you have a very powerful (and profitable) weapon.
Without personal privacy, the government knows every tiny law you have ever broken, down to the time you parked your car in a fire lane. Do you look like you might be a terrorist? Do you have religious beliefs that don't fall in line with the norm? Do you live a certain lifestyle that the government may take issue with? If they ever feel like ruining your life for these reasons they can just pick you up, throw you in a truck, and read to you the list of laws you have broken.
"Anti-terrorism" is used to hide the profit, too! In a world increasingly dominated by corporate interests, it should come as no surprise to anyone that the government's secrecy and security agencies sell their data to corporations. What insurance company wouldn't pay billions for a list of people who they can raise rates for? What marketing firm wouldn't pay dearly for a detailed description of every citizen with a SS number, his likes, dislikes, beliefs, eating habits and route to work?
Don't be naive. The governments couldn't care less about "terrorists". In fact, the more real terrorists are allowed to do their thing, the more the governments can justify the massive invasions of privacy that are already happening.
Cut the guy a little slack. He probably just doesn't want to reboot his system to Windows and back just to watch some stupid Quicktime flick. If I got a million submissions a day, I wouldn't want to constantly be rebooting either.
Corporate progress should not be at the expense of ordinary citizens and/or small business. That's why the government steps in when "shady" stuff starts to happen.
I don't mind if it's an expensive legal battle, as long as a message is sent to these huge corporations: That they can't grow to the point where they threaten the public good.
Would anyone who uses this FS on their box please post a little bit about what's so good about it? The only thing I could tell from reading the posts in the kernel archive is that it's a journaling FS.
Realistically, this argument is silly. It doesn't matter if code "gets in the kernel". As long as it is available and can be patched into the kernel, then that's just fine!
You have to realize, that when you write parts of the kernel or kernel modules, you are part of a community. You need to be able to work with everyone because the end goal is the same: Making Linux a better system. When I started writing the Matrox Marvel video capture drivers for Linux, I just wanted something that I could use to grab screenshots from a web-cam. It's been a while since I released the code, and the development has really taken off, with other more capable and more talented people. Although I haven't done too much development on this project lately, I know that sometimes there are disagreements, and the best way to resolve them is to think about what is best for Linux as a whole. Although "getting your code into the kernel" may seem [neat/eleet/prestigious/etc] it may not be best for the overall system.
That's whats great about loadable modules. If your code is not ready for the kernel, you can still release it and people can compile it as a module. People can STILL use your code, while the community makes the decision about kernel inclusion.
Although I didn't have the patience to wade through that huge article, one thing Jon mentioned early in the artical was right on. The media's #1 priority is promoting itself.
Turn on your local news station one night and grab a stop-watch. It's funny, but also sad, to compare the length of time they spend talking about themselves with the length of time they spend on news. You will more than likely find that your local news station spends more seconds saying things like "LIVE! LATE BREAKING! CHANNEL 7 NEWS!!" than it spends talking about the story.
When I moved from Windows and started coding for Linux (and unix in general), what really impressed me was how easy it was to do I/O. You open a file, read/write, and close it. There's none of that IDirectSound2->QueryDeviceAndPrayToGod() crap. It's SIMPLE.
Need information from about the system? Just read a few files from/proc. You don't have to go find the undocumented hidden Win32 call that only works on Service Pack 3.
Linux has another advantage in that it ships with vi, emacs, the standard development toolchain, bash, perl, etc., which once you get used to, totally blows Visual C++ out of the water as far as ease of use and customizability goes.
If they are only comparing Quake speeds, you can hardly call it a comparison of OpenGL implementations. Quake and Quake-based games use a relatively TINY portion of the OpenGL API.
If run at high resolutions, the tests are basically testing the hardware's fill rate, and at lower resolutions, they are testing the drivers' geometry rates--definitely nowhere near a comprehensive "OpenGL benchmark".
Perhaps the headline, "Quake faster on BeOS" would be more appropriate...
...And as we all know, fromt the Windows world, "Rapid Application Development" == shovelware.
Call me elitist, but I believe if any fool can write a Linux application (quickly, no less), then we can probably expect the Linux world to be flooded with lots of applications seemingly written by fools.
Fire up a Windows box one day, go to www.download.com, and start downloading and trying out random shareware applications you find and you'll soon see what I mean.
I saw Paul Steed do a talk on modeling at a Quake-con a while back. He really knows his stuff... I can't wait to see who is lucky enough to get him next!
Let's not get all excited about going out and colonizing Mars now. Even if we could produce enough oxygen to breathe, it wouldn't do anyone any good. The minute you got out in the open the radiation that makes it through Mars's atmosphere would do a number on you.
Now, if NASA could put something together that would generate a thicker atmosphere for Mars...
class widget { void open(void); void close(void); };
This "you can't do OO in plain C" attitude is silly and immature. Anyone who has done any work on a large (>100,000 line) C project has probably run into OO methodologies employed within the program. Heck, you can do OO in assembly if you have a good design and structure your code properly.
On the other hand, I've seen plenty of C++ code that was far from object-oriented--inelegant, over-classed, and buggy C++ code. No matter what language you use, you can program it wisely or poorly, elegantly or hacked together.
What first got me into programming was a little program for the Commodore 64 called "Arcade Game Construction Kit" All it was, was this gui thing that let you create sprites and sounds background drawings and make a little top-down run-n-shoot game out of it (think "Rambo"). There was no programming involved, it was really fun and easy, and it got me thinking about things like system resources and what could and could not be done with that particular machine.
Well I enjoyed and used that program so much that after cranking out 3 pretty cool games, I began to outgrow it.
Next thing my dad knew, I turned 14 and for my birthday I asked for the C64 programmer's reference guide (basically a big thick book detailing the 6502 (?) assembly language) and the rest was history!
I didn't really even know about "high level languages" like C until I was around 16.
While I am all for the harshest of penalties against Microsoft (why isn't their a corporate death penalty? or corporate imprisonment?) I doubt anything the US government can do will have any significant impact on MS or the way they do business.
Microsoft will still bully, break or buy their competitors, because companies large and small fear them.
Microsoft will still embrace and extend "standards" because developers will tolerate anything to be on MS's good side.
Microsoft will still have tons of customers because customers prefer name-brand over quality.
The government's moves are nothing more than making a loud noise, and saying "We thing this company is doing wrong." If they had any guts and/or really cared about customers getting shafted they would utterly destroy the company to allow fresh competition come to the scene.
I find that most non-techies are quite annoyed with spam, but they sweep it under the rug since they don't know what else to do. I took about 10 minutes to show my friend how to look at the headers, find what is most likely the mail's original domain, and email abuse@, he now has something he can do about it.
Trust me, it feels good to get that message back from their ISP, informing you that they canceled the spammer's account.
I was just trying to be poetic. Geez, nerds. APIs can be faster or slower than others based on how effectivly it allows access to hardware and how effectivly it manages resources.
But neither D3D nor OpenGL specify access to hardware or resource management! These are both implementation details, and can be bad or good depending on who wrote the implementation.
In current implementations, however, the pipeline has been streamlined, the whole thing has been nearly rewritten, and provides much better access to hardware.
Exactly my point. As implementations improve, speed improves. A few years ago, no one had a particularly fast OpenGL implementation, but as more and more engineering hours have been put into them, now, most vendors have very fast implementations. But the API never changed!
I can easily (relativly) write an engine that uses every features in D3D. Now no matter what graphics card I'm using, my app will run, with D3D smoothing over hardware differences.
No game developer in their right mind would risk using a feature not implemented in hardware on most cards. Why would you want to fall back to Microsoft's HAL? It's SLOW.
In this case, OpenGL is almost the same as D3D. Instead of being implemented by the HAL, unsupported features of OpenGL are implemented by the vendor.
If I use the skinning support in DirectX 8.0, my game will automatically take advantage of both the GeForce 2 and the Radeon. In OpenGL, I would have to use both the NV skinning extension and the ATI skinning extension.
But what if the user is running on an S3 Virge? Heck, I guess he's out of luck! Time for the slow HAL to kick in! As a game developer, you should know whether or not your neat little trick is actually running in hardware!
In OpenGL, you have an abstract access to color, depth, etc buffers, vertex buffers, and hardware resources. In D3D, you have direct access to these.
This is entirely false. Both API's abstract access to vertex buffers, and provide direct access to frame buffers (depth, color). Do you really thing that when you fill a vertex buffer in D3D that you are using the vertex format that will eventually get sent to the card? Think again.
Hell, you even have direct access to what textures are uploaded to the card! None of this glPrioritizeTextures crap.
What about implementations that don't even load textures into a card's on-board memory? How will your LoadThisTextureToVideoMemory work on a card without local video memory free? You'll get an error and will have to load it into AGP anyway. Why not let the implementation take care of this minor detail.
Case in point, in D3D, you can render directly to a secondary hardware buffer, let's see OpenGL do that!
I can't stand developing for 3 different browsers on 4 different platforms, 12 screen resolutions, 3 color depths...
Then don't! Thats one thing many "web authors" still don't get... The WWW is a text-oriented medium. It's a page of text that has links to other pages of text. Everything else is just cruft.
HTML doesn't define how a web site should look to the pixel, and this is one of it's strong points. It's up to the user to decide how to view a site. If the user doesn't want images, your site should look just fine without them.
The minute you start checking to make sure your site looks the same on all browsers, you should re-think your entire site. Why do you want it to look the same on all browsers (it won't by the way...)? This usually indicates that you are focusing too much on presentation and not enough on content.
The web is broke. We're not using it properly
I agree with your second statement. The web isn't broke... people just aren't using it properly. There are so many corporate sites that look like brochures. It's sickening. My previous job was to set up a web page for a small business, and all they wanted me to do was scan each page of their brochure into GIF's, put them up on the web, and put "forward" and "backward" buttons on the bottom to navigate between pages. I said, WTF!?!? The concept of actually including text information and links to other resources was totally absurd to my boss.
These kinds of people think of the web only as a marketing tool, and thus can't take advantage of the power it has to offer.
ID software don't have a problem, whenever they are about to release a big-name title all the card vendors run around making sure there drivers are optimally configured for the feature set ID is using. If you're a smaller developer, things work differently, the vendors are not as concerned with you and basically you have to limit yourself to using the features that the big-boys have already used.
This is a very good point, one that no one has brought up before. I think it's more of a "chicken and egg" problem than you realize. Although many vendors' OpenGL drivers are highly optimized for Quake (compiled vertex arrays), id also goes to great lengths to code in a way that will be fast on all current hardware--something that a lot of smaller and/or inexperienced game programmers don't do (or don't know how to do).
Things like using the more generic GL_RGBA texel format, instead of the more obscure GL_LUMINANCE6_ALPHA2 and then complaining that it isn't supported as fast as GL_RGBA. Or, loading all the textures a level needs once at the beginning, rather than constantly loading and unloading them. Learn how to best use the API, and the small-time developer can take advantage of the fast parts of implementations that Quake's popularity has produced.
IF you claim that opengl is better, then please give some examples. All I know is that under Unreal tournment, directx is faster on my geforce 256.
Out of that whole message, this was the only thing I could even comprehend, so I'll address it. OpenGL is better for people who want a portable, robust API, that doesn't change every six months. It's not the only API out there, and it may not be the best for everyone.
And I repeat, there is nothing about an API that would make one faster or slower than another. An API is just a specification.
If a game is faster in D3D than in OpenGL on the same hardware, then this is almost always due to the fact that the game did not make better use of the OpenGL API, and has nothing to do with the illusion that one API is faster than another.
Slashdot Mirror
Even now that the Cold War has finished there are any number of threats to people in every country that are dealt with by intelligence services all the time without people even realising it. And if these agencies cannot access information when it is required then they cannot do their jobs, and the chances of say, a terrorist bomb attack, goes up dramatically.
Have you ever personally seen a terrorist? Anyone here at Slashdot ever met a real live terrorist? I doubt it. There just aren't that many of them. "Anti-terrorism" is just the cover story, folks. Most governments in the world (including those of nations who claim to be free countries) are very much interested in destroying their citizens' privacy. If you know every little detail about millions of people, you have a very powerful (and profitable) weapon.
Without personal privacy, the government knows every tiny law you have ever broken, down to the time you parked your car in a fire lane. Do you look like you might be a terrorist? Do you have religious beliefs that don't fall in line with the norm? Do you live a certain lifestyle that the government may take issue with? If they ever feel like ruining your life for these reasons they can just pick you up, throw you in a truck, and read to you the list of laws you have broken.
"Anti-terrorism" is used to hide the profit, too! In a world increasingly dominated by corporate interests, it should come as no surprise to anyone that the government's secrecy and security agencies sell their data to corporations. What insurance company wouldn't pay billions for a list of people who they can raise rates for? What marketing firm wouldn't pay dearly for a detailed description of every citizen with a SS number, his likes, dislikes, beliefs, eating habits and route to work?
Don't be naive. The governments couldn't care less about "terrorists". In fact, the more real terrorists are allowed to do their thing, the more the governments can justify the massive invasions of privacy that are already happening.
Cut the guy a little slack. He probably just doesn't want to reboot his system to Windows and back just to watch some stupid Quicktime flick. If I got a million submissions a day, I wouldn't want to constantly be rebooting either.
Corporate progress should not be at the expense of ordinary citizens and/or small business. That's why the government steps in when "shady" stuff starts to happen.
I don't mind if it's an expensive legal battle, as long as a message is sent to these huge corporations: That they can't grow to the point where they threaten the public good.
Would anyone who uses this FS on their box please post a little bit about what's so good about it? The only thing I could tell from reading the posts in the kernel archive is that it's a journaling FS.
Realistically, this argument is silly. It doesn't matter if code "gets in the kernel". As long as it is available and can be patched into the kernel, then that's just fine!
You have to realize, that when you write parts of the kernel or kernel modules, you are part of a community. You need to be able to work with everyone because the end goal is the same: Making Linux a better system. When I started writing the Matrox Marvel video capture drivers for Linux, I just wanted something that I could use to grab screenshots from a web-cam. It's been a while since I released the code, and the development has really taken off, with other more capable and more talented people. Although I haven't done too much development on this project lately, I know that sometimes there are disagreements, and the best way to resolve them is to think about what is best for Linux as a whole. Although "getting your code into the kernel" may seem [neat/eleet/prestigious/etc] it may not be best for the overall system.
That's whats great about loadable modules. If your code is not ready for the kernel, you can still release it and people can compile it as a module. People can STILL use your code, while the community makes the decision about kernel inclusion.
Although I didn't have the patience to wade through that huge article, one thing Jon mentioned early in the artical was right on. The media's #1 priority is promoting itself.
Turn on your local news station one night and grab a stop-watch. It's funny, but also sad, to compare the length of time they spend talking about themselves with the length of time they spend on news. You will more than likely find that your local news station spends more seconds saying things like "LIVE! LATE BREAKING! CHANNEL 7 NEWS!!" than it spends talking about the story.
When I moved from Windows and started coding for Linux (and unix in general), what really impressed me was how easy it was to do I/O. You open a file, read/write, and close it. There's none of that IDirectSound2->QueryDeviceAndPrayToGod() crap. It's SIMPLE.
/proc. You don't have to go find the undocumented hidden Win32 call that only works on Service Pack 3.
Need information from about the system? Just read a few files from
Linux has another advantage in that it ships with vi, emacs, the standard development toolchain, bash, perl, etc., which once you get used to, totally blows Visual C++ out of the water as far as ease of use and customizability goes.
Just a nit-pick:
If they are only comparing Quake speeds, you can hardly call it a comparison of OpenGL implementations. Quake and Quake-based games use a relatively TINY portion of the OpenGL API.
If run at high resolutions, the tests are basically testing the hardware's fill rate, and at lower resolutions, they are testing the drivers' geometry rates--definitely nowhere near a comprehensive "OpenGL benchmark".
Perhaps the headline, "Quake faster on BeOS" would be more appropriate...
Hard rock band Metallica and rapper Dr. Dre have trolled...
Hmm... I didn't see these guys post. They must have been moderated down fast...
...And as we all know, fromt the Windows world, "Rapid Application Development" == shovelware.
Call me elitist, but I believe if any fool can write a Linux application (quickly, no less), then we can probably expect the Linux world to be flooded with lots of applications seemingly written by fools.
Fire up a Windows box one day, go to www.download.com, and start downloading and trying out random shareware applications you find and you'll soon see what I mean.
I saw Paul Steed do a talk on modeling at a Quake-con a while back. He really knows his stuff... I can't wait to see who is lucky enough to get him next!
Let's not get all excited about going out and colonizing Mars now. Even if we could produce enough oxygen to breathe, it wouldn't do anyone any good. The minute you got out in the open the radiation that makes it through Mars's atmosphere would do a number on you.
Now, if NASA could put something together that would generate a thicker atmosphere for Mars...
Please describe what is functionally different between:
struct widget_s {
void(*open)(struct widget_s*);
void(*close)(struct widget_s*);
};
and:
class widget {
void open(void);
void close(void);
};
This "you can't do OO in plain C" attitude is silly and immature. Anyone who has done any work on a large (>100,000 line) C project has probably run into OO methodologies employed within the program. Heck, you can do OO in assembly if you have a good design and structure your code properly.
On the other hand, I've seen plenty of C++ code that was far from object-oriented--inelegant, over-classed, and buggy C++ code. No matter what language you use, you can program it wisely or poorly, elegantly or hacked together.
..preparing to begin on the road towards..
;-)
So, exactly what kind of time frame is that, Hemos?
What first got me into programming was a little program for the Commodore 64 called "Arcade Game Construction Kit" All it was, was this gui thing that let you create sprites and sounds background drawings and make a little top-down run-n-shoot game out of it (think "Rambo"). There was no programming involved, it was really fun and easy, and it got me thinking about things like system resources and what could and could not be done with that particular machine.
Well I enjoyed and used that program so much that after cranking out 3 pretty cool games, I began to outgrow it.
Next thing my dad knew, I turned 14 and for my birthday I asked for the C64 programmer's reference guide (basically a big thick book detailing the 6502 (?) assembly language) and the rest was history!
I didn't really even know about "high level languages" like C until I was around 16.
I can't see why anyone would need more than a few Xterms running vi, gdb, and the standard unix tools (grep, awk, sed, etc.)
I've not yet seen an IDE as scriptable as bash.
I've never seen an editor that lets you accomplish programming-related tasks than vi, although emacs is close and I admire many of its features.
I must admit, however, I am currently being swayed down the dark path of some of the nicer GUI debuggers out there...
It'll provide exactly one window manager, exactly one desktop, etc. It won't bother with any useful network tools...
There already exists an O/S dumbed down to the extent that you described. It's called "Windows" and is available in almost all computer stores.
Karma Whore, (n.), term used against those who post useful information, by those who dont.
While I am all for the harshest of penalties against Microsoft (why isn't their a corporate death penalty? or corporate imprisonment?) I doubt anything the US government can do will have any significant impact on MS or the way they do business.
Microsoft will still bully, break or buy their competitors, because companies large and small fear them.
Microsoft will still embrace and extend "standards" because developers will tolerate anything to be on MS's good side.
Microsoft will still have tons of customers because customers prefer name-brand over quality.
The government's moves are nothing more than making a loud noise, and saying "We thing this company is doing wrong." If they had any guts and/or really cared about customers getting shafted they would utterly destroy the company to allow fresh competition come to the scene.
Not really.
I find that most non-techies are quite annoyed with spam, but they sweep it under the rug since they don't know what else to do. I took about 10 minutes to show my friend how to look at the headers, find what is most likely the mail's original domain, and email abuse@, he now has something he can do about it.
Trust me, it feels good to get that message back from their ISP, informing you that they canceled the spammer's account.
Truly, having to cater to clueless clients is what makes all jobs difficult
I still reject the (for some people) dogmatic view that a site needs to look the same in all browsers.
I certainly agree with you, you have a simple site that looks the same in all browsers!
;-)
I was just trying to be poetic. Geez, nerds. APIs can be faster or slower than others based on how effectivly it allows access to hardware and how effectivly it manages resources.
But neither D3D nor OpenGL specify access to hardware or resource management! These are both implementation details, and can be bad or good depending on who wrote the implementation.
In current implementations, however, the pipeline has been streamlined, the whole thing has been nearly rewritten, and provides much better access to hardware.
Exactly my point. As implementations improve, speed improves. A few years ago, no one had a particularly fast OpenGL implementation, but as more and more engineering hours have been put into them, now, most vendors have very fast implementations. But the API never changed!
I can easily (relativly) write an engine that uses every features in D3D. Now no matter what graphics card I'm using, my app will run, with D3D smoothing over hardware differences.
No game developer in their right mind would risk using a feature not implemented in hardware on most cards. Why would you want to fall back to Microsoft's HAL? It's SLOW.
In this case, OpenGL is almost the same as D3D. Instead of being implemented by the HAL, unsupported features of OpenGL are implemented by the vendor.
If I use the skinning support in DirectX 8.0, my game will automatically take advantage of both the GeForce 2 and the Radeon. In OpenGL, I would have to use both the NV skinning extension and the ATI skinning extension.
But what if the user is running on an S3 Virge? Heck, I guess he's out of luck! Time for the slow HAL to kick in! As a game developer, you should know whether or not your neat little trick is actually running in hardware!
In OpenGL, you have an abstract access to color, depth, etc buffers, vertex buffers, and hardware resources. In D3D, you have direct access to these.
This is entirely false. Both API's abstract access to vertex buffers, and provide direct access to frame buffers (depth, color). Do you really thing that when you fill a vertex buffer in D3D that you are using the vertex format that will eventually get sent to the card? Think again.
Hell, you even have direct access to what textures are uploaded to the card! None of this glPrioritizeTextures crap.
What about implementations that don't even load textures into a card's on-board memory? How will your LoadThisTextureToVideoMemory work on a card without local video memory free? You'll get an error and will have to load it into AGP anyway. Why not let the implementation take care of this minor detail.
Case in point, in D3D, you can render directly to a secondary hardware buffer, let's see OpenGL do that!
Read up on auxilary buffers.
I can't stand developing for 3 different browsers on 4 different platforms, 12 screen resolutions, 3 color depths...
Then don't! Thats one thing many "web authors" still don't get... The WWW is a text-oriented medium. It's a page of text that has links to other pages of text. Everything else is just cruft.
HTML doesn't define how a web site should look to the pixel, and this is one of it's strong points. It's up to the user to decide how to view a site. If the user doesn't want images, your site should look just fine without them.
The minute you start checking to make sure your site looks the same on all browsers, you should re-think your entire site. Why do you want it to look the same on all browsers (it won't by the way...)? This usually indicates that you are focusing too much on presentation and not enough on content.
The web is broke. We're not using it properly
I agree with your second statement. The web isn't broke... people just aren't using it properly. There are so many corporate sites that look like brochures. It's sickening. My previous job was to set up a web page for a small business, and all they wanted me to do was scan each page of their brochure into GIF's, put them up on the web, and put "forward" and "backward" buttons on the bottom to navigate between pages. I said, WTF!?!? The concept of actually including text information and links to other resources was totally absurd to my boss.
These kinds of people think of the web only as a marketing tool, and thus can't take advantage of the power it has to offer.
ID software don't have a problem, whenever they are about to release a big-name title all the card vendors run around making sure there drivers are optimally configured for the feature set ID is using. If you're a smaller developer, things work differently, the vendors are not as concerned with you and basically you have to limit yourself to using the features that the big-boys have already used.
This is a very good point, one that no one has brought up before. I think it's more of a "chicken and egg" problem than you realize. Although many vendors' OpenGL drivers are highly optimized for Quake (compiled vertex arrays), id also goes to great lengths to code in a way that will be fast on all current hardware--something that a lot of smaller and/or inexperienced game programmers don't do (or don't know how to do).
Things like using the more generic GL_RGBA texel format, instead of the more obscure GL_LUMINANCE6_ALPHA2 and then complaining that it isn't supported as fast as GL_RGBA. Or, loading all the textures a level needs once at the beginning, rather than constantly loading and unloading them. Learn how to best use the API, and the small-time developer can take advantage of the fast parts of implementations that Quake's popularity has produced.
IF you claim that opengl is better, then please give some examples. All I know is that under Unreal tournment, directx is faster on my geforce 256.
Out of that whole message, this was the only thing I could even comprehend, so I'll address it. OpenGL is better for people who want a portable, robust API, that doesn't change every six months. It's not the only API out there, and it may not be the best for everyone.
And I repeat, there is nothing about an API that would make one faster or slower than another. An API is just a specification.
If a game is faster in D3D than in OpenGL on the same hardware, then this is almost always due to the fact that the game did not make better use of the OpenGL API, and has nothing to do with the illusion that one API is faster than another.