Is there an Android implementation of JOGL's GL2ES2? - android

JOGL includes several interfaces that represent the common features of various versions of OpenGL and OpenGL-ES.
Is there an Android implementation of the GL2ES2 interface somewhere in one of the JOGL packages, or do I have to bite the bullet and implement it myself?

You should read this documentation:
http://jogamp.org/jogl/doc/Overview-OpenGL-Evolution-And-JOGL.html
JOGL 2 already works as is under Android. What are you trying to do? Numerous tablets and mobile phones support OpenGL-ES.
Imagine that you want to launch a Java program using JOGL on my Samsung Galaxy S3 4G i9305. It supports both OpenGL ES 1 and OpenGL ES 2, it will pick the former or the latter depending on how you create your GL profile. If it picks OpenGL ES 2, GLContext.getCurrentGL() will return a GLES2 instance. GLES2 is a subinterface of GL2ES2. What's the matter with that?

Related

Android OpenGL ES 2.0: Do I need to check if VBOs are supported before using?

I want my code to perform well in all devices supporting Es 2.0. In my code, I am using VBOs, reading documentation reveals that it requires the implementation of extension "GL_ARB_vertex_buffer_object".
However, glGetString(GL_EXTENSIONS) does not list the above mentioned extension string for the device I am using (Samsung Tab) though it supports it.
To my knowledge, the VBO extension is only meant for OpenGLES 1.1. OpenGLES 2.0 supports this by default. This tutorial, which I consider one of the best, makes no consideration to test the device before running the VBOs.
In all my Android apps I use OpenGL ES 2.0 with VBO without any additional checks.
And VBOs work on Galaxy Tab.
In OpenGLES2 you do not have to check for VBO extension.
In OpenGLES2 you do have to check for vertex_array_object if you want to use VAO as well.
Here is a database of extensions from various devices.

3D graphics engine for embedded Linux without Android

I am facing a task to introduce some custom yet to be written written 3D games into our embedded Linux board. Our system is a custom Linux distribution. Main application is running with Qt and the plan is for this application to run games as separate processes that will overtake the screen while active. The board is capable of OpenGL ES2 and is on par with modern phones.
What are my options for a good, performant 3D graphics engine on such a platform?
Preferably I would love to have Unity3D, but it only supports Android. (Maybe there is a possibility to skip Android by providing only basic dependencies instead?)
Have a look at www.inka3d.com. The same engine also works on embedded linux with some more features (e.g. clip libraries of Maya can be used). Currently it works on BeagleBoard even with character animation at 30 fps and 1024x768.
Since you've decided on Qt for your UI, you definitely want a graphics library that's compatible with Qt.
So it sounds like OpenGL ES is exactly what you're looking for:
http://doc.qt.nokia.com/stable/qt-embeddedlinux-opengl.html
Qt for Embedded Linux provides support for integrating OpenGL ES for
drawing into a QGLWidget. The current implementation supports OpenGL
and 2D painting within a QGLWidget.
Q: Exactly what's holding you back (you didn't specify the exact board or any details about your toolchain/library vendors)?
PS:
You might also wish to look here:
http://doc.qt.nokia.com/stable/qt-embeddedlinux-opengl.html
The reference integration for OpenGL into Qt for Embedded Linux is for
the PowerVR chipset from Imagination Technologies. It consists of
two components: pvreglscreen, which provides the Qt for Embedded Linux
screen driver, and QWSWSEGL, which implements a plug-in to the PowerVR
EGL implementation to implement low-level OpenGL drawing surfaces.
PPS:
This is a great, great book on Linux Embedded: satisfaction guaranteed:
Embedded Linux Primer, Christopher Hallinan:
http://www.amazon.com/Embedded-Linux-Primer-Practical-Real-World/dp/0137017839/

Android Mixing OpenGLES 1.0 and OpenGLES 2.0

I've been asked to create shaders for our Android engine and I'm a little confused. So far the engine has been built on the premise that we use GL10 instances to be responsbile for the drawing of everything. But because shaders are OpenGL 2.0 if I were to set the context client version to 2.0 and draw a simple scene (say a cube) nothing appears whereas it does if I use the default 1.0.
I'm not entirely sure how I should proceed - do I need to create different engines based on the highest level version of OpenGLES supported by the device? Use the higest possible regardless of what it can support (assuming backward compatibility)?
Any help/suggestions appreciated...
OpenGL ES 2.x is not backward compatible with OpenGL ES 1.x. You have to write different code to support both of them.

Difference in iOS OpenGl ES and Android OpenGl Es

I am wondering what the difference (if any) there is in OpenGl ES for Android and OpenGl ES for iOS
OpenGLES API for Android have many unsported API and any problems.
For instance, glColorub, glPointParameterfv, point sprite OES(Extension) APIs, and so on.
And, Xpreia(android device) have glFlush bug.
When glFlush used, occurred display noise.
OpenGLES API for Android implementation is asunder each devices.
There is no difference. The OpenGL ES 1.x and 2.x are available on most phones. Many mobile GPU have specific extensions but if you don't use them, iOS or Android can share same code. OpenGL is a C API, so the Java One provided by Android is specific.
Our games share the same code for iOS and Android. Only the EGL(Android) and AGL(iOS) parts are different. For performance reason, we use some specific extensions (Compressed Textures...).

iOS OpenGL ES compatible with Android OpenGL ES?

In theory, can I write a game for iOS in openGL ES and expect to easily port it to Android? How about from Android to iOS?
There are differences in Android and iOS game development that you need to take into account:
In android you need to support multiple graphics chips:
Different texture compression support
Major differences in performance
Different OpenGL ES implementations:
Buggy gluUnproject implementation in Android (there are custom implementations, for example )
Lack of glGet* functions in Android (however you can use MatrixTrackingGL)
Yes, I believe that if you write a game in C/C++ for iOS, to port it to Android wouldn't be too much of a hassle. However, if you write the game in Objective-C, then it could be quite a hassle indeed.

Categories

Resources