| Subcribe via RSS
After a couple more coding sessions, we decided to stop the project’s development for the time being.
To promote an open collaboration I just moved the repository to GitHub for easy forking.
The code got all the foundations to start developing a real game, so if you are just starting Android Development, I recommend you go and take a look at http://github.com/pirelenito/gonp.
Tags: android, game, OpenGL
Today myself and a couple of friends (Renato Besen and Vitor Pelizza) started on a saga to develop a game on Android, there is not much to see or do after our approximately three hours of work but of what is on the screenshot bellow:
A green square, composed of 2 triangles and 4 points. Which might not seem much at a first glance, but there was a lot of learning in the process.
Through the development we followed loosely this tutorial series, but as good questioners as we are, we quickly started to put some query upon some of the tutorial’s solutions. For instance, why does the buffer creation needs all this code:
ByteBuffer ibb = ByteBuffer.allocateDirect(_nrOfVertices * 2);
ibb.order(ByteOrder.nativeOrder());
_indexBuffer = ibb.asShortBuffer();
_indexBuffer.put(_indicesArray);
When we thought it could be done with something like this:
ShortBuffer _indexBuffer = ShortBuffer.wrap(_indicesArray);
After seeing the app crash on start we understood that all buffers used by OpenGL ES need to be of the device’s native byte order, which is not the default order when creating a Buffer through the wrap method. To solve this more elegantly we created a factory for native byte order buffers.
Next up was drawing our Player(the square), but since OpenGL ES does not support QUADs, it would need to be composed of two triangles. After figuring out how the glVertexPointer and glDrawElements methods work, we finally made our Player class render on the screen:
gl.glVertexPointer(3, GL10.GL_FLOAT, 0, vertexes);
gl.glDrawElements(GL10.GL_TRIANGLES, indexes.capacity() …
On the first line we tell OpenGL wich are the points that it needs to render, next we pass an array containing the order that they need to be drawn.
That is it for now, but you can follow our progress through the project’s Redmine or by checking out the code at the git repository.
Update: Moved the repository to github.
Tags: android, development, game, Java, mobile, OpenGL, sagaSometimes during development we need to save an object state so that we can latter return to it, due to a problem or a by an user undo request. In these scenarios usually some type of cloning is a good way to go.
Java has a standard way of doing this through the .clone() method, but in order for it to work, the classes need to implement it explicitly. Then comes a day that you need to clone some third party object that does not implement the clone() method, so what do you do?
Me and friend Renato Besen came along an interesting solution during a pair, and I thought it would be fun to share. The object we wanted to clone was Serializable, so we created a class that perform a cloning through serialization, writing the object into memory and then reading it back into another new instance, effectively making a clone of it.
The class is generic, so the final solution is pretty neat, just call:
new SerializationCloner<ThirdPartyClass>().clone(instance);
And that is it! You can get the source from here.
The only obvious downside is performance, so use it with caution.
Tags: class, clone, Java, serialization, utility