EXT_packed_depth_stencil released

Originally posted by Korval:

OpenGL is not a well-designed API. It is an API that has had layers and layers built on it, each one depricating the previous one but without actually removing it from the language. As such, implementing it becomes an ever escalating problem. Maybe if the API could be rebuilt from the ground up, then it might be considered well-designed. Until then, it is a mismash of features that, while certainly functional, has innumerable pitfalls in its design. OpenGL ES, by contrast, is far better of a 3D API.

This is also my impression. But that is a problem with support of long-lasting software. That I find really annoying is, that I have to bind something to change his parameters. I like the Shader Objects API much better. But there should be also a way to change uniforms without use the shader if the uniforms are saved. I don’t say the the binding way should go. I think both ways should be possible.

regards

marco

PS sorry for my english but I have big problems in my native language too.

PS sorry for my english but I have big problems in my native language too.
Why to you apologise Marco ? No need. Is a simple skill, which can be learned, given enough interes.
Your potential spellind errors are of practical importance only to very picky and weird persons.

I got 2 MVPs for Widnows DDK from Microsoft, and helped online hundred of ppl with this awfull english I have, many which finalized complex projects due to my help. And yes they where able to understood what I want to say. All this in a ****ty, every 2 words with spelling errors english. It helped the US and UK guys as well as others :stuck_out_tongue:

Dont apologise for the likes of Korval only, those persons which pretend they cant understand because
your english is so miserable are just telling you
this because they have nothing better to do.

This has also absolutely nothing to do with the subject.

Korval wrote:
OpenGL’s strength is not the “great design” of its API, but in the fact that it is the only cross-platform 3D graphics API. That is it’s only strength compared to its competition.
While I agree with the rest you wrote, I don’t consider this OpenGL’s only strengt.

I think OpenGL has more speaking for it (compared to the competition or not). Cross-platform is perhaps the most obviously, but I wouldn’t discount the fact I can today take an OpenGL program written 12+ years ago, compile it, and it works.

Can you even find equally old “competition” code, that’s still even valid?

OpenGL has managed, like e.g. the Win32 or POSIX API’s, to grow and expand the existing interface(s). DirectX hasn’t grown. It has been superceeded time and time again by “new and shiny” (and even incompatible) interfaces. Heck, a DirectX interface Microsoft released just a few years ago is now documented as “obsolete” and its documentation has even been revoked!

I suspect the first Red Book is still as valid as they day it was first printed.

To this one could add the incompatible changes introduced in the many versions of different DirectX interfaces. I mean, 10+ versions in just a little over a decade? That’s AFAIK only surpassed (but then by an insane margin) by nvidia’s 75-80 versions in a similar timeframe.

That said, obviously I also think OpenGL displays its age, and on many occasions I get annoyed with its flaws. But then again, is there an alternative? No. Furthermore, if an alternative was created and available now, today, could anyone with less than under threat of thermonuclear warheads and total annihilation of Redmond get the largest software “almost”-monopoly on the planet to support such an API? Even if the API today had implementations for ALL other operating systems than Windows?

Okay, I feel like I’m adding to a thread that has already lost any of it’s value, however, I still haven’t learned my lesson from past experience. That said, I’m going to post my opinion, if it even matters.

1.) the FBO stuff is pretty easy to use and it’s performance for me has been outstanding. The only problems I (there may certainly be others… not discounting them) have had are regarding errors… sometimes I do something wrong and don’t get a good error message to tell me. For instance: binding a framebuffer while one of it’s texture objects is still bound to a texture target.

2.) PBuffers suck. They were are PITA to use, especially with shaders.

3.) The “extension hell”… I don’t feel the extensions are that bad. There is currently a mess of extensions, but since they’re getting rolled into the core API, it’s really not that big of a deal. The first thing I tend to do in a project is look at the desired feature set, and then go through building a wrapper library for the stuff in GL that I want to use. If there is desired functionality in the core spec, I make sure to use it. It’s really not that tough for me. The only extensions I use currently are: ARB_texture_non_power_of_two, EXT_framebuffer_object, EXT_packed_depth_stencil. I’ve got a near complete engine with shaders and all. All I’m doing is using OpenGL 2.0. Thats it. Pretty easy, pretty solid, runs on a wide range of graphics cards… I even have some fallbacks with the ability to run on cards that only do OpenGL 1.5 with GLSL as an extension.

Why is this easy for me? It’s an investment. I only have to learn the OpenGL API once. My knowledge from 4 years ago still applies today. When a new extension comes out, I simply read over it and decide if I want to use it. If I want to use it, I’ll simply roll it into my codebase. Viola! New feature! Try doing that with Direct3D. In short, when you’re on a project that takes a long time, you grow to love the extension mechanism. I can be adding in new graphics features all the way to a few months before ship. I don’t have to worry about whether or not I’ll have to rewrite my engine internals to use a single new feature, simply because it wasn’t included in the current version of D3D at the time the engine was started. The OpenGL extension mechanism works great for an iterative development process.

