Opengl -> Opengl Es Wrapper Library

[EdCa22]

I have to admit I've not done any OpenGL programming, but from what I hear ES is pretty similar to OGL, the main difference being that some deprecated bits are removed. Is it similar enough that most of the functions/classes are basically the same? If so could we not write a wrapper that just swaps takes the OGL calls and calls the ES equivalents? You wouldn't even need to implement missing functionality as long as whatever you were trying to compile didn't make use of the deprecated parts, right? And if it's written properly it shouldn't make use of those parts, from what I hear, though I guess implementing the missing stuff would be a later priority. This would make it very easy to port OGL applications.

Maybe I haven't realised how different they are and this is a silly question, if so just tell me, but...

thoughts? volunteers?

 

[Pickle]

I have to admit I've not done any OpenGL programming, but from what I hear ES is pretty similar to OGL, the main difference being that some deprecated bits are removed. Is it similar enough that most of the functions/classes are basically the same? If so could we not write a wrapper that just swaps takes the OGL calls and calls the ES equivalents? You wouldn't even need to implement missing functionality as long as whatever you were trying to compile didn't make use of the deprecated parts, right? And if it's written properly it shouldn't make use of those parts, from what I hear, though I guess implementing the missing stuff would be a later priority. This would make it very easy to port OGL applications.

Maybe I haven't realised how different they are and this is a silly question, if so just tell me, but...

thoughts? volunteers?

probally in up in toe much overhead to be worth it, although i dont consider myself an expert in the opengl api.
but this has been done the other way round, the windows development kit uses sw in between the opengl es app and the normal opengl hw. But es is really a subset of ogl.

 

[darkblu]

the way i see things, it'd make sense for (a) implementing missing gl functionality for gl ports, and (b ) getting pre-compiled, es-friendly gl apps to run without recompilation, i.e. gl emulation.

now, re (b ) - i don't think pandora is too mature a platform to have many binary-only gl apps to warrant the effort.

as re (a) - it can be quite a daunting task. but it could be interesting nevertheless.

 

[Adventus]

http://opensource.dylogic.com/DOGLESS/Articles/About.html

Translates OpenGL calls to OpenGL ES 1.1 in realtime. Its complete enough to run quakeI/II, however much of the functionality is still missing. Would probably be a good starting point.

Display lists would probably the hardest (and most commonly used) feature to implement.

 

[mali]

Maybe if Maciek &Co succeed with reverse engineering SGX , somebody could write a full featured Opengl driver some day.

 

[maciek_urbanski]

I have to admit I've not done any OpenGL programming, but from what I hear ES is pretty similar to OGL, the main difference being that some deprecated bits are removed. Is it similar enough that most of the functions/classes are basically the same?

Yes it's similar. In many ways way better, in fact. OpenGL is a very old API and drags a big burden of ancient calls. Those calls are 'easy' and 'straightforward' way do start drawing something on the screen, but they are very slow and there is lots of them. Both are burden to driver developer and results in general low performance of OpenGL applications using those legacy calls (immediate mode being prime example).

If so could we not write a wrapper that just swaps takes the OGL calls and calls the ES equivalents?

Yup, it possible but it's a lot of work, because you need to implement entire legacy state processor. For emulation it makes sense, but for new projects I'd strongly advise against it. I don't want to start flame war, but OpenGL ES is significantly more elegant than OpenGL itself. The 'missing calls' should not be missed too much...

You wouldn't even need to implement missing functionality as long as whatever you were trying to compile didn't make use of the deprecated parts, right? And if it's written properly it shouldn't make use of those parts, from what I hear, though I guess implementing the missing stuff would be a later priority.

If nobody calls it - it may be empty function. But sadly, regardless of what 'should be' - most folks use those legacy functions in some non-mission-critical parts of code, so you'd just end up implementing them anyway...

his would make it very easy to port OGL applications.

I suggest alternative route. When porting we have sources to application, so we can/should change application itself. Using OGL ES instead OGL_via_emulation + OGL ES would be significantly faster (fps-wise) IMHO.

Maybe I haven't realised how different they are and this is a silly question, if so just tell me, but...

This is not a silly question.

 

[EdCa22]

If so could we not write a wrapper that just swaps takes the OGL calls and calls the ES equivalents?

Yup, it possible but it's a lot of work, because you need to implement entire legacy state processor. For emulation it makes sense, but for new projects I'd strongly advise against it. I don't want to start flame war, but OpenGL ES is significantly more elegant than OpenGL itself. The 'missing calls' should not be missed too much...

