[dec1pher]

ok this will be a small drama from the eyes of the top-of-the-sector guy;

<hr>

[idsoftware.com]
Login name: johnc
In real life: John Carmack
Directory: /raid/nardo/johnc
Shell: /bin/csh
On since Dec 15 01:19:05 6 days 5 hours Idle Time
on ttyp2 from idnewt
On since Dec 17 01:05:12 4 days 23 hours Idle Time
on ttyp3 from idcarmack
Plan:

I am going to use this installment of my .plan file to get up on a
soapbox about an important issue to me: 3D API. I get asked for my
opinions about this often enough that it is time I just made a public
statement. So here it is, my current position as of december '96...

While the rest of Id works on Quake 2, most of my effort is now
focused on developing the next generation of game technology. This
new generation of technology will be used by Id and other companies
all the way through the year 2000, so there are some very important
long term decisions to be made.

There are two viable contenders for low level 3D programming on win32:
Direct-3D Immediate Mode, the new, designed for games API, and OpenGL,
the workstation graphics API originally developed by SGI. They are
both supported by microsoft, but D3D has been evangelized as the one
true solution for games.

I have been using OpenGL for about six months now, and I have been
very impressed by the design of the API, and especially it's ease of
use. A month ago, I ported quake to OpenGL. It was an extremely
pleasant experience. It didn't take long, the code was clean and
simple, and it gave me a great testbed to rapidly try out new research
ideas.

I started porting glquake to Direct-3D IM with the intent of learning
the api and doing a fair comparison.

Well, I have learned enough about it. I'm not going to finish the
port. I have better things to do with my time.

I am hoping that the vendors shipping second generation cards in the
coming year can be convinced to support OpenGL. If this doesn't
happen early on and there are capable cards that glquake does not run
on, then I apologize, but I am taking a little stand in my little
corner of the world with the hope of having some small influence on
things that are going to effect us for many years to come.

Direct-3D IM is a horribly broken API. It inflicts great pain and
suffering on the programmers using it, without returning any
significant advantages. I don't think there is ANY market segment
that D3D is appropriate for, OpenGL seems to work just fine for
everything from quake to softimage. There is no good technical reason
for the existence of D3D.

I'm sure D3D will suck less with each forthcoming version, but this is
an opportunity to just bypass dragging the entire development community
through the messy evolution of an ill-birthed API.

Best case: Microsoft integrates OpenGL with direct-x (probably calling
it Direct-GL or something), ports D3D retained mode on top of GL, and
tells everyone to forget they every heard of D3D immediate mode.
Programmers have one good api, vendors have one driver to write, and
the world is a better place.


To elaborate a bit:

"OpenGL" is either OpenGL 1.1 or OpenGL 1.0 with the common
extensions. Raw OpenGL 1.0 has several holes in functionality.

"D3D" is Direct-3D Immediate Mode. D3D retained mode is a separate
issue. Retained mode has very valid reasons for existence. It is a
good thing to have an api that lets you just load in model files and
fly around without sweating the polygon details. Retained mode is
going to be used by at least ten times as many programmers as
immediate mode. On the other hand, the world class applications that
really step to new levels are going to be done in an immediate mode
graphics API. D3D-RM doesn't even really have to be tied to D3D-IM.
It could be implemented to emit OpenGL code instead.

I don't particularly care about the software only implementations of
either D3D or OpenGL. I haven't done serious research here, but I
think D3D has a real edge, because it was originally designed for
software rendering and much optimization effort has been focused
there. COSMO GL is attempting to compete there, but I feel the effort
is misguided. Software rasterizers will still exist to support the
lowest common denominator, but soon all game development will be
targeted at hardware rasterization, so that's where effort should be
focused.

The primary importance of a 3D API to game developers is as an
interface to the wide variety of 3D hardware that is emerging. If
there was one compatible line of hardware that did what we wanted and
covered 90+ percent of the target market, I wouldn't even want a 3D
API for production use, I would be writing straight to the metal, just
like I always have with pure software schemes. I would still want a
3D API for research and tool development, but it wouldn't matter if it
wasn't a mainstream solution.

Because I am expecting the 3D accelerator market to be fairly
fragmented for the foreseeable future, I need an API to write to, with
individual drivers for each brand of hardware. OpenGL has been
maturing in the workstation market for many years now, always with a
hardware focus. We have existing proof that it scales just great
from a $300 permedia card all the way to a $250,000 loaded infinite
reality system.

