I know both DirectX and openGL, and I like them both, a lot, for
different reasons.

I wish an absolute expert in each would write the same test app in
both APIs, as a spinning piece of heavy geometry, textured, with a
framerate printout.  Only because I would like to see my own findings
confirmed or denied:

1) If you draw a heavy model, a triangle at a time, (no strips, no
vertex arrays, no display lists, or data acceleration techniques), 
openGL is (noticably) faster.

2) If you use DirectX's own Mesh primitive with the OptimizeMesh
function, compared to all the tricks of the trade openGL suggests
(using triangle strips, vertex arrrays, with indexed vertices, etc),
DirectX is (noticably) faster. I even tried the same optimized data
layout in DirectX and it was slower than its own Optimize Mesh
version. Even though I did everything the performance improvment
papers suggested.

  I'm tempted to write my version of the two, post the source, and let
the gurus from each side optimize the test code, post the revised
source, and prove me right or wrong. (By letting me re-compile the
test on my own machine and seeing the results myself)

Unless someone already has such a thing written? 

I've read people's opinion's experiences about one or the other, but
when someone says "openGL is slower", it makes me think they don't
have the right driver installed, or their message posting date is so
old that their gfx card is one I'm not interested in.  (I'm interested
in any GeForce4 / ATI card).

> 2) If you use DirectX's own Mesh primitive with the OptimizeMesh
> function, compared to all the tricks of the trade openGL suggests
> (using triangle strips, vertex arrrays, with indexed vertices, etc),
> DirectX is (noticably) faster. I even tried the same optimized data
> layout in DirectX and it was slower than its own Optimize Mesh
> version. Even though I did everything the performance improvment
> papers suggested.

Try using a Display List in OpenGL.  In any case they are basically the same
in the end given a DX driver and OGL driver from the IHV being at equal
levels of optimization.

    WTH

Display Lists are the only thing I didn't try, I did all the other
data layout optimization stuff. But *if* I remember correctly, from
reading one of the nVidia papers (or newsgroups), display lists
weren't going to be faster than the other optimization methods I
tried.

The more I think about it, the more I like the idea of having a piece
of source that everyone can look at and say "you did this wrong", or
"try this".

Your conclusion is what I'd like to reach: Their speeds are the same.
But my implementations so far haven't shown that.   I'd like to be
able to choose between the two APIs based on reasons other than speed.


"WTH" <ih8spam@spamtrap.com> wrote in message news:<vk7grkqjpk8pbc@corp.supernews.com>...
> > 2) If you use DirectX's own Mesh primitive with the OptimizeMesh
> > function, compared to all the tricks of the trade openGL suggests
> > (using triangle strips, vertex arrrays, with indexed vertices, etc),
> > DirectX is (noticably) faster. I even tried the same optimized data
> > layout in DirectX and it was slower than its own Optimize Mesh
> > version. Even though I did everything the performance improvment
> > papers suggested.
> 
> Try using a Display List in OpenGL.  In any case they are basically the same
> in the end given a DX driver and OGL driver from the IHV being at equal
> levels of optimization.
> 
>     WTH

"happyhappy" <gtarzz@yahoo.com> wrote in message
news:a8500eb1.0308201307.2606256c@posting.google.com...
> Display Lists are the only thing I didn't try, I did all the other
> data layout optimization stuff. But *if* I remember correctly, from
> reading one of the nVidia papers (or newsgroups), display lists
> weren't going to be faster than the other optimization methods I
> tried.
>
> The more I think about it, the more I like the idea of having a piece
> of source that everyone can look at and say "you did this wrong", or
> "try this".
>
> Your conclusion is what I'd like to reach: Their speeds are the same.
> But my implementations so far haven't shown that.   I'd like to be
> able to choose between the two APIs based on reasons other than speed.

there really isnt a reason that one API should be faster than another, given
they are both triangle pushers.  its probably something in your code that is
resulting in any speed differences.

in terms of reasons for selecting - how about cleanness of the API with D3D?
as compared to having numerous vendor specific hacks, I mean extensions,
littering your code?

