GDC 2014 Report

libgdx: We’ll go 1.0 next weekend!

Recent posts

A Performance Comparison Between Java and C on the Nexus 5

How Powerful Is Your Nexus 7?

Finishing up Our Native Air Hockey Project with Touch Events and Basic Collision Detection

Android native development

Android on x86: Java Native Interface and the Android Native Development Kit 

jnigen wiki page

Wrapping a C++ library with JNI – introduction

Game industry & development

How In-app Purchases Have Destroyed The Industry

How in-app purchase is not really destroying the games industry

How to become a Graphics Programmer in the games industry

The indie roadmap

You Don’t Need Millions of Dollars

Online books and references

Data-Oriented Design

Game Programming Patterns

Platform/GFX/MobileGPUs

OpenGL articles & tutorials

OpenGL dumb mistakes: the mysterious Perfect Circular Hole

GLKit to the max: OpenGL ES 2.0 for iOS

Web development

Asset loading in emscripten and PNaCl

Compiling to the Web

First 3D Commercial Web Game Powered By asm.js Unveiled

On Asm.js

Playing With Emscripten and ASM.js

Misc

Farewell DirectX

Modern C++: What you need to know

Never Again in Graphics: Unforgivable graphic curses.

Support RoboVM (and get Java 8 and other Goodies)

Copyright © 2012

This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
The use of this feed on other websites that do not comply to the CC-BY-SA 3.0 breaches copyright. If this content is not in your news reader, the page you are viewing may be an infringement of the copyright. (Digital Fingerprint:
e5945dcc83892602ba406e1f54f77ae6)

In this post, I will take a look at a DSP filter adapted from coefficients generated with mkfilter, and compare three different implementations: one in C, one in Java, and one in Java with some manual optimizations. The source for these tests can be downloaded at the end of this post.

To compare the results, I ran the filter over an array of random data on the Nexus 5, and the compared the results to the fastest implementation. In the following table, a lower runtime is better, with the fastest implementation getting a relative runtime of 1.

The statically-compiled C code gave the best execution times, followed by ART and then by Dalvik. The C code uses JNI via GetShortArrayRegion and SetShortArrayRegion to marshal the data from Java to C, and then back from C to Java once processing has completed.

The best performance came courtesy of GCC 4.8, with little variation between the different additional optimization options. Clang’s ARM builds are not quite as optimized as GCC’s; toggling LOCAL_ARM_NEON := true in the NDK makefile also makes a clear difference in performance.

Even the slowest native build using clang is not more than 43% slower than the best native build using gcc. Once we switch to Java, the variance starts to increase significantly, with the best runtime about 2.2x slower than native code, and the worst runtime a staggering 17.8x slower.

What explains the large difference? For one, it appears that both ART and Dalvik are limited in the amount of static optimizations that they are capable of. This is understandable in the case of Dalvik, since it uses a JIT and it’s also much older, but it is disappointing in the case of ART, since it uses ahead-of-time compilation.

Is there a way to speed up the Java code? I decided to try it out, by applying the same static optimizations I would have expected the compiler to do, like converting modulo to bit masks and inlining function calls. These changes resulted in one massive and hard to read function, but they also dramatically improved the runtime performance, with Dalvik speeding up from a 17.8x penalty to 2.9x, and ART speeding up from an 8.0x penalty to 2.2x.

The downside of this is that the code has to be abused to get this additional performance, and it still doesn’t come close to matching the ahead-of-time code generated by gcc and clang, which can surpass that performance without similar abuse of the code. The NDK is still a viable option for those looking for improved performance and more efficient code which consumes less battery over time.

Just for fun, I decided to try things out on a laptop with a 2.6 GHz Intel Core i7. For this table, the relative results are in the other direction, with 1x corresponding to the best time on the Nexus 5, 2x being twice as fast, and so on. The table starts with the best results first, as before.

As on the Nexus 5, the C code runs faster, but to Java’s credit, the gap between the best & worst result is less than 4x, which is much less variance than we see with Dalvik or ART. Java 1.6 and 1.7 are very close to each other, unless “-XX:+AggressiveOpts” is used; with that option enabled, 1.7 is able to pull ahead.

There is still an unfortunate gap between the “normal” code and the manually-optimized code, which really should be closable with static analysis and inlining.

The other interesting result is that the gap between mobile and PC is closing over time, and even more so if you take power consumption into account. It’s quite impressive to see that as far as single-core performance goes, the PC and smartphone are closer than ever.

Conclusion

Recent Android devices are getting very powerful, and with the new ART runtime, common Java code can be executed quickly enough to keep user interfaces responsive and users happy.

Sometimes, though, we need to go further, and write demanding code that needs to run quickly and efficiently. With the latest Android devices, these algorithms may be able to run quickly enough in the Dalvik VM or with ART, but then we have to ask ourselves: is the benefit of using a single language worth the cost of lower performance? This isn’t just an academic question: lower performance means that we need to ask our users to give us more CPU cycles, which shortens their device’s battery life, heats up their phones, and makes them wait longer for results, and all because we didn’t want to write the code in another language.

For these reasons, writing some of our code in C/C++, FORTRAN, or another native language can still make a lot of sense.

For more reading on this topic, check out How Powerful is Your Nexus 7?

Source

dsp.c