Is the state processor etc needed for the ancient calls or just for newer code? I was definently not suggesting this as a way forward for new applications...but I thought it would make many applications much, much easier to port (basically just recompile). BTW, I wasn't suggesting a real-time conversion of the API functions...so I don't think it would be useful for emulators would it? Or I suppose it might...I guess I don't know enough about emulators yet...I always assumed they just converted machine code into another machine code but it seems that they actually often intercept non-native API calls as well and implement those a bit like WINE, which makes sense, and then you would need to compile into the emulator some way to carry out OGL functions...but I'm still a bit confused about the mechanisms. Need to get my hands dirty with emulators at some point...

If nobody calls it - it may be empty function. But sadly, regardless of what 'should be' - most folks use those legacy functions in some non-mission-critical parts of code, so you'd just end up implementing them anyway...

I guess that the majority of applications will not compile without implementing the whole API then...sigh..

I suggest alternative route. When porting we have sources to application, so we can/should change application itself. Using OGL ES instead OGL_via_emulation + OGL ES would be significantly faster (fps-wise) IMHO.

I suppose it was mostly laziness talking...just trying to think of the quickest way to get software ported on to the Pandora...I feel that having some decent native games and easy access to them is going to be the deciding factor as to whether the Pandora is a success or not in the long run...for the second batch people will really pay attention to this and I don't know how many high quality homebrew projects will be ready by then.

This is not a silly question.

That's good then

 

[DesktopMan]

Nobody argues that using OpenGL ES for new projects is a bad idea. However, as we've seen all over these forums, actual original new content will be rare. A lot of potential ports would run *well enough* with a wrapper, which is why it makes sense.

 

[maciek_urbanski]

Nobody argues that using OpenGL ES for new projects is a bad idea. However, as we've seen all over these forums, actual original new content will be rare. A lot of potential ports would run *well enough* with a wrapper, which is why it makes sense.

Don't misunderstood me - I will applaud anyone who will undertake task of writing OGL -> OGL ES translator/wrapper. I'm only saying that its lots of code, and performance may be sub-par for some ports.
Then again, you're right - for some other ports it will be enough.

I'm more focussed on creating new games for Pandora, so for me it's not worth the effort.
But from 'fast porting' standpoint - it's a great idea.

 

[Svartalf]

Is the state processor etc needed for the ancient calls or just for newer code? I was definently not suggesting this as a way forward for new applications...but I thought it would make many applications much, much easier to port (basically just recompile). BTW, I wasn't suggesting a real-time conversion of the API functions...so I don't think it would be useful for emulators would it? Or I suppose it might...I guess I don't know enough about emulators yet...I always assumed they just converted machine code into another machine code but it seems that they actually often intercept non-native API calls as well and implement those a bit like WINE, which makes sense, and then you would need to compile into the emulator some way to carry out OGL functions...but I'm still a bit confused about the mechanisms. Need to get my hands dirty with emulators at some point...

It's needed for the legacy crap (Which the bulk of the stuff you're talking about really is...). DOGLESS had to provide a state machine around the whole ES thing that did the "right" things when it was legacy, didn't break the ES state machine behavior and properly punted things to the other state machine. Moreover, the bulk of the code in games is going to BE ES 1.1 or ES 2.0 code in the first place. They stripped out the "missing" stuff for a reason...

QUOTE

I guess that the majority of applications will not compile without implementing the whole API then...sigh..



Again, why worry about it. An application that's not doing stupid things (How do you think they got Quake3 Arena ON the OMAP dev boards, hm?) will largely move over with no major changes needed.

QUOTE

I suppose it was mostly laziness talking...just trying to think of the quickest way to get software ported on to the Pandora...I feel that having some decent native games and easy access to them is going to be the deciding factor as to whether the Pandora is a success or not in the long run...for the second batch people will really pay attention to this and I don't know how many high quality homebrew projects will be ready by then.



Heh... The "quickest" way is often NOT the best way. How many WINE/Winelib titles are sold? How many have "issues"? "Few" and "most of them" would be the answers to those questions. Don't be taking shortcuts. I know I won't with the titles I'm going to be off a porting. (By the by... I hope to have something shortly in that vein... Maybe as a "dev demo" if I and we're lucky... )

 

[ldesnogu]

Again, why worry about it. An application that's not doing stupid things (How do you think they got Quake3 Arena ON the OMAP dev boards, hm?) will largely move over with no major changes needed.

I didn't know Q3 had been demonstrated on OMAP dev boards running Linux and OpenGL ES. The only port I know is for Windows CE and ES 1.1 and it's certainly awful.

 

[Svartalf]

I didn't know Q3 had been demonstrated on OMAP dev boards running Linux and OpenGL ES. The only port I know is for Windows CE and ES 1.1 and it's certainly awful.

If it's ES, it doesn't really matter what OS- part of the beauty of ES' interfaces. You have the same code work on any OS platform (as far as the Graphics are concerned...) you have the same hardware profile supported.