the only rational reason I can see for chosing the mess of extensions that
OGL is today is for cross-OS portability. but even there if the exact same
set of extensions isnt available then you are stuck with coding multiple
paths anyways.

>
>
> "WTH" <ih8spam@spamtrap.com> wrote in message
news:<vk7grkqjpk8pbc@corp.supernews.com>...
> > > 2) If you use DirectX's own Mesh primitive with the OptimizeMesh
> > > function, compared to all the tricks of the trade openGL suggests
> > > (using triangle strips, vertex arrrays, with indexed vertices, etc),
> > > DirectX is (noticably) faster. I even tried the same optimized data
> > > layout in DirectX and it was slower than its own Optimize Mesh
> > > version. Even though I did everything the performance improvment
> > > papers suggested.
> >
> > Try using a Display List in OpenGL.  In any case they are basically the
same
> > in the end given a DX driver and OGL driver from the IHV being at equal
> > levels of optimization.
> >
> >     WTH

one thing thats likely not available in OGL, at least not as simply, is the
vertex-cache aware optimizer used by the OptimizeMesh sample.

this optimizer is aware of specific details on various IHV cards, and is
thus better than all but the most connected developers could write.

again, each vendor might have an extension or separate pre-process program
to do this, but not via 1 call during execution of your program.

D3DX is a nice collection of bits.

"Philip Taylor [ATI]" <ptaylor@online.newsgroup-poster.ati.com> wrote in
message news:eP$vdG2ZDHA.2648@TK2MSFTNGP09.phx.gbl...
>
> "happyhappy" <gtarzz@yahoo.com> wrote in message
> news:a8500eb1.0308201307.2606256c@posting.google.com...
> > Display Lists are the only thing I didn't try, I did all the other
> > data layout optimization stuff. But *if* I remember correctly, from
> > reading one of the nVidia papers (or newsgroups), display lists
> > weren't going to be faster than the other optimization methods I
> > tried.
> >
> > The more I think about it, the more I like the idea of having a piece
> > of source that everyone can look at and say "you did this wrong", or
> > "try this".
> >
> > Your conclusion is what I'd like to reach: Their speeds are the same.
> > But my implementations so far haven't shown that.   I'd like to be
> > able to choose between the two APIs based on reasons other than speed.
>
> there really isnt a reason that one API should be faster than another,
given
> they are both triangle pushers.  its probably something in your code that
is
> resulting in any speed differences.
>
> in terms of reasons for selecting - how about cleanness of the API with
D3D?
> as compared to having numerous vendor specific hacks, I mean extensions,
> littering your code?
>
> the only rational reason I can see for chosing the mess of extensions that
> OGL is today is for cross-OS portability. but even there if the exact same
> set of extensions isnt available then you are stuck with coding multiple
> paths anyways.
>
> >
> >
> > "WTH" <ih8spam@spamtrap.com> wrote in message
> news:<vk7grkqjpk8pbc@corp.supernews.com>...
> > > > 2) If you use DirectX's own Mesh primitive with the OptimizeMesh
> > > > function, compared to all the tricks of the trade openGL suggests
> > > > (using triangle strips, vertex arrrays, with indexed vertices, etc),
> > > > DirectX is (noticably) faster. I even tried the same optimized data
> > > > layout in DirectX and it was slower than its own Optimize Mesh
> > > > version. Even though I did everything the performance improvment
> > > > papers suggested.
> > >
> > > Try using a Display List in OpenGL.  In any case they are basically
the
> same
> > > in the end given a DX driver and OGL driver from the IHV being at
equal
> > > levels of optimization.
> > >
> > >     WTH
>
>

Now Phil, I love D3D and I love OGL, so I've got to interject some here.

How is 'coding for different paths' only applicable to OpenGL?  I mean, D3D
has caps that you need to check and it isn't simply a case of "Well, I won't
use that feature", you have the same issue.