#include "dsp.h"<br />#include &lt;algorithm&gt;<br />#include &lt;cstdint&gt;<br />#include &lt;limits&gt;<br /><br />static constexpr int int16_min = std::numeric_limits&lt;int16_t&gt;::min();<br />static constexpr int int16_max = std::numeric_limits&lt;int16_t&gt;::max();<br /><br />static inline int16_t clamp(int input)<br />{<br /><%%KEEPWHITESPACE%%>     return std::max(int16_min, std::min(int16_max, input));<br />}<br /><br />static inline int get_offset(const FilterState&amp; filter_state, int relative_offset)<br />{<br /><%%KEEPWHITESPACE%%>     return (filter_state.current + relative_offset) % filter_state.size;<br />}<br /><br />static inline void push_sample(FilterState&amp; filter_state, int16_t sample)<br />{<br /><%%KEEPWHITESPACE%%>     filter_state.input[get_offset(filter_state, 0)] = sample;<br /><%%KEEPWHITESPACE%%>     ++filter_state.current;<br />}<br /><br />static inline int16_t get_output_sample(const FilterState&amp; filter_state)<br />{<br /><%%KEEPWHITESPACE%%>     return clamp(filter_state.output[get_offset(filter_state, 0)]);<br />}<br /><br />static inline void apply_lowpass(FilterState&amp; filter_state)<br />{<br /><%%KEEPWHITESPACE%%>     double* x = filter_state.input;<br /><%%KEEPWHITESPACE%%>     double* y = filter_state.output;<br /><br /><%%KEEPWHITESPACE%%>     y[get_offset(filter_state, 0)] =<br /><%%KEEPWHITESPACE%%>       (  1.0 * (1.0 / 6.928330802e+06) * (x[get_offset(filter_state, -10)] + x[get_offset(filter_state,  -0)]))<br /><%%KEEPWHITESPACE%%>     + ( 10.0 * (1.0 / 6.928330802e+06) * (x[get_offset(filter_state,  -9)] + x[get_offset(filter_state,  -1)]))<br /><%%KEEPWHITESPACE%%>     + ( 45.0 * (1.0 / 6.928330802e+06) * (x[get_offset(filter_state,  -8)] + x[get_offset(filter_state,  -2)]))<br /><%%KEEPWHITESPACE%%>     + (120.0 * (1.0 / 6.928330802e+06) * (x[get_offset(filter_state,  -7)] + x[get_offset(filter_state,  -3)]))<br /><%%KEEPWHITESPACE%%>     + (210.0 * (1.0 / 6.928330802e+06) * (x[get_offset(filter_state,  -6)] + x[get_offset(filter_state,  -4)]))<br /><%%KEEPWHITESPACE%%>     + (252.0 * (1.0 / 6.928330802e+06) *  x[get_offset(filter_state,  -5)])<br /><br /><%%KEEPWHITESPACE%%>     + (  -0.4441854896 * y[get_offset(filter_state, -10)])<br /><%%KEEPWHITESPACE%%>     + (   4.2144719035 * y[get_offset(filter_state,  -9)])<br /><%%KEEPWHITESPACE%%>     + ( -18.5365677633 * y[get_offset(filter_state,  -8)])<br /><%%KEEPWHITESPACE%%>     + (  49.7394321983 * y[get_offset(filter_state,  -7)])<br /><%%KEEPWHITESPACE%%>     + ( -90.1491003509 * y[get_offset(filter_state,  -6)])<br /><%%KEEPWHITESPACE%%>     + ( 115.3235358151 * y[get_offset(filter_state,  -5)])<br /><%%KEEPWHITESPACE%%>     + (-105.4969191433 * y[get_offset(filter_state,  -4)])<br /><%%KEEPWHITESPACE%%>     + (  68.1964705422 * y[get_offset(filter_state,  -3)])<br /><%%KEEPWHITESPACE%%>     + ( -29.8484881821 * y[get_offset(filter_state,  -2)])<br /><%%KEEPWHITESPACE%%>     + (   8.0012026712 * y[get_offset(filter_state,  -1)]);<br />}<br /><br />void apply_lowpass(FilterState&amp; filter_state, const int16_t* input, int16_t* output, int length)<br />{<br /><%%KEEPWHITESPACE%%>     for (int i = 0; i &lt; length; ++i) {<br /><%%KEEPWHITESPACE%%>          push_sample(filter_state, input[i]);<br /><%%KEEPWHITESPACE%%>          apply_lowpass(filter_state);<br /><%%KEEPWHITESPACE%%>          output[i] = get_output_sample(filter_state);<br /><%%KEEPWHITESPACE%%>     }<br />}
dsp.h
#include &lt;cstdint&gt;<br /><br />struct FilterState {<br /><%%KEEPWHITESPACE%%>	static constexpr int size = 16;<br /><br /><%%KEEPWHITESPACE%%>    double input[size];<br /><%%KEEPWHITESPACE%%>    double output[size];<br /><%%KEEPWHITESPACE%%>	unsigned int current;<br /><br /><%%KEEPWHITESPACE%%>	FilterState() : input{}, output{}, current{} {}<br />};<br /><br />void apply_lowpass(FilterState&amp; filter_state, const int16_t* input, int16_t* output, int length);
Here is the Java adaptation of the C code:
package com.example.perftest;<br /><br />import com.example.perftest.DspJavaManuallyOptimized.FilterState;<br /><br />public class DspJava {<br /><%%KEEPWHITESPACE%%>	public static class FilterState {<br /><%%KEEPWHITESPACE%%>		static final int size = 16;<br /><br /><%%KEEPWHITESPACE%%>		final double input[] = new double[size];<br /><%%KEEPWHITESPACE%%>		final double output[] = new double[size];<br /><br /><%%KEEPWHITESPACE%%>		int current;<br /><%%KEEPWHITESPACE%%>	}<br /><br /><%%KEEPWHITESPACE%%>	static short clamp(short input) {<br /><%%KEEPWHITESPACE%%>		return (short) Math.max(Short.MIN_VALUE, Math.min(Short.MAX_VALUE, input));<br /><%%KEEPWHITESPACE%%>	}<br /><br /><%%KEEPWHITESPACE%%>	static int getOffset(FilterState filterState, int relativeOffset) {<br /><%%KEEPWHITESPACE%%>		return ((filterState.current + relativeOffset) % FilterState.size + FilterState.size) % FilterState.size;<br /><%%KEEPWHITESPACE%%>	}<br /><br /><%%KEEPWHITESPACE%%>	static void pushSample(FilterState filterState, short sample) {<br /><%%KEEPWHITESPACE%%>		filterState.input[getOffset(filterState, 0)] = sample;<br /><%%KEEPWHITESPACE%%>		++filterState.current;<br /><%%KEEPWHITESPACE%%>	}<br /><br /><%%KEEPWHITESPACE%%>	static short getOutputSample(FilterState filterState) {<br /><%%KEEPWHITESPACE%%>		return clamp((short) filterState.output[getOffset(filterState, 0)]);<br /><%%KEEPWHITESPACE%%>	}<br /><br /><%%KEEPWHITESPACE%%>	static void applyLowpass(FilterState filterState) {<br /><%%KEEPWHITESPACE%%>		final double[] x = filterState.input;<br /><%%KEEPWHITESPACE%%>		final double[] y = filterState.output;<br /><br /><%%KEEPWHITESPACE%%>		y[getOffset(filterState, 0)] =<br /><%%KEEPWHITESPACE%%>		   (  1.0 * (1.0 / 6.928330802e+06) * (x[getOffset(filterState, -10)] + x[getOffset(filterState,  -0)]))<br /><%%KEEPWHITESPACE%%>		 + ( 10.0 * (1.0 / 6.928330802e+06) * (x[getOffset(filterState,  -9)] + x[getOffset(filterState,  -1)]))<br /><%%KEEPWHITESPACE%%>		 + ( 45.0 * (1.0 / 6.928330802e+06) * (x[getOffset(filterState,  -8)] + x[getOffset(filterState,  -2)]))<br /><%%KEEPWHITESPACE%%>		 + (120.0 * (1.0 / 6.928330802e+06) * (x[getOffset(filterState,  -7)] + x[getOffset(filterState,  -3)]))<br /><%%KEEPWHITESPACE%%>		 + (210.0 * (1.0 / 6.928330802e+06) * (x[getOffset(filterState,  -6)] + x[getOffset(filterState,  -4)]))<br /><%%KEEPWHITESPACE%%>		 + (252.0 * (1.0 / 6.928330802e+06) *  x[getOffset(filterState,  -5)])<br /><br /><%%KEEPWHITESPACE%%>		 + (  -0.4441854896 * y[getOffset(filterState, -10)])<br /><%%KEEPWHITESPACE%%>		 + (   4.2144719035 * y[getOffset(filterState,  -9)])<br /><%%KEEPWHITESPACE%%>		 + ( -18.5365677633 * y[getOffset(filterState,  -8)])<br /><%%KEEPWHITESPACE%%>		 + (  49.7394321983 * y[getOffset(filterState,  -7)])<br /><%%KEEPWHITESPACE%%>		 + ( -90.1491003509 * y[getOffset(filterState,  -6)])<br /><%%KEEPWHITESPACE%%>		 + ( 115.3235358151 * y[getOffset(filterState,  -5)])<br /><%%KEEPWHITESPACE%%>		 + (-105.4969191433 * y[getOffset(filterState,  -4)])<br /><%%KEEPWHITESPACE%%>		 + (  68.1964705422 * y[getOffset(filterState,  -3)])<br /><%%KEEPWHITESPACE%%>		 + ( -29.8484881821 * y[getOffset(filterState,  -2)])<br /><%%KEEPWHITESPACE%%>		 + (   8.0012026712 * y[getOffset(filterState,  -1)]);<br /><%%KEEPWHITESPACE%%>	}<br /><br /><%%KEEPWHITESPACE%%>	public static void applyLowpass(FilterState filterState, short[] input, short[] output, int length) {<br /><%%KEEPWHITESPACE%%>		for (int i = 0; i &lt; length; ++i) {<br /><%%KEEPWHITESPACE%%>			pushSample(filterState, input[i]);<br /><%%KEEPWHITESPACE%%>			applyLowpass(filterState);<br /><%%KEEPWHITESPACE%%>			output[i] = getOutputSample(filterState);<br /><%%KEEPWHITESPACE%%>		}<br /><%%KEEPWHITESPACE%%>	}<br />}
Since all of the Java runtimes tested don’t exploit static optimization opportunities as well as it seems that they could, here is an optimized version that has been inlined and has the modulo replaced with a bit mask:
package com.example.perftest;<br /><br />public class DspJavaManuallyOptimized {<br /><%%KEEPWHITESPACE%%>	public static class FilterState {<br /><%%KEEPWHITESPACE%%>		static final int size = 16;<br /><br /><%%KEEPWHITESPACE%%>		final double input[] = new double[size];<br /><%%KEEPWHITESPACE%%>		final double output[] = new double[size];<br /><br /><%%KEEPWHITESPACE%%>		int current;<br /><%%KEEPWHITESPACE%%>	}<br /><br /><%%KEEPWHITESPACE%%>	public static void applyLowpass(FilterState filterState, short[] input, short[] output, int length) {<br /><%%KEEPWHITESPACE%%>		for (int i = 0; i &lt; length; ++i) {<br /><%%KEEPWHITESPACE%%>			filterState.input[(filterState.current + 0) &amp; (FilterState.size - 1)] = input[i];<br /><%%KEEPWHITESPACE%%>			++filterState.current;<br /><%%KEEPWHITESPACE%%>			final double[] x = filterState.input;<br /><%%KEEPWHITESPACE%%>			final double[] y = filterState.output;<br /><br /><%%KEEPWHITESPACE%%>			y[(filterState.current + 0) &amp; (FilterState.size - 1)] =<br /><%%KEEPWHITESPACE%%>			   (  1.0 * (1.0 / 6.928330802e+06) * (x[(filterState.current + -10) &amp; (FilterState.size - 1)] + x[(filterState.current + -0) &amp; (FilterState.size - 1)]))<br /><%%KEEPWHITESPACE%%>			 + ( 10.0 * (1.0 / 6.928330802e+06) * (x[(filterState.current + -9) &amp; (FilterState.size - 1)] + x[(filterState.current + -1) &amp; (FilterState.size - 1)]))<br /><%%KEEPWHITESPACE%%>			 + ( 45.0 * (1.0 / 6.928330802e+06) * (x[(filterState.current + -8) &amp; (FilterState.size - 1)] + x[(filterState.current + -2) &amp; (FilterState.size - 1)]))<br /><%%KEEPWHITESPACE%%>			 + (120.0 * (1.0 / 6.928330802e+06) * (x[(filterState.current + -7) &amp; (FilterState.size - 1)] + x[(filterState.current + -3) &amp; (FilterState.size - 1)]))<br /><%%KEEPWHITESPACE%%>			 + (210.0 * (1.0 / 6.928330802e+06) * (x[(filterState.current + -6) &amp; (FilterState.size - 1)] + x[(filterState.current + -4) &amp; (FilterState.size - 1)]))<br /><%%KEEPWHITESPACE%%>			 + (252.0 * (1.0 / 6.928330802e+06) *  x[(filterState.current + -5) &amp; (FilterState.size - 1)])<br /><br /><%%KEEPWHITESPACE%%>			 + (  -0.4441854896 * y[(filterState.current + -10) &amp; (FilterState.size - 1)])<br /><%%KEEPWHITESPACE%%>			 + (   4.2144719035 * y[(filterState.current + -9) &amp; (FilterState.size - 1)])<br /><%%KEEPWHITESPACE%%>			 + ( -18.5365677633 * y[(filterState.current + -8) &amp; (FilterState.size - 1)])<br /><%%KEEPWHITESPACE%%>			 + (  49.7394321983 * y[(filterState.current + -7) &amp; (FilterState.size - 1)])<br /><%%KEEPWHITESPACE%%>			 + ( -90.1491003509 * y[(filterState.current + -6) &amp; (FilterState.size - 1)])<br /><%%KEEPWHITESPACE%%>			 + ( 115.3235358151 * y[(filterState.current + -5) &amp; (FilterState.size - 1)])<br /><%%KEEPWHITESPACE%%>			 + (-105.4969191433 * y[(filterState.current + -4) &amp; (FilterState.size - 1)])<br /><%%KEEPWHITESPACE%%>			 + (  68.1964705422 * y[(filterState.current + -3) &amp; (FilterState.size - 1)])<br /><%%KEEPWHITESPACE%%>			 + ( -29.8484881821 * y[(filterState.current + -2) &amp; (FilterState.size - 1)])<br /><%%KEEPWHITESPACE%%>			 + (   8.0012026712 * y[(filterState.current + -1) &amp; (FilterState.size - 1)]);<br /><%%KEEPWHITESPACE%%>			output[i] = (short) Math.max(Short.MIN_VALUE, Math.min(Short.MAX_VALUE, (short) filterState.output[(filterState.current + 0) &amp; (FilterState.size - 1)]));<br /><%%KEEPWHITESPACE%%>		}<br /><%%KEEPWHITESPACE%%>	}<br />}
Comment on the blog
Copyright © 2012
 
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
 The use of this feed on other websites that do not comply to the CC-BY-SA 3.0 breaches copyright. If this content is not in your news reader, the page you are viewing may be an infringement of the copyright. (Digital Fingerprint:
 e5945dcc83892602ba406e1f54f77ae6)
]]>
			http://www.learnopengles.com/a-performance-comparison-between-java-and-c-on-the-nexus-5/feed/
		3
		
		
		
		http://www.learnopengles.com/how-powerful-is-your-nexus-7/?utm_source=rss&utm_medium=rss&utm_campaign=how-powerful-is-your-nexus-7
		http://www.learnopengles.com/how-powerful-is-your-nexus-7/#comments
		Thu, 03 Apr 2014 18:09:46 +0000
		
				
		
		
		
		
		
		
		
		
		

		http://www.learnopengles.com/?p=2264
		
				The following post is based on a paper generously contributed by Jerome Huck, a senior aerospace/defence engineer, scientist, and author. A link to figures and the code can be found at the bottom of this post.

