Android Game Engine / Blog: Recent posts

We are finally back to working on AGE; picking up where we left off, the OBJ loader. After all, who wants to hard-code all of those vertices!?

There's not much documentation on the format, but it's that simple! The current state of implementations is pretty sorry with respect to Garbage Generation; ArrayList<Float> is a path to ruin, even for a small model. There's that, then there's use of some parser like StringTokenizer or worse yet, Scanner! We looked at the Java 7 source, there's lots of "state" in there! This is compounded by the fact that these are immutable on the input, so you have to create lots of these heavyweight beauties (multiple per line in some cases).... read more

Added the blogged-about Box2D AGE components to the Files section, in Box2D folder.

Still here, but pulled onto some other stuff for just a bit longer.

There are some local edits we haven't committed yet; not ready for prime time, issues with the SurfaceHolder lifecycle and seamlessly bringing back GL resources.

Fun, fun, fun...

Sorry for the delay between posts, but it's been busy elsewhere!

In this possibly final part of the series, we discuss some specific Box2D subclasses that represent concrete game objects.

Since it's getting concrete, you will notice some model-related bookkeeping.

In this game, a Ball is just that, a circular object that bounces around the play field, and is under force via the device's accelerometer.... read more

We hope you are enjoying the Box2D series, there is one more part that covers some subclasses of Box2DBody and how get to the game logic.

We will get that packaged up on the Files section very soon afterwards.

There's still a lot to get done; there are some uncommited changes and another release coming and still no Demo on the Files section, but all in due course.

To those who downloaded, any feedback or defect report is appreciated.

In this 3rd part, we discuss the receiver of the World events generated from the box2d callbacks ContactListener and BoundaryListener.

Here is where it gets into the game logic. This is taken from a game we are porting, which is a "bashing" game where contacts with certain objects score points, and if certain objects exit the world, they are conditionally re-spawned.

We have the following filter flags:... read more

In Part 2 of this series, we look at the Body component for AGE.

The primary purpose for this GO is to handle the box2d bookkeeping for Body instances, map that information to its drawable resources, and provide an abstract base class for more complicated objects.

In here we set up some more infrastructure by way of an abstract class:

• Implement the filter flags for the World filter methods. This is a public field because it gets accessed a lot.
• Add a passive flag so subclasses can control how force acts upon them.
• Add a marker interface UnderForce for subclasses to signal the World they want forces applied. This is then further controlled by passive flag.
• Put in the bare minimum box2d resource acquisition. The simplest object in box2d needs a BodyDef and a Body.... read more

As promised, this starts the series on how to create custom Game Objects (GOs) in AGE.

Our example uses the box2d framework, for creating physics-based action with AGE. We assume you are somewhat familiar with box2d and won't elaborate too much on its internals.

box2d is made up of a few distinct components, and we will concentrate on the World and Body components, as these will get you started. This first part will concentrate on the internals of the World component implemented for AGE.... read more

We updated the status to "Beta".

The existing game we're porting to AGE from another framework is nearly complete, minus textures.

We were able to simplify many design details in the game, because of the Pipeline architecture. We also created some box2d components, and will release those soon.

The emphasis on indirect coupling was maintained throughout the port; there are no tangled messes of components holding references to each other, and the Pipelines make for very clean call sites.... read more

We are pleased to announce that age-r21.jar has been uploaded to the Files section, along with Javadoc.

Please leave feedback in the Tickets section of the site.

First off, sorry about the "Read More" non-links appearing in the code; that is a defect in the SourceForge engine.

Things are crunching right along, still some internals getting ironed out before we put more attention into the GL end of it.

We posted a Javadoc update, more to follow.

Some of the changes have cascaded into the Demo, so that is slightly delayed. We made some Blog posts in the meantime.... read more

In the first part, we covered the GameCycle subclass.

In this part, we cover the timer events.

Timers are just GameObject subclasses that implement TimerCallback to do the actual work of changing the cube z-rotation.

public class CubeAnimator extends GameObject implements TimerCallback {
final String[] targets;

The constructor takes a list of names, not objects!

public CubeAnimator(String name, String[] targets) {
    super(name, true);
    this.targets = targets;
}... [read more](/p/androidgameng/blog/2013/05/inside-the-demo-part-2/)

This post goes briefly over the GameCycle subclass of the Demo App, a simple rotating cube scene.

There will be some additional follow-up posts that cover the other moving parts (pun intented) of the demo.

Here is part of the GameplayActivity code; it is really simple. It also contains an empty implementation of GameHost, which is required for the GameCycle constructor.

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_gameplay_demo);
    setupContentView(R.id.ANDROID_GAME_VIEW);
    // the rest of the method....
}... [read more](/p/androidgameng/blog/2013/05/inside-the-demo/)