All of the game oriented PC 3D hardware basically came into existence
in the last year. Because of the frantic nature of the PC world, we
may be getting stuck with a first guess API and driver model which
isn't all that good.

The things that matter with an API are: functionality, performance,
driver coverage, and ease of use.

Both APIs cover the important functionality. There shouldn't be any
real argument about that. GL supports some additional esoteric
features that I am unlikely to use (or are unlikely to be supported by
hardware -- same effect). D3D actually has a couple nice features
that I would like to see moved to GL (specular blend at each vertex,
color key transparency, and no clipping hints), which brings up the
extensions issue. GL can be extended by the driver, but because D3D
imposes a layer between the driver and the API, microsoft is the only
one that can extend D3D.

My conclusion about performance is that there is not going to be any
significant performance difference (< 10%) between properly written
OpenGL and D3D drivers for several years at least. There are some
arguments that gl will scale better to very high end hardware because
it doesn't need to build any intermediate structures, but you could
use tiny sub cache sized execute buffers in d3d and achieve reasonably
similar results (or build complex hardware just to suit D3D -- ack!).
There are also arguments from the other side that the vertex pools in
d3d will save work on geometry bound applications, but you can do the
same thing with vertex arrays in GL.

Currently, there are more drivers available for D3D than OpenGL on the
consumer level boards. I hope we can change this. A serious problem
is that there are no D3D conformance tests, and the documentation is
very poor, so the existing drivers aren't exactly uniform in their
functionality. OpenGL has an established set of conformance tests, so
there is no argument about exactly how things are supposed to work.
OpenGL offers two levels of drivers that can be written: mini client
drivers and installable client drivers. A MCD is a simple, robust
exporting of hardware rasterization capabilities. An ICD is basically
a full replacement for the API that lets hardware accelerate or extend
any piece of GL without any overhead.

The overriding reason why GL is so much better than D3D has to do with
ease of use. GL is easy to use and fun to experiment with. D3D is
not (ahem). You can make sample GL programs with a single page of
code. I think D3D has managed to make the worst possible interface
choice at every opportunity. COM. Expandable structs passed to
functions. Execute buffers. Some of these choices were made so that
the API would be able to gracefully expand in the future, but who
cares about having an API that can grow if you have forced it to be
painful to use now and forever after? Many things that are a single
line of GL code require half a page of D3D code to allocate a
structure, set a size, fill something in, call a COM routine, then
extract the result.

Ease of use is damn important. If you can program something in half
the time, you can ship earlier or explore more approaches. A clean,
readable coding interface also makes it easier to find / prevent bugs.

GL's interface is procedural: You perform operations by calling gl
functions to pass vertex data and specify primitives.

glBegin (GL_TRIANGLES);
glVertex (0,0,0);
glVertex (1,1,0);
glVertex (2,0,0);
glEnd ();

D3D's interface is by execute buffers: You build a structure
containing vertex data and commands, and pass the entire thing with a
single call. On the surface, this appears to be an efficiency
improvement for D3D, because it gets rid of a lot of procedure call
overhead. In reality, it is a gigantic pain-in-the-ass.

(pseudo code, and incomplete)
v = &buffer.vertexes;[0];
v->x = 0; v->y = 0; v->z = 0; v++;
v->x = 1; v->y = 1; v->z = 0; v++;
v->x = 2; v->y = 0; v->z = 0;
c = &buffer.commands;
c->operation = DRAW_TRIANGLE;
c->vertexes[0] = 0;
c->vertexes[1] = 1;
c->vertexes[2] = 2;
IssueExecuteBuffer (buffer);

If I included the complete code to actually lock, build, and issue an
execute buffer here, you would think I was choosing some
pathologically slanted case to make D3D look bad.

You wouldn't actually make an execute buffer with a single triangle in
it, or your performance would be dreadful. The idea is to build up a
large batch of commands so that you pass lots of work to D3D with a
single procedure call.

A problem with that is that the optimal definition of "large" and
"lots" varies depending on what hardware you are using, but instead of
leaving that up to the driver, the application programmer has to know
what is best for every hardware situation.

You can cover some of the messy work with macros, but that brings its
own set of problems. The only way I can see to make D3D generally
usable is to create your own procedural interface that buffers
commands up into one or more execute buffers and flushes when needed.
But why bother, when there is this other nifty procedural API already
there...

