Develop Reference

JOGL vs OpenGL ES API on Android. Pros&Cons

We are trying to migrate our project from PC version to Android. PC version uses JOGL.
Can anyone explain main advantages of using JOGL in Android application instead of OpenGL ES API?
For example, on PC pros of JOGL are:
In theory you can use it on any platform.
It's more or less integrated with AWT, Swing and SWT.
Also it's some kind of wrapper, so in theory there are some abstractions that make it easier to use OpenGL.
But I can't see advantages of using it in Android, here are the cons from my point of view:
It's another dependency, APK size will be larger.
Some issues that affect both JOGL and OpenGL ES will require more
time to pinpoint and fix.
It's not a silver bullet that would not require some time for
refactoring, since in Android we should use right patterns for
Activities, Services, etc.
JOGL has less tutorials and smaller community that OpenGL ES API
has.
So what's the point of using it in Android project?

You can use JOGL only on the platforms that we support. I confirm that JOGL has a good interoperability with AWT, Swing and SWT (not yet with OpenJFX/JavaFX but we'll improve that when Oracle does the necessary things). Yes there are some nice abstractions but you forget tons of things:
JOGL has its own AWT-free image management. It has a better support of JPEG than ImageIO and it is faster
You can preserve the OpenGL context even when your application is paused and put in background (when you press "home"), it's build-in
You can test your OpenGL-ES code on your computer even though it doesn't replace the tests on a real device
You can use exactly the same OpenGL code on desktop and embedded environments, especially if you already use GL2ES2
you can rely on us if something goes wrong, there are already a few commercial games on Google Play
I admit that there is a lack of documentation about JOGL under Android. I'm sorry, I have spent several months in writing a tutorial about JogAmp's Ardor3D Continuation and I prefer leaving the task of doing the same for JOGL Android usage to someone more experienced with it.
Edit.: Sorry for the late reply but I had a problem with my OpenID. Please rather post questions about JOGL on our official forum.

SDL2 cross-platform OpenGL 3+ and OpenGL ES 2.0 or 3.0

Is there some super-easy basic hello world cube project (with setup tutorial) for SDL2 that builds and runs easily across (Windows, Linux eg Ubuntu, Mac OS X, Android, iOS), using modern OpenGL as in OpenGL 3.x or 4.x and OpenGLES 2.0 or 3.0?
I downloaded SDL2 and it was pretty easy to get their example testgles.cpp and testgl.cpp to build...
However, the testgl.cpp one is horribly old (gl2 style), so I tried the testgles.cpp. Unfortunately, even this is full of old style fixed function calls like glMatrixMode(GL_MODELVIEW). And it's annoyingly over-integrated with SDLTest_Common code.
Is there a better simple clean hello world project (eg colored cube, textured cube) that I can start from?
Or is there some reason why they don't include such an example starting project or tutorial?
Or should I be using a different library instead of SDL2 that is simpler & cleaner to setup? Basically I want to write OpenGL / OpenGLES (and maybe DirectX) cross-platform C++ code. But setting up SDL2 has been a lot messier and more painful than I expected.
So far I just made an svn repository with SDL2 code and got testgl.cpp and testgles.cpp to build on those five platforms. But that used a lot of old style OpenGL/OpenGLES code, so now I am slowly hacking it to use newer stuff... It's been quite a pain. I don't get why SDL2 doesn't just include a basic hello world cross-platform starting project (eg textured cube) using modern OpenGL/OpenGLES (and DirectX).

SDL2 is a good way to start. I could even say, that SDL is the most popular and yet multiplatform lib for that, especially is you think about using joystics or going steam later on. There is no need to look for any other lib. But please remember, that it's just low level layer for providing media access. It's not their job to provide high quality Opengl 3.0 projects to users. What you need is to learn some modern OGL basics - and you have to do it somewhere else. As simple as that.
A good place to start is http://www.open.gl. There is a couple of very straightforward and simple tutorials written in C++ with some SDL and SFML approach.
Lazy Foo also cover some of the topic http://lazyfoo.net/tutorials/SDL/
http://openme.gl/ is also nice, maybe http://openme.gl/opengl-4-x-example-using-sdl2-and-glm/ is something for you. It seems to be a quite good quality code.
http://www.opengl-tutorial.org/ is also a great place to learn OpenGL 3.3+. It's recomended in many places.
You can always come with some kind of project like this and link to official SDL wiki. ;) SDL community will be greatfull for that.
And by the way. DirectX is "Microsoft's non-opensource SDL" - and it's very non-crossplatform.

If you want to write cross platform OpenGL, you might take a look at GLFW for setting up your OpenGL context. It handles simple window and context creation as well as user input.
I have a method to render a colored cube in some of my example code here. It's pretty enmeshed in my library though as it makes lots of calls out to my wrapper classes. They're also available in the same library, or you can take a look at the latest version of them here.

Are there cross-compilable OpenGL examples made with Oxygene?

We have a working OpenGL project made for PC (works on MacOS and Linux under Wine as well) which we want to try to cross-compile to tablets. Delphi XE2/XE4 offers iOS support, but there's no Android yet and judging from iOS implementation history it might take 1-2 years. Now we start looking into other possibilities which will allow us to keep the majority of Pascal codebase (80k lines). So here's the question for the Oxygene:
Are there any examples of OpenGL applications made with Oxygene that can be cross-compiled to work on PC/MacOS/iOS/Android ?
If not, what alternatives are there (except Lazarus)?