So thats it. Those are my opinions for what they’re worth. Dunno if it will help anyone with their problems, or will perhaps provide a new perspective for anyone, but if so, great. If not, then I really haven’t learned my lesson. =)

  • Kevin

Try doing that with Direct3D.
Dont be naive. Look at DX9 API. It almost , and I stress the word almost, cleaner and at least as usable as OpenGL. I can guarantee you that the changes in the API will be very conservative, and differences will be minimal, for DirectX Next. DX has evolved to an API which is comparable with OpenGL both as strength and flexibility. DX9+ only lacks cross platform. As “real world” features, it already exceed OpenGl.

Im afraid, altough I really do not desire this, that DirectX Next will be a much more better API then OpenGL.

There where posts here saying that “game developers need latest features and speed”. Well,
its true ! Go check the figures and see how much
% of the 3D market is entertainment. And , unfortunately OpenGL loose space every day in it.

Truth is, DirectX evolves at at least 2x speed of OpenGL. ARB comitee can save OpenGL. If they understand their failures and want to save it.
If not, GL will become almost extinct soon.

It has been superceeded time and time again by “new and shiny” (and even incompatible) interfaces. Heck, a DirectX interface Microsoft released just a few years ago is now documented as “obsolete” and its documentation has even been revoked!
tamlin, that’s the beauty of it!

you see, for game development, it doesn’t matter if interfaces change a little each year or so, since it’s not that difficult to remedy in a properly written renderer, for one thing, and it’s a heck of a lot better than waiting while engineers try to shoehorn square pegs into round holes. we are, after all, talking about interfaces, not core features.

think about it. in opengl, if a new extension is released, we’re presented with an entirely new api, a new set of functions, enums, and documentation. what’s the difference if a function has been changed, or documentation has to be rewritten? look at all the necessary modification to existing spec each time an extension is released. yes, your old code will work, and for certain developers that’s important. but eventually you have to cut your losses and realize that no matter how smart you are, you can’t predict the future. technology is changing quickly, and you can’t anticipate and design optimal interfaces around technology that doesn’t exist yet.

heck, to me it’s refreshing to get a clean start. sometimes you need to rethink things; ideas that were good at the time just don’t stand the test of time sometimes. it’s just a pity that opengl is not in a good position to do that. i’m sure the arb would love to change some things if they could. it would probably makes their jobs a lot easier. but because opengl is not a game api specifically, this is not likely to happen anytime soon. as much as you might gripe about how long things are taking, there would be a mighty, cantankerous din, the likes of which has never been heard, if you were to change things and disturb a code base out there the size of canada.

bonehead, you may be explain why OpenGL ES exist, why it is used to PS3 programming. Maybe, because it will become an OpenGL game API.

Even if OpenGL wasn’t used in games I still trust it and I think that every OpenGL Extensions witch replace WGL or GLX features are welcomes

Originally posted by Groovounet:
[b]bonehead, you may be explain why OpenGL ES exist, why it is used to PS3 programming. Maybe, because it will become an OpenGL game API.

Even if OpenGL wasn’t used in games I still trust it and I think that every OpenGL Extensions witch replace WGL or GLX features are welcomes[/b]
Maybe EGL is the way to go?

Dont be naive. Look at DX9 API. It almost , and I stress the word almost, cleaner and at least as usable as OpenGL
of course the word ‘almost’ means even though its close its still worse.
randomly picked example

pd3dDevice->SetRenderState( D3DRS_ALPHABLENDENABLE, true );
vs
glEnable( GL_BLEND );

Truth is, DirectX evolves at at least 2x speed of OpenGL. ARB comitee can save OpenGL. If they understand their failures and want to save it.
If not, GL will become almost extinct soon.
how on earth can it become extinct soon if the ps3 uses it, in fact ild say WRT to game sales opengl’s market share by 2007 is gonna be larger than d3d

Can you even find equally old “competition” code, that’s still even valid?
As part of COM, DirectX must provide (functioning) interfaces for all previous versions of DirectX. As such, Direct3D 3.0 (the earliest and ugliest version of D3D) should still run. Unfortunately, I have no applications this old that run on a WinXP machine. However, I do know of a game that does run under WinXP that uses DirectDraw 2.0, and it runs under any DirectX install.

This happens because Microsoft makes sure it happens. They put the legacy code into each DirectX release (which is one reason why they keep getting bigger); they do not force the legacy on either the modern API or driver developers. It’s one of the few smart things Microsoft did early on with DirectX. Putting new APIs into new interfaces that are completely separate from the old API is what allows modern D3D to be a relatively clean API, free of legacy APIs.

