High-language-level SDK layer

It seems the ARB/Khronos is going to sepparate the core layer and the application layer and blah blah and to make an official OpenSDK with docs, examples, etc etc etc

My question and suggestion is to include into that C++, C#/VB/J#/IronPhyton/RubyNET, Java and D wrappers. Of course, the current C implementation should persist because most of the parts in the OS are written in asm and C… and well some people still works with C. No problem with that.

Currently, I can pass a GL_CUBEMAP_FACE_POSITIVE_X to, for example, glHint. That is because C is not enough “strong typed”. If you see at DX10, when you render to a cubemap yoou need to use a IDirect3DCubeTexture and a eCUBE_FACE. If you try to pass a “0xBC16” to that the compiler will complain because is “strong typed”.
Also, if you see at the current gl.h/glext.h is a monstruous file with tons of “0xBAAD” things, too much integer types that you can easy mistake, etc… Some OOP job will rock there.

If you see at Managed DirectX, XNA, etc, Microsoft did that for DirectX. Extrapolating that will be good to see a D3DX OpenGL library, highlevel OOP interfaces, etc… In general more OOP in OGL will be good.

The question is if Khronos is the one that should do that or we could live using 3rd party wrappers like Tao, JavaGL, etc…Well I think an official SDK should include this in the same manner Microsoft does with MDX, XNA and the DirectX SDK which include .NET wrappers, C/C++ and COM interfaces.

Btw… it appears there is not much information about what the Khronos SDK will include and the new OGL application layer… anybody have more information that could share pls? All I see is some abstract specs at Khronos, and the EGL Native platform… no track of the promised SDK.

thx

If you try to pass a “0xBC16” to that the compiler will complain because is “strong typed”.
What C++ are you using?

Enums aren’t typed well enough to do that. The compiler does not check to see if the number you pass is an actual enumerant of that enum type.

Originally posted by Korval:
What C++ are you using?

Enums aren’t typed well enough to do that. The compiler does not check to see if the number you pass is an actual enumerant of that enum type.
Using Visual Studio 2005 SP1 Orcas Dec2006 Ed and GNU g++ 4.1.1 complains(good) if you do this:

class OGLDevice
{
public:
   enum eCUBE_FACE
   { 
      CUBE_FACE_POSITIVE_X = 0,
      CUBE_FACE_NEGATIVE_X,
      CUBE_FACE_POSITIVE_Y,
      CUBE_FACE_NEGATIVE_Y,
      CUBE_FACE_POSITIVE_Z,
      CUBE_FACE_NEGATIVE_Z
   };

   void SetCubeFace ( const eCUBE_FACE face )
   {
	   m_iFoo = 2;
   }

protected:
	int m_iFoo;
};

void main ()
{
	OGLDevice *l_pOGLDev = new OGLDevice();
	l_pOGLDev->SetCubeFace(3); //error C2664
        l_pOGLDev->SetCubeFace(0xBC16); //error C2664
        l_pOGLDev->SetCubeFace(OGLDevice::CUBE_FACE_POSITIVE_Y); //correct
}

error C2664: 'OGLDevice::SetCubeFace' : cannot convert parameter 1 from 'int' to 'const OGLDevice::eCUBE_FACE'
        Conversion to enumeration type requires an explicit cast (static_cast, C-style cast or function-style cast)

On the other hand, using the existing C headers:

#include <GL/gl.h>
#include <GL/glext.h>

void main ()
{
	glEnable(GL_ALPHA_TEST);
        glEnable(GL_TEXTURE_CUBE_MAP_POSITIVE_X);//no error/warning because is a GLenum so is valid... compiled ok introducing a potential leak or bug
}

