Sign in to follow this  
Erkokite

An OGL coder's mullings on D3D

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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. ;-)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by phantom
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).


I did know about LP. My main issue is that it probably won't be compatible with older hardware. And besides that, I'm impatient. :)

Judging by the responses here, writing a whole new 3d api as a single coder would be a bad idea, and probably a waste of time.

Share this post


Link to post
Share on other sites
http://www.opengl.org/pipeline/article/vol002_1/

Quote:
OpenGL Longs Peak will be a significant departure for us. While there will still be backwards API compatibility, the new "Lean and Mean" profile, and a substantial refactoring in terms of the new object model, make it in many ways an entirely new API design.

While OpenGL Longs Peak will be implementable on current and last generation hardware, OpenGL Mt. Evans will only be implementable on the newest hardware available.


As I understand it, Longs Peak will be available on older hardware (assuming that the drivers are available).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this