To this one could add the incompatible changes introduced in the many versions of different DirectX interfaces. I mean, 10+ versions in just a little over a decade? That’s AFAIK only surpassed (but then by an insane margin) by nvidia’s 75-80 versions in a similar timeframe.
That’s actually pretty good. Remember, D3D didn’t even exist in DX 2.0 (there never was a DX 1.0), and it wasn’t changed in DX 4.0. I don’t even know if DX 6.0 changed the D3D API. So what you really have are 5-6 API changes over 10 years.

That’s pretty good for a company that initially knew nothing about 3D APIs.

But then again, is there an alternative? No. Furthermore, if an alternative was created and available now, today, could anyone with less than under threat of thermonuclear warheads and total annihilation of Redmond get the largest software “almost”-monopoly on the planet to support such an API?
Does Linus Torvald get consulted on OpenGL changes? Of course not; he’s just involved with the kernel, which has nothing to do with a 3D API. The idea that Microsoft must be involved with or must support any 3D API is simply in error; it’s the IHV’s who must provide support, not Microsoft.

bonehead, you may be explain why OpenGL ES exist, why it is used to PS3 programming. Maybe, because it will become an OpenGL game API.
Because:

1: Sony is (finally) aware that they need to provide some kind of API for graphics, rather than just shoving some tech manuals at developers and telling them to go to work like they did with the PS2.

2: Because D3D is Microsoft’s, and the last thing Sony wants to do is legitimize Microsoft.

3: It’s less work to extend an already existing API than to write a new one from scratch.

4: The graphics chip is an nVidia chip; they already have a functioning OpenGL implementation that can be used to create the implementation for the PS3.

Originally posted by Korval:
[b] [quote]Can you even find equally old “competition” code, that’s still even valid?
As part of COM, DirectX must provide (functioning) interfaces for all previous versions of DirectX. As such, Direct3D 3.0 (the earliest and ugliest version of D3D) should still run. Unfortunately, I have no applications this old that run on a WinXP machine. However, I do know of a game that does run under WinXP that uses DirectDraw 2.0, and it runs under any DirectX install.

This happens because Microsoft makes sure it happens. They put the legacy code into each DirectX release (which is one reason why they keep getting bigger); they do not force the legacy on either the modern API or driver developers. It’s one of the few smart things Microsoft did early on with DirectX. Putting new APIs into new interfaces that are completely separate from the old API is what allows modern D3D to be a relatively clean API, free of legacy APIs.

[/b][/QUOTE]So you have ABI but not API compability over the versions. This is good for games but not so much for long-lived Applications. But don’t forget DX is windows only and the best force for innovations is competition. I don’t care how long the names of the functions are but how much the design of the opengl api contrainst me.

Dont be naive. Look at DX9 API. It almost , and I stress the word almost, cleaner and at least as usable as OpenGL. I can guarantee you that the changes in the API will be very conservative, and differences will be minimal, for DirectX Next. DX has evolved to an API which is comparable with OpenGL both as strength and flexibility. DX9+ only lacks cross platform. As “real world” features, it already exceed OpenGl.
Of course D3D is cleaner =). I never made any claim that it isn’t. My point was that D3D doesn’t work as well with an iterative development process. Why? Because you have to
“port” your application to the latest version of D3D to take advantage of various features. Just as you said, “when DirectX next comes out”. Yeah, when it does, I’ll be adding in new features and you’ll be porting your code. When your development cycle is 3-4 years long, you begin to appreciate certain things about OpenGL. If I went with DirectX, I would have “ported” once already, possibly again to support the new features of latest update, and then at least one more time when “DirectX Next” comes out. Fun stuff right there. As far as “real world” features, OpenGL matches everything D3D has plus some. For instance, I can do an asynchronous texture/vertex buffer upload in GL; can’t do that in D3D. I can do depth clamp in GL; can’t do that in D3D. I can do primitive restart instead of degenerate tris in GL; can’t do that in D3D. In Direct3D’s defense, it has D3DX. It has a number of rather useful functions for loading images as well as a pretty nice math library. I’d say here it kicks the crap out of GL. Really though, is D3DX that big of a deal? I doubt I would have saved time using D3DX over the course of a project simply because of the cost of doing those “ports”. However, D3DX rules for getting something up and running though.

Also, don’t expect the changes to DirectX Next (WGF 2.0) to be minimal. Matter of fact, I doubt you’ll even recognize most of the API. :wink: :cool: However! If you’re talking about DX9+, then you’re right, the changes will be fairly light except for a few new (and big) features.

So you have ABI but not API compability over the versions. This is good for games but not so much for long-lived Applications.
I’m not sure I understand your point here. If you want, you can get the Direct3D 3.0 documents and use that interface for doing your rendering. You won’t get much in terms of functionality out of your graphics chip, but the older API’s are still there. A “long-lived” application can still use the old API’s.