So you want to run some heavy-duty algorithms on your Android device, and you’re wondering what is the best environment to use, and whether your Nexus 7 tablet would be up to the job. In this post, based upon a paper generously contributed by Jerome Huck, a senior aerospace engineer & scientist, we’ll take a look at a test involving some heavy-duty computational fluid dynamics equations, and we’ll compare the execution times on a PC and a Nexus 7 tablet.
Implementation languages
Which language & development environment is the best fit? The Eclipse SDK is one obvious choice to go, with development usually done in Java. Unlocking additional performance through native C & C++ code can also be done via the Native Development Kit (NDK), though this adds complexity due to the mixing of Java, C/C++, and JNI glue code.
What if you want to develop directly on your device? Thanks to the openness of Google Play, there are many options available. The Java AIDE will allow you to write, compile and run programs directly on your Android tablet.
For native performance, C/C++ are available through C4DROID and CCTOOLS, an implementation of the GNU GCC 4.8.1 compiler. Fortran is also available for download from CCTOOLS’s menu.
Python development is available via QPython or Kivy. QPython implements the Python language but is still in beta stage; the Kivy Launcher enables you to run Kivy applications, an open source Python library for rapid development. Kivy applications can also make use of innovative user interfaces, including multi-touch apps.
So, just how powerful is your Nexus 7? Java, Basic, C/C++, Python and Fortran all seem like good candidates to evaluate the power of a Nexus 7 with a test case.
The Test Case
The test developed by Jerome involves some heavy-duty math, of the type often employed by scientists and engineers. Here are the details, as specified by Jerome and edited for formatting within this post:
For evaluating the performance, let’s use a test case using computational fluid dynamics algorithms, including Navier-Stokes fluid equations, the Maxwell electromagnetism equations, forming the magnetohydrodynamics (MHD) set of equations. The original Fortran code was published in An Introduction to Computational Fluid Mechanics by Chuen-Yen-Chow, in 1983. The MHD stationary flow calculation is no longer included in the 2011 update by Biringen and Chow, but the details pertaining to the equations discretization, stability analysis, and so on can still be found in their Benard and Taylor instabilities example of the instationary solution of Navier-Stokes equations coupled with the temperature equation.
For simplicity, a stream-vorticity formulation is used. Standard boundary conditions, or even simplified ones, are used, with a value or derivative given. Discretization of the nonlinear terms in the Navier-Stokes, the one involving the velocity components, was, historically, a source of problems. The numerical scheme has to properly capture the flow direction.
Upwind differencing form solves this problem. The spatial difference is on the upwind side of the point indexed (i,j). This numerical scheme is only first order by reference to a Taylor series expansion. The second order upwind schemes introduces non physical behaviour, such as oscillations. Total Variation Diminishing (TVD) schemes are a cure to this problem. They introduce stable, non-oscillatory, high order schemes, preserving monotonicity, with no overshot or undershoot for the solution. They are the result of more than 30 years of research in CFD.
Only the upwind scheme was present in the original Fortran code. It was rewritten using a general TVD formulation. Corner Transport Upwind (CTU) was also added as an experiment, and not fully tested. Details can be in good CFD books such as An Introduction to Computational Fluid Dynamics: The Finite Volume Method (2nd Edition) by Versteeg and Malalasekera, or Finite Volume Methods for Hyperbolic Problems by Leveque.
The solution procedure is straightforward. The current flow, RH variable, is solved via the Laplace equation solver. Then the electromagnetic force, EM variable, is computed. Time stepping is used to find the solution of the flow until the convergence criteria are matched, error or maximum step. A Poisson solver is used.
Comments are given in the Fortran source code.
The results are presented for a Reynolds number of 50, a magnetic pressure number C of 0.3, using the upwind scheme.
Execution times on a PC
Before looking at the Nexus 7 results, let’s first compare the results on the PC. Here are the results that Jerome obtained on a i3 2.1 GHz laptop, running Windows 7 64-bit:



 


GNU Fortran
62ms


GNU GCC
78ms


Oracle Java JDK 7u45
150ms


PyPy 2.0
1020ms


Python 3.3.2
6780ms



For this particular run, Fortran is the best, with C a close second; the Java JDK also put in a good showing here. The interpreted languages are very disappointing, as expected.
Even with the slower execution times, some scientists are still moving some their code to Python; they want to benefit from the scripting capabilities of interpreted languages. Users don’t need to edit the source code to change the boundary equations or add a subroutine to solve a particular equation. FiPy, a finite volume code from NIST, uses this approach. However, most of the critical parts are still written in C or in Fortran.
Another approach is to use a dedicated language such the one implemented in FreeFem++, a partial differential equation solver. With this tool, a problem with one billion unknowns was solved in 2 minutes on the Curie Thin Node, a CEA machine. The CEA is the French Atomic Energy and Alternative Energies Commission.
What does the Nexus 7 has to offer?
Let’s now take a look at the results on a 1.2 GHz 2012 Nexus 7; the 2013 model, with its Qualcomm Snapdragon S4 Pro at 1.5 GHz, may boost these results a step further.



 


Fortran CCTOOLS with -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3 -03
70ms


Fortran CCTOOLS with -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3 -02
79ms


C99 C4DROID with -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3 -02 (64-bit floats)
120ms


C99 C4DROID with -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3 (32-bit floats)
380ms


C99 C4DROID with mfloat-abi=softfp (32-bit floats)
394ms


C99 C4DROID with -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3 (32-bit floats)
420ms


C99 C4DROID with mfloat-abi=softfp (64-bit floats)
450ms


C4DROID with -msoft-float (32-bit floats)
1163ms


C4DROID with -msoft-float (64-bit floats)
1500ms


Java compiled with Eclipse
1563ms


Java AIDE with dex optimizations
2100ms


Java AIDE
3030ms


QPython
24702ms



These are the best execution times. Some variance was seen with C4DROID, while CCTOOLS was more stable overall. As before, we can see the same ranking, with Fortran emerging as the leader, and C, Java, and Python following behind. With the proper compiler flags, CCTOOLS Fortran is even competitive against the PC, which is a very good result.
The Java results, on the other hand, are quite bad. Is it a fault of the Dalvik virtual machine? Results may improve with the ART runtime, but they’d have to improve dramatically to come close to the performance of optimized FORTRAN and C.
Python, with an execution time of over 24 seconds, can definitely be forgotten for serious scientific computations.
Verdict
The Nexus 7 2012 is very powerful on this particular test, when running Fortran or C code compiled to native machine code. Can these good results be extrapolated to more demanding programs, and software that needs more time to run?
The Nexus 7 tablets are very high-quality products, and Android is a smart and fun operating system to use. The 2012 model is already quite powerful, and the 2013 should see even better results; all that’s needed is a dedicated approach to unleash the power sleeping within those processors.
Paper, equations, and code
This blog post is based on work generously contributed by Jerome Huck, a senior aerospace/defence engineer, scientist, and author. Jerome graduated from the École nationale supérieure de l’aéronautique et de l’espace in Toulouse, and has worked on various projects including the Hermes space shuttle, Rafale fighter, and is the author of “The Fire of the Magicians“.


Comment on the blog
Copyright © 2012
 
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
 The use of this feed on other websites that do not comply to the CC-BY-SA 3.0 breaches copyright. If this content is not in your news reader, the page you are viewing may be an infringement of the copyright. (Digital Fingerprint:
 e5945dcc83892602ba406e1f54f77ae6)
]]>
			http://www.learnopengles.com/how-powerful-is-your-nexus-7/feed/
		1
		
		
		
		http://www.learnopengles.com/finishing-up-our-native-air-hockey-project-with-touch-events-and-basic-collision-detection/?utm_source=rss&utm_medium=rss&utm_campaign=finishing-up-our-native-air-hockey-project-with-touch-events-and-basic-collision-detection
		http://www.learnopengles.com/finishing-up-our-native-air-hockey-project-with-touch-events-and-basic-collision-detection/#comments
		Fri, 08 Nov 2013 14:51:43 +0000
		
				
		
		
		
		
		
		
		
		
		
		
		
		

		http://www.learnopengles.com/?p=2200
		
				In this post in the air hockey series, we’re going to wrap up our air hockey project and add touch event handling and basic collision detection with support for Android, iOS, and emscripten.

Prerequisites
This lesson continues the air hockey project series, building upon the code from GitHub for ‘article-3-matrices-and-objects’. Here are the previous posts in this series:
Setting up a simple build system

Calling OpenGL from C on Android by using the NDK
Calling OpenGL from C on iOS, Sharing Common Code with Android
Calling OpenGL from C on the Web by Using Emscripten, Sharing Common Code with Android and iOS

Adding support for PNG loading into a texture

Loading a PNG into Memory and Displaying It as a Texture with OpenGL ES 2, Using (Almost) the Same Code on iOS, Android, and Emscripten
Loading a PNG into Memory and Displaying It as a Texture with OpenGL ES 2: Adding Support for iOS
Loading a PNG into Memory and Displaying It as a Texture with OpenGL ES 2: Adding Support for Emscripten

Adding a 3d perspective, mallets, and a puck

Adding a 3d Perspective and Object Rendering to Our Air Hockey Project in Native C Code

Updating our game code for touch interaction
The first thing we’ll do is update the core to add touch interaction to the game. We’ll first need to add some helper functions to a new core file called geometry.h.
geometry.h
Let’s start off with the following code:
#include "linmath.h"
#include

typedef struct {
	vec3 point;
	vec3 vector;
} Ray;

typedef struct {
	vec3 point;
	vec3 normal;
} Plane;

typedef struct {
	vec3 center;
	float radius;
} Sphere;
These are a few typedefs that build upon linmath.h to add a few basic types that we’ll use in our code. Let’s wrap up geometry.h:
static inline int sphere_intersects_ray(Sphere sphere, Ray ray);
static inline float distance_between(vec3 point, Ray ray);
static inline void ray_intersection_point(vec3 result, Ray ray, Plane plane);

