Music Fader for Cocos2dx

Here’s a class for fading music in Cocos2dx 2.x using the SimpleAudioEngine. Seems like this should be a basic function of the SimpleAudioEngine itself, but this is pretty easy to use, just run it on any CCNode like any other action:

runAction(MusicFade::create(1.0f, 0.0f, true));

Copy and paste from below, or here’s a zip with the files.

#include "MusicFade.h"
#include "SimpleAudioEngine.h"

using namespace cocos2d;
using namespace CocosDenshion;

MusicFade::MusicFade()
{
    m_initialVal = 0;
    m_targetVal = 0;
}

MusicFade* MusicFade::create(float duration, float volume, bool pauseOnComplete)
{
    MusicFade *pAction = new MusicFade();
    pAction->initWithDuration(duration, volume, pauseOnComplete);
    pAction->autorelease();

    return pAction;
}

bool MusicFade::initWithDuration(float duration, float volume, bool pauseOnComplete)
{
    if (CCActionInterval::initWithDuration(duration))
    {
        m_targetVal = volume;
        m_bPauseOnComplete = pauseOnComplete;
        return true;
    }

    return false;
}

void MusicFade::update(float time)
{
    float vol = m_initialVal + time*(m_targetVal - m_initialVal);
    SimpleAudioEngine::sharedEngine()->setBackgroundMusicVolume(vol);

}

void MusicFade::startWithTarget(CCNode *pTarget)
{
    CCActionInterval::startWithTarget( pTarget );
    m_initialVal = SimpleAudioEngine::sharedEngine()->getBackgroundMusicVolume();
}

void MusicFade::stop(void)
{
    if(m_bPauseOnComplete) SimpleAudioEngine::sharedEngine()->pauseBackgroundMusic();
    CCActionInterval::stop();
}
#ifndef __MusicFade__
#define __MusicFade__

#include "cocos2d.h"

class MusicFade : public cocos2d::CCActionInterval
{
public:
    MusicFade();

    static MusicFade* create(float d, float volume, bool pauseOnComplete = false );
    bool initWithDuration(float d, float volume, bool pauseOnComplete );

    virtual void startWithTarget(cocos2d::CCNode *pTarget);
    virtual void update(float time);
    virtual void stop(void);

protected:
    float m_targetVal;
    float m_initialVal;
    bool m_bPauseOnComplete;
};

#endif /* defined(__MusicFade__) */

GLYF Design now Fuguelike

Glyf Design has changed it’s name to Fuguelike.

Why? Glyf Design was created back in 2006. The ‘design’ label is no longer accurate. And ‘glyf’ seems to be confusing for many people to read.

Fuguelike is an unusual word, and it has a double connotation: First it is the name for the baroque form of music that has a formal structure and a mathematical beauty. There is also the fugue state – a memoryless dreamlike trance. The aim is to produce both through digital experiences.

This blog’s new domain will be http://fuguelike.com, although it will be duplicated here for a while longer as well.

fuguelike4dx800

VOSC Update now Live

An update to VOSC Visual Particle Synthesizer is now live online. It includes a new RANDOMIZE function, which loads random values for all parameters of all oscillators. Since it’s random, a lot of times the result won’t look like anything, but every once in a while something interesting will pop up. It’s a great way to explore the realm of the program’s capability, and to find a place to start tweaking from.

The update also includes a way to cap the particle resolution so that loading patches that have high settings won’t slow your machine down to a crawl. Find it in the RES panel.

This update is live online and on the Android version. Pending approval on iOS.

Announcing VOSC Visual Particle Synthesizer

Here are a couple screens from an app currently under development, to be released on iOS and Android, with other platforms/versions to follow.

It could be described as a visual particle synthesizer. It consists mainly of 4 oscillators that control the position of a vast array of on-screen particles. Adjustments to the frequency and shapes of the oscillators can produce some very intricate moving patterns.

It’s an evolution and systemization of the phaSing series of flash toys that I made quite a while back. Here, the rendering and most of the “synthesis” calculations are performed using GPU shaders written in AGAL for the Stage3D feature of Flash Player / AIR.

Physics Engine Performance on Mobile – AIR, HaxeNME, Native

I’ve been developing a game for mobile devices, primarily tablets, and my first choice was to use AIR for mobile and one of the nice new Stage3D game libraries. I chose ND2D over Starling and Genome2D, since unlike Starling the API was flexible and nicely similar to the Flixel and FlashPunk engines, and unlike Genome2D was open source. Using the ROLF fork I was able to get performance comparable to Genome2D.

The rendering performance of all these engines is pretty impressive, about on par here with native rendering on mobile devices, with some language overhead only when you get into the thousands of objects. Problem is the game also makes use of a physics engine, and it this is where the limitations of the platform really start to become a problem. Using the as3 version of the Nape engine (a really nice engine – way faster that Box2DAS3 and with a much better API), I was only able to simulate around 50 dynamic bodies on an iPad2 (hardly a low end device) with decent frame rates (above 40 FPS).

So I decided to run some tests using HaxeNME. Since it compiles to C++ and runs without a VM I expected to see a big performance gain. Using DrawTiles for batched rendering and the Haxe version of Nape for physics I was able to get a pretty good improvement here – about 90 dynamic bodies before dropping below 40FPS on the iPad2. Since I really would like to target lower end devices and am building creatures that each have over 20 dynamic bodies, this was still pretty limiting though.

So I took a look at native, deciding on Cocos2Dx for the rendering, which is an open source C++ port of Cocos2D, and the Chipmunk physics engine. Here I was able to get over 450 colliding objects before the frame rate even started to drop below 60 – more than a 10 fold increase in performance over the best possible solution in AS3, and more than 5 fold increase over HaxeNME. This was way more than I expected, especially  given that the rendering speed across the various platforms, all utilizing OpenGL ES, is virtually the same.

I guess the take away from this is that although Stage3D was a great step forward for the Flash platform in bringing native rendering (and I’m still using it in other projects), when it comes to computationally intense features of games like physics or AI it still isn’t a viable platform, at least on mobile. Recent developments like the new Falcon compiler and AS workers are nice but Adobe is going to have to make more radical changes to the language and VM to be a competitive platform for gaming. Here’s to hoping that hints about Actionscript 4 are followed through on.