Thursday, July 26, 2012

GLES20Fix

This post is about how I added the OpenGL ES 2.0 methods glDrawElements and glVertexAttribPointer with VBOs on older android devices which (by a mistake?) did not get these methods. I am basically doing what the guys on this project have done and credit goes to them for their nice and clean solution. The fix will result in two static methods. I've also added a small part in the end about building the native code.

As the functions already exists in native code the only thing that is needed is to bind these functions to Java methods. To do this we create two native methods (one for glDrawElements and one for glVertexAttribPointer) and call the pre-existing OpenGL functions in native code. The source of the native code is named GLES20Fix.c and put inside the jni folder in the root of your project (create the folder if it doesn't exist). It should look like this:
#include <jni.h>
#include <GLES2/gl2.h>

void my_packagepath_GLES20Fix_glDrawElements(JNIEnv *env, 
    jclass c, jint mode, jint count, jint type, jint offset) {
        glDrawElements(mode, count, type, (void *) offset);
}

void my_packagepath_GLES20Fix_glVertexAttribPointer(
    JNIEnv *env, jclass clazz, jint index, jint size, 
    jint type, jboolean normalized, jint stride, 
    jint offset) {
        glVertexAttribPointer(index, size, type, normalized, 
                              stride, (void *) offset);
}
where my_package is changed to the package where the class containing the Java methods is - in this case the class is called GLES20Fix.

The Java class must declare the two native methods and should also load the jni library during initialization (unless you want to load it elsewhere).
package my.packagepath;

public class GLES20Fix {
 
    native public static void glVertexAttribPointer(int index,
        int size, int type, boolean normalized, int stride, 
        int offset);

    native public static void glDrawElements(int mode, 
        int count, int type, int offset);
 
    private GLES20Fix() {}
    
    static {
        System.loadLibrary("GLES20Fix");
    }
}

NDK Builder
Native code needs to be compiled and put inside the obj folder in the root of the project. This can be done by using a NDK builder for Eclipse which can be created by following this walkthrough. The builder needs a makefile for the GLES20Fix.c which must be named Android.mk and put inside the jni folder. The following is an example of a makefile for GLES20Fix.c
LOCAL_PATH := $(call my-dir)
 
include $(CLEAR_VARS)
 
LOCAL_MODULE := GLES20Fix
LOCAL_SRC_FILES := GLES20Fix.c
LOCAL_LDLIBS := -llog -lGLESv2 -ldl
 
include $(BUILD_SHARED_LIBRARY)

Sunday, July 22, 2012

Re-emerging with links

To get some consistent blogging going on I've decided that I will try to summarize links that I've found beeing useful for my project. In case I've forgotten to blog recently I will be using this type of post to get it going again - I will also try to include a shorter version in regular posts. The summary consists of a bunch of links which are divided into categories that addresses some part that I've been studying or found interesting.

Google I/O 
Google I/O is a great event for android developers as they provide a lot of information about how their OS works and how you can use it. I've found their youtube channel to be one of the best sources for android development and I want to emphasize three vids here.

Google I/O 2009: Writing Real-Time Games for Android - Chris Pruett talks about game development on android devices listing common pitfalls by using his game Replica Island as an example.

Google I/O 2010: Writing real-time games for Android redux - A follow-up on the Google I/O 2009. Chris Pruett goes more in-depth with his game.

Google I/O 2011: Memory management for Android Apps - A talk about efficient memory management on android devices.

The Game Loop and the Timestepping
Making sure that my game runs smooth even on older and slower devices is an important task and required some additional thought on my game loop. Even if the info from the following links is not directly applicable to my android game because I'm doing the threaded solution as suggested by Chris Pruett in the Google I/O talk, the fundamentals is still explained really well. This and this Q&A have also been useful.

Fix Your Timestep! - This is truly the main article on timestepping, even if you're not focusing on this right now you should still read it. It is written by Glenn Fiedler in his series of articles on game physics.

deWiTTERS Game Loop - Another great article on timestepping with a more implementation-specific approach for game loops.

Timestepping - A great follow-up to the Fix your Timestep! article. Written by Peter Sundqvist.

Lighthouse3D
Last, I want to give credits to Lighthouse3D with its many tutorials on game development and rendering using OpenGL. They are all very useful and interesting to read.

Friday, December 30, 2011

End-of-year wrap-up

The project is still in a very early stage, with most of the work spent on the engine and not so much spent on the game design. This will probably continue until I get a better base for the game. A few things I will focus on or make sure they work correctly based on my current game design.
  • The camera must be easily positioned and oriented relative to another entity.
  • The manipulation of an entity should not be limited to a specific entity so that switching controls between entites doesn't become difficult.

A decision has been made to remove or exclude a couple of features to speed up the development and to gain further knowledge in android specific solutions. 
  • For the in-game menu, a viewpager will be used over the engines drawing surface.
  • Any text will be displayed in a textview over the engines drawing surface
Since both of these will be separated from my rendering in the opengl surface, a preliminary decision has been made to pause the game whenever the menu or any text is displayed since I don't know how and can't change how these will affect the flow of the game.

The DDMS in eclipse has been really useful for profiling the application. The allocation tracker has helped me alot to find parts where i reallocate a lot of memory. To prevent the garbage collector from running constantly, I've been forced to make my vector objects mutable. While it was a difficult task to change such a widely used class it was nice to see that the synchronization worked correctly between the two threads.

As a memento for the future, here is a screen capture of the game :)