static inline int sphere_intersects_ray(Sphere sphere, Ray ray) {
	if (distance_between(sphere.center, ray) < sphere.radius)
		return 1;
	return 0;
}

static inline float distance_between(vec3 point, Ray ray) {
	vec3 p1_to_point;
	vec3_sub(p1_to_point, point, ray.point);
	vec3 p2_to_point;
	vec3 translated_ray_point;
	vec3_add(translated_ray_point, ray.point, ray.vector);
	vec3_sub(p2_to_point, point, translated_ray_point);

	// The length of the cross product gives the area of an imaginary
	// parallelogram having the two vectors as sides. A parallelogram can be
	// thought of as consisting of two triangles, so this is the same as
	// twice the area of the triangle defined by the two vectors.
	// http://en.wikipedia.org/wiki/Cross_product#Geometric_meaning
	vec3 cross_product;
	vec3_mul_cross(cross_product, p1_to_point, p2_to_point);
	float area_of_triangle_times_two = vec3_len(cross_product);
	float length_of_base = vec3_len(ray.vector);

	// The area of a triangle is also equal to (base * height) / 2. In
	// other words, the height is equal to (area * 2) / base. The height
	// of this triangle is the distance from the point to the ray.
	float distance_from_point_to_ray = area_of_triangle_times_two / length_of_base;
	return distance_from_point_to_ray;
}

// http://en.wikipedia.org/wiki/Line-plane_intersection
// This also treats rays as if they were infinite. It will return a
// point full of NaNs if there is no intersection point.
static inline void ray_intersection_point(vec3 result, Ray ray, Plane plane) {
	vec3 ray_to_plane_vector;
	vec3_sub(ray_to_plane_vector, plane.point, ray.point);

	float scale_factor = vec3_mul_inner(ray_to_plane_vector, plane.normal)
					   / vec3_mul_inner(ray.vector, plane.normal);

	vec3 intersection_point;
	vec3 scaled_ray_vector;
	vec3_scale(scaled_ray_vector, ray.vector, scale_factor);
	vec3_add(intersection_point, ray.point, scaled_ray_vector);
	memcpy(result, intersection_point, sizeof(intersection_point));
}
We’ll do a line-sphere intersection test to see if we’ve touched the mallet using our fingers or a mouse. Once we’ve grabbed the mallet, we’ll do a line-plane intersection test to determine where to place the mallet on the board.
game.h
We’ll need two new function prototypes in game.h:
void on_touch_press(float normalized_x, float normalized_y);
void on_touch_drag(float normalized_x, float normalized_y);
game.c
Now we can begin the implementation in game.c. Add the following in the appropriate places to the top of the file:
#include "geometry.h"
// ...
static const float puck_radius = 0.06f;
static const float mallet_radius = 0.08f;

static const float left_bound = -0.5f;
static const float right_bound = 0.5f;
static const float far_bound = -0.8f;
static const float near_bound = 0.8f;
// ...
static mat4x4 inverted_view_projection_matrix;

static int mallet_pressed;
static vec3 blue_mallet_position;
static vec3 previous_blue_mallet_position;
static vec3 puck_position;
static vec3 puck_vector;

static Ray convert_normalized_2D_point_to_ray(float normalized_x, float normalized_y);
static void divide_by_w(vec4 vector);
static float clamp(float value, float min, float max);
We’ll now begin with the code for handling a touch press:
void on_touch_press(float normalized_x, float normalized_y) {
	Ray ray = convert_normalized_2D_point_to_ray(normalized_x, normalized_y);

	// Now test if this ray intersects with the mallet by creating a
	// bounding sphere that wraps the mallet.
	Sphere mallet_bounding_sphere = (Sphere) {
	   {blue_mallet_position[0],
		blue_mallet_position[1],
		blue_mallet_position[2]},
	mallet_height / 2.0f};

	// If the ray intersects (if the user touched a part of the screen that
	// intersects the mallet's bounding sphere), then set malletPressed =
	// true.
	mallet_pressed = sphere_intersects_ray(mallet_bounding_sphere, ray);
}

static Ray convert_normalized_2D_point_to_ray(float normalized_x, float normalized_y) {
	// We'll convert these normalized device coordinates into world-space
	// coordinates. We'll pick a point on the near and far planes, and draw a
	// line between them. To do this transform, we need to first multiply by
	// the inverse matrix, and then we need to undo the perspective divide.
	vec4 near_point_ndc = {normalized_x, normalized_y, -1, 1};
	vec4 far_point_ndc = {normalized_x, normalized_y,  1, 1};

    vec4 near_point_world, far_point_world;
    mat4x4_mul_vec4(near_point_world, inverted_view_projection_matrix, near_point_ndc);
    mat4x4_mul_vec4(far_point_world, inverted_view_projection_matrix, far_point_ndc);

	// Why are we dividing by W? We multiplied our vector by an inverse
	// matrix, so the W value that we end up is actually the *inverse* of
	// what the projection matrix would create. By dividing all 3 components
	// by W, we effectively undo the hardware perspective divide.
    divide_by_w(near_point_world);
    divide_by_w(far_point_world);

	// We don't care about the W value anymore, because our points are now
	// in world coordinates.
	vec3 near_point_ray = {near_point_world[0], near_point_world[1], near_point_world[2]};
	vec3 far_point_ray = {far_point_world[0], far_point_world[1], far_point_world[2]};
	vec3 vector_between;
	vec3_sub(vector_between, far_point_ray, near_point_ray);
	return (Ray) {
		{near_point_ray[0], near_point_ray[1], near_point_ray[2]},
		{vector_between[0], vector_between[1], vector_between[2]}};
}

static void divide_by_w(vec4 vector) {
	vector[0] /= vector[3];
	vector[1] /= vector[3];
	vector[2] /= vector[3];
}
This code first takes normalized touch coordinates which it receives from the Android, iOS or emscripten front ends, and then turns those touch coordinates into a 3D ray in world space. It then intersects the 3D ray with a bounding sphere for the mallet to see if we’ve touched the mallet.
Let’s continue with the code for handling a touch drag:
void on_touch_drag(float normalized_x, float normalized_y) {
	if (mallet_pressed == 0)
		return;

	Ray ray = convert_normalized_2D_point_to_ray(normalized_x, normalized_y);
	// Define a plane representing our air hockey table.
	Plane plane = (Plane) {{0, 0, 0}, {0, 1, 0}};

	// Find out where the touched point intersects the plane
	// representing our table. We'll move the mallet along this plane.
	vec3 touched_point;
	ray_intersection_point(touched_point, ray, plane);

	memcpy(previous_blue_mallet_position, blue_mallet_position,
		sizeof(blue_mallet_position));

	// Clamp to bounds
	blue_mallet_position[0] =
		clamp(touched_point[0], left_bound + mallet_radius, right_bound - mallet_radius);
	blue_mallet_position[1] = mallet_height / 2.0f;
	blue_mallet_position[2] =
		clamp(touched_point[2], 0.0f + mallet_radius, near_bound - mallet_radius);

	// Now test if mallet has struck the puck.
	vec3 mallet_to_puck;
	vec3_sub(mallet_to_puck, puck_position, blue_mallet_position);
	float distance = vec3_len(mallet_to_puck);

	if (distance < (puck_radius + mallet_radius)) {
		// The mallet has struck the puck. Now send the puck flying
		// based on the mallet velocity.
		vec3_sub(puck_vector, blue_mallet_position, previous_blue_mallet_position);
	}
}

static float clamp(float value, float min, float max) {
	return fmin(max, fmax(value, min));
}
Once we’ve grabbed the mallet, we move it across the air hockey table by intersecting the new touch point with the table to determine the new position on the table. We then move the mallet to that new position. We also check if the mallet has struck the puck, and if so, we use the movement distance to calculate the puck’s new velocity.
We next need to update the lines that initialize our objects inside on_surface_created() as follows:
puck = create_puck(puck_radius, puck_height, 32, puck_color);
	red_mallet = create_mallet(mallet_radius, mallet_height, 32, red);
	blue_mallet = create_mallet(mallet_radius, mallet_height, 32, blue);

	blue_mallet_position[0] = 0;
	blue_mallet_position[1] = mallet_height / 2.0f;
	blue_mallet_position[2] = 0.4f;
	puck_position[0] = 0;
	puck_position[1] = puck_height / 2.0f;
	puck_position[2] = 0;
	puck_vector[0] = 0;
	puck_vector[1] = 0;
	puck_vector[2] = 0;
The new linmath.h has merged in the custom code we added to our matrix_helper.h, so we no longer need that file. As part of those changes, our perspective method call in on_surface_changed() now needs the angle entered in radians, so let’s update that method call as follows:
mat4x4_perspective(projection_matrix, deg_to_radf(45),
	(float) width / (float) height, 1.0f, 10.0f);
We can then update on_draw_frame() to add the new movement code. Let’s first add the following to the top, right after the call to glClear():
// Translate the puck by its vector
	vec3_add(puck_position, puck_position, puck_vector);

	// If the puck struck a side, reflect it off that side.
	if (puck_position[0] < left_bound + puck_radius 
	 || puck_position[0] > right_bound - puck_radius) {
		puck_vector[0] = -puck_vector[0];
		vec3_scale(puck_vector, puck_vector, 0.9f);
	}
	if (puck_position[2] < far_bound + puck_radius
	 || puck_position[2] > near_bound - puck_radius) {
		puck_vector[2] = -puck_vector[2];
		vec3_scale(puck_vector, puck_vector, 0.9f);
	}

	// Clamp the puck position.
	puck_position[0] = 
		clamp(puck_position[0], left_bound + puck_radius, right_bound - puck_radius);
	puck_position[2] = 
		clamp(puck_position[2], far_bound + puck_radius, near_bound - puck_radius);

	// Friction factor
	vec3_scale(puck_vector, puck_vector, 0.99f);
This code will update the puck’s position and cause it to go bouncing around the table. We’ll also need to add the following after the call to mat4x4_mul(view_projection_matrix, projection_matrix, view_matrix);:
mat4x4_invert(inverted_view_projection_matrix, view_projection_matrix);
This sets up the inverted view projection matrix, which we need for turning the normalized touch coordinates back into world space coordinates.
Let’s finish up the changes to game.c by updating the following calls to position_object_in_scene():
position_object_in_scene(blue_mallet_position[0], blue_mallet_position[1],
	blue_mallet_position[2]);
