An OGL coder's mullings on D3D

Started by
10 comments, last by OrangyTang 16 years, 11 months ago
I've been programming in OGL for the last 4 or so years. My reason for this is that I much prefer doing cross platform work, and I use Ubuntu for my day-to-day stuff including development. Well a few days ago, while my Ubuntu box was still in the process of being shipped home from school, I decided to learn some D3D stuff. I was really impressed actually. The only thing I didn't like was the window initialization, but I got around that by using SDL. I like its object model a lot more, and it is far more OO than OGL. D3DX was also really nice. So, overall I was quite impressed. My major issue is that it is windows only. Windows only software is something I very much despise writing. So I came up with an interesting idea. What if a new D3D-like, cross-platform API were written? Nothing fancy of course. Lightweight, minimalistic, object-oriented, etc... Such a thing would bring 3d graphics on non-windows platforms more up to speed with D3D. It would make porting easier too. Thoughts?
Advertisement

Aside from the open question if there'd be any market for the more commercially oriented D3D apps/games on non-windows platforms ('free' software and all that), I always thought Wine (and another package I can't recall right now) was actually doing a pretty good job of emulating D3D on *nix architectures. There's also the XNA for Mono initiative that aims to do something similar, which may be better suited for the casual/non-commercial 3D developer, who I think would typically use a cross-platform API like this.

Sorry if I don't seem too enthousiastic, but these are my thoughts :)
Rim van Wersch [ MDXInfo ] [ XNAInfo ] [ YouTube ] - Do yourself a favor and bookmark this excellent free online D3D/shader book!
OOOGL? Kind of wondering why it's not around yet. I know there are "OO" wrappers like JOGL, but gl.glBegin can hardly be called real OO.

I should note, however, that almost everything I have done in OpenGL starts with an OO interface that we code ourselves.
The reason there is no object oriented OpenGL is because OpenGL is written in C, not C++. The former is not object oriented, but the latter is. Not saying that it wouldn't be cool, just pointing out a fact.
Quote:Original post by esrix
The reason there is no object oriented OpenGL is because OpenGL is written in C, not C++. The former is not object oriented, but the latter is. Not saying that it wouldn't be cool, just pointing out a fact.


One can write object-oriented libraries and software in C as well. The problem with OpenGL was that it was designed to be mostyl procedural, not object-oriented (although it does contain some object-oriented elements as well, display lists for example).

And, sadly, there are very few ways in which OpenGL can be turned into (or wrapped by) an object-oriented system and that I would deem useful (RAII handling, mostly).
Quote:Original post by ToohrVyk
One can write object-oriented libraries and software in C as well.
Just to bonk again on it, first C++ compilers where actually layered on top of C. OO is a paradigm which can be implemented even in ASM (in fact, overriding is a low-level pointer hack).

I see little difference between
this->Func();

and
Func(this)


I bet many originally dismissed OO as "syntactic sugar".

As for the thread itself, I would like to note that they're called "texture objects" for something. ;-)

Previously "Krohm"

Quote:Original post by Erkokite
So I came up with an interesting idea. What if a new D3D-like, cross-platform API were written? Nothing fancy of course. Lightweight, minimalistic, object-oriented, etc... Such a thing would bring 3d graphics on non-windows platforms more up to speed with D3D. It would make porting easier too. Thoughts?

I think libwine has a DirectX wrapper. If it does, you can improve it or fork it rather than starting from scratch.

Quote:Original post by Erkokite
What if a new D3D-like, cross-platform API were written? Nothing fancy of course. Lightweight, minimalistic, object-oriented, etc... Such a thing would bring 3d graphics on non-windows platforms more up to speed with D3D. It would make porting easier too. Thoughts?


Have you looked at the plans for OpenGL Longs Peak? (which is due for release in spec form at least in June).

It's 'light weight' in that the API is a thin layer over the hardware, matching it much more closely than the evolved and built upon system which exists in GL2.0.

It uses alot more 'objects' in the sense that everything is an object and you act on them, so function become func(obj, params) instead of 'bind(obj); func(params);' as thngs are now.

It will also brings OGL up to par with D3D10 API cleaness wise (although it'll lack a number of D3D10 specifics as Longs Peak is aimed at 'current' hardware, Mt Evans which will follow a few months after and will be targeted at D3D10 hardware), indeed in some cases it could be argued it's better (for example one API call to bind a 'vertex array object' which sets up all the buffers and their associated vertex format, as apose to all the calls GL2.0 currently requires and then, admitly few, that D3D10 needs).

Quote:It uses alot more 'objects' in the sense that everything is an object and you act on them, so function become func(obj, params) instead of 'bind(obj); func(params);' as thngs are now.


Just curious, wouldn't you prefer obj.func(params) instead (where appropriate of course)? Coming from a Java background, I like how this is done in MDX/XNA and to a certain extent in C++ D3D as well with the COM interfaces.
Rim van Wersch [ MDXInfo ] [ XNAInfo ] [ YouTube ] - Do yourself a favor and bookmark this excellent free online D3D/shader book!
Quote:Original post by remigius
Just curious, wouldn't you prefer obj.func(params) instead (where appropriate of course)?

Probably because they'll stick with a C interface for maximum portability, so the first method is the only option.

This topic is closed to new replies.

Advertisement