OpenGL ES Versus . .

Why is OpenGL ES a good API.

I’ve been reading into J2ME programming language and most websites say that it is much more efficient to work with than C++ based work on Brew and Symbian.

Which offers more potetial in the future, especially for developing 3D games.

Obviously OpenGL ES prvide more 3D tools but I’m looking for simplicity.

I like J2ME better at the moment because of my frustartion at using(SORRY>>>ATTEMPTING TO USE) C++ ON EMBEDDED DEVICES.

Any replies would be much appreciated
(even if they are general rude remarks to my crap knowledge on this stuff . . .innit).

Cloud7 on cloud9 and out . . .zzzz

Wasn’t some work going on with regards to opengl es bindings with j2me.

You’re comparing apples to oranges. You’re talking about broad development platforms and languages and comparing this to OpenGL|ES.

OpenGL|ES is a graphics API, and ONLY a graphics API.

I assume you’re thinking about JSR-184 in J2ME vs OpenGL|ES on everything else. I just gave the spec a quick once over and the immediate mode stuff it’s very similar in to OpenGL. It does still seem dominated by higher level scene stuff in there though. If you use it the right way it’d be mostly compatible with a quick port to OpenGL or vice versa (but that would probably undermine the value of using it for rapid development in the first place since the scene graph support would be off limits).

On the platform efficiency evangelical stuff read this for a reality check:

It’s not certain that you won’t get OpenGL|ES in the long term on J2ME, for example Aromasoft has announced plans for this (quite how they’re exposing it I don’t know, it may be old news and/or maybe they went JSR-184) but it’s a tough call to make, that probably depends on your current level of experience with the environments and 3D.

[ April 21, 2005: Message edited by: dorbie ]

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.