// ...
position_object_in_scene(puck_position[0], puck_position[1], puck_position[2]);
Adding touch events to Android
With these changes in place, we now need to link in the touch events from each platform. We’ll start off with Android:
MainActivity.java
In MainActivity.java, we first need to update the way that we create the renderer in onCreate():
final RendererWrapper rendererWrapper = new RendererWrapper(this);
// ...
glSurfaceView.setRenderer(rendererWrapper);
Let’s add the touch listener:
glSurfaceView.setOnTouchListener(new OnTouchListener() {
@Override
public boolean onTouch(View v, MotionEvent event) {
	if (event != null) {
		// Convert touch coordinates into normalized device
		// coordinates, keeping in mind that Android's Y
		// coordinates are inverted.
		final float normalizedX = (event.getX() / (float) v.getWidth()) * 2 - 1;
		final float normalizedY = -((event.getY() / (float) v.getHeight()) * 2 - 1);

		if (event.getAction() == MotionEvent.ACTION_DOWN) {
			glSurfaceView.queueEvent(new Runnable() {
			@Override
			public void run() {
				rendererWrapper.handleTouchPress(normalizedX, normalizedY);
			}});
		} else if (event.getAction() == MotionEvent.ACTION_MOVE) {
			glSurfaceView.queueEvent(new Runnable() {
			@Override
			public void run() {
				rendererWrapper.handleTouchDrag(normalizedX, normalizedY);
			}});
		}

		return true;
	} else {
		return false;
	}
}});
This touch listener takes the incoming touch events from the user, converts them into normalized coordinates in OpenGL’s normalized device coordinate space, and then calls the renderer wrapper which will pass the event on into our native code.
RendererWrapper.java
We’ll need to add the following to RendererWrapper.java:
public void handleTouchPress(float normalizedX, float normalizedY) {
		on_touch_press(normalizedX, normalizedY);
	}

	public void handleTouchDrag(float normalizedX, float normalizedY) {
		on_touch_drag(normalizedX, normalizedY);
	}

	private static native void on_touch_press(float normalized_x, float normalized_y);

	private static native void on_touch_drag(float normalized_x, float normalized_y);
renderer_wrapper.c
We’ll also need to add the following to renderer_wrapper.c in our jni folder:
JNIEXPORT void JNICALL Java_com_learnopengles_airhockey_RendererWrapper_on_1touch_1press(
	JNIEnv* env, jclass cls, jfloat normalized_x, jfloat normalized_y) {
	UNUSED(env);
	UNUSED(cls);
	on_touch_press(normalized_x, normalized_y);
}

JNIEXPORT void JNICALL Java_com_learnopengles_airhockey_RendererWrapper_on_1touch_1drag(
	JNIEnv* env, jclass cls, jfloat normalized_x, jfloat normalized_y) {
	UNUSED(env);
	UNUSED(cls);
	on_touch_drag(normalized_x, normalized_y);
}
We now have everything in place for Android, and if we run the app, it should look similar to as seen below:
Air Hockey with touch, running on a Galaxy Nexus
Adding support for iOS
To add support for iOS, we need to update ViewController.m and add support for touch events. To do that and update the frame rate at the same time, let’s add the following to viewDidLoad: before the call to [self setupGL]:
view.userInteractionEnabled = YES;
self.preferredFramesPerSecond = 60;
To listen to the touch events, we need to override a few methods. Let’s add the following methods before - (void)glkView:(GLKView *)view drawInRect:(CGRect)rect:
static CGPoint getNormalizedPoint(UIView* view, CGPoint locationInView)
{
    const float normalizedX = (locationInView.x / view.bounds.size.width) * 2.f - 1.f;
    const float normalizedY = -((locationInView.y / view.bounds.size.height) * 2.f - 1.f);
    return CGPointMake(normalizedX, normalizedY);
}

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
    [super touchesBegan:touches withEvent:event];
    UITouch* touchEvent = [touches anyObject];
    CGPoint locationInView = [touchEvent locationInView:self.view];
    CGPoint normalizedPoint = getNormalizedPoint(self.view, locationInView);
    on_touch_press(normalizedPoint.x, normalizedPoint.y);
}

- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event
{
    [super touchesMoved:touches withEvent:event];
    UITouch* touchEvent = [touches anyObject];
    CGPoint locationInView = [touchEvent locationInView:self.view];
    CGPoint normalizedPoint = getNormalizedPoint(self.view, locationInView);
    on_touch_drag(normalizedPoint.x, normalizedPoint.y);
}

- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event
{
    [super touchesEnded:touches withEvent:event];
}

- (void)touchesCancelled:(NSSet *)touches withEvent:(UIEvent *)event
{
    [super touchesCancelled:touches withEvent:event];
}
This is similar to the Android code in that it takes the input touch event, converts it to OpenGL’s normalized device coordinate space, and then sends it on to our game code.
Our iOS app should look similar to the following image:
Air Hockey with touch, on iOS
Adding support for emscripten
Adding support for emscripten is just as easy. Let’s first add the following to the top of main.c:
static void handle_input();
// ...
int is_dragging;
At the beginning of do_frame(), add a call to handle_input();:
static void do_frame()
{
	handle_input();
	// ...
Add the following for handle_input:
static void handle_input()
{
	glfwPollEvents();
	const int left_mouse_button_state = glfwGetMouseButton(GLFW_MOUSE_BUTTON_1);
	if (left_mouse_button_state == GLFW_PRESS) {
		int x_pos, y_pos;
		glfwGetMousePos(&x_pos, &y_pos);
		const float normalized_x = ((float)x_pos / (float) width) * 2.f - 1.f;
	    const float normalized_y = -(((float)y_pos / (float) height) * 2.f - 1.f);

		if (is_dragging == 0) {
			is_dragging = 1;
			on_touch_press(normalized_x, normalized_y);
		} else {
			on_touch_drag(normalized_x, normalized_y);
		}
	} else {
		is_dragging = 0;
	}
}
This code sets is_dragging depending on whether we just clicked the primary mouse button or if we’re currently dragging the mouse. Depending on the case, we’ll call either on_touch_press or  on_touch_drag. The code to normalize the coordinates is the same as in Android and iOS, and indeed a case could be made to abstract out into the common game code, and just pass in the raw coordinates relative to the view size to that game code.
After compiling with emcc make, we should get output similar to the below:

Exploring further
That concludes our air hockey project! The full source code for this lesson can be found at the GitHub project. You can find a more in-depth look at the concepts behind the project from the perspective of Java Android in OpenGL ES 2 for Android: A Quick-Start Guide. For exploring further, there are many things you could add, like improved graphics, support for sound, a simple AI, multiplayer (on the same device), scoring, or a menu system.
Whether you end up using a commercial cross-platform solution like Unity or Corona, or whether you decide to go the independent route, I hope this series was helpful to you and most importantly, that you enjoy your future projects ahead and have a lot of fun with them.  
Comment on the blog
Copyright © 2012
 
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
 The use of this feed on other websites that do not comply to the CC-BY-SA 3.0 breaches copyright. If this content is not in your news reader, the page you are viewing may be an infringement of the copyright. (Digital Fingerprint:
 e5945dcc83892602ba406e1f54f77ae6)
]]>
			http://www.learnopengles.com/finishing-up-our-native-air-hockey-project-with-touch-events-and-basic-collision-detection/feed/
		1
		
		
		
		http://www.learnopengles.com/opengl-roundup-november-4-2013/?utm_source=rss&utm_medium=rss&utm_campaign=opengl-roundup-november-4-2013
		http://www.learnopengles.com/opengl-roundup-november-4-2013/#comments
		Mon, 04 Nov 2013 18:55:43 +0000
		
				
		
		
		
		
		

		http://www.learnopengles.com/?p=2193
		
				Android 4.4 for Game Developers

APPS WORLD LONDON 2013
New Adventures in C++ with Cinder and More
Objectively Stylish – The NYTimes Objective-C style guide.
Vivante Unveils Less than 1 mm2 OpenGL ES 2.0 GPU for Wearables and Internet of Things (IoT) Devices
Why use a Graphics Library instead of an Engine? (Ex: OpenGL vs Unity) – Graphics Programming and Theory – GameDev.net
From the libgdx blog: “Intel Developer Zone and BeMyApp are holding a couple of code fests over the next few weeks in Berlin, New York and Santa Clara. During these events, Intel will help you port your Android apps using native code to x86, free of charge!”
Check out the source code for the new acko.net front end: https://github.com/unconed/fuse10/.
Comment on the blog
Copyright © 2012
 
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
 The use of this feed on other websites that do not comply to the CC-BY-SA 3.0 breaches copyright. If this content is not in your news reader, the page you are viewing may be an infringement of the copyright. (Digital Fingerprint:
 e5945dcc83892602ba406e1f54f77ae6)
]]>
			http://www.learnopengles.com/opengl-roundup-november-4-2013/feed/
		0
		
		
		
		http://www.learnopengles.com/opengl-roundup-october-28-2013-narasimha-live-wallpaper-military-mobile-and-more/?utm_source=rss&utm_medium=rss&utm_campaign=opengl-roundup-october-28-2013-narasimha-live-wallpaper-military-mobile-and-more
		http://www.learnopengles.com/opengl-roundup-october-28-2013-narasimha-live-wallpaper-military-mobile-and-more/#comments
		Mon, 28 Oct 2013 17:17:58 +0000
		
				
		
		
		

		http://www.learnopengles.com/?p=2170
		
				This time around, we have some new live wallpapers as well as a new Android application using OpenGL ES 2.0. Check them out below…

3D Ganesh Live Wallpaper

https://play.google.com/store/apps/details?id=com.justharinama.ganeshlivewallpaper
3D Narasimha Live Wallpaper

https://play.google.com/store/apps/details?id=com.justharinaam.narasimha
3D Jagannath Live Wallpaper

https://play.google.com/store/apps/details?id=com.justharinama.skynormalwall
Military Mobile
Military Mobile features accurate information regarding Military Bases, Military Ribbons, and Military Ranks. Military Mobile also comes with quizzes on US Military subject matter, as well as a rich set of social features.
  
 

https://play.google.com/store/apps/details?id=com.savageking.empireofbases

You can also check out the Facebook page here.
 