The only real difference is unless an extension becomes an ARB extension
your code may have a little bit more on the path side than if you took D3D.

    WTH

"Philip Taylor [ATI]" <ptaylor@online.newsgroup-poster.ati.com> wrote in
message news:eP$vdG2ZDHA.2648@TK2MSFTNGP09.phx.gbl...
>
> "happyhappy" <gtarzz@yahoo.com> wrote in message
> news:a8500eb1.0308201307.2606256c@posting.google.com...
> > Display Lists are the only thing I didn't try, I did all the other
> > data layout optimization stuff. But *if* I remember correctly, from
> > reading one of the nVidia papers (or newsgroups), display lists
> > weren't going to be faster than the other optimization methods I
> > tried.
> >
> > The more I think about it, the more I like the idea of having a piece
> > of source that everyone can look at and say "you did this wrong", or
> > "try this".
> >
> > Your conclusion is what I'd like to reach: Their speeds are the same.
> > But my implementations so far haven't shown that.   I'd like to be
> > able to choose between the two APIs based on reasons other than speed.
>
> there really isnt a reason that one API should be faster than another,
given
> they are both triangle pushers.  its probably something in your code that
is
> resulting in any speed differences.
>
> in terms of reasons for selecting - how about cleanness of the API with
D3D?
> as compared to having numerous vendor specific hacks, I mean extensions,
> littering your code?
>
> the only rational reason I can see for chosing the mess of extensions that
> OGL is today is for cross-OS portability. but even there if the exact same
> set of extensions isnt available then you are stuck with coding multiple
> paths anyways.
>
> >
> >
> > "WTH" <ih8spam@spamtrap.com> wrote in message
> news:<vk7grkqjpk8pbc@corp.supernews.com>...
> > > > 2) If you use DirectX's own Mesh primitive with the OptimizeMesh
> > > > function, compared to all the tricks of the trade openGL suggests
> > > > (using triangle strips, vertex arrrays, with indexed vertices, etc),
> > > > DirectX is (noticably) faster. I even tried the same optimized data
> > > > layout in DirectX and it was slower than its own Optimize Mesh
> > > > version. Even though I did everything the performance improvment
> > > > papers suggested.
> > >
> > > Try using a Display List in OpenGL.  In any case they are basically
the
> same
> > > in the end given a DX driver and OGL driver from the IHV being at
equal
> > > levels of optimization.
> > >
> > >     WTH
>
>

using extensions is a lot more involved than using caps bits.

selecting what features to use in D3D FFP multi-texture is a lot easier than
using the various vendor extensions for MT. one is branching off
ValidateDevice within a single code path. the other is completely separate
code paths. and we havent even got to how complicated shaders are today in
OGL...

and how many apps have blown up because of caps bits being added? Quake blew
up because the extension strings got larger than 1k.

regardless, the point was in the case of thinking using OGL will give you
more portability - even there thats somewhat tainted if the exact same set
of extensions isnt supported on that other OS, whatever it might be. of
course, you code code vanilla OGL and avoid that, but vanilla OGL is
definitely less filling. :-).