My point was that D3D doesn’t work as well with an iterative development process. Why? Because you have to
“port” your application to the latest version of D3D to take advantage of various features. Just as you said, “when DirectX next comes out”. Yeah, when it does, I’ll be adding in new features and you’ll be porting your code.
Yes, but we’ve been on D3D 9.0 for quite some time. And the difference between 9.0 and 8.0 aren’t that much, so you could consider them to be effectively the same API. So, looking at it from that perspective, D3D hasn’t changed since the GeForce 3 came out. OpenGL has had more API changes since then than D3D.

Originally posted by Korval:
[quote]So you have ABI but not API compability over the versions. This is good for games but not so much for long-lived Applications.
I’m not sure I understand your point here. If you want, you can get the Direct3D 3.0 documents and use that interface for doing your rendering. You won’t get much in terms of functionality out of your graphics chip, but the older API’s are still there. A “long-lived” application can still use the old API’s.
[/QUOTE]Yes, but if I want use the new features I have to change my complete code to the new interface. In OpenGL I can change my code and still can use the old way in the old code(change code in complex stuff cost allmost time and money). But I think the GPUs will change very much in next years and where will be a need for very different API. So I hope OpenGL (ES) 3 will be not backward compatible. I hope my point is now clearer.

direct3d is much more cpu heavy, because of the processing needed to construct large batches, which are certainly neccessary for realtime rendering in d3d.
Out of the two abstract implementations of my renderer, I use (and recommend to customers) the opengl version, because the data they use is usually large numbers of small objects, which draw much faster with opengl - and it’s not pratical to pre-process data dynamically submitted by the user into large batches.

direct3d is much more cpu heavy, because of the processing needed to construct large batches, which are certainly neccessary for realtime rendering in d3d.
This will change in DirectX next. Buffers will be constructed differently.

D3DX that big of a deal?
D3DX doesn’t matter to game developers because creating their own code takes very little time and it needs to be done once.

What matters is the core. Does the API in question do what you need? Are video drivers stable? Will your target audience be able to enjoy your product?

Sidenote : I hope FBO gets perfected quickly. There better be trouble free drivers available as well!

Originally posted by DanPartelly:
This will change in DirectX next. Buffers will be constructed differently.
Is this the virtual memory thing?

as for d3d being a cleaner api, my opinion is I really hate enums. OpenGL has less, D3D has more. If you’re going to do an object orientated api (which D3D is mascarading as), use polymorphism. Over reliance on enums is a sign of bad design. It’s nothing to do with performance, because a look-up table has the same cost as a vtable look-up. It’s nothing to do with making it extensible, because they’ve demonstrated they change the entire API interface at the drop of a hat.

direct3d is much more cpu heavy, because of the processing needed to construct large batches, which are certainly neccessary for realtime rendering in d3d.
No, the reason D3D is more CPU heavy is because it is easier to write D3D drivers. An OpenGL implementation has full control over a function call from the moment it gets made. OpenGL implementations implement the API that the user uses directly.

D3D drivers don’t work like that. Microsoft defines an API for D3D driver developers to implement. This driver runs in unprotected mode on the CPU. As such, every call to D3D that has to talk to the driver forces a switch to Ring0 on the CPU. This is not a fast operation. Because D3D itself implements a layer between the application and the hardware driver, it cannot properly do marshalling of various function calls (for various reasons), especially considering that “proper” marshalling for a GeForce isn’t necessarily proper for a Radeon.

So, basically, it is exchanging performance for easier to implement drivers (and thus more robust drivers). Much like giving Microsoft responsibility over the HLSL compiler rather than putting it in the driver trades potential performance for robustness of the API.

As I understand it, in DirectX 10 (or whatever they call it), they are going to remove some of the more bothersome layers between the driver and the application, thus allowing the driver to do some marshalling (and probably async uploads and so forth). I doubt that the entire mechanism will be exposed as it is under OpenGL, but it should alieviate the most significant performance penalties associated with this issue.

as for d3d being a cleaner api, my opinion is I really hate enums. OpenGL has less, D3D has more.
Admittedly, I haven’t looked at D3D in quite some time, but I can’t imagine the API having more enums than OpenGL. The possibilities that fit into glGet* alone probably outstrip anything in D3D.

If you’re going to do an object orientated api (which D3D is mascarading as), use polymorphism.
I would suggest that D3D is not an object oriented API. It uses objects (instances of C++ classes and COM objects), but it clearly follows few if any OOP design principles. Furthermore, I would suggest that OOP doesn’t really belong at the low-level graphics API, but at a higher level scene-graph level (or, at least, a level that recognizes a “mesh” as being more than just a group of vertex buffers). So, under that belief, it is a good thing that D3D is not an object-oriented API.