It was my understanding that they'd demoed it on an OMAP board- I could be wrong on that score, though. The main reason I understand that the current version that people have seen was awful was more because it was crippled down to fit into the system footprint of the WinCE machines it was being ran on- not that it's an ES 1.1 version... We're not going to need to lower texture sizes now...

 

[JayFoxRox]

Yeh, they had a video of Quake 2 on the devboard - not Quake 3.

Without reading the other posts: A wrapper makes alot of sense to me, but most developers will work their own framework so it can be optimized a bit more. I m not sure if its worth the trouble to write a wrapper only to be used in a few ports.

 

[Creature XL]

Yup, it possible but it's a lot of work, because you need to implement entire legacy state processor. For emulation it makes sense, but for new projects I'd strongly advise against it. I don't want to start flame war, but OpenGL ES is significantly more elegant than OpenGL itself. The 'missing calls' should not be missed too much...

Correct. That is why it is DEPRICATED in OpenGL 3.0 and will be dropped in future updates to the API

 

[ldesnogu]

The main reason I understand that the current version that people have seen was awful was more because it was crippled down to fit into the system footprint of the WinCE machines it was being ran on- not that it's an ES 1.1 version...

The "awful" was referring to how it was done, patch-wise. I get angry when people start renaming C files as if they were C++; at that point I stop looking at files :lol:

Correct. That is why OpenGL 3.0 got rid of the old stuff aswell.

My understanding is that that "old stuff" is only deprecated in 3.0. Did I get it wrong?

 

[greasy]

Here's a similar wrapper a guy is (or was) working on for Maemo.

http://www.unrealvoodoo.org/hiteck/projects/maemo

Scroll down and look for "glesport."

 

[darkblu]

My understanding is that that "old stuff" is only deprecated in 3.0. Did I get it wrong?

nope.

 

[TheGoodDoktor]

The project I'm working on has GL & ES versions. Since I wrote the GL code I was very careful not to use any stuff that you couldn't do in ES (glBegin & glEnd and mapping vertex buffer object memory).
All the other stuff I manage to cover simply by using #defines.

I did a few things like this:
#ifdef _VERSION_GL_
#define CreateVertexBuffers(nobuf, bufptr) glGenBuffersARB(nobuf, bufptr)
#define DeleteVertexBuffers(nobuf, bufptr) glDeleteBuffersARB(nobuf, bufptr)
#endif

#ifdef _VERSION_GLES_
#define CreateVertexBuffers(nobuf, bufptr) glGenBuffers(nobuf, bufptr)
#define DeleteVertexBuffers(nobuf, bufptr) glDeleteBuffers(nobuf, bufptr)
#endif

and also like this:

#ifdef _VERSION_GLES_
#define glOrtho glOrthof
#define glDepthRange glDepthRangef
#define glFrustum glFrustumf
#endif

Although my project isn't finished I did manage to get both versions working with minimal GL code changes.
I had more trouble jamming in the EGL stuff (I was using SDL & GL on the GL version)
The main problem I'm having is converting all my texture data to PVRTC but that's another story for another day.

Cheers,
TheGoodDoktor

 

[Svartalf]

Here's a similar wrapper a guy is (or was) working on for Maemo.

http://www.unrealvoodoo.org/hiteck/projects/maemo

Scroll down and look for "glesport."


OUCH. That's a LOT of effort to avoid doing largely simple stuff like TheGoodDoktor has indicated.
It'll work, yes. Work "okay" at best. But you're adding an additional API with even MORE complexity and duplicated code ON TOP of the ES layer you're ultimately going to.

WHY do that to yourself? Serously. (Especially in light of people griping about SDL and this and that and then going to the metal on this forum... )

 

[darkblu]

OUCH. That's a LOT of effort to avoid doing largely simple stuff like TheGoodDoktor has indicated.
It'll work, yes. Work "okay" at best. But you're adding an additional API with even MORE complexity and duplicated code ON TOP of the ES layer you're ultimately going to.

WHY do that to yourself? Serously. (Especially in light of people griping about SDL and this and that and then going to the metal on this forum... )

not speaking on behalf of the people behind glesport, my simple answer would be:

convenience and/or automation.

if i want to quickly check gl stuff on an es platform, material from the 'what if' domain, i'd rather have a quick-n-dirty way than the 'proper' approach. and in general, i'm a strong proponent of the evolutionary approach in app development - don't over-engineer your transient stuff. better hack together 5 versions and choose the best, and only *then* do it properly, than properly design 1 version from the start and eventually discover it's not what you want.

anyway, many well written* gl apps would map more or less 1:1 to the underlying es.

* and yet, even an exemplary lean-n-mean gl app may face serious obstacles - all it takes is for it to be mixed fixed-pipe/shaders-pipe and voila - you'll need considerable rewrite just to get that app up on any es2 platform.