Getting ever-so-close to initial release. Of course, you could pull it from SVN, but that's work-in-progress.

In addition to demo programs, we also have an actual game we are porting over from a previous framework and Canvas-based graphics, so we are dog-fooding AGE to suss out any potential problems before you see them. This port is driving many of the changes to the Install Pipeline.

The initial demo is only missing a texture example, and that will happen this week.

Making changes to GameObject and Scene classes, and the Install Pipeline.

The locatable flag is added to GameObject and determines whether the GO is loaded into the Locator on install. This allows for transient GOs that do not permanently register.

Some of the details of the Install Pipeline were removed, in particular the logic that triggered on Scene instances. There is now an explicit Scene Start method and event, so a Scene can be built up completely before displaying it. There is also now a SceneInstallSentinel GO you can use to "signal" when an install sequence on the Scene is complete.... read more

We are getting very close to an initial release for your consumption. We have published the Javadoc to the Files section in advance of the JAR being published.

The current set of changes are performing extremely well; our latest test of the Cube Demo on an HTC One X (Android 4.0.3) was triggering Concurrent GC only once per 7 minutes so that is a long time to run without any GC activity!

Another exciting result is that Concurrent GC on these newer 4.x platforms runs very fast, typically under 10ms! The upshot of that is there shouldn't be any noticeable GC "pauses" that make gameplay so frustrating for users.

A couple more HPROF runs really helped dial in the Render() call path, which is assumed the one that gets executed the most. If you run the Timer Base Tick less than the framerate, then less so. To recap, the demo uses 30 FPS (33ms it currently truncates) and 100ms TBT.

Our goal is simple: do not generate per-frame "garbage". Even simple things like ArrayList.iterator() allocate small objects, and these build up in between GC cycles, and ultimately trigger GC sooner than it otherwise would. So the fastest allocation is the one that is avoided.... read more

Sometimes debugging with ADT can be really fun!

We were playing with the upcoming demo app in an API 17 hardware-accelerated emulator, and decided to do an HPROF run just to see where things were at. After all, it just takes a couple clicks to get one!

The results were not surprising: majority of the time is spent in the rendering cycle. It was not too bad, but we found some places to eliminate per-frame re-calculations. The next HRPOF run should be better.... read more

We are adding support for Framebuffer and interleaved vertex data for geometry.

We are adding a new concept to the Install Pipeline: keying on the class of the loaded instance. This is used for processing Scenes and Transitions; the Game Cycle automatically "handles" it appropriately.

We also must solve how new Game Objects get themselves "into" any composite GOs (e.g. Scene), since it's bad practice to add an instance to a list before it is completely loaded. This "connection point" may be specified by (list-of) GO Name and use the Locator to "connect" via a marker interface.... read more

We are adding Scene as the new top-level drawable component, to organize things for transitions. Scene subclasses GameObject because it uses the Install Pipeline.

Things like the Locator and Timer may get moved into the Scene, so it stays a self-contained unit, and makes tearing down a Scene simpler.

The RenderService manages Scenes and their lifecycle. Transitions are subclasses of Scene and use render-to-texture and multi-texture techniques.... read more

What good is anything without its "Hello World"? One is in the works, and it will be posted in the Files section shortly, in both source and APK format.

The initial version is some Z-rotating cubes, with the camera position rotating around the origin clockwise in the ZX plane (y=constant).

Even this simple start demonstrates a great deal:

• how to subclass the GameplayActivity class
• how to subclass the GameCycle class
• how to create geometry and materials
• how to initialize components with the install pipeline
• how to animate properties with update events... read more

We have completed the initial implementation for GL ES 2 rendering with shaders, and are providing a core set of shaders with AGE:

• solid color
• per-vertex color
• texture-mapped
• per-vertex lighting
• per-pixel lighting

Plus the ability to install any other shaders of your choosing.

As a result, we are going to remove the GL 1.x related rendering code.

Putting in the infrastructure for GLES 2 and shaders.

This leaves an unfortunate, hopefully temporary, issue: there are separate call-chains for GLES 1 and GLES 2 rendering, starting at the GLSurfaceView. The view you choose in your layout determines the rest of the rendering "stack".

The RenderService for GLES 2 calls a different method on RequireRender, which DrawableGameObject in turn delegates to its model, which in turn uses the actual GLES 2 rendering code.... read more

We have started committing files into SVN so be tuned in for a drop in the files area pretty soon.

We are working on GLES 2 support at the moment, and that is causing some refactoring, so that should settle out fairly soon, then there will be support for both versions.

Bringing everything online, there will be source code shortly!

In the meantime, enjoy the Wiki pages.