Jump to content
  • Advertisement
Sign in to follow this  
anist

OpenGL so where's all this going? (OpenGL)

This topic is 4835 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

just would like to hear some of the views on where OpenGL is heading. no sooner than we had celebrated the release of the 2.0 standard, the "Great Vista Freakout of 05" hit and all our thunder was stolen in the face of "50% slower" quotes from slashdot twerps. now that things have settled down, and the cooler heads are pointing towards MS's history of offering lackluster support, i feel a deeper rumbling. while C++ will be around for quite some time, i feel C is moving towards the lowel levels that were once reserved for assembly (look at shaders). the thing is that OpenGL is low level, and C style. it is not object oriented. the new languages (Java, C#, VB.NET) don't work comfortably with it. unlike python, and even VB 6.0, there is no direct support for these. secondary wrapper libraries are the best that Java and C# can offer. whereas the .NET languages get a shiny new wrapper for Direct3D. this may seem like a small issue, but in the professional world where support for libraries used in a product come into play when picking technologies, it may mean everything. in fact, it has been OpenGL's bread and butter for many years. i am biased to liking OpenGL, and could care less about moving to .NET. i do however wonder if its on the sturdy ground it has been on. can it survive while OO langauges lack support? if so, will c++ be enough to keep it going? is a GDI+ or STL type standard unthinkable?

Share this post


Link to post
Share on other sites
Advertisement
You realize it isn't all that difficult to make a OO wrapper around OpenGL, right? Anyway, OpenGL also has literally no competition for hardware-accelerated 3D cross-platform development, so it'll probably stay around for a while there.

Share this post


Link to post
Share on other sites
Quote:
Original post by Roboguy
You realize it isn't all that difficult to make a OO wrapper around OpenGL, right? Anyway, OpenGL also has literally no competition for hardware-accelerated 3D cross-platform development, so it'll probably stay around for a while there.


no, that one blew past me. but seriously, i mean a standard wrapper. are we ever going beyond a C style standard and if not will it cost OpenGL?

Share this post


Link to post
Share on other sites
personally, i think the rigid use of OO in Java (and others) is plain silly. there are things were OO makes sense, but others don't really fit the paradigm and things only become more complicated by forcing it's use. i think opengl should stick with the C-style api, even if only for compatibility reasons. maybe an aditional standardized wrapper, but that might be hard to define due to differences between languages. besides, as Roboguy said, writing a wrapper isn't that difficult, and there already are wrappers for the languages you mentioned. (albeit not standardized)

Share this post


Link to post
Share on other sites
In any serious project there will be at least one level of abstraction between the graphics API calls and scene management, so there's no real need for a natively OO design. Frankly, in my experience it's a little easier to wrap OpenGL into an OO framework than it is to wrap D3D into an OO framework since you don't have to worry about keeping COM's reference counts happy. But that's a minor difference; this whole thing is pretty much a non-issue.

Share this post


Link to post
Share on other sites
It doesn't really make much sense to abstract something as low level as a 3D API into some object structure or hierarchy. Sure, an object oriented resource manager (for texture, shaders, etc) is useful, but many will argue that this is the job of the engine, and not of the API. Yeah, OpenGL is low level, but so is D3D. That's the very nature of the thin layer between GPU and application that current 3D APIs are.

If we're talking about graphics engines, then things look very different. A heavily object oriented approach is a good choice on that level, and perfectly well suited for such an application. But it really doesn't matter whether the underlaying API is OOP or not, since its calls are going to be deeply buried into the engine internals anyway.

OOP is great for high level abstraction. But on a 3D API, it's just semantics without any real advantage or drawback. It really doesn't matter.

Edit: well, Sneftel was faster :)

Share this post


Link to post
Share on other sites
I agree with the mods, but on the other hand it would be nice to have some standardized OO management stuff in an add-on library rather than everyone having to roll their own and worrying about bugs / supporting anyone else who may end up using it.

That said, I doubt the OpenGL ARB will take it upon themselves to begin such an undertaking. In the world of OSS, things like that are generally accomplished by an individual or group beginning a project, this project reaches maturity and gains popularity, and then finally (if its deemed worthy) is addopted by the 'parent' project or otherwise officially/unnofficially recognized.

If you want to see this, find some like-minded and intelegent people to get together and start it yourself.

Share this post


Link to post
Share on other sites
Quote:
Original post by Ravyne
I agree with the mods, but on the other hand it would be nice to have some standardized OO management stuff in an add-on library rather than everyone having to roll their own and worrying about bugs / supporting anyone else who may end up using it.


I would not like to see that I really like having a "thin" layer to interface with the graphics card. This allows the fastest results and leaves the OO design in the hands of programmer. After years of designing my own management, I would feel really restricted moving to a force OO design of some one else’s planning.

OpenGL is fine, and going to stay.

Share this post


Link to post
Share on other sites
Quote:
Original post by skow
Quote:
Original post by Ravyne
I agree with the mods, but on the other hand it would be nice to have some standardized OO management stuff in an add-on library rather than everyone having to roll their own and worrying about bugs / supporting anyone else who may end up using it.


I would not like to see that I really like having a "thin" layer to interface with the graphics card. This allows the fastest results and leaves the OO design in the hands of programmer. After years of designing my own management, I would feel really restricted moving to a force OO design of some one else’s planning.

OpenGL is fine, and going to stay.


Thats why I said an "add on" library, similar to GLUT or GLX, "official", standardized, but not strictly necessary. Something that people can learn and use if they don't want to be bothered writting their own to get things up more quickly.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!