I'm an experienced Android developer (if such thing exists) who has never worked with OpenGL before.
There are various advantages of the Android platform (open-source, open distribution, portable, and so on) that make me think that it might be a great environment to finally get into OpenGL.
But I'm also worried that the complexity of working in a environment with limited resources might be too much for someone who has never worked with 3D graphics before. Also, it seems that Android only uses a subset of OpenGL, and I don't know how this will affect my learning experience.
What do you think? Is Android OpenGL development newcomer-friendly, or for experienced OpenGL developers only?
There's not really an "Android OpenGL", it's just OpenGL ES 1.1 or OpenGL ES 2.0, which IS a subset of OpenGL, but oriented to mobile and embedded devices.
I don't think any platform is "newcomer-friendly", is just that you need to get the necessary knowledge to use it. For OpenGL/OpenGL ES, you need to have certain computer graphics knowledge before trying to use it. GL ES and GL are very similar and GL ES knowledge also works in GL (not viceversa, since it's a subset), so just get into it.
I recommend the book OpenGL ES 2.0 Programming Guide (for GL ES 2.0) and the book OpenGL ES Game Development for OpenGL ES 1.1. These books are in C, you need to "port" them to Java, since Android uses that, but the basics are the same.
Related
What programming language works well with OpenGL ES on iOS and Android?
I am specifically looking to get graphics experience with OpenGL ES 2. My experience has been with web development in Javascript and iOS development using C# and Unity3D. (Unity3D is great but far removed from dealing directly with OpenGL ES.)
The short answer is there probably is none. That's why tools like Unity exist. Making things work between iOS and Android is a huge difficult task. If all you need is OpenGL ES experience, why not try it on just one platform? Both Android and iOS can make calls to Open GL ES, but Android does it in Java while iOS does it in C.
If you like C# you should look into MonoTouch. It brings great C# experience to iOS. And it provides you with direct access to OpenGL ES API.
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/
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.
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...).
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.