With OpenGL, you can get something working with simple,
straightforward code, then if it is warranted, you can convert to
display lists or vertex arrays for max performance (although the
difference usually isn't that large). This is the right way of doing
things -- like converting your crucial functions to assembly language
after doing all your development in C.

With D3D, you have to do everything the painful way from the
beginning. Like writing a complete program in assembly language,
taking many times longer, missing chances for algorithmic
improvements, etc. And then finding out it doesn't even go faster.

I am going to be programming with a 3D API every day for many years to
come. I want something that helps me, rather than gets in my way.

John Carmack
Id Software

also downloadable multi-platform plain text version included

Attached File(s)

•  jcarmack_oglvsdx.txt (11.05K)
  Number of downloads: 407

[Nova Dragoon]

I think this sums up the article pretty well

Quote

I think D3D has managed to make the worst possible interface
choice at every opportunity. COM

And its true


OH so true

[dec1pher]

directx really sucks really but when you turn your head and look back huge games were always done with directx but why? what is the reason for it. the reason is simple... directx is the worst interface for a programmer but on windows we must accept that it is more fullfilled than opengl via math classes, model loading classes, texture classes... but i think it kills the hardwork and that small smile after a good work. hey Bill Gates will be in Istanbul @ Sunday. And we can ask questions via mailing to NTV and i'll ask about Vista's opengl removal... This is not acceptable. There are too many guys programming games via opengl like me... So here's a small in-brain of Microsoft. Their API is worst than OpenGL and they know they can't do better than GL so they plan to disable GL and lead the game development on Windows platform. As i said that sucks. Because of these evil plans i hate Microsoft...

This post has been edited by dec1pher: 27 January 2006 - 03:23 PM

[eLliDKraM]

i love microsoft

[Nova Dragoon]

dec1pher, on 27 Jan, 2006 - 05:16 PM, said:

i'll ask about Vista's opengl removal... This is not acceptable. There are too many guys programming games via opengl like me... So here's a small in-brain of Microsoft. Their API is worst than OpenGL and they know they can't do better than GL so they plan to disable GL and lead the game development on Windows platform.

IIRC, they weren't removing opengl support, it was they wouldnt be providing it. I think all GL stuff currently is handed by the device driver writers, not anything from MS

[WolfCoder]

I agree that all the DirectX stuff will turn my grey matter into an odd pudding but I need power, and I can't get the power I need with OpenGL. I don't really know where all you guys come from but OpenGL is used for simplicity and DirectX is used for power.

...

I have spoken.

[BlueVD]

What can I say about it... DX & D3D suck. If you want conclusive tests, I'll post my small tester engine.
I took the liberty of implementing the same code (that simply creates a sphere with low poly count (and it spins it while moving it random on a XYZ axis) and after that it simply multiplies the polygons until the whole fps drops under 5 (if you have a really fast pc, you can press the ESC key, cause the test will probably last an eternity).
On my old pc (duron 1,1 GHz, 128 SDRAM, Video 8 MB Ram) opengl was able to render 1.4 times more polys than DX before droping under 5 fps.
Bottom line: OpenGL is better, faster and easyer to code.

[WolfCoder]

BlueVD, on 11 Feb, 2006 - 04:30 AM, said:

What can I say about it... DX & D3D suck. If you want conclusive tests, I'll post my small tester engine.
I took the liberty of implementing the same code (that simply creates a sphere with low poly count (and it spins it while moving it random on a XYZ axis) and after that it simply multiplies the polygons until the whole fps drops under 5 (if you have a really fast pc, you can press the ESC key, cause the test will probably last an eternity).
On my old pc (duron 1,1 GHz, 128 SDRAM, Video 8 MB Ram) opengl was able to render 1.4 times more polys than DX before droping under 5 fps.
Bottom line: OpenGL is better, faster and easyer to code. 

There's something wrong with your machine and code because it's the reverse on my PC. OpenGL has much lower power than DirectX on my machine. I have a weak video card and DirectX somehow makes it do some cool stuff. OpenGL runs like crap with the same kind of program.

It's probably an optimization issue or PC issue as optimization surely must work differently for OpenGL than it does for DirectX.

You are correct that it's hard to code for DirectX but it's worth the pure power.

(The epic battle between DirectX and OpenGL is eternal, but it's what YOU like to code in that counts. It doesn't matter if DirectX is better or OpenGL is better, it counts if YOU'RE confortable coding in it. Somehow, i'm comfortable coding in DirectX. Use what YOU feel like, as long as it runs at all, that's all that matters).

This post has been edited by WolfCoder: 11 February 2006 - 09:28 PM

[knownasilya]

Well said!

[dec1pher]

no one can compare DX w/ GL because they're different things! GL is a graphics library but DX is a complete game (or whatever else) development library in this case we are comparing GL w/ D3D and i must say that D3D's performance is better than GL on Windows. I'm not a M$ lover i even hate it. But there lies the truth we can't just act like it's not true. and GL is slower because it's using shit m$'s bindings. So this way GL is as fast as D3D (or @ nears) so this means GL is more powerful than D3D but why? Because in spite of M$'s shit implementings it can still catch (sometimes) D3D on Windows...

[BlueVD]

Strangely enough, I finally found some real info's on this subject from the real specialists.
I have a freind (he's a specialist in chips and proccessors design) that managed to explain me the main difference between OpenGL and DX:
"The graphical proccessors on the video cards are built differently. In a perfect world, if 2 different proccessors would have the same frequency (and some other specifications) then they would get the same level of quality. In real life this doesn't happen. Look at ATI and NVidia. So here's why on some cards DX is better and on other OpenGL: each manufacturer can program the chips on video card to provide hardware compatibility with certain types of software: see tha case of the new <<all in wonder>> graphics cadrs that are proud to say they are DX 9 compatible. You've seen an Apple pc. At graphica it renders most IMB compatibles useless. That's because everything in that pc is made fro graphics. Also, remember the 3DFX? THey had their own technology. So they worked great with 3Dfx built games, but on other types of 3d engines it was a bit messy. It all depends on the manufacturer (and sometimes on the contracts with MS). That's why my Video Card behaves in DX better while yours works better with OpenGL."

Eh, I guess that this time I was wrong. But I'm still going to code my games and 3D apps on OpenGL

[supersloth]

how long ago was that article written? john carmack recently moved id to the xbox 360 as the primary development platform (even before pc), and it uses a very similiar if not identical development environment as directx.

[1lacca]

Quote

my current position as of december '96...

This article was written a long time ago, so I am not sure, if it is relevant nowadays - was there only voodoo, or tnt2, too? Some arguments, like vertex arrays vs. looped declaration just doesn't make any sense today, as the number of vertices clearly demands the array approach that is supported by OGL, too - OGL ES(the embedded version) actually does not even support glBegin and glEnd.

Quote

john carmack recently moved id to the xbox 360 as the primary development platform (even before pc), and it uses a very similiar if not identical development environment as directx.

Are you sure about this? As of January 31th I've only read that the gameplay development was moved to XBOX, but all the other tools and things are safe on the PC - but headlines liked to quote his lines really out of context. Also, Carmack seemed to be pretty proud of his engine being cross-platform all the time - supporting Linux - and I am not sure if he would really move to D3D - I wonder if his plan file refreshes more often than his blog. However it is also true, that porting a working engine between D3D and OGL is not that difficult, so it could be true as well, but it would clearly denote the end of an era - and although I don't know anythign about the XBOX devkit, I think if Carmack asks for OGL support, he gets it (especially that the hardware is quite similar to PCs), like the way he got nVidia to produce chips that can render textures without Z value, a feature used almost exclusively by the doom3 engine.

[supersloth]

http://www.joystiq.c...imary-platform/ that's all i got

[1lacca]

Its getting interesting, so I've googled for this a bit, and this is the biggest snippet I could find out of this "interview" before I got bored:

Quote

"The Xbox 360 will probably will be id's primary development platform. As it is right now, we would get the game up on the 360. When I would do major hack-and-slash architectural changes it was back on the PC, but it’s looking like the Xbox 360 will be our target. All of our tools are on the PC, and we’re maintaining the game running on the PC, but probably all of our gameplay development and testing will be done on the Xbox 360. It’s a really sweet development system."

Reading this at first is a bit confusing. However what I think here is the case, is that at teh beginning he is talking about the different consoles, and not XBOX360 vs PC - so Xbox would be the primary development platform amongst consoles. And I think it is backed up by his speech at Quakecon where he praised the xbox dev kit against the other consoles' and that he thinks consoles might be faster in the short term only, and PCs outpace them long before their next generation would appear.

Hell, editors should stop quoting things totally out of context...