Opengl -> Opengl Es Wrapper Library

[EdCa22]

I am considering taking this up...trouble is, as I said, I've got no GL experience at all, although from what I've seen it's not THAT complex.

As I said before I think the important thing is that the Pandora has lots of native playable games in a few months, not lots of half finished new homebrew games (though I'm really looking forward to seeing what homebrew does come from Pandora ).

There are lots of very high quality open source games around; games like planeshift, lincity-ng, glest, nexuiz, tremulous, spring, supertuxkart, UFOAI, Warzone 2100, Vega Strike, Wormux, Torcs, Sauerbraten, Neverball (would be really nice with an accelerometer), GUSANOS (liero clone), Globulation2....the list goes on...

(I realise not all of those are OGL)

If a list of titles like that was available for the second batch, it's end of problem in terms of people not adopting Pandora because it has amazing hardware but doesn't have the games...and that is what worries me most in terms of making this a real success.

The question is, is this the solution or would efforts be better placed porting each game individually?

 

[Creature XL]

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?

Sorry, I overread it! You are right. However, it will be removed in the next version (that si th eidea behind depricated anyways )

So sorry again. i will edit my previous post.

 

[ldesnogu]

So sorry again. i will edit my previous post.

Heh no problem It looks like that removal generated a lot of discussion in the OpenGL comity and in the community :lol:

 

[Svartalf]

* 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.

And you'll be doing the rewrite work anyhow because this piece will not speed up anything. It'll just be slow because it'll have to do the work of the state engine not once but twice.

By all means, go ahead- but realize you're not the first to attempt this. (Just so you know, there's a GOOD reason why I am not so hot on this idea... I've done OpenGL drivers several times in my long career in the computer field. I'm credited with working with the Utah-GLX driver base (John Carmack's hack to make the RagePRO work without any config was evil, but brilliant all the same...), involved at one point in time with the DRI project, and I've worked as a sustaining engineer for AMD's OpenGL group (I won't discuss the subject of their drivers...bad form... ).) What you're proposing, while it'll work after a fashion, but there will always be some state engine gotchas going from the Mesa one to the ES one. Moreover, you won't be able to actually use the work as much of any basis other than a source for initial ideas as it's designed around the ES 1.1 edge and in order to make it work you'll have to code to the ES 2.0 edge, handling all the fixed functionality being expressed, as fixed functionality shaders provided to the ES 2.0 pipeline, coupled with expressing the typical OpenGL 2.0 functionality as ES 2.0 stuff- just to make it all work the way you envision it.

 

[Lazrhog]

Only took me about 2 weeks to port Neverball to OpenGLES and that uses GTKRadiant for maps, so it really isn't that hard to do. I reckon porting any opengl app is fairly easy to do. I also rewrote Noiz2sa and rRootage in opengles, so porting stuff that just writes to frame buffers is also fairly simple to do. Just wish I hadn't missed the pre-order for pandora Still next batch I will get mine.

 

[mali]

Only took me about 2 weeks to port Neverball to OpenGLES and that uses GTKRadiant for maps, so it really isn't that hard to do. I reckon porting any opengl app is fairly easy to do. I also rewrote Noiz2sa and rRootage in opengles, so porting stuff that just writes to frame buffers is also fairly simple to do. Just wish I hadn't missed the pre-order for pandora Still next batch I will get mine.

Maybe PM Craig after the cc-reorder is through. There may be some slots open again, especially if you are a dev.

 

[Svartalf]

Maybe PM Craig after the cc-reorder is through. There may be some slots open again, especially if you are a dev.

I would do so. I'm sure there'll be some people with cold feet, understandably, and they may have a few slots open in the production pass for someone who's done a title before.

 

[Lazrhog]

Maybe PM Craig after the cc-reorder is through. There may be some slots open again, especially if you are a dev.

I would do so. I'm sure there'll be some people with cold feet, understandably, and they may have a few slots open in the production pass for someone who's done a title before.



I shall do that then. Cheers.

 

[darkblu]

By all means, go ahead- but realize you're not the first to attempt this. (Just so you know, there's a GOOD reason why I am not so hot on this idea... I've done OpenGL drivers several times in my long career in the computer field. I'm credited with working with the Utah-GLX driver base (John Carmack's hack to make the RagePRO work without any config was evil, but brilliant all the same...), involved at one point in time with the DRI project, and I've worked as a sustaining engineer for AMD's OpenGL group (I won't discuss the subject of their drivers...bad form... ).) What you're proposing, while it'll work after a fashion, but there will always be some state engine gotchas going from the Mesa one to the ES one. Moreover, you won't be able to actually use the work as much of any basis other than a source for initial ideas as it's designed around the ES 1.1 edge and in order to make it work you'll have to code to the ES 2.0 edge, handling all the fixed functionality being expressed, as fixed functionality shaders provided to the ES 2.0 pipeline, coupled with expressing the typical OpenGL 2.0 functionality as ES 2.0 stuff- just to make it all work the way you envision it.

well, the way i envision it, anything that can save me some work from such daunting tasks like porting gl2 code to es2, down to the last nuisance, just to see that code running, is a plus. for instance, a JIT shader compiler for those fixed-pipe texture stages would be welcome. the fact that it won't be up to speed does not bother me as long as it does not shift the bottlenecks in my code radically - as mechanical speed optimisations (of the type 'substitute known slower code X for known faster code Y') will anyway occur till the last moment of a project cycle. not to mention that speed is not the sole concern when protoyping/porting graphical apps - correctnes of output can be just as important.

