i just found one thing that dx is really supperior in…
rendertarget.
that wgl/pbuffer/rendertexture construct that got created is really crap. rendering to an offscreen target has nothing to do with the os gl is running on. its just a buffer for gl to draw into. rendering to a texture, the same. it has nothing to do with the os. else we would need wglTexImage2D and wglCopyTexSubImage2D as well…
thats the main thing i prefer in dx.
“Wait so learning direct x will be easier for you than just using GL in this project? Man I wish I could learn how to use graphics API’s as fast as you can…”
Well yes. I worked for ******* Interactive a good few years ago and learnt D3D 6 there. Moving up to D3D 8, I can get up and running very quickly.
Originally posted by Robbo:
Well yes. I worked for ******* Interactive a good few years ago and learnt D3D 6 there. Moving up to D3D 8, I can get up and running very quickly.
My first look at Dx was 6 and I had a brief look at 7 & 8. I gave up because all I could remember from 6 was irrelevant in 8…
I think that many people are missing the fact that the learning time of an API is a really important component. So, it’s true that in gaming industry openGL is not the most efficient API, because it is not oriented on feature set, but on low level programming historically made to use with very old SGI hardware : for basics operations, OGL and DX are both efficient, but for an abstraction in a more unified manner of complexe optimised features, DX seems to be really more simple.
All Guru are all time saying that his prefered API is the best, but it seems that to build a advanced rendering wich simply provide the best vertex system, bump mapping + shadows, DX9 will be faster and easier than OGL.
Isn’t it ?
Gaby
An interesting reply. I think we can all have a grown up debate about this, even though in the past this subject has always sparked a religious war.
Another aspect of this that is not mentioned is the fact that without the gl icd being updated by Microsoft, OpenGL 2 will just be extensions in any case. I don’t like using extensions particularly, they feel like hacks (I don’t know why, they just do) - I always feel I have to write a fallback just in case the extension isn’t present.
I have used both APIs intensively over the last couple of years. For me, OpenGL was and is always first choice when it comes to writing a quick demo, because it is easier to set up things and also somewhat easier to remember most of the function names and enumeration names.
Also I hated all DX versions before 8.0. I didn’t really like the design that much. But with 8.0 and especially now with 9.0 my opinion has changed. D3D’s object-oriented design with version 9.0 is really quite nice, I must say. And the D3DX library is a very useful lib for which OpenGL has no equivalent.
Other plus points for D3D are render-to-texture (one line of code that says SetRenderTarget as opposed to about 100 lines of code in OpenGL to setup a pbuffer, render to it, bind it…) and vertex buffers.
So if I had to make a product that is definitely only ever going to run on Windows, I’d use D3D nowadays.
I’m currently working on a platform- and API-independent engine http://xengine.sourceforge.net and it has renderer libraries for OpenGL 1.3 and Direct3D 8.1. They both do exactly the same, but the Direct3D renderer has about half the lines of code. Also it took me about a week to develop the Direct3D renderer as opposed to about a month for the OpenGL renderer where I had some troubles getting render-to-texture up and running.
During the development of the engine I encountered about 20 driver bugs (both NVIDIA and ATI). Only 2 of them were bugs in the Direct3D drivers, the rest in the OpenGL drivers. Admittedly that doesn’t say very much, since OpenGL is more actively developed by the companies with new extensions and all that.
Still I like OpenGL a lot and hope it gets a more object-oriented design with version 2.0. So far I like the drafts for OpenGL 2.0 a lot. But I also like D3D 
Just use whatever is most convenient for you at the time. The OpenGL API won’t be mad at you for not using it for a project or two. The reason so many people are torn over this issue is because there is very little difference in actual output. The only difference has to do with how the API calls are made, but the results are indistinguishible.
When it comes down to it, the MAJORITY of code in a big appication will not be making API calls. It will be performing the logic and performing its purpose. This is the real meat of the project, this is the part that will show your medal.
NitroSR: I think you mean “mettle” 
Asgard: One of the things I dislike most about D3D is its object-oriented structure. I find it generally easier to read code that is along the lines of “function(data)” than it is to read code like “data->function()”, especially if “data” is a non-trivial expression.
woah, 28 posts already ! 
Robbo> Canst Thou teach me, Ô Great Troll Master ? \o/
Julien.
Originally posted by Coriolis:
Asgard: One of the things I dislike most about D3D is its object-oriented structure. I find it generally easier to read code that is along the lines of “function(data)” than it is to read code like “data->function()”, especially if “data” is a non-trivial expression.
You’re not a fan of C++ then?
knackered:
I’m a big fan of C++. I like it a lot better than C. I think the problem is that most people confuse C++ with classes.
I use templates when appropriate, and constructors / destructors are quite useful for getting stuff to always happen when you leave a function. The inline options it gives are very nice. It is convenient to be able to make vectors into a class and do normal math on them. Inheritance (if used properly) is convenient.
However, I am not a fan of rampant C++, for lack of a better term. C++ has a nasty way of hiding what is really happening. I really dislike default arguments for this reason. Operator and function overloading are also obfuscatory, though frequently convenient.
Overly object-oriented C++ also has a way of making functions go into source files based on what data they manipulate rather than based on what function they perform, which tends to distribute related functionality and group unrelated functionality.
I like classes for game code, but not much else. Classes are not really useful for rendering or physics, and tend to be horrible offendors at spreading related code into many files according to the data that gets operated on instead of the functionality being done.
Originally posted by knackered:
Hey, it’s quite possible to support both, y’know. It’s a little tricky at first, but once you know both API’s then writing an abstract renderer interface is quite straightforward - you really should be doing this anyway (saves you rewriting stuff)…you have to track render states don’t you? You have to do this no matter which API you use, so put a nice layer between you and the rendering api to keep things tidy. Clever use of function pointers will speed things up.
Do you (or anyone else) maintain any kind of short demo with source to illustrate how you abstract away the two implementations behind one interface? Even if it’s just header files, that would be interesting to me to see.
I haven’t ventured into supporting multiple renderers (DirectX) yet, but would like to keep options open certainly. And I also do agree that in principle this layer of abstraction could be a useful thing, even if supporting only one rendering API.
From Mark Kilgard’s OpenGLforNV30 presentation:
OpenGL exposes all NV30 features
Well beyond even what DirectX 9 exposes
So there you go, more features. But that is definitely a double-edge sword and you can cut yourself pretty easy.
I’d target GL1.4/ARB functionality. With that you can do VPs, FPs, cubemaps, texture compression and environment stuff, and pretty soon VAO. You can created an engine with ppl, bumpmaps, and shadows with those extensions. Do skinned meshes on the CPU and you’ll have a hell of an engine.
Then pick and choose other extensions you want your engine to support.
Everything is starting to converge pretty good. And I’ll agree that the extension hell of the past little while was not fun.
Originally posted by Coriolis:
[b]knackered:
I’m a big fan of C++. I like it a lot better than C. I think the problem is that most people confuse C++ with classes.
I use templates when appropriate, and constructors / destructors are quite useful for getting stuff to always happen when you leave a function. The inline options it gives are very nice. It is convenient to be able to make vectors into a class and do normal math on them. Inheritance (if used properly) is convenient.
However, I am not a fan of rampant C++, for lack of a better term. C++ has a nasty way of hiding what is really happening. I really dislike default arguments for this reason. Operator and function overloading are also obfuscatory, though frequently convenient.
Overly object-oriented C++ also has a way of making functions go into source files based on what data they manipulate rather than based on what function they perform, which tends to distribute related functionality and group unrelated functionality.
I like classes for game code, but not much else. Classes are not really useful for rendering or physics, and tend to be horrible offendors at spreading related code into many files according to the data that gets operated on instead of the functionality being done.[/b]
It’s funny that you consider inheritance as merely convenient. Inheritance is simply the point of C++. Why do you like classes? There just structures, so why do you point them out for praise when inheritance is not important to you?
You’re not making sense.
Inheritance is beautiful - get yourself a decent class browser if you suffer from the old complaint of not knowing what functionality a class possesses without knowing its parents.
How would you elegantly implement a scenegraph using C? (have you seen the C version of Performer? It’s horrible).
How could you create an abstracted renderer in C without messy function pointers?
C++ hides things, yes - but if you know C, and you know how C++ implements the things it hides, then you should not worry.
In other words, I think it has a big place in rendering. As for physics, well - ODE (open dynamics engine) is written in C++ (granted it exposes functionality using C interfaces, but that’s just lowering itself to the common denominator).
Anyway, this isn’t a C vs C++ argument, so I’ll leave it now.
Originally posted by PK:
Has the December meeting taken place?
Has anybody any news about that?
Is the ARB_VAO spec finished?
Thanks
knackered: I think you mis-interpreted what I wrote. I don’t like classes and dislike inheritance. I like both of them when used appropriately, but I think that people tend to use them way too often. I used to suffer from the same object-oriented extremism myself. I didn’t say that you can’t use classes with renderers and physics engines, I just said it didn’t seem appropriate to me. I also know that the only difference between a class and a struct in C++ is that one defaults to private members and the other to public.
I don’t buy into the not knowing what functionality a class possesses argument. It seems pretty weak, because the problem can be just as big with knowing what functions you can call on a structure.
I can find the hidden stuff in C++ as well as anybody, it just makes learning code well a whole lot harder and take longer. Even a simple statement like “a = b + c;” can hide about four function calls. C++ tempts you to make everything into operators; I saw one source base that used the bitwise or operator for vector dot products, which makes no sense and has the wrong precedence.
I don’t think I do scene graphs in the generic sense, or at least not anything like the way Eberly describes in his book, which is the only explanation I’ve seen of it. It seems overly complicated for something so simple. I prefer to stick to more basic data structures than to cram everything into a scene graph. I still do heirarchical structures for representing the data I use to draw my scenes, of course, but i don’t think they fit under the moniker “scene graph”, except in the loosest sense of the term. I tend to prefer several simple, obvious, easily debugged data structures that each map well to their specific use rather than a universal data structure that has everything crammed into it. I find scene graphs are nice from a pure computer science standpoint, but end up being less nice from a software engineering standpoint .
I agree.
If everything is considered being an object, and all objects live in a parent object and so on, its confusing. I like to have object-oriented machines living in a procedural world.
fritzlang
PainterB (RE: Could someone show me how to wrap DX and OGL)
No one shoud wrap OGL and DX in a low level interface which is barely more functional than either library alone. That is rather pointless, because it introduces a layer of complexity without adding any functionality.
What you would do is create a higher level interface which does what you need for the game or application you are programming. The functions would look more like ‘Draw(ThisGeometry, ThisStateDescription)’ than like ‘SetStateX();SetStateY();SetState();SetStream();Draw();’
I use the term ‘StateDescription’ instead of ‘Shader’ because I am thinking more in terms of Quake 3’s high level pass and state description language (which it calls shaders), instead of like low level vertex and fragment shaders. A state description language is a lot like CgFX or RenderMonkey.
Your ‘wrapper’ may even be as high level as ‘DrawBSP’ or ‘DrawModel’. It definitely should have far more than 1 or 2 OGL or DX calls per call.
Basically you want to build somthing that is less than a whole graphics engine. I would call it a Renderer. The renderer would be able to read abstract state descriptions and geometry descriptions and then translate these into OpenGL or Direct3D calls. It would do cacheing and redundant state checking.
Even if you only used one API, it would still be worth it to abstract OpenGL or DirectX out of your engine code this way. Good for OpenGL so you can support future extensions, good for D3D because of future versions.
I still do not understand your comment about future maintainers having a problem with this. In this system, all the OpenGL code is in one place, instead of scattered throughout the engine.
It just makes sense to seperate out low level OpenGL calls from the higher level graphics code. (e.g., what does visibility determination have to do with OpenGL?)
Inheritence is ONE of the points of C++, the other big one is encapsulation of data with methods, the other reason for liking classes. Abstraction features like overloading and virtual functions are also important. Most strong OO proponents make the mistake of thinking one solution fits all problems. Like all things it has it’s place.
[This message has been edited by dorbie (edited 12-11-2002).]
C++ is philosophically agnostic. Pick your idiom: functional, procedural, object-oriented, generic. Pick your tool: functors, structs, classes, inheritence, polymorphism, templates, exceptions. TMTOWTDI. And you don’t take a performance hit for the features that you don’t use. That’s the thought process when C++ was designed.
It is a huge language and you don’t have to use all of it. This becomes even more evident when the creator of C++ doesn’t consider himself an expert.
Now back to my original question about this months ARB meeting. Any word on VAR???