AFAIK there is none.
Even the low-level Sugar cross-platform RTL is not finished. It would be a first mandatory step to be done before accessing higher level libraries in a cross-platform way (i.e. with identical source code), like OpenGL.
So with Oxygene, you have a great cross-compiler, but you are tied to use the RTL available on each platform.
You can compare with two object-pascal compilers:
With FreePascal, which has built-in OpenGL units, and already several libraries over it - one of the most powerful/known is GLScene;
With SmartMobileStudio, which has built-in WebGL support and can do amazing things on modern browsers - WebGL is a translation of the OpenGL API/concepts in HTML5.

Oxygene doesn't attempt to be source compatible with Delphi. What's more the runtime libraries used by the various Oxygene flavours differ entirely from those used by Delphi. So you won't find any serious libraries that have single source that can compile on Oxygene and Delphi.
The way that RemObjects have developed Oxygene on different platforms is quite interesting and radically different from the approach taken by Embarcadero with Delphi.
With Delphi the goal is that you can single source development for all the platforms. That is made possible by the FireMonkey framework which presents a common interface to all platforms. Obviously you need to vary some elements of an app to account for device differences.
With Oxygene, each platform is targetted separately. So for Windows, the runtime is .net. For Java it is the JVM and for Apple platforms you target Cocoa.
All this means that you cannot expect to write a GUI app in Oxygene and have it work on multiple platforms.
So not only can you single source your app between Delphi and Oxygene, you cannot readily single source multiple Oxygene targets.
Now, you can probably port to Oxygene or FPC without too much trouble. But maintaining single source is liable to mean a lot more effort. Whether that's worth the effort is debateable. In the long run you'll want a codebase in one of Delphi, FPC, Oxygene, or even something radically different. But you won't want your code spread out over multiple languages.

You can write or own OpenGL layer in Oxygene with the usage of mapped types like it is used in the sugar open source project.
It sounds pretty cool. In your code you have just to use one class which is during compiling direktly mapped to the underlying platform class method, without an overhead of that layer.
IMHO, when Oxygene is growing, we will then find a lot of such "suger" layers and write once compile anywhere will come closer :)
Edit:
Using OpenGL with .Net
OpenGL Java Tuturial

Android OpenAL?

Has anyone built OpenAL for the Android, or found the shared library for it on the system? This seems like an obvious need for a game of any kind, yet there's no resources out there for it. It seems the Android java sound library can't do pitch changes from what I can tell, so there seems a need for OpenAL. I know OpenAL Soft can be built on top of ALSA, but I'm not sure if anyones done that, and I'm sure it would take me a month.
If there's a good guide somewhere on sound manipulation on the Android without OpenAL, that's fine too. It's just that OpenAL is sort of a standard for game makers and it would be nice to port my thousands of lines over to this system, which I sort of thought was the point of the NDK before I dugg into it and saw that there's almost no shared library access on the system.
Thanks.. I hope I can actually port without becoming a java expert myself. Really disliking the NDK so far!

A few options are available now for NDK audio:
It's not OpenAL, but OpenSL ES 1.0.1 is an official part of the NDK as of API level 9 (2.3). More information here.
OpenAL Soft has an OpenSL ES backend in its git master (not released as of version 1.13). It is however at this time broken on Android, as it is written for OpenSL ES 1.1, not 1.0.1. See this commit for a fix.
As mentioned in a previous answer, a JNI backend for OpenAL Soft is linked to and described here as the only option for OpenAL on pre-2.3 Android platforms. However, this is an outdated fork of OpenAL Soft - I've updated the backend to the latest version on a github repo here along with the OpenSL ES 1.0.1 fix. Also included is an untested optional patch that claims to provide better performance and less latency.

Just before Google announced that 3D audio is going to be included into Android 2.3, I managed to compile OpenAL for Android, and package it as shared object.
See http://pielot.org/2010/12/14/openal-on-android/
Might still be helpful if you'd like to target devices < 2.3.
Cheers.

OpenSL is planned for a future Android build; OpenAL isn't available, and the low-level hardware is off-limits to anything you can do in the NDK, so you can't safely build it yourself.
There's no support for low-latency audio even planned; there's a bug to that effect here:
http://code.google.com/p/android/issues/detail?id=3434
Star it if it's relevant to you; maybe Google will listen if it gets enough stars.
EDIT: There IS low latency audio in Android 4.0+, and OpenSL is available now. See this page and linked pages: http://source.android.com/devices/audio/latency.html Also see the NDK guide on OpenSL.

You can use the NDK to build OpenAL and package it with your APK. That way you can access it from your native code.

Will JavaFX work on Android?

It would be a shame if it doesn't, because it will make for more attractive looking Android applications.

Not right now, and it would be a nontrivial task to make it work. Android doesn't have all the libraries that the typical desktop JRE does. Although since Android is open source and it will run anything that can be compiled to Dalvik byte code, it's not impossible.
Really, I don't really think JavaFX will make for more attractive looking Android applications - the most important thing is how integrated the application is into the hardware and the Android display framework has a lot of stuff to make that easier.

JavaFX 2.0 is now a library. The implementations are platform specific because, amongst others, of the use of hardware accelerated graphics. There's a version for Windows (that uses DirectX) and a developer preview for Linux and Mac (which uses OpenGL) : oracle
Because of the heavy use of hardware acceleration, I guess if there will be an android version (very likely), the target will be relatively new tables, rather then all android devices.

Perhaps it's not so important the attractiveness. I think portability matters a lot nowadays, and this kind of tech makes it very portable.

Please go through below link : openjdk , oracle