Which API is better?

[NeARAZ]

Can you explain why OpenGL doesn't work on Cube or PS2? Doesn't Sony in fact, have an implementation of OpenGL for the PS2?
Sure, you might need to add extensions to expose native features, and you might not reach the efficiency of some Glide-like to-the-metal API, but I find it hard to believe that OpenGL simply "can't be implemented" on those platforms.

It does work, but ain't useful for anything "serious". It's somewhat similar to, say, plain glVertex() calls in OpenGL (no lists, no varrays) - it does work, but...
PS2 is a beast that's too different. It's too different in terms of architecture (it's nothing like a PC), and in terms on graphics processing. Eg. T&L is done via vector units - which leave current PC "vertex shaders" lightyears behind - that is, they are fully programmable general purpose vector processors. You can do T&L with them, compute intensive math with them, do tesselation with them, even generate dynamic textures with them. More, there are smaller things like triangle clippers, DMA transfers etc.
You can't efficiently wrap GL/DX (which are quite similar) onto this architecture.

 

[DemoCoder]

Yes, I understand the difficulty with mapping OpenGL to PS2's "parallel" nature, but OpenGL2.0 would help alot with that.

What I don't understand is the reference to the Xbox and the Cube as not allowing an OpenGL implementation. I'd need serious convincing that OpenGL can't be mapped to the NV2A, very serious convincing, it is, after all, just a tweaked NV20/25. And unless someone can point out some exotic feature of the Cube that makes it difficult, that one seems a candidate as well.

(I don't count "unexposed" features as a reason, since extensions can always expose them)

 

[NeARAZ]

What I don't understand is the reference to the Xbox and the Cube as not allowing an OpenGL implementation. I'd need serious convincing that OpenGL can't be mapped to the NV2A, very serious convincing

It can be used, sure. But is there a need for that?

I don't count "unexposed" features as a reason, since extensions can always expose them

In that sense, you could expose SQL database as OGL extension
Even if all the strange architectures will be exposed as extensions - then you WILL have separate rendering paths for each. You will use GL, but with a new subset of extensions for each. Isn't it the same as using different APIs then?

 

[DemoCoder]

In that sense, you could expose SQL database as OGL extension
Even if all the strange architectures will be exposed as extensions - then you WILL have separate rendering paths for each. You will use GL, but with a new subset of extensions for each. Isn't it the same as using different APIs then?

I don't think they're equivalent, since with each different API you'll have to learn totally new paradigms, datatypes, init conventions, etc. Even if you have to utilize a few custom extensions, you still share a huge amount of commonality.

There is a far larger difference between having to code both DX and OGL, and code OGL and OGL with the exception of a few extensions. If you know OGL and have to do DX, you have to learn an entirely different way of doing things, nasty Win32 hungarian notation, COM, etc.

In terms of extensions, I'm thinking of things like NV_register_combiners2 and CUBE_texture_combiners. I may have to call different functions to set up the texturing, but I still can share alot of common OGL code.

Think of Doom3 using both ARB_ and NV_ fragment programs. It doesn't demand a huge rewrite of the entire rasterizer anymore than dealing with the plethora of DX CAPs bits does.

 

[Bohdy]

Cube already uses and has since launch an api similar to opengl called GLX (afaik).

 

[Simon F]

PS2 is a beast that's too different. It's too different in terms of architecture (it's nothing like a PC), and in terms on graphics processing. Eg. T&L is done via vector units - which leave current PC "vertex shaders" lightyears behind - that is, they are fully programmable general purpose vector processors. You can do T&L with them, compute intensive math with them, do tesselation with them, even generate dynamic textures with them.

'leave current PC "vertex shaders" lightyears behind' - I can't see that. The vector units in the EE probably are more flexible but, AFAICS, the mathematical support seems far more limited than the VS units. (This is based on the EE article that was in an IEEE journal.)

You can't efficiently wrap GL/DX (which are quite similar) onto this architecture.

Which would seem to imply that perhaps it isn't all that fantastic after all? <shrug>

 

[NeARAZ]

'leave current PC "vertex shaders" lightyears behind' - I can't see that. The vector units in the EE probably are more flexible but, AFAICS, the mathematical support seems far more limited than the VS units. (This is based on the EE article that was in an IEEE journal.)

Well, it has multiple precision modes, branching, and you can use it for whatever you like (that is, it ain't dedicated for vertex processing). You can use one VU for transforms, and another for, say, physics inner loop. Or have one of them generate procedural textures.

Which would seem to imply that perhaps it isn't all that fantastic after all?

I'm not saying it's fantastic! It's different.

 

[Rodéric]

Glide rulesss !!!
(never even used it, but I had to say something stupid for such a topic )

 

[darkblu]

Glide rulesss !!!
(never even used it, but I had to say something stupid for such a topic )

not wanting to take this thread astray, but glide was a decent IMR rasteriser api, fairly general at that (despite the fact it was written for one architecture only). the api was following more or less the OGL paradigms in what it was doing. the essential problem people had with glide was that it was proprietary to the max - developed by one vender for the sake of one architecture only.

 

[Simon F]

Glide rulesss !!!
(never even used it, but I had to say something stupid for such a topic )

not wanting to take this thread astray, but glide was a decent IMR rasteriser api, fairly general at that (despite the fact it was written for one architecture only). the api was following more or less the OGL paradigms in what it was doing. the essential problem people had with glide was that it was proprietary to the max - developed by one vender for the sake of one architecture only.

And, IIRC, didn't they came down like a tonne of bricks on any attempt to make glide wrappers?

 

[darkblu]

Glide rulesss !!!
(never even used it, but I had to say something stupid for such a topic )

not wanting to take this thread astray, but glide was a decent IMR rasteriser api, fairly general at that (despite the fact it was written for one architecture only). the api was following more or less the OGL paradigms in what it was doing. the essential problem people had with glide was that it was proprietary to the max - developed by one vender for the sake of one architecture only.

And, IIRC, didn't they came down like a tonne of bricks on any attempt to make glide wrappers?

erm, that would've been more like a tonne of sidewalk boulders (which everyone knows is a bit heavier than a tonne of bricks)

 

[KimB]

Really? A ton heaver than a .... ton?

 

[Randell]

hmm what's heavier, a ton of feathers or a ton of lead..

 

[KimB]

hmm what's heavier, a ton of feathers or a ton of lead..

Actually, due to buoyancy, the same mass of feathers would feel lighter...

 

[no_way]

hmm what's heavier, a ton of feathers or a ton of lead..

Actually, due to buoyancy, the same mass of feathers would feel lighter...

Somewhat depends on where you stand, too. Its somewhat lighter living for polynesians, compared to eskimos.

 

[KimB]

Yep, by about 0.3%

 

[OpenGL guy]

hmm what's heavier, a ton of feathers or a ton of lead..

Actually, due to buoyancy, the same mass of feathers would feel lighter...

Unless you're in a vacuum.

 

[Randell]

or they were compressed into a tight cube..

 

[Crazyace]

'leave current PC "vertex shaders" lightyears behind' - I can't see that. The vector units in the EE probably are more flexible but, AFAICS, the mathematical support seems far more limited than the VS units. (This is based on the EE article that was in an IEEE journal.)

You can't efficiently wrap GL/DX (which are quite similar) onto this architecture.

Which would seem to imply that perhaps it isn't all that fantastic after all? <shrug>

Vu is pretty general purpose - and I think you could wrap the GL/DX lighting pipeline quite efficiently, ( blend modes on the other hand ) - nothing stay's fantastic though....

I think the trouble is that people make statements such as the 'lightyears behind' one - which just aren't correct anymore - ps2 vu competes well with the Geforce 2/3 and Xbox to a certain extent, but doesn't match up with the latest NVidea and ATI offerings...

 

[KimB]

or they were compressed into a tight cube..

Nah, you can only compress the feathers so much, and the atoms are still going to be different. Lead would still be more dense (unless you went so far as to compress them into nothing but neutrons...but that's going a bit far...).