This is the final item in a series of short posts about OpenGL ES. The series investigates OpenGL ES as a series of concepts and is aimed at those who are in the early stages of learning the language. I have spoken to many people who have complained that OpenGL ES is difficult to learn. I think that the previous installments in this series show that OpenGL ES is not difficult, just different, and with very good reason.
OpenGL ES is an extremely efficient fully-functioning section of an open standard C API. This gives it particular characteristics. These include C based naming conventions. Unlike the desktop version and most open standards, OpenGL ES has distinct versions that are not subsets of each other. This is necessary to fulfill it’s mobile brief. Checking the API version used for tutorials is therefore critical. Continue reading →
In this series I will describe some of the basic concepts of OpenGL ES. In the previous installment I examined OpenGL as a state machine. I mentioned that there is a mathematical scene description. This update will list some of the key features of that description. It is a condensed list of keywords you should investigate and understand. It will help to explain some of the core terminology used in OpenGL ES tutorials.
Scene Object Descriptions
Vertex – A vertex is a point in 3D space. A co-ordinate where x is width, y is height and z is depth. Objects in OpenGL ES is described using vertex arrays, these are lists of vertices.
Draw Mode – This is a setting which describes the rendering of an object from a vertex array or set of vertices. OpenGL ES draws objects exclusively in triangles. Multiple triangles are drawn to create an object. There are various draw modes for creating these lists of triangles. The most common modes are GL_TRIANLGE_STRIP and GL_TRIANGLE_FAN.
Happy new year! Welcome back, I have had a break over Christmas and now I am trying to get some OpenGL material out while I have some fresh ideas. In this particular series I am describing some of the basic concepts of OpenGL ES, so that it makes the language more accessible. For this, the third installment, I will examine a key phrase that commonly appears when learning OpenGL ES, the ‘state machine’.
In general, a state machine is any device that stores the status of something at a given time. It can operate on input to change the status and possibly cause an action or output to take place for any given input change. It normally has an initial state and a set of possible input events. Additionally, it will normally have a set of new states may result from new input and a set of possible actions or output events that result from a new state.
In this series I will describe some of the basic concepts of OpenGL ES so that it makes the finer details of the language more accessible. This second post describes how OpenGL ES originated as a functional language API to target graphics cards and what effect that has had upon it.
During the 1980’s Silicon Graphics were a company that made specialist graphics computers. For that time, they had extremely advanced machines. Programming for these workstations was carried out using procedural languages such as C, BASIC and even assembly language. The IRIS Graphics Language was used to communicate with the graphics cards. Silicon graphics became dominant in this field. They opened up their standard for people to both license and implement hardware. This open standard was named OpenGL and it flourished, unlike Silicon Graphics who collapsed.
As OpenGL grew, many features were added to give it increased power and efficiency. Around 15 years later, in 2006, 3D graphics was beginning to become possible for hand-held devices. An older version of the OpenGL standard was used to assist in this process. All the uncommonly used features were removed from it. In addition, where two or more ways to carried out a task existed, the least efficient ones were scrapped. This new streamline graphics library was dubbed OpenGL for Embedded Systems (OpenGL ES).
OpenGL ES is a free, cross-platform API for 2D and 3D graphics on mobile devices, consoles and many more platforms. It is features on both the iPhone and Android devices. It consists of defined subsets of desktop OpenGL. This creates a flexible and powerful, low-level interface between software and graphics acceleration. The picture on the right shows Epic Citadel. This is a free iPhone game developed using OpenGL ES 2.0. It demonstrates the amazing potential of the language.
I have spoken to many people who have attempted to learn OpenGL ES. Many ended up being put off by what they call an unusual API. OpenGL ES can seem disconcerting at a quick look. It uses a slightly different programming paradigm to many other API’s for mobile devices. Often, once people understand the concepts behind OpenGL ES, they find that the can learn it’s nuances at a greatly accelerated rate.
Originally, I intended to write a post as a precursor for those learning OpenGL ES. It expanded to be larger than I had anticipated. Therefore, I am going to write a short series of posts examining OpenGL ES from a variety of conceptual angles. The first of these angles looks at the history of OpenGL ES. All of the posts will be in short bite-sized chunks so that the concepts are easy to digest. They will attempt to give an overview of the structure of OpenGL ES.
The first installment should be ready in the next few days.
This post is relevant to those who like to code natively, but want their apps to be available on multiple platforms. I recently took a quick look at cross platform mobile development frameworks and found that many of them may only be useful for certain tasks (see previous post). There was, however, a couple of recurring ‘themes’. A quick analysis of the underlying technologies used for these environments paints an intriguing picture.
The technologies I surveyed were essentially divided into two camps. The first, based on web standards, included Rhodes, Titanium and PhoneGap. These environments demonstrate that the HTML5 Canvas element can be used to create responsive 2D Graphics to run on multiple mobile platforms.
The second group were C++ based, often evolving OpenGL ES. This grouping may not be so obvious. Haxe compiles to iPhone and Android using NME, which is open source. It works by utilising the C++ and OpenGL ES capabilities of these platforms. I have no solid evidence, however, some of the optimisation tips provided by Adobe, suggest that the Flash tool does something similar. According to Wikipedia, Unity 3D also uses OpenGL ES. MoSync is open source and clearly uses C++. The MoSync team are are working on OpenGL support. Continue reading →
I recently decided to carry out some investigation into frameworks and tools for creating graphical apps using a cross platform methodology.
Cross platform technologies can have a time saving advantage over writing an app separately for multiple platforms. This applies to initial development time, maintenance and update time. It also overcomes the hurdle of different platforms using varying languages.
Cross platform technologies can often be less efficient, offer less features and usually take longer to release feature updates than the native environments. Effective aesthetics, efficient coding and groundbreaking new features are often essential to mark an app out against its competitors. An individual user will rate the app on their personal experience, not if it runs on other platforms.
I have searched out a variety of technologies. There may be others. I am not necessarily recommending these technologies, just linking to them as they look like they could be interesting.
Available on Android, iOS, Blackberry, Symbian. Coding is accomplished using Adobe ActionScript. Flash CS5 is needed and it has a rather expensive price tag. The main advantage is that there would be very little porting between platforms and most of the work would just be re-sizing assets and slight UI redesigns. It can not currently access native UI elements. Some platforms only support Flash Lite, which currently uses different code base. This platform supports some 3D but would be best utilised for 2D applications.
An extremely similar solution to Flash but free and open source. It is available on the same platforms and Adobe Flash and also can not access native GUI elements. The Haxe language is extremely similar to ActionScript but with some added features. NME can be a bit complex to set up for those not familiar with Haxe. Not all of the Flash API classes can be used when using in conjunction with NME.
MoSync is an open source, cross platform mobile development tool-set. It works on iOS, Android, J2ME, RIM, Symbian, Windows Mobile and Brew. It uses a C++ code-base with libraries to help with various common tasks. It is capable of 3D as well as 2D graphics. It is free for publishing open source apps but there is a cost for publishing closed source apps. There are no native UI elements at current time. Is may be useful for porting existing C++ code-base applications.
This is the final installation in a series of articles which has looked at development on four of the main mobile platforms.
It has shown that a free sign-up may attract those with limited budgets into the Ovi store. This may be dependent on if they can obtain a cheap device. Those wishing to make more complex apps that can be sold at a higher price may be attracted to Blackberry. Developers who intend to create many apps in a short sequence may be inclined to investigate Apples platform, due to it’s pricing strategy and device similarity. The speed of the Android market growth and openness of it’s platform may beckon some developers in its direction.
The main conclusion to draw is that all of the technologies have a comprehensive development platform and an organised way to distribute applications. All of them look like strong contenders which should have the potential for future growth. The main decisions from a programmers perspective may boil down to which device they can access easily and which technologies they already have experience using.
There are many other sources available to help with a decision. This is a list of just a few which I have found useful while creating this series. Good luck.
Links to market research companies who provide statistics for mobile phones: Distimo Gartner
Don’t forget Windows Mobile. Depending upon when you are reading this it may now be up and functioning in it’s exciting new ‘metro’ form: Engadget Preview Windows Phone Dev Centre
Can’t make up your mind? There are technologies which allow developers to publish to multiple platforms. Perhaps one of these would be a good place to start. A list of them is mentioned in the 5th installment of this series “What Languages will I need to Know?”
This is the fifth in a series of posts which aims to provide a guide to choosing an initial mobile development platform. It explores the subject by discussing a series of questions which may be posed by a new developer.
Technologies vary from device to device due to continual device evolution. Despite this, the underlying tools, languages and main APIs generally remain the same on each platform.
Apple iOS
The Apple SDK is based around use use of Objective-C. This is a C based language with no garbage collection also used for Apple desktop programming. It works on a GCC compiler so C++ code can be included, however, all of the GUI components are Objective-C based. OpenGL ES is also supported. There are also various 3rd party applications that allow the developer to create iPhone apps using other languages including Mono, Adobe Flash and Unity3D.
Android
The Android SDK primarily uses Java within the Eclipse IDE. It also supports OpenGL ES. It does have an NDK (Native Development Kit) which supports some C++ but does not provide any support for the STL or C++exceptions. It is not recommended to develop a whole application in C++ but it can be called from the Java code. Again, there are 3rd party tools including Flash and Unity3D.
Nokia Ovi
Nokia Ovi has various platforms on which developers can work. Each of these can be submitted to the Ovi store. These include Qt, a C++ based framework which supports OpenGL. Java MIDP and Flash Lite/Flash are also supported. It also has a Symbian C++ platform but this may not be as suitable for new developers. Additionally, the Ovi store has a non-programming way to make applications using a technology called the ‘Ovi App Wizard’.
Blackberry
The Blackberry SDK is based around Java within the Eclipse IDE or within Microsoft Visual Studio. It also has support for OpenGL ES. There are two types of Java application which can be created. The first uses standard Java for mobile (MIDP). The second uses a special Blackberry version with more specific features called CIDC. There is also a web technologies method of creating applications on the horizon. Flash support is expected imminently.
This post is the third in a series of posts which aims to provide a guide to choosing an initial mobile development platform. It explores the subject by discussing a series of questions which may be posed by a new developer.
All of the platforms I am examining have a free SDK but some are restricted to working on a particular desktop OS. This will mean the the cost will be different depending on what hardware you already own. There are some limitations for each platform, for instance, an Apple computer is needed to develop for iOS. Eventually a developer will probably want to have multiple mobile devices for testing, however, for a first app this may not be essential.
Many platforms come with simulators. Do not be tempted to think that you could release something to a mobile application store without having tested it on a device. There may be differences in connection or memory as well as many other things. Simulators are very good for following a few tutorials in order to discover if you enjoy working with a platform. This can be done before making any real investment.
(Please note that the chart above contains an error. Android has only the one $25 fee, no additional fees apply)
This table shows that there is a slight difference in setup prices that may effect the overall cost. Once the cost of the hardware is factored into the equation, it is unlikely that these costs will make a large overall difference. Once thing that might make a difference is choosing a platform with cheaper devices available. That would be more likely to reduce the cost if your starting budget is tight.
Blackberry Device publishing requires the largest initial investment. Their strategy may still yield savings for those who wish to produce multiple applications. Also, the price that the developer can charge for an app appears to be larger for Blackberry. The other stores show similar average app prices, this may indicate that Blackberry has a different target market. The Ovi Store is the only application market with no initial charge, very tempting for those on limited budgets.
(Information Sources – Gartner, Distimo, RIM, Google, Apple and Nokia.)