Thursday, October 20, 2011

Status update

To not fall behind with the blogging, I've created this post just to give a status update on my current project even if no major development has been made.

To be able to easier create material for the game, I've made an export script for Blender that exports models to a custom file format that I'm now able to load into the project.

The two threads that the game consists of have gotten some structure and a way to communicate with each other. The threads have a reference to a container that they are able to send handlers to which updates the contents of the container in a thread safe manner.

I've ported an entity system that I've used in another project for the game thread. I will probably continue with the renderer though, before i start to populate the entity system so that it supports som basic rendering and can render the things I put in the entity system.

I expect I will be using these kinds of status posts more frequently now in the beginning since I feel I really can't make any more decisions until i get a better understanding of the ground I'm trying to build this game on.

Saturday, October 15, 2011

Project ideas - First draft

Alright! The idea for my next project will be a Zelda - Phantom Hourglass-inspired game that will run on Android. The game will be a typical adventure - rpg viewed from above and controlled with the thouchscreen. The plan was first to limit the environment to inside caverns and dungeons but I don't see any reason as to not include places with an open type of landscape. As I still want to include dark areas with fog of war, the openGL ES 2.0 will be fun working with since I get to play with shaders. 

Because of ES 2.0 I don't think i will go any lower than to support Froyo-based handhelds. I also think i will exclude the low density and the small screen size configuration. This will still support the majority of all handhelds (85% - thanks to Google for these, these and these numbers). 

As I want to learn more about Android I've decided that I will not discard Android-specific solutions over a more general solution which is easier to port to other platforms.

 Some implementation-specific decisions:
  • Fragments will be used for the different views/activities, e.g. the main menu, the level select menu, the "game" view, etc.  
  • The rendering will be executed in a separate thread (from the "game" thread)
  • An entity system will be used in the "game" thread 
Not much game design has been done so that needs some work and as far as implementation goes, I will probably start with the structure of the different "game" threads and how they will communicate and then start with the entity system. I will postpone the solution of how to structure the fragments for the different activities/view or start with it on the side - separate from the "game" activity/view.

The app will be divided into two different versions, one with ads and one without so I will probably have to check out ad options like AdMob and AdSense and how they will be implemented.

Saturday, October 8, 2011

Prettify added

Just testing google's prettify to format source code.
@Deprecated
public class Foo {

    // comment
    private String bar;
    private float primitive;

    public Foo(String bar) {
        this.bar = "foo" + bar;
    }
}
 <TableLayout
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    … />
Kudos to this post on how to add prettify to Blogger. The colors I use is in the source code of this page. The idea was to make it look like eclipse standard color theme.

Blog up

This blog has been created in an attempt to log my progress in projects I am currently doing or will be doing in the future. The main reason for tracking my work is so that i get a greater understanding of what I am doing by writing a kind of a wrap up of the work I've done so far.

I'm starting this blog now since I've just reached a conclusion on a project on aspect-oriented programming and are looking for a new project on the side of my studies at the university.

I'm currently looking at the Fragment feature in the Android API which made the TabActivity deprecated since Honeycomb (3.0). I would like to be able to use my toolkit for managing fog of war in OpenGL since I haven't really been able to use it that much. Creating some small games for my Desire is fun so I'm probably going in that direction.