"WTH" <ih8spam@spamtrap.com> wrote in message
news:vk7vishn3hllf9@corp.supernews.com...
> Now Phil, I love D3D and I love OGL, so I've got to interject some here.
>
> How is 'coding for different paths' only applicable to OpenGL?  I mean,
D3D
> has caps that you need to check and it isn't simply a case of "Well, I
won't
> use that feature", you have the same issue.
>
> The only real difference is unless an extension becomes an ARB extension
> your code may have a little bit more on the path side than if you took
D3D.
>
>     WTH
>
> "Philip Taylor [ATI]" <ptaylor@online.newsgroup-poster.ati.com> wrote in
> message news:eP$vdG2ZDHA.2648@TK2MSFTNGP09.phx.gbl...
> >
> > "happyhappy" <gtarzz@yahoo.com> wrote in message
> > news:a8500eb1.0308201307.2606256c@posting.google.com...
> > > Display Lists are the only thing I didn't try, I did all the other
> > > data layout optimization stuff. But *if* I remember correctly, from
> > > reading one of the nVidia papers (or newsgroups), display lists
> > > weren't going to be faster than the other optimization methods I
> > > tried.
> > >
> > > The more I think about it, the more I like the idea of having a piece
> > > of source that everyone can look at and say "you did this wrong", or
> > > "try this".
> > >
> > > Your conclusion is what I'd like to reach: Their speeds are the same.
> > > But my implementations so far haven't shown that.   I'd like to be
> > > able to choose between the two APIs based on reasons other than speed.
> >
> > there really isnt a reason that one API should be faster than another,
> given
> > they are both triangle pushers.  its probably something in your code
that
> is
> > resulting in any speed differences.
> >
> > in terms of reasons for selecting - how about cleanness of the API with
> D3D?
> > as compared to having numerous vendor specific hacks, I mean extensions,
> > littering your code?
> >
> > the only rational reason I can see for chosing the mess of extensions
that
> > OGL is today is for cross-OS portability. but even there if the exact
same
> > set of extensions isnt available then you are stuck with coding multiple
> > paths anyways.
> >
> > >
> > >
> > > "WTH" <ih8spam@spamtrap.com> wrote in message
> > news:<vk7grkqjpk8pbc@corp.supernews.com>...
> > > > > 2) If you use DirectX's own Mesh primitive with the OptimizeMesh
> > > > > function, compared to all the tricks of the trade openGL suggests
> > > > > (using triangle strips, vertex arrrays, with indexed vertices,
etc),
> > > > > DirectX is (noticably) faster. I even tried the same optimized
data
> > > > > layout in DirectX and it was slower than its own Optimize Mesh
> > > > > version. Even though I did everything the performance improvment
> > > > > papers suggested.
> > > >
> > > > Try using a Display List in OpenGL.  In any case they are basically
> the
> > same
> > > > in the end given a DX driver and OGL driver from the IHV being at
> equal
> > > > levels of optimization.
> > > >
> > > >     WTH
> >
> >
>
>

> the only rational reason I can see for chosing the mess of extensions that
> OGL is today is for cross-OS portability. but even there if the exact same
> set of extensions isnt available then you are stuck with coding multiple
> paths anyways.

OpenGL also allows exposing more chip explicit functionality than 
Direct3D does. For example, the register combiners of a GeForce2 are a 
superset of what Direct3D texture stages allow, and their description 
is very clear, compared to the trial and error method of getting 
texture stages to work. So if you want to get the most out of the 
hardware, OpenGL may at times be a better choice.

	Eyal

> 1) If you draw a heavy model, a triangle at a time, (no strips, no
> vertex arrays, no display lists, or data acceleration techniques), 
> openGL is (noticably) faster.

OpenGL's triangle at a time method should be equivalent to filling a 
dynamic vertex buffer with data in Direct3D and then rendering it with 
one call. Although it would have a higher overhead of calls. It's 
definitely not the equivalent of rendering single triangles in Direct3D.

 > 2) If you use DirectX's own Mesh primitive with the OptimizeMesh
 > function, compared to all the tricks of the trade openGL suggests
 > (using triangle strips, vertex arrrays, with indexed vertices, etc),
 > DirectX is (noticably) faster. I even tried the same optimized data
 > layout in DirectX and it was slower than its own Optimize Mesh
 > version. Even though I did everything the performance improvment
 > papers suggested.

Did you copy the exact same data from the optimised mesh into other 
buffers? Did you try loading the same data into OpenGL?

	Eyal

> (using triangle strips, vertex arrrays, with indexed vertices, etc),

If you forgot ordering of vertex indices to improve vertex-cache 
coherency, you actually just forgot the most important of these
for generic meshes (good ordering in GL_TRIANGLES mode will often
result in faster output than poor ordering with GL_TRIANGLE_STRIP).

Eric