Until next time!
Comment on the blog
Copyright © 2012
 
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
 The use of this feed on other websites that do not comply to the CC-BY-SA 3.0 breaches copyright. If this content is not in your news reader, the page you are viewing may be an infringement of the copyright. (Digital Fingerprint:
 e5945dcc83892602ba406e1f54f77ae6)
]]>
			http://www.learnopengles.com/opengl-roundup-october-28-2013-narasimha-live-wallpaper-military-mobile-and-more/feed/
		0
		
		
		
		http://www.learnopengles.com/opengl-roundup-october-1-2013-hexscreen-3d-live-wallpaper-and-more/?utm_source=rss&utm_medium=rss&utm_campaign=opengl-roundup-october-1-2013-hexscreen-3d-live-wallpaper-and-more
		http://www.learnopengles.com/opengl-roundup-october-1-2013-hexscreen-3d-live-wallpaper-and-more/#comments
		Fri, 20 Sep 2013 14:58:15 +0000
		
				
		
		
		
		
		

		http://www.learnopengles.com/?p=2157
		
				A fellow developer and blogger, Hisham, has released his Hexscreen 3D Live Wallpaper to the market, and it looks quite cool. Check it out:




The wallpaper can be downloaded from Google Play.
In other news…
Libgdx and Bullet Physics on iOS via RoboVM
Comment on the blog
Copyright © 2012
 
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
 The use of this feed on other websites that do not comply to the CC-BY-SA 3.0 breaches copyright. If this content is not in your news reader, the page you are viewing may be an infringement of the copyright. (Digital Fingerprint:
 e5945dcc83892602ba406e1f54f77ae6)
]]>
			http://www.learnopengles.com/opengl-roundup-october-1-2013-hexscreen-3d-live-wallpaper-and-more/feed/
		0
		
		
		
		http://www.learnopengles.com/opengl-roundup-september-19-2013/?utm_source=rss&utm_medium=rss&utm_campaign=opengl-roundup-september-19-2013
		http://www.learnopengles.com/opengl-roundup-september-19-2013/#comments
		Thu, 19 Sep 2013 15:30:19 +0000
		
				
		
		
		
		
		
		
		
		

		http://www.learnopengles.com/?p=2107
		
				Here’s the beginning of a new series on OpenGL ES 2.0 for iOS, using Apple’s GLKit.


GLKit to the max: OpenGL ES 2.0 for iOS – Part 1: GLKit Features
OpenGL ES 2: How does it draw?

ROBOVM BACKEND IN LIBGDX NIGHTLIES AND FIRST PERFORMANCE FIGURES! - Libgdx is moving to a new backend for iOS that uses RoboVM, a Java to machine code compiler for iOS. Initial performance figures look good!
Zero to Sixty in One Second - the developer & designer behind acko.net has redesigned his header and website using WebGL, and I have to say that it looks very cool.
And now for something completely different…
Using runtime-compiled C++ code as a scripting language.
Comment on the blog
Copyright © 2012
 
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
 The use of this feed on other websites that do not comply to the CC-BY-SA 3.0 breaches copyright. If this content is not in your news reader, the page you are viewing may be an infringement of the copyright. (Digital Fingerprint:
 e5945dcc83892602ba406e1f54f77ae6)
]]>
			http://www.learnopengles.com/opengl-roundup-september-19-2013/feed/
		0
		
		
		
		http://www.learnopengles.com/adding-a-3d-perspective-and-object-rendering-to-our-air-hockey-project-in-native-c-code/?utm_source=rss&utm_medium=rss&utm_campaign=adding-a-3d-perspective-and-object-rendering-to-our-air-hockey-project-in-native-c-code
		http://www.learnopengles.com/adding-a-3d-perspective-and-object-rendering-to-our-air-hockey-project-in-native-c-code/#comments
		Wed, 18 Sep 2013 11:45:27 +0000
		
				
		
		
		
		
		
		
		
		
		
		
		

		http://www.learnopengles.com/?p=2111
		
				For this post in the air hockey series, we’ll learn how to render our scene from a 3D perspective, as well as how to add a puck and two mallets to the scene. We’ll also see how easy it is to bring these changes to Android, iOS, and emscripten.

Prerequisites
This lesson continues the air hockey project series, building upon the code from GitHub for ‘article-2-loading-png-file’. Here are the previous posts in this series:
Setting up a simple build system

Calling OpenGL from C on Android by using the NDK
Calling OpenGL from C on iOS, Sharing Common Code with Android
Calling OpenGL from C on the Web by Using Emscripten, Sharing Common Code with Android and iOS

Adding support for PNG loading into a texture

Loading a PNG into Memory and Displaying It as a Texture with OpenGL ES 2, Using (Almost) the Same Code on iOS, Android, and Emscripten
Loading a PNG into Memory and Displaying It as a Texture with OpenGL ES 2: Adding Support for iOS
Loading a PNG into Memory and Displaying It as a Texture with OpenGL ES 2: Adding Support for Emscripten

Adding support for a matrix library
The first thing we’ll do is add support for a matrix library so we can use the same matrix math on all three platforms, and then we’ll introduce the changes to our code from the top down. There are a lot of libraries out there, so I decided to use linmath.h by Wolfgang Draxinger for its simplicity and compactness. Since it’s on GitHub, we can easily add it to our project by running the following git command from the root airhockey/ folder:
git submodule add https://github.com/datenwolf/linmath.h.git src/3rdparty/linmath
Updating our game code
We’ll introduce all of the changes from the top down, so let’s begin by replacing everything inside game.c as follows:
Headers and declarations
#include "game.h"
#include "game_objects.h"
#include "asset_utils.h"
#include "buffer.h"
#include "image.h"
#include "linmath.h"
#include "math_helper.h"
#include "matrix.h"
#include "platform_gl.h"
#include "platform_asset_utils.h"
#include "program.h"
#include "shader.h"
#include "texture.h"

static const float puck_height = 0.02f;
static const float mallet_height = 0.15f;

static Table table;
static Puck puck;
static Mallet red_mallet;
static Mallet blue_mallet;

static TextureProgram texture_program;
static ColorProgram color_program;

static mat4x4 projection_matrix;
static mat4x4 model_matrix;
static mat4x4 view_matrix;

static mat4x4 view_projection_matrix;
static mat4x4 model_view_projection_matrix;

static void position_table_in_scene();
static void position_object_in_scene(float x, float y, float z);
We’ve added all of the new includes, constants, variables, and function declarations that we’ll need for our new game code. We’ll use Table, Puck, and Mallet to represent our drawable objects, TextureProgram and ColorProgram to represent our shader programs, and the mat4x4 (a datatype from linmath.h) matrices for our OpenGL matrices. In our draw loop, we’ll call position_table_in_scene() to position the table, and position_object_in_scene() to position our other objects.
For those of you who have also followed the Java tutorials from OpenGL ES 2 for Android: A Quick-Start Guide, you’ll recognize that this has a lot in common with the air hockey project from the first part of the book. The code for that project can be freely downloaded from The Pragmatic Bookshelf.
on_surface_created()
void on_surface_created() {
	glClearColor(0.0f, 0.0f, 0.0f, 0.0f);
	glEnable(GL_DEPTH_TEST);

	table = create_table(
		load_png_asset_into_texture("textures/air_hockey_surface.png"));

	vec4 puck_color = {0.8f, 0.8f, 1.0f, 1.0f};
	vec4 red = {1.0f, 0.0f, 0.0f, 1.0f};
	vec4 blue = {0.0f, 0.0f, 1.0f, 1.0f};

	puck = create_puck(0.06f, puck_height, 32, puck_color);
	red_mallet = create_mallet(0.08f, mallet_height, 32, red);
	blue_mallet = create_mallet(0.08f, mallet_height, 32, blue);

	texture_program = get_texture_program(build_program_from_assets(
		"shaders/texture_shader.vsh", "shaders/texture_shader.fsh"));
	color_program = get_color_program(build_program_from_assets(
		"shaders/color_shader.vsh", "shaders/color_shader.fsh"));
}
Our new on_surface_created() enables depth-testing, initializes the table, puck, and mallets, and loads in the shader programs.
on_surface_changed(int width, int height)
void on_surface_changed(int width, int height) {
	glViewport(0, 0, width, height);
	mat4x4_perspective(projection_matrix, 45, (float) width / (float) height, 1, 10);
	mat4x4_look_at(view_matrix, 0.0f, 1.2f, 2.2f, 0.0f, 0.0f, 0.0f, 0.0f, 1.0f, 0.0f);
}
Our new on_surface_changed(int width, int height) now takes in two parameters for the width and the height, and it sets up a projection matrix, and then sets up the view matrix to be slightly above and behind the origin, with an eye position of (0, 1.2, 2.2).
on_draw_frame()
void on_draw_frame() {
    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
    mat4x4_mul(view_projection_matrix, projection_matrix, view_matrix);

	position_table_in_scene();
    draw_table(&table, &texture_program, model_view_projection_matrix);

	position_object_in_scene(0.0f, mallet_height / 2.0f, -0.4f);
	draw_mallet(&red_mallet, &color_program, model_view_projection_matrix);

	position_object_in_scene(0.0f, mallet_height / 2.0f, 0.4f);
	draw_mallet(&blue_mallet, &color_program, model_view_projection_matrix);

	// Draw the puck.
	position_object_in_scene(0.0f, puck_height / 2.0f, 0.0f);
	draw_puck(&puck, &color_program, model_view_projection_matrix);
}
Our new on_draw_frame() positions and draws the table, mallets, and the puck.
Because we changed the definition of on_surface_changed(), we also have to change the declaration in game.h. Change void on_surface_changed(); to void on_surface_changed(int width, int height);.
Adding new helper functions
static void position_table_in_scene() {
	// The table is defined in terms of X & Y coordinates, so we rotate it
	// 90 degrees to lie flat on the XZ plane.
	mat4x4 rotated_model_matrix;
	mat4x4_identity(model_matrix);
	mat4x4_rotate_X(rotated_model_matrix, model_matrix, deg_to_radf(-90.0f));
	mat4x4_mul(
		model_view_projection_matrix, view_projection_matrix, rotated_model_matrix);
}