See how C++ ( and any strong typed OOP language, C# and D can be even better ) protected us against this situation.

That’s why I think we need an IVertexBuffer(as virtual abstract class), some design patterns(iterators, factories, blah blah) and some OOP, etc and try to avoid enums or GLint/GLenum/GLxxx as function parameters.

For example:

glEnable(GL_ALPHA_TEST);//I could pass here GL_CUBEFACE_POSITIVE_X which is a GLenum too and the compiler won't complain

m_pGLDev->EnableAlphaTest(true);//better

Santy, whatever it is you’re smoking, I could sure use some of it about now :slight_smile:

Actually I spent a good chunk of time on my own C# wrapper for GL and it’s pretty darn nifty if I do say so myself… slapping all the enums into tidy enum bins and so on… nice and neat. I wrap up my DX stuff too, so it’s no biggie to have to do it for GL, but that’s me. However, I certainly wouldn’t object to someone doing it for me… you know, if it worked out that way.

Man, I need a new drug :frowning:

I have to back santyhammer on the strongly typed enums. If you reference the enum type directly, the compiler will check that the value is in the enum definition. Enums will convert to ints, but ints won’t convert to enums. I wrote a similar OO layer on top of GL and have been very happy with the new semantics. It pays for itself very quickly.

Originally posted by Leghorn:
However, I certainly wouldn’t object to someone doing it for me… you know, if it worked out that way.

Yep, I did a 200k-lines C# wrapper too some time ago :frowning: Then Tao appeared!

Well… perhaps you could donate yours to Khronos or perhaps they could be interested in hire you for that task… All I know is that the gl.h/glext.h header is a mess actually and could use some fixes and conversions to modern languages and OOP.

But what’s C headers got to do with GL? What about all the other language bindings? How are you going to enforce such things among myriad languages? Hmmm?

Come on, santy… pass the bong :wink:

P.S. I saw Tao, but that was stuck in like NET 1.1 land last I checked, and it seemed just a bit chunky for my needs. Though it looks like a nice framework, to be sure.

P.P.S You really think the gl headers are a mess?

C / C++ languages are generally not that strong-typed and neither should be their API’s / libraries. For example:
glActiveTexture(GL_TEXTURE0 + i);
With strong types you would have to add type cast here and that wouldn’t be pretty :slight_smile:

If you want OO why not just use a scene graph?

As well as an OO wrapper to OpenGL state and geometry you also get lots of other things like culling, state sorting, threading, database reading/writing, database paging, and they even come as open source so it can be free to use to boot.

Robert.

Originally posted by k_szczech:
C / C++ languages are generally not that strong-typed and neither should be their API’s / libraries. For example:
glActiveTexture(GL_TEXTURE0 + i);
With strong types you would have to add type cast here and that wouldn’t be pretty :slight_smile:
That C horrible and ugly expression could be translated as:

Originally posted by Robert Osfield:
If you want OO why not just use a scene graph?
Nah, too much work. By the moment I just need some better organization and some modern OOP for the basic GL headers and the extension ones.

If you want to include a small scenegraph in the official SDK will be welcome but I won’t use it because I prefer to do myself ( I love my own portal system, PVS, custom exporters, etc )

Originally posted by Leghorn:
What about all the other language bindings? How are you going to enforce such things among myriad languages? Hmmm?

Not a myriad really. We need only “unmanaged” C++, a managed C++(which can be shared and used by MC++, C#, VB.NET, J#, IronPhyton, RubyNET due to IJW magic) and Java one. So, with three the 90% of the most used languages will be covered initially.
Notice Microsoft has four wrappers running around DirectX (ManagedDX for .NET, XNA Framework for pc/360, C/C++ DirectX and COM/TLB bindings for VC6).

People with wrappers already done like Tao should just email Khronos an offer it and your services. Perhaps you can get $$$ for them so they could save TONS of work in the SDK and will be very nice for the comunity. Khronos should give us some sign of live about the SDK, is too quiet.

Originally posted by santyhammer:
[b] [quote]Originally posted by Leghorn:
What about all the other language bindings? How are you going to enforce such things among myriad languages? Hmmm?

Not a myriad really. We need only “unmanaged” C++, a managed C++(which can be shared and used by MC++, C#, VB.NET, J#, IronPhyton, RubyNET due to IJW magic) and Java one. So, with three the 90% of the most used languages will be covered initially.
Notice Microsoft has four wrappers running around DirectX (ManagedDX for .NET, XNA Framework for pc/360, C/C++ DirectX and COM/TLB bindings for VC6).[/b][/QUOTE]And for those using something other than Windows?

And for those using something other than Windows?
Yeah, they have this thing called Mono for those Windows-challenged persons who still want to use the future (aka, .NET).

For people using .Net languages, Tao 2.0 RC1 will be released on Monday 29th. OpenGL bindings have been updated to version 2.1, while Tao now relies on .Net 2.0 and Mono 1.2 (Linux, MacOSX and Windows compatible). More information: http://www.taoframework.com/forum/index.php?topic=491.0

Moreover, I have been experimenting with OpenTK ( http://sourceforge.net/projects/opentk ) to create a managed OpenGL wrapper for .Net languages. Right now, OpenTK provides cross-platform OpenGL context handling, clean low-level OpenGL bindings and a simple application framework. However, the project sorely needs developers to help with the higher-level (object oriented ) OpenGL syntax, the framework, and math / input and timing modules. (If someone is interested to help, please contact: stapostol at gmail dot com with “OpenTK” in the subject line, or post at the forums http://opentk.sourceforge.net )

People with wrappers already done like Tao should just email Khronos an offer it and your services.
Now, this is a very good idea. I’ll try and see if there is a reply.