"Philip Taylor [ATI]" <ptaylor@online.newsgroup-poster.ati.com> wrote in message news:<unTvpz2ZDHA.1832@TK2MSFTNGP09.phx.gbl>...
> one thing thats likely not available in OGL, at least not as simply, is the
> vertex-cache aware optimizer used by the OptimizeMesh sample.
> 
> this optimizer is aware of specific details on various IHV cards, and is
> thus better than all but the most connected developers could write.

Vertex cache is an issue sending non-stripped primitives, since with
strips you do no repeat vertices, no ?

~velco

> D3DX is a nice collection of bits.

<flamebait>
Go, ATI, go, show it to these GNU/Linux/OpenGL supporting bastards
from nVidia.
No XBOX for them! :P
</flamebait>

j/k :)

> regardless, the point was in the case of thinking using OGL will give you
> more portability - 

Aye, it even gives you more portability for the same OS, which is why I prefer
OpenGL (just don't want to have to start again everytime a new DirectX
version comes out). 
DirectX is good for fire & forget code, whose lifetime won't exceed a few years,
but for pro application, you just can't rewrite the graphics code every day.
How many of your DirectX 5 or 6 (even 7) applications and games still work on 
current drivers? Not many do work correctly anymore here... And I'm not referring
undersized buffers issues (which are rather due to the of C/C++), but graphical
glitches, incorrect rendering and performance issues.

Eric

> selecting what features to use in D3D FFP multi-texture is a lot easier
than
> using the various vendor extensions for MT. one is branching off
> ValidateDevice within a single code path. the other is completely separate
> code paths. and we havent even got to how complicated shaders are today in
> OGL...

Why would you not just use the ARB extension for MT?  And yes, shaders are
easier in D3D right now, but the ARB will have either integrated it into the
API or into an ARB extension shortly.

> and how many apps have blown up because of caps bits being added? Quake
blew
> up because the extension strings got larger than 1k.

So, you're saying that the true reason behind that issue was the extension
strings, and not a programmatic issue?

> regardless, the point was in the case of thinking using OGL will give you
> more portability - even there thats somewhat tainted if the exact same set
> of extensions isnt supported on that other OS, whatever it might be. of
> course, you code code vanilla OGL and avoid that, but vanilla OGL is
> definitely less filling. :-).

I agree with you there, believe me, I just spent the last couple of days
getting grilled by OpenGL zealots who were crapping on Direct3D in the
OpenGL ng.  Drivers for 1.4 don't exist for each card, the 1.4 driver's for
the cards which have them do not necessarily support all of 1.4, et
cetera...  Things on Irix, HP-Unix, Solaris, and WinTel are not the same, et
cetera...

    WTH:)

> DirectX is good for fire & forget code, whose lifetime won't exceed a few
years,

This simply places the murky issue of OpenGL versus D3D into specific
relief, DirectX's overriding goals defer to game development.  OpenGL's do
not.

> but for pro application, you just can't rewrite the graphics code every
day.

Every day? ;)

> How many of your DirectX 5 or 6 (even 7) applications and games still work
on
> current drivers? Not many do work correctly anymore here... And I'm not
referring
> undersized buffers issues (which are rather due to the of C/C++), but
graphical
> glitches, incorrect rendering and performance issues.

Actually, I have some very old code DX5 (I haven't tried the DX3 version
lately) here that runs just great.

    WTH:)

Eric Grange <egrange@glscene.org> wrote in message news:<3F449384.13DE84FF@glscene.org>...
> > Vertex cache is an issue sending non-stripped primitives, since with
> > strips you do no repeat vertices, no ?
> 
> With proper vertex ordering, strips can be faster than strips,
> essentially because you can have triangles "for free" from a T&L point
> of view. In a strip with no ordering, you'll usually have to transform
> one vertex to have one new triangle, but if that new vertex you specify 
> for the strip is one of the recently transformed vertex (ie. is in the
> cache of 10-15 or so vertices), then it won't have to be transformed
> again. 
> Particularly useful when starting new strips, if you can start from
> the last vertices of the previous strip, or for the small clumps
> of stray triangles you get at the end of a stripification.