static void position_object_in_scene(float x, float y, float z) {
	mat4x4_identity(model_matrix);
	mat4x4_translate_in_place(model_matrix, x, y, z);
	mat4x4_mul(model_view_projection_matrix, view_projection_matrix, model_matrix);
}
These functions update the matrices to let us position the table, puck, and mallets in the scene. We’ll define all of the extra functions that we need soon.
Adding new shaders
Now we’ll start drilling down into each part of the program and make the changes necessary for our game code to work. Let’s begin by updating our shaders. First, let’s rename our vertex shader shader.vsh to texture_shader.vsh and update it as follows:
texture_shader.vsh
uniform mat4 u_MvpMatrix;

attribute vec4 a_Position;
attribute vec2 a_TextureCoordinates;

varying vec2 v_TextureCoordinates;

void main()
{
    v_TextureCoordinates = a_TextureCoordinates;
    gl_Position = u_MvpMatrix * a_Position;
}
We can rename our fragment shader shader.fsh to texture_shader.fsh without making any other changes.
We’ll also need a new set of shaders to render our puck and mallets. Let’s add the following new shaders:
color_shader.vsh
uniform mat4 u_MvpMatrix;
attribute vec4 a_Position;
void main()
{
    gl_Position = u_MvpMatrix * a_Position;
}
color_shader.fsh
precision mediump float;
uniform vec4 u_Color;
void main()
{
    gl_FragColor = u_Color;
}
Creating our game objects
Now we’ll add support for generating and drawing our game objects. Let’s begin with game_objects.h:
#include "platform_gl.h"
#include "program.h"
#include "linmath.h"

typedef struct {
	GLuint texture;
	GLuint buffer;
} Table;

typedef struct {
	vec4 color;
	GLuint buffer;
	int num_points;
} Puck;

typedef struct {
	vec4 color;
	GLuint buffer;
	int num_points;
} Mallet;

Table create_table(GLuint texture);
void draw_table(const Table* table, const TextureProgram* texture_program, mat4x4 m);

Puck create_puck(float radius, float height, int num_points, vec4 color);
void draw_puck(const Puck* puck, const ColorProgram* color_program, mat4x4 m);

Mallet create_mallet(float radius, float height, int num_points, vec4 color);
void draw_mallet(const Mallet* mallet, const ColorProgram* color_program, mat4x4 m);
We’ve defined three C structs to hold the data for our table, puck, and mallets, and we’ve declared functions to create and draw these objects.
Drawing a table
Let’s continue with game_objects.c:
#include "game_objects.h"
#include "buffer.h"
#include "platform_gl.h"
#include "program.h"
#include "linmath.h"
#include <math.h>

// Triangle fan
// position X, Y, texture S, T
static const float table_data[] = { 0.0f,  0.0f, 0.5f, 0.5f,
        						   -0.5f, -0.8f, 0.0f, 0.9f,
        						   	0.5f, -0.8f, 1.0f, 0.9f,
        						   	0.5f,  0.8f, 1.0f, 0.1f,
        						   -0.5f,  0.8f, 0.0f, 0.1f,
        						   -0.5f, -0.8f, 0.0f, 0.9f};

Table create_table(GLuint texture) {
	return (Table) {texture, 
		create_vbo(sizeof(table_data), table_data, GL_STATIC_DRAW)};
}

void draw_table(const Table* table, const TextureProgram* texture_program, mat4x4 m)
{
	glUseProgram(texture_program->program);

	glActiveTexture(GL_TEXTURE0);
	glBindTexture(GL_TEXTURE_2D, table->texture);
	glUniformMatrix4fv(texture_program->u_mvp_matrix_location, 1, 
		GL_FALSE, (GLfloat*)m);
	glUniform1i(texture_program->u_texture_unit_location, 0);

	glBindBuffer(GL_ARRAY_BUFFER, table->buffer);
	glVertexAttribPointer(texture_program->a_position_location, 2, GL_FLOAT,
		GL_FALSE, 4 * sizeof(GL_FLOAT), BUFFER_OFFSET(0));
	glVertexAttribPointer(texture_program->a_texture_coordinates_location, 2, GL_FLOAT,
		GL_FALSE, 4 * sizeof(GL_FLOAT), BUFFER_OFFSET(2 * sizeof(GL_FLOAT)));
	glEnableVertexAttribArray(texture_program->a_position_location);
	glEnableVertexAttribArray(texture_program->a_texture_coordinates_location);
	glDrawArrays(GL_TRIANGLE_FAN, 0, 6);

	glBindBuffer(GL_ARRAY_BUFFER, 0);
}
After the imports, this is the code to create and draw the table data. This is essentially the same as what we had before, with the coordinates adjusted a bit to change the table into a rectangle.
Generating circles and cylinders
Before we can draw a puck or a mallet, we’ll need to add some helper functions to draw a circle or a cylinder. Let’s define those now:
static inline int size_of_circle_in_vertices(int num_points) {
	return 1 + (num_points + 1);
}

static inline int size_of_open_cylinder_in_vertices(int num_points) {
	return (num_points + 1) * 2;
}
We first need two helper functions to calculate the size of a circle or a cylinder in terms of vertices. A circle drawn as a triangle fan has one vertex for the center, num_points vertices around the circle, and one more vertex to close the circle. An open-ended cylinder drawn as a triangle strip doesn’t have a center point, but it does have two vertices for each point around the circle, and two more vertices to close off the circle.
static inline int gen_circle(float* out, int offset, 
	float center_x, float center_y, float center_z, 
	float radius, int num_points)
{
	out[offset++] = center_x;
	out[offset++] = center_y;
	out[offset++] = center_z;

	int i;
	for (i = 0; i <= num_points; ++i) {
		float angle_in_radians = ((float) i / (float) num_points) 
                               * ((float) M_PI * 2.0f);
		out[offset++] = center_x + radius * cos(angle_in_radians);
		out[offset++] = center_y;
		out[offset++] = center_z + radius * sin(angle_in_radians);
	}

	return offset;
}
This code will generate a circle, given a center point, a radius, and the number of points around the circle.
static inline int gen_cylinder(float* out, int offset, 
	float center_x, float center_y, float center_z, 
	float height, float radius, int num_points)
{
	const float y_start = center_y - (height / 2.0f);
	const float y_end = center_y + (height / 2.0f);

	int i;
	for (i = 0; i <= num_points; i++) {
		float angle_in_radians = ((float) i / (float) num_points) 
                               * ((float) M_PI * 2.0f);

		float x_position = center_x + radius * cos(angle_in_radians);
		float z_position = center_z + radius * sin(angle_in_radians);

		out[offset++] = x_position;
		out[offset++] = y_start;
		out[offset++] = z_position;

		out[offset++] = x_position;
		out[offset++] = y_end;
		out[offset++] = z_position;
	}

	return offset;
}
This code will generate the vertices for an open-ended cylinder. Note that for both the circle and the cylinder, the loop goes from 0 to num_points, so the first and last points around the circle are duplicated in order to close the loop around the circle.
Drawing a puck
Let’s add the code to generate and draw the puck:
Puck create_puck(float radius, float height, int num_points, vec4 color)
{
	float data[(size_of_circle_in_vertices(num_points) 
              + size_of_open_cylinder_in_vertices(num_points)) * 3];

	int offset = gen_circle(data, 0, 0.0f, height / 2.0f, 0.0f, radius, num_points);
	gen_cylinder(data, offset, 0.0f, 0.0f, 0.0f, height, radius, num_points);

	return (Puck) {{color[0], color[1], color[2], color[3]},
				   create_vbo(sizeof(data), data, GL_STATIC_DRAW),
				   num_points};
}
A puck contains one open-ended cylinder, and a circle to top off that cylinder.
void draw_puck(const Puck* puck, const ColorProgram* color_program, mat4x4 m)
{
	glUseProgram(color_program->program);

	glUniformMatrix4fv(color_program->u_mvp_matrix_location, 1, GL_FALSE, (GLfloat*)m);
	glUniform4fv(color_program->u_color_location, 1, puck->color);

	glBindBuffer(GL_ARRAY_BUFFER, puck->buffer);
	glVertexAttribPointer(color_program->a_position_location, 3, GL_FLOAT, 
		GL_FALSE, 0, BUFFER_OFFSET(0));
	glEnableVertexAttribArray(color_program->a_position_location);

	int circle_vertex_count = size_of_circle_in_vertices(puck->num_points);
	int cylinder_vertex_count = size_of_open_cylinder_in_vertices(puck->num_points);

	glDrawArrays(GL_TRIANGLE_FAN, 0, circle_vertex_count);
	glDrawArrays(GL_TRIANGLE_STRIP, circle_vertex_count, cylinder_vertex_count);
	glBindBuffer(GL_ARRAY_BUFFER, 0);
}
To draw the puck, we pass in the uniforms and attributes, and then we draw the circle as a triangle fan, and the cylinder as a triangle strip.
Drawing a mallet
Let’s continue with the code to create and draw a mallet:
Mallet create_mallet(float radius, float height, int num_points, vec4 color)
{
	float data[(size_of_circle_in_vertices(num_points) * 2 
	          + size_of_open_cylinder_in_vertices(num_points) * 2) * 3];

	float base_height = height * 0.25f;
	float handle_height = height * 0.75f;
	float handle_radius = radius / 3.0f;

	int offset = gen_circle(data, 0, 0.0f, -base_height, 0.0f, radius, num_points);
	offset = gen_circle(data, offset, 
		0.0f, height * 0.5f, 0.0f, 
		handle_radius, num_points);
	offset = gen_cylinder(data, offset, 
		0.0f, -base_height - base_height / 2.0f, 0.0f, 
		base_height, radius, num_points);
	gen_cylinder(data, offset, 
		0.0f, height * 0.5f - handle_height / 2.0f, 0.0f, 
		handle_height, handle_radius, num_points);

	return (Mallet) {{color[0], color[1], color[2], color[3]},
					 create_vbo(sizeof(data), data, GL_STATIC_DRAW),
				     num_points};
}
A mallet contains two circles and two open-ended cylinders, positioned and sized so that the mallet’s base is wider and shorter than the mallet’s handle.
void draw_mallet(const Mallet* mallet, const ColorProgram* color_program, mat4x4 m)
{
	glUseProgram(color_program->program);

	glUniformMatrix4fv(color_program->u_mvp_matrix_location, 1, GL_FALSE, (GLfloat*)m);
	glUniform4fv(color_program->u_color_location, 1, mallet->color);

	glBindBuffer(GL_ARRAY_BUFFER, mallet->buffer);
	glVertexAttribPointer(color_program->a_position_location, 3, GL_FLOAT, 
	GL_FALSE, 0, BUFFER_OFFSET(0));
	glEnableVertexAttribArray(color_program->a_position_location);

	int circle_vertex_count = size_of_circle_in_vertices(mallet->num_points);
	int cylinder_vertex_count = size_of_open_cylinder_in_vertices(mallet->num_points);
	int start_vertex = 0;

	glDrawArrays(GL_TRIANGLE_FAN, start_vertex, circle_vertex_count); 
	start_vertex += circle_vertex_count;
	glDrawArrays(GL_TRIANGLE_FAN, start_vertex, circle_vertex_count); 
	start_vertex += circle_vertex_count;
	glDrawArrays(GL_TRIANGLE_STRIP, start_vertex, cylinder_vertex_count); 
	start_vertex += cylinder_vertex_count;
	glDrawArrays(GL_TRIANGLE_STRIP, start_vertex, cylinder_vertex_count);
	glBindBuffer(GL_ARRAY_BUFFER, 0);
}
Drawing the mallet is similar to drawing the puck, except that now we draw two circles and two cylinders.
Adding math helper functions
We’ll need to add a helper function that we’re currently using in game.c; create a new header file called math_helper.h, and add the following code:
#include <math.h>