actually, speaking of swift prototyping, i suspect that i will eventually end up carrying all prototyping in es-friengly gl2 on the desktop, and postpone doing the human-translator part to later in the production. of course that can, and therefore will, introduce its own can of worms, as it's not only APIs that will change, but actual platform characteristics as well (thus undermining the value of the prototyping), as i don't happen to have an sgx530 in a desktop.

see, no matter what details of the puzzle we discuss today, the big picture during the lifespan of the pandora will likely constitute of a good deal of gl(2) code ported over from desktops. and the daunting task of 'see how that gl looks on pandora's es' will become an utterly recurrent task in our repertoire. unless tomorrow all desktops miraculously switched to a very es2-like gl 3+, hallow be khronos' name.

 

[Svartalf]

well, the way i envision it, anything that can save me some work from such daunting tasks like porting gl2 code to es2, down to the last nuisance, just to see that code running, is a plus. for instance, a JIT shader compiler for those fixed-pipe texture stages would be welcome. the fact that it won't be up to speed does not bother me as long as it does not shift the bottlenecks in my code radically - as mechanical speed optimisations (of the type 'substitute known slower code X for known faster code Y') will anyway occur till the last moment of a project cycle. not to mention that speed is not the sole concern when protoyping/porting graphical apps - correctnes of output can be just as important.

Heh... You'll spend more effort making that wrapper work right than you'd ever spend porting apps over unless you port 10+ of them over. This is from a driver guy tellin' you that. But, again...suit yourself...I'm only going to tell ya that it's not the time saver you think it is, but if you think it's a good use of your time and you can actually bring together an answer like you think you will, by all means...

If you're set on it- go amaze me.

QUOTE

actually, speaking of swift prototyping, i suspect that i will eventually end up carrying all prototyping in es-friengly gl2 on the desktop, and postpone doing the human-translator part to later in the production. of course that can, and therefore will, introduce its own can of worms, as it's not only APIs that will change, but actual platform characteristics as well (thus undermining the value of the prototyping), as i don't happen to have an sgx530 in a desktop.



Actually, that's what they tell you to do- and then do the ES 1.1/2.0 work against the wrapper libraries that map back the other way that were done by the people making the API edges in the first place (Not to be confused with what you're proposing- it's easier to do a 1.1 to OpenGL 1.4 mapping or an ES 2.0 to OpenGL 2.0 mapping than doing the all-encompassing mapping of OpenGL 2.0 to ES 2.0...).

QUOTE

see, no matter what details of the puzzle we discuss today, the big picture during the lifespan of the pandora will likely constitute of a good deal of gl(2) code ported over from desktops. and the daunting task of 'see how that gl looks on pandora's es' will become an utterly recurrent task in our repertoire. unless tomorrow all desktops miraculously switched to a very es2-like gl 3+, hallow be khronos' name.



Heh... You're going to find that it's a lot easier than you think. FEW people did mixed fixed and shader function games. It's easier and simpler (because you get BENT results if you mix modes- which one takes precedence, etc...) if you stick with one or the other. Serious. Once you accept that this is likely to be the case, and figure out if it's fixed or shader based, you pick an API and tweak the app up slightly to go on to the selected API- so long as they didn't do an idiotic thing like do immediate mode rendering (Ugh...no game would do that- it's EVIL BAD SLOW... ) it'll go surprisingly smooth on the Pandora.

Khronos and the people on the boards (of which I know a few of them personally (incl. the gents who DID the current edition of the OpenGL Superbible...)) kept in mind what you're talking about and actually derived the APIs in question (Safety, 1.1, 2.0) based off of the given use-cases that would be expected to be used with the given APIs. 1.1 and 2.0 were based more off of mobile game usages than anything else.

 

[EdCa22]

I now understand some of the general basics of OpenGL - helped by a good understanding of 3D maths (thankyou manipulator robotics...). However, I still have yet to get to grips with any code, so I'm wondering if anyone can explain how much work is involved to convert code from using fixed pipeline of OGL 1.3 to the programmable pipeline of OpenGL ES? I'm thinking about where to start porting...I'm looking at Glest at the moment which uses a fixed pipeline. Cheers.

 

[Svartalf]

I now understand some of the general basics of OpenGL - helped by a good understanding of 3D maths (thankyou manipulator robotics...). However, I still have yet to get to grips with any code, so I'm wondering if anyone can explain how much work is involved to convert code from using fixed pipeline of OGL 1.3 to the programmable pipeline of OpenGL ES? I'm thinking about where to start porting...I'm looking at Glest at the moment which uses a fixed pipeline. Cheers.

If you're using fixed functionality, the ES 1.1 fixed functionality pipeline is probably better as a choice than the ES 2.0 (which both should be there- you'll just link against the ES 1.1 API .so instead of the 2.0 to use the one you need...). Having said this, if you've got immediate mode gotchas in there, your work will be higher (Heh... At least part of my code I'm in the progress of porting happens to have that nasty stuff in it in one or two constrained places (thankfully) and I'm having to re-express it as vertex array rendering. The API edges are designed with more Mobile Gaming in mind so they're more the use cases people were using in their games (i.e. OpenGL 1.3 for ES 1.1 or OpenGL 2.0 for ES 2.0)- so they're like cleaned up, minimalized versions of the respective API versions. So, you should have, unless they did immediate mode rendering calls, only a few things you need to change, if that much. If you've got immediate mode crap in there, you'll need to do a bit of "modernization" of the rendering code, which is a bit more work.

 

[EdCa22]

Aha - I hadn't appreciated that the GPU supported ES 1.1. I see from the specs page that I was wrong - great, that sounds much more straightforward!