Sure, my point is whether strips are this short that vertex cache can
make any difference ? I'd suspect they are usually much longer, or
else one wouldn't notice a difference between strips/no-strips anyway
(because of the cache).

~velco

> Sure, my point is whether strips are this short that vertex cache can
> make any difference ? I'd suspect they are usually much longer,

With a greedy stripifier (and all stripifier that stripify large leshes
in a second or less are "greedy"), you end up with lots of small strips.
Even with more advanced schemes, there are still lots of strips, 
see with nvTriStrip f.i (which isn't greedy):

http://developer.nvidia.com/object/nvtristrip_v1_1.html

> or else one wouldn't notice a difference between strips/no-strips anyway
> (because of the cache).

Which is the case, if an unordered GL_TRIANGLES won't stand a chance against
GL_TRIANGLE_STRIPS, an ordered GL_TRIANGLES will get close.

Eric

> Sure, my point is whether strips are this short that vertex cache can
> make any difference ? I'd suspect they are usually much longer, or
> else one wouldn't notice a difference between strips/no-strips anyway
> (because of the cache).

The reason strips are noticed is because you need to optimise for the 
cache to get its full benefit. If you do, you should get a bit of a 
speedup over a strip.

	Eyal

On Wed, 20 Aug 2003 17:25:17 -0400, "Philip Taylor [ATI]"
<ptaylor@online.newsgroup-poster.ati.com> wrote:

....
>in terms of reasons for selecting - how about cleanness of the API with D3D?
>as compared to having numerous vendor specific hacks, I mean extensions,
>littering your code?

I don't see much difference between:
if(EXT_cubemap)path1; else path2;
and
if(capabilityBits&CUBEMAP)path1; else path2;

The rest is just standard data abstraction; you shouldn't be using
both API's directly anyway in a big enough project.


Ruud van Gaal
Free car sim: http://www.racer.nl/
Pencil art  : http://www.marketgraph.nl/gallery/

On Wed, 20 Aug 2003 17:25:17 -0400, "Philip Taylor [ATI]"
<ptaylor@online.newsgroup-poster.ati.com> wrote:

....
>in terms of reasons for selecting - how about cleanness of the API with D3D?
>as compared to having numerous vendor specific hacks, I mean extensions,
>littering your code?

In my view btw, you have:
- OpenGL; has a base functionality that's generated, and there can be
more through extensions
- D3D: has more functionality than most cards offer, but not all of it
is really supported.

That's the only design difference (although it has quite some impact).
The rest is just indeed, getting stuff to the gfx card, and hopefully
providing an optimal path to do that.


Ruud van Gaal
Free car sim: http://www.racer.nl/
Pencil art  : http://www.marketgraph.nl/gallery/

BTW, is there a good tool that munges your model data, does
tristripping and ordering?  I wrote my own, but I'm curious if there
is a commerical version...

Eric Grange <egrange@glscene.org> wrote in message news:<3F4476FF.47A2C23B@glscene.org>...
> > (using triangle strips, vertex arrrays, with indexed vertices, etc),
> 
> If you forgot ordering of vertex indices to improve vertex-cache 
> coherency, you actually just forgot the most important of these
> for generic meshes (good ordering in GL_TRIANGLES mode will often
> result in faster output than poor ordering with GL_TRIANGLE_STRIP).
> 
> Eric

"WTH" <ih8spam@spamtrap.com> wrote in message news:<vk9k7gqgdpth83@corp.supernews.com>...
> > selecting what features to use in D3D FFP multi-texture is a lot easier
>  than
> > using the various vendor extensions for MT. one is branching off

Eh? What vendor extensions for multitexture ? ARB_multitexture
appeared as ARB extension in OpenGL 1.2.1, released October 14, 1998,
went into the core in version 1.3, released August 14, 2001.

> > ValidateDevice within a single code path. the other is completely separate
> > code paths. and we havent even got to how complicated shaders are today in
> > OGL...
> 
> Why would you not just use the ARB extension for MT?  And yes, shaders are
> easier in D3D right now, but the ARB will have either integrated it into the
> API or into an ARB extension shortly.

ARB_vertex_program - Approved by ARB on June 18, 2002.
ARB_fragment_program - Approved by ARB on September 18, 2002.

> Things on Irix, HP-Unix, Solaris, and WinTel are not the same, et
> cetera...

Sure, but the differences with DX on WinTel and DX on Irix, HP-Unix,
Solaris, etc. are even bigger :)