static inline float deg_to_radf(float deg) {
	return deg * (float)M_PI / 180.0f;
}
Since C’s trigonometric functions expect passed-in values to be in radians, we’ll use this function to convert degrees into radians, where needed.
Adding matrix helper functions
While linmath.h contains a lot of useful functions, there’s a few missing that we need for our game code. Create a new header file called matrix.h, and begin by adding the following code, all adapted from Android’s OpenGL Matrix class:
#include "linmath.h"
#include <math.h>
#include <string.h>

/* Adapted from Android's OpenGL Matrix.java. */

static inline void mat4x4_perspective(mat4x4 m, float y_fov_in_degrees, 
	float aspect, float n, float f)
{
	const float angle_in_radians = (float) (y_fov_in_degrees * M_PI / 180.0);
	const float a = (float) (1.0 / tan(angle_in_radians / 2.0));

	m[0][0] = a / aspect;
	m[1][0] = 0.0f;
	m[2][0] = 0.0f;
	m[3][0] = 0.0f;

	m[1][0] = 0.0f;
	m[1][1] = a;
	m[1][2] = 0.0f;
	m[1][3] = 0.0f;

	m[2][0] = 0.0f;
	m[2][1] = 0.0f;
	m[2][2] = -((f + n) / (f - n));
	m[2][3] = -1.0f;

	m[3][0] = 0.0f;
	m[3][1] = 0.0f;
	m[3][2] = -((2.0f * f * n) / (f - n));
	m[3][3] = 0.0f;
}
We’ll use mat4x4_perspective() to setup a perspective projection matrix.
static inline void mat4x4_translate_in_place(mat4x4 m, float x, float y, float z)
{
	int i;
    for (i = 0; i < 4; ++i) {
        m[3][i] += m[0][i] * x
        		+  m[1][i] * y
        		+  m[2][i] * z;
    }
}
This helper function lets us translate a matrix in place.
static inline void mat4x4_look_at(mat4x4 m,
		float eyeX, float eyeY, float eyeZ,
		float centerX, float centerY, float centerZ,
		float upX, float upY, float upZ)
{
	// See the OpenGL GLUT documentation for gluLookAt for a description
	// of the algorithm. We implement it in a straightforward way:

	float fx = centerX - eyeX;
	float fy = centerY - eyeY;
	float fz = centerZ - eyeZ;

	// Normalize f
	vec3 f_vec = {fx, fy, fz};
	float rlf = 1.0f / vec3_len(f_vec);
	fx *= rlf;
	fy *= rlf;
	fz *= rlf;

	// compute s = f x up (x means "cross product")
	float sx = fy * upZ - fz * upY;
	float sy = fz * upX - fx * upZ;
	float sz = fx * upY - fy * upX;

	// and normalize s
	vec3 s_vec = {sx, sy, sz};
	float rls = 1.0f / vec3_len(s_vec);
	sx *= rls;
	sy *= rls;
	sz *= rls;

	// compute u = s x f
	float ux = sy * fz - sz * fy;
	float uy = sz * fx - sx * fz;
	float uz = sx * fy - sy * fx;

	m[0][0] = sx;
	m[0][1] = ux;
	m[0][2] = -fx;
	m[0][3] = 0.0f;

	m[1][0] = sy;
	m[1][1] = uy;
	m[1][2] = -fy;
	m[1][3] = 0.0f;

	m[2][0] = sz;
	m[2][1] = uz;
	m[2][2] = -fz;
	m[2][3] = 0.0f;

	m[3][0] = 0.0f;
	m[3][1] = 0.0f;
	m[3][2] = 0.0f;
	m[3][3] = 1.0f;

	mat4x4_translate_in_place(m, -eyeX, -eyeY, -eyeZ);
}
We can use mat4x4_look_at() like a camera, and use it to position the scene in a certain way.
Adding shader program wrappers
We’re almost done the changes to our core code. Let’s wrap up those changes by adding the following code:
program.h
#pragma once
#include "platform_gl.h"

typedef struct {
	GLuint program;

	GLint a_position_location;
	GLint a_texture_coordinates_location;
	GLint u_mvp_matrix_location;
	GLint u_texture_unit_location;
} TextureProgram;

typedef struct {
	GLuint program;

	GLint a_position_location;
	GLint u_mvp_matrix_location;
	GLint u_color_location;
} ColorProgram;

TextureProgram get_texture_program(GLuint program);
ColorProgram get_color_program(GLuint program);
program.c
#include "program.h"
#include "platform_gl.h"

TextureProgram get_texture_program(GLuint program)
{
	return (TextureProgram) {
			program,
			glGetAttribLocation(program, "a_Position"),
			glGetAttribLocation(program, "a_TextureCoordinates"),
			glGetUniformLocation(program, "u_MvpMatrix"),
			glGetUniformLocation(program, "u_TextureUnit")};
}

ColorProgram get_color_program(GLuint program)
{
	return (ColorProgram) {
			program,
			glGetAttribLocation(program, "a_Position"),
			glGetUniformLocation(program, "u_MvpMatrix"),
			glGetUniformLocation(program, "u_Color")};
}
Adding support for Android
We first need to update Android.mk and add the following to LOCAL_SRC_FILES:
				   $(CORE_RELATIVE_PATH)/game_objects.c \
                   $(CORE_RELATIVE_PATH)/program.c \
We also need to add a new LOCAL_C_INCLUDES:
LOCAL_C_INCLUDES += $(PROJECT_ROOT_PATH)/3rdparty/linmath/
We then need to update renderer_wrapper.c and change the call to on_surface_changed(); to 	on_surface_changed(width, height);. Once we’ve done that, we should be able to run the app on our Android device, and it should look similar to the following image:
Air hockey, running on a Galaxy Nexus
Adding support for iOS
For iOS, we just need to open up the Xcode project and add the necessary references to linmath.h and our new core files to the appropriate folder groups, and then we need to update ViewController.m and change on_surface_changed(); to the following:
on_surface_changed([[self view] bounds].size.width, [[self view] bounds].size.height);
Once we run the app, it should look similar to the following image:
Air hockey, running on the iPhone simulator
Adding support for emscripten
For emscripten, we need to update the Makefile and add the following lines to SOURCES:
		  ../../core/game_objects.c \
		  ../../core/program.c \
We’ll also need to add the following lines to OBJECTS:
		  ../../core/game_objects.o \
		  ../../core/program.o \
We then just need to update main.c, move the constants width and height from inside init_gl() to outside the function near the top of the file, and update the call to on_surface_changed(); to on_surface_changed(width, height);. We can then build the file by calling emmake make, which should produce a file that looks as follows:

See how easy that was? Now that we have a minimal cross-platform framework in place, it’s very easy for us to bring changes to the core code across to each platform.
Exploring further
The full source code for this lesson can be found at the GitHub project. In the next post, we’ll take a look at user input so we can move our mallet around the screen.
Comment on the blog
Copyright © 2012
 
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
 The use of this feed on other websites that do not comply to the CC-BY-SA 3.0 breaches copyright. If this content is not in your news reader, the page you are viewing may be an infringement of the copyright. (Digital Fingerprint:
 e5945dcc83892602ba406e1f54f77ae6)
]]>
			http://www.learnopengles.com/adding-a-3d-perspective-and-object-rendering-to-our-air-hockey-project-in-native-c-code/feed/
		2
		
		
		
		http://www.learnopengles.com/opengl-roundup-september-12-2013/?utm_source=rss&utm_medium=rss&utm_campaign=opengl-roundup-september-12-2013
		http://www.learnopengles.com/opengl-roundup-september-12-2013/#comments
		Thu, 12 Sep 2013 16:25:36 +0000
		
				
		
		
		
		

		http://www.learnopengles.com/?p=2090
		
				As some of you may already know, Apple recently announced the iPhone 5s & 5c at their annual iPhone event, and one of the new updates is that the iPhone 5s will also be coming with support for OpenGL ES 3.0! Google announced support for OpenGL ES 3.0 with their release of Android 4.3 not too long ago, so the new version is slowly making its way onto mobile devices.

OpenGL ES 3.0 is backwards-compatible with OpenGL ES 2.0, so everything you learned about OpenGL ES 2.0 still applies. This post from Phoronix goes into more detail about what the new version brings: A Look At OpenGL ES 3.0: Lots Of Good Stuff.
On to the roundup:
Ghoshehsoft’s Blog - A look at many topics related to OpenGL ES 2.0 on Android.
Project Anarchy - “Project Anarchy is a complete end to end game engine and state-of-the-art toolset for mobile. Project Anarchy also comprises a vibrant game development community centered right here at www.projectanarchy.com. Project Anarchy includes an entirely free license to ship your game on iOS, Android and Tizen platforms.”
emscripten and PNaCl: Build Systems
What Does gpus_ReturnGuiltyForHardwareRestart Mean?
Theoretical Engineering: Occlusion Culling for BrickSmith
Comment on the blog
Copyright © 2012
 
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
 The use of this feed on other websites that do not comply to the CC-BY-SA 3.0 breaches copyright. If this content is not in your news reader, the page you are viewing may be an infringement of the copyright. (Digital Fingerprint:
 e5945dcc83892602ba406e1f54f77ae6)
]]>
			http://www.learnopengles.com/opengl-roundup-september-12-2013/feed/
		0