Thursday 20 June 2013

Enable Nape debugging with CitrusEngine.

After initializing the engine you need to enable a onEnterFrame listener to constantly refresh it all the debug images:

This is how I have done it:


           var params:Object = new Object();

           nape = new Nape("nape", params);
           nape.touchable = false;
           enableDebug();
           add(nape);
           


        private function enableDebug():void
        {
            debug = new ShapeDebug(GameVars.SCREEN_X,GameVars.SCREEN_Y);
            debug.drawBodies = true;
            debug.drawSensorArbiters = true;
            debug.drawConstraints = true;
            Starling.current.nativeOverlay.addChild(debug.display);
            stage.addEventListener(Event.ENTER_FRAME, loop );
        }

        public function loop( evt:Event ) : void {
            debug.clear();
            debug.draw(nape.space);
            debug.flush();
        }
It should be easy to adapt it to your needs. It's pretty straight forward!

Monday 17 June 2013

Optimizing performance when developing high responsive apps: Pools

Everything needs to be pooled.

This means that you create objects when they don't exist. When an enemy or bullet get destroyed it will only get destroyed visually, not in the logics of the game.

The engine places that enemy or bullet in a place in the screen that is not possible to interact. Then disable it and wait until a new enemy of the same kind comes into the screen , then we recycle the object and reuse it as new by refreshing or resiting all its variables.

Why this? Creating destroying objects can be very heavy on the CPU when done several times in a frame (or loop). So by avoiding the creation of new objects we will have a smoother game play.

When creating objects we enable themt and when we don't need them, we can just disable them. In my particular game I've created this function to be used with CitrusObjects (from CitrusEngine).
       private function enableObject(status:Boolean):void
        {
            view.pauseAnimation(status); //textures will not update.
            view.visible = status; //will hide the object
            updateCallEnabled = status;//will stop updating each frame.
            _inUse = status;
            set_bodyEnabled(status); //disable collisions
        }

I hope it helps!

Thursday 13 June 2013

From Box2D to Nape in CitrusEngine

Due the massive Garbage generated by Box2D creating memory fragmentation. I will be porting my shoot'em up game Beekyr (using CitrusEngine) from Box2D to Nape.


Firstly, I have changed these physics instance from:
var params:Object = new Object();
params.doSleep = false;
var box2D:Box2D = new Box2D("box2D",params);

box2D.gravity = new b2Vec2(0, 0);

box2D.touchable = false;
box2D.world.SetContinuousPhysics(false);
box2D.velocityIterations = 1;
add(box2D);
to Nape:
var params:Object = new Object();
var nape:Nape = new Nape("nape", params);
nape.gravity = new Vec2(0, 0);
nape.touchable = false;
add(nape);

I changed all my objects from extending Box2DPhysicsObject to NapePhysicsObject.
All my custom fixtures has been erased, and collision groups dissapeared.
_body.SetActive(true/false);
to Nape:
_body.space = null; //to disable
_body.space = _nape.space //to enable.

Updating rotation:
before, Box2D:

_body.setRotation(rads)

now, Nape, (I think this same code should work the box2D wrapper?):

_body.rotation = rads;


Updating velocity:
before, Box2D:

_body.SetLinearVelocity(new b2Vec2(_currentSpeed.x, _currentSpeed.y);

now, Nape, (I think this same code should work the box2D wrapper?):

_body.velocity = new Vec2(_currentSpeed.x, _currentSpeed.y);
But since the units change betweens engines, Im using pixels as unit and updating the position with my own engine:
x +=speed.x;
y +=speed.y;
This is uesful for shoot'em ups but I am very unsure what would happen if I was using real physics, with gravity, etc.

Updating collisions... they use now a different override, but the rest is the same:

before, Box2D:

override public function handleBeginContact(contact:b2Contact):void {
var collisionWith:* = Box2DUtils.CollisionGetOther(this, contact);

now, Nape:

override public function handleBeginContact(contact:InteractionCallback):void {
var collisionWith:* = NapeUtils.CollisionGetOther(this, contact);


now fixtures are not present as such so I needed to change the way I set up the filters and physics:

override protected function defineBody():void {
_bodyType = BodyType.KINEMATIC ;
}

override protected function createFilter():void {
super.createFilter();
_shape.sensorEnabled = true;
_shape.filter.sensorGroup = PhysicsCollisionCategories.Get("enemyBullet");
_shape.filter.sensorMask = PhysicsCollisionCategories.Get("player", "playerBullet");
}

I think I didn't have to change anything else...

Performance doubled on my smartphone, I went from 18-30FPS to constant 30FPS for the game.

Monday 10 June 2013

Optimizing performance in CitrusEngine and Box2D

Performance tips.

I will explain my experience when I was building Beekyr game for AIR using CitrusEngine and Box2D....

This might be applied to other game engines.... but the way Box2D is used might be the same.
When I created first Beekyr stage prototype I had about 2000 objects moving smoothly in screen, Stage3D was just amazing. But I needed the sprites to collide between each other. Everyone recommended to use the physics engine Box2D, even it if was just for collisions (later on I replaced it for Nape engine (for AS3), which is at least twice as fast, click here to see how I converted from Box2D to Nape).

After adding the physics engine, I only was able to have about hundred of objects moving smooth and fast (still no code to make them react with each other).

I didn't realize that a physics engine would make things THAT slow, specially in smartphones, so I had to start optimizing everything:
I made everything to be classified as sensor:
_fixtureDef.isSensor = true;
That means that touching objects can overlap without having a bounce effect or something.

Enable only begin handle contact:
beginContactEnabled = true;
Objects will not react until I enabled at least one form of contact in Citurs Engine.
Then I want to create groups, that means groups with the same ID will not react to each other this is very good when you have loads of real bullets or lots of enemies, this will stop most collision functions to be triggered when the bullets or enemies overlap.
The way to do this is to edit the fixture filter, this is how enemy bodies are filtered:
    override protected function defineFixture():void {
           super.defineFixture();
           _fixtureDef.filter.groupIndex = GameVars.ENEMY_GROUP;
           _fixtureDef.isSensor = true;
        }

Don't ever use isBullet() unless is completelly necesary. This will add more calculations to the engine making it slower.