~velco

> BTW, is there a good tool that munges your model data, does
> tristripping and ordering?  I wrote my own, but I'm curious if there
> is a commerical version...

For offline optimization, you can use NVTriStrip (there is both a library
and a utility version of the thing). It isn't particularly swift, so for 
everyday purposes I use my own code, but to preprocess your final resources, 
it's a good tool, and it's free.

Google has direct links to both versions of NVTriStrip, and Tom from Delphi3D
has a DLL version (also linked from google).

Eric

"Momchil Velikov" <velco@fadata.bg> wrote in message
news:87bded37.0308210828.3074e6cc@posting.google.com...
> "WTH" <ih8spam@spamtrap.com> wrote in message
news:<vk9k7gqgdpth83@corp.supernews.com>...
> > > selecting what features to use in D3D FFP multi-texture is a lot
easier
> >  than
> > > using the various vendor extensions for MT. one is branching off
>
> Eh? What vendor extensions for multitexture ? ARB_multitexture
> appeared as ARB extension in OpenGL 1.2.1, released October 14, 1998,
> went into the core in version 1.3, released August 14, 2001.

Why are you asking me that?  I said exactly the same thing, "Why would you
not just use the ARB extension for MT?"


> ARB_vertex_program - Approved by ARB on June 18, 2002.
> ARB_fragment_program - Approved by ARB on September 18, 2002.

He easier, he didn't say ONLY in D3D.  You need to read better.

> Sure, but the differences with DX on WinTel and DX on Irix, HP-Unix,
> Solaris, etc. are even bigger :)

LOL, true...  I missed the Irix release party?  Damn...  Of course, there
aren't a whole lot of game companies releasing games on
Irix/HP-Unix/Solaris, et cetera... ;)

    WTH

He won't see it (possibly) since you didn't include the DX graphics group in
this response...

    WTH

"Ruud van Gaal" <KILLSPAMruud@marketgraph.nl> wrote in message
news:3f47ee03.170427972@news.xs4all.nl...
> On Wed, 20 Aug 2003 17:25:17 -0400, "Philip Taylor [ATI]"
> <ptaylor@online.newsgroup-poster.ati.com> wrote:
>
> ...
> >in terms of reasons for selecting - how about cleanness of the API with
D3D?
> >as compared to having numerous vendor specific hacks, I mean extensions,
> >littering your code?
>
> I don't see much difference between:
> if(EXT_cubemap)path1; else path2;
> and
> if(capabilityBits&CUBEMAP)path1; else path2;
>
> The rest is just standard data abstraction; you shouldn't be using
> both API's directly anyway in a big enough project.
>
>
> Ruud van Gaal
> Free car sim: http://www.racer.nl/
> Pencil art  : http://www.marketgraph.nl/gallery/

> Google has direct links to both versions of NVTriStrip, and Tom from Delphi3D
> has a DLL version (also linked from google).

..gll -- Google-Linked-Library! :)

    - Alex

> Wasn't my idiotic comment properly marked as such ? :)

Apparently not. I've seen too many crazed fans (of both APIs and 
graphics cards) to ignore such a comment as a joke. So sorry that I 
didn't get it.

	Eyal

Hello,

I have a problem with using vertex arrays to speed up loading 3D objects
under OpenGL.

Problem is the format of the object file describes an object with
polygons which has a variable number of sides. Therefore I cannot use
glDrawElements(GL_TRIANGLES, ....); // as each side is not always 3

The Rabbi Stiffkugel (Opherian@aol.com)