Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
30. August 2012

 

In celebration of their 40th anniversary, Atari has re-released a number of their classic games as HTML5 in their newly launched web arcade.  Each of the titles has received a facelift, and the list includes:

  • Asteroids
  • Centipede
  • Combat
  • Lunar Lander
  • Missile Command
  • Pong
  • Super Breakout
  • Yar’s Revenge

 

 

As you can see, the games have received a facelift:

 

Asteroids:

image

 

Yar’s Revenge:

image

 

 

 

The project is a team up between Atari, CreateJS and Microsoft.  The Microsoft connection is Internet Explorer 10, which allows you to view the arcade ad free.  Atari is releasing an SDK for publishing on their arcade, the download and documentation page is currently down, so details are a bit sparse right now.  Their quick start pdf is currently available and gives a glimpse into the process. Presumably the arcade would work on a revenue sharing scheme, but that is just guesswork at the moment.

 

The library used to create all the games is called CreateJS, and is a bundling of HTML5 libraries including:

EaselJS – a HTML5 Canvas library with a Flash like API

TweenJS – a chainable tweening library

SoundJS – a HTML5 audio library

PreLoadJS – an asset loading and caching library

 

Plus the newly added tool, Zoe.  Zoe is a tool that takes SWF Flash animations and generates sprite sheets.

 

 

I look forward to looking in to Atari’s new API once their documentation page is back online.  Atari has also created a GitHub repository to support the project, but it is currently a little sparse.  In their own words:

 

Welcome to the Atari Arcade SDK.

This is the initial release of the SDK, which we hope to evolve over the next few weeks, adding
* more documentation
* examples
* updates

This repository contains
* Atari Arcade SDK classes in scripts/libs
* scripts necessary to run the SDK locally, in scripts/min
* API documentation and a quick start guide in docs/
* A test harness page to bootstrap and launch games

 

 

All told, a pretty cool project.  At the very least, check out the arcade, it’s a great deal of fun.

 

General


17. August 2012

 

In the past I mentioned and even recommended HTML5 developers give WebStorm a shot, this is the IDE I use personally when working in JavaScript, but I realized I never actually said why.  One of the big reasons is, its just a good solid text editor, with good project management and solid code completion, which is an area most tools fail at.  But one of the biggest reasons is, it gives a rock solid debugging experience… very similar to native code.  This is something that can make JavaScript development a WHOLE lot nicer.

EDIT: I should make it clear at this point, virtually nothing in this guide is specific to WebStorm, you can debug using the Chrome Developer Tools or using Firebug in FireFox. Webstorm however integrates the process directly within the IDE.  The process will change slightly ( different buttons/hotkeys ), but the instructions below basically apply to debugging in browser as well.

 

At the same time it dawned on me… if you don’t come from a compiled code background, you probably don’t even realize what you have been missing!  So, I have put this post together, it will hopefully make the developer experience better for at least a couple of you.  If you are currently debugging using a combination of alerts, console writes and breakpoints in the browser, listen up!

 

First off, you are going to need a project to debug.  I am going to use my most recent tutorial post on creating sprite sheets with Cocos2D if you want to download and follow along.  Of course, any project will work, but that particular project has an interesting… quirk that will come in useful.  Next, to get the most out of Webstorm debugging, you should also have Firefox installed.  If you are doing web development, I assume you do already anyways.  Alright, let’s get started.

 

Open the project up in WebStorm.

Now we want to create a debug profile.  In Webstorm, select Run->Edit Configurations…

image

 

In the resulting dialog, click the + icon:

image

 

Choose JavaScript Debug –> Local

image

 

On the left hand side, a new entry should appear.  Select it and file in the form like follows.  Navigate to your index.html or root HTML file, select Firefox from the browser dropdown and name it whatever you would like:

image

Click Apply then Ok when complete.

 

You are now ready to debug. 

Select Run-> Debug ‘Your App’ or press Shift + F9

image

 

Voila, or app should load up in our browser:

image

 

Now what we want to debug is debug the activity that occurs when the user presses a key.  Go back over to Webstorm, open MyFifthApp.js , locate the line with onKeyDown: function, and select the line right below it.  Here we want to set a breakpoint, which will cause our code to stop when the breakpoint is hit.  Set a breakpoint by hitting CTRL+F8 or selecting Run->Toggle Line Breakpoint.  You will see a red dot once your breakpoint is set, like so:

image

 

With the breakpoint set, now flip back to Firefox and hit a key.  This will immediately trigger the breakpoint, pausing your programs execution.  Now if you head back to Webstorm, there will be a wealth of information available to you:

 

image

 

There is quite a bit going on here.  Our code is currently paused executing on our breakpoint.  You can’t see it in the screenshot, but I am hovering my mouse over the e parameter, and it is popping up a tooltip showing its current value.  When debugging, you can interact with your code in a lot more detail.  Now lets take a closer look at the different bits of the interface here.

 

At the bottom left you have a very important window:

image

 

The toolbar on the left hand side can be used to resume program execution, stop completely, or to run from the beginning ( currently grayed out ).  When you are done with a breakpoint, you hit the resume button to continue your program execution.  The two buttons below on the toolbar are for managing breakpoints ( you can end up with a lot of them quickly! ), as well as to mute a breakpoint, which causes it not to fire DURING THIS DEBUGGING SESSION.  The next time you run your program, your breakpoint will be re-enabled unless you remove it.

 

To the right is something traditionally called a callstack, and it’s extremely useful.  Basically, it’s a hierarchy of the last functions called.  So in this case, you can see that our current ( anonymous) method inside MyFifthApp, was called by an anonymous method in CCKeyboardDispatcher, which was called by a different method in the same file.  Clicking the value in the callstack will immediately bring you to the line of code, where you can inspect the current value of any variables there.  Often the error actually occurs further up the callstack, so being able to trace backwards through a programs execution is incredible handy.

 

Next is an incredibly valuable toolbar, that controls your program’s execution while debugging.

 

image

These three are the most commonly used.

Step Over will cause your code to jump to the next line of code in the same file.

Step Into will jump into the code that you are currently on.  If it is a function for example, it will jump into the code for that function, even if it is in a different file.

Step Out backs you out, think of it like undoing a step into, you basically jump back into the calling code.

You use these 3 buttons ( or their hotkey/menu equivalents ) to run through your code as you debug.  There is also an option of run to cursor, which will run to whatever line of code your cursor is currently active on ( clicked on, not just hovering over ).

 

The program will update as it executes, so keep in mind, variable values will often be garbage, until the line they are allocated on is executed.

 

Next up is the Variables window.  Often called “Locals” in other IDEs:

image

 

This is a list of all locally declared variables.  Notice how indexAsString and prevPrefix are both shown, but valued as void?  This is because they haven’t been executed yet.  Lets take a closer look at that.  In WebStorm, locate the line this.removeChild(this.sprite), left click it to focus your cursor, then select run to cursor from the toolbar we just discussed:

image

 

As you can see from the blue line, or program execution continued to that point.  More importantly, if you look in the Variables window, they will now have values, since they have executed in the debugger:

image

 

You may also notice the + sign next to this.  That is because it isn’t a single value variable, so it is composed of other values.  Clicking the + icon will give you more details about the contents of that object:

image

 

Of course, often you want particular information about a specific variable.  This is where watches come in.  Say we want to see more details about this.sprite. In your code window, select all of this.sprite, right click and select Add To Watches.

image

 

Now details of that variable will be available in the watches window, at least, when it is in scope it will:

image

 

You can watch a number of variables at the same time.  Watches are especially useful for watching long lasting variables, like Director or when working in a browser, document.  Just like in the variables list, you can drill down to get more information on child values of the watched variable.

 

Another incredibly handy ability is the expression evaluator, invoked with this button:

image

 

The expression evaluator allows you to run any arbitrary code and see the value.  You can used it for example, to see what a function value would return.  Here for example, I am examining the results of calling this.sprite.getPosition().  Nicely, the expression evaluator has full code hints.

 

image

 

 

 

Finally, sometimes you want to debug code that is running from a server.  This is especially true if you are doing a number of AJAX or socket requests.  You can do this with Webstorm as well, with a few requirements.  First, you need to have a copy of the code installed locally, next you need to use Firefox for this part.

 

Let’s try it with our sample project, which exists on my servers at https://www.gamefromscratch.com/downloads/cocos2d/run/MyFifthApp/index.html while you can download the project source code at https://www.gamefromscratch.com/downloads/Cocos2d/zips/MyFifthApp.zip.

 

First we need to create a new remote debugging session.  In WebStorm, select Run->Edit Configurations…  Hit the + icon and selection JavaScript Debug->Remote.

image

 

Fill the resulting dialog out like so:

image

 

Click Apply then OK. Now everything else works exactly like it did before, with one exception.  Select Debug MyFifthApp Remote.

When you run your code and it hits a breakpoint, it will need you to tell it what file on the remote server matches the file the breakpoint is in.  Since we have a breakpoint set in MyFifthApp.js, when we run it, we will see:

 

image

 

Simply click the Set link, and a dialog will appear:

image

Simply type the URL of the remote file.  You only need to perform this once per file you set a breakpoint into.  You of course can perform this setup step in advance if you want.

 

Now you can locally debug code that is actually running on a remote server.

 

I hope you’ve found this guide handy.  In IDE debugging can make life a thousand times easier. 

General Programming


14. August 2012

 

This tutorial covers the process of creating and using a spritesheet.  A spritesheet is a collection of individual sprites grouped together into a single image.  I created the spritesheet for this tutorial using TexturePacker.  I already documented the process in this tutorial, the only difference is you set the Data Format to Cocos2D instead of Generic XML.  The spritesheet and all of the sprites that went in to making it are included in the archive at the end of this tutorial.

 

The cocos2d.js and main.js files are relatively unchanged:

 

cocos2d.js:

(function () {
    var d = document;
    var c = {
        COCOS2D_DEBUG:2,
        box2d:false,
        showFPS:false,
        frameRate:60,
        tag:'gameCanvas', 
        engineDir:'../cocos2d/',
        appFiles:['MyFifthApp.js'],
        mainFile:'main.js'
    };
    window.addEventListener('DOMContentLoaded', function () {
        var s = d.createElement('script');
        s.src = c.engineDir + 'platform/jsloader.js';
        d.body.appendChild(s);
        s.c = c;
        s.id = 'cocos2d-html5';
    });
})();

The only real different here is the file name passed in the appFiles array.

 

main.js:

var cocos2dApp = cc.Application.extend({
    config:document.querySelector('#cocos2d-html5')['c'],
    ctor:function (scene) {
        this._super();
        this.startScene = scene;
        cc.COCOS2D_DEBUG = this.config['COCOS2D_DEBUG'];
        cc.setup(this.config['tag']);
        cc.Loader.shareLoader().onloading = function () {
            cc.LoaderScene.shareLoaderScene().draw();
        };
        cc.Loader.shareLoader().onload = function () {
            cc.AppController.shareAppController().didFinishLaunchingWithOptions();
        };

        cc.Loader.shareLoader().preload([
            {type:"plist",src:"spritesheet.plist"}
        ]);
    },
    applicationDidFinishLaunching:function () {
        var director = cc.Director.getInstance();
        director.setDisplayStats(this.config['showFPS']);
        director.setAnimationInterval(1.0 / this.config['frameRate']);
        director.runWithScene(new this.startScene());

        return true;
    }
});
var myApp = new cocos2dApp(MyFifthAppScene);

 

There are only two changes here.  First we added spritesheet.plist to the preloader list.  plist files are short for Property List is a configuration format used in Mac/iOS development, but at the end of the day, it’s just data in an XML format.  This file was generated for us by TexturePacker and it describes the details and locations of each sprite within the spritesheet, indexed by the original file name.  The other difference is we pass MyFifthAppScene to our new cocos2dApp call.

 

Let’s take a look at ( a portion of ) the file spritesheet.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
    <dict>
        <key>frames</key>
        <dict>
            <key>Walk_left00.png</key>
            <dict>
                <key>frame</key>
                <string>{{0,0},{128,96}}</string>
                <key>offset</key>
                <string>{0,0}</string>
                <key>rotated</key>
                <false/>
                <key>sourceColorRect</key>
                <string>{{0,0},{128,96}}</string>
                <key>sourceSize</key>
                <string>{128,96}</string>
            </dict>
            <key>Walk_left01.png</key>
            <dict>
                <key>frame</key>
                <string>{{128,0},{128,96}}</string>
                <key>offset</key>
                <string>{0,0}</string>
                <key>rotated</key>
                <false/>
                <key>sourceColorRect</key>
                <string>{{0,0},{128,96}}</string>
                <key>sourceSize</key>
                <string>{128,96}</string>
            </dict>
            <key>spritesheet.png</key>
            <dict>
                <key>frame</key>
                <string>{{0,960},{512,1024}}</string>
                <key>offset</key>
                <string>{0,0}</string>
                <key>rotated</key>
                <false/>
                <key>sourceColorRect</key>
                <string>{{0,0},{512,1024}}</string>
                <key>sourceSize</key>
                <string>{512,1024}</string>
            </dict>
        </dict>
        <key>metadata</key>
        <dict>
            <key>format</key>
            <integer>2</integer>
            <key>realTextureFileName</key>
            <string>spritesheet.png</string>
            <key>size</key>
            <string>{512,2048}</string>
            <key>smartupdate</key>
            <string>$TexturePacker:SmartUpdate:873706d2c1ad9f5b33d90eefda3a7084$</string>
            <key>textureFileName</key>
            <string>spritesheet.png</string>
        </dict>
    </dict>
</plist>

 

The details of the file aren’t important, Cocos2D does all of the heavy lifting for us.  Just be aware that it describes the general layout and name of each sprite within your spritesheet. Now let’s take a look at MyFifthApp.js where the majority of our changes occurred:

 

var MyFifthApp = cc.LayerColor.extend({
    sprite:null,
    spriteFrameNamePrefix:"Walk_left",
    spriteFrameIndex:0,
    init:function()
    {
        this._super();
        this.initWithColor(new cc.Color4B(0,0,0,255));
        var size = cc.Director.getInstance().getWinSize();

        var cache = cc.SpriteFrameCache.getInstance();
        cache.addSpriteFrames("spritesheet.plist", "srcSprites/spritesheet.png");

        this.sprite = cc.Sprite.createWithSpriteFrameName(this.spriteFrameNamePrefix + "00.png");
        this.sprite.setPosition(new cc.Point(300,300));
        this.sprite.setScale(3);
        this.addChild(this.sprite);

        this.setKeyboardEnabled(true);
        return this;
    },
    onKeyUp:function(e){},
    onKeyDown:function(e){
        if(e == cc.KEY.left || e == cc.KEY.right){
            var prevPrefix = this.spriteFrameNamePrefix;
            if(e == cc.KEY.left)
                this.spriteFrameNamePrefix = "Walk_left";
            else
                this.spriteFrameNamePrefix = "Walk_right";
            if(prevPrefix !== this.spriteFrameNamePrefix)
                this.spriteFrameIndex = 0;


            if(this.spriteFrameIndex > 18)
                this.spriteFrameIndex = 0;
            var indexAsString;
            if(this.spriteFrameIndex < 10)
                indexAsString = "0" + this.spriteFrameIndex.toString();
            else
                indexAsString = this.spriteFrameIndex.toString();

            this.removeChild(this.sprite);
            this.sprite  = cc.Sprite.createWithSpriteFrameName(
                this.spriteFrameNamePrefix + indexAsString + ".png"
            );

            this.sprite.setPosition(new cc.Point(300,300));
            this.sprite.setScale(3);
            this.addChild(this.sprite);
            this.spriteFrameIndex++;
        }
    }
});


MyFifthAppScene = cc.Scene.extend({
    onEnter:function(){
        this._super();
        var layer = new MyFifthApp();
        layer.init();
        this.addChild(layer);
    }
});

 

I wont bother going in to detail on MyFifthAppScene, we’ve done that enough times already.  In MyFifthApp we declare a sprite variable to point at the currently active sprite, then declare spriteFrameNamePrefix and spriteFrameIndex.  We access the sprites within the sprite sheet using the keys defined in the plist ( the file name ), of which there are 18 frames for walking left and right:

Walk_left00.png –> Walk_left18.png

Walk_right00.png –> Walk_right18.png

 

We will be building this key dynamically as we switch between sprites.

 

I am only going to cover the new stuff here, the rest should be pretty familiar at this point.  Cocos2D has a built in cache for Sprite frames ( in cocos2D a SpriteFrame is an individual sprite within the spritesheet, while a spritesheet is a SpriteFrames (<- note, plural ) ), the singleton SpriteFrameCache.  We add a new spritesheet to it with the call addSpriteFrames, passing in the name of the plist we preloaded earlier in main.js, as well as the path to the spritesheet graphic.

 

 

Speaking of which, this is spritesheet.png that TexturePacker generated:

spritesheet

We then get our sprite reference from the spritesheet with a call to createWithSpriteFrameName, passing in the key of the sprite specified in the plist.  In this case we are starting with Walk_left00.png.  We then position the sprite at 300,300, scale it to 3x it’s size and add it to our layer.  Finally we tell Cocos we want to handle keyboard events with a call to setKeyboardEnabled().

 

Next in the onKeyDown handler we check to see if the user has pressed ( and released ) the left or right arrow.  Depending on which direction we are walking, that determines which prefix to use for accessing the sprite sheet, left or right.  Next we check if the direction has changed since the last frame, if so, we start the frame index back to 0 to start the animation over.

 

Next we check to see if we’ve exceed our 18 frames, if we have we roll over to 0.  Next we check to see if our index is a single digit ( 0..9 ), in which case we pad it with a 0, so 1 becomes 01.  This is simply because that is how the source frames were named when I imported them to TexturePacker.  We remove our current ( about to be replaced ) animation frame from the layer. We then put our prefix, index and “.png” together to get the key to the next frame of animation, we access with using createWithSpriteFrameName again.  We position and scale the new sprite frame and add it to the scene to replace the previous frame.  Finally we advance to the next frame index.

 

 

Here is our game in action.  Be sure to click in the window to focus keyboard events, then use Left and Right arrows to walk:



This code wouldn’t run when I first deployed it live to my IIS server but worked fine in Apache!  The XML loader in CCSAXParser.js was failing, and it turned out to be a permissions issue.  When you deploy a new file extensions ( like plist ) to IIS, you need to be sure to add it as an allowed mime type!

 

For the record, there are actually better ways to handle animation that we will cover in a later tutorial. This tutorial does however illustrate how to load a sprite sheet and access individual sprites. You can download the entire archive here.

Programming


11. August 2012

 

I just finished updating all of the cocos2D source code to the newest beta code ( as of today anyways ).  You can read about what was involved here or you can download the source code below.  I will be updating the text of each tutorial shortly, but in the meanwhile, you should be able to puzzling things out using just the source, the process stays pretty similar over all, even though there were extensive changes to the code.

 

Project Source Code

 

I will post again when the text of the tutorials are updated.

 

A quick question to all of you, is there any value in keeping the old tutorials and link to the new ones, or should I just overwrite the existing tutorials?  I can’t really think of a use for outdated tutorials, unless of course someone wanted to keep working with their old code base I suppose.

Programming General


10. August 2012

 

I received a comment from a Cocos2D-HTML developer saying that the API is complete for the upcoming beta release, so that I could update the tutorials on this site.  So today I jumped in to see exactly what changed and the answer is quite a bit!  In the process of updating the code to work with the newest Cocos2D code, I went through a great deal of pain tracking down those changes.  This post is to illustrate what has changed, so you don’t have to go through the same process.

 

The code being ported is the example code from this tutorial.

Changes:

 

Filename changes

 

I encountered a few filename changes ( which JavaScript can make exceedingly annoying to find ).  First off, a few files have had their casing changed, which you won’t notice you are working in Windows, but under Linux you will.  Mostly it’s a matter of files being renamed from cc to CC.  Additionally the folder keypad_dispatcher is now keyboard_dispacter, and CCKeypadDelegate.js and CCKeypadDispatcher.cs have been renamed to CCKeyboardDelegate.js and CCKeyboardDispatcher.cs respectively.

 

Function changes

 

ccp is now Point

ccc2/3/4/ is now Color2B,Color3B,Color4B

Layer.setIsRelativeAnchorPoint has been removed.

Director.sharedDirector() is now Director.getInstance();

setIsTouchEnabled() is simply isTouchEnabled()

setIsKeypadEnabled() is now isKeyboardEnabled()

 

Events have been renamed, for example:

ccTouchesEnded is now onTouchesEnded

 

The Keyboard delegate have renamed events from:

keyDown and keyUp to onKeyDown and onKeyUp

cc.key.[name] is now cc.KEY.[name]

cc.Touch ( the value passed to touch handlers ) has changed from .locationInView() to .getLocation()

cc.AudioManager.sharedEngine() is now cc.AudioEngine.getInstance();

cc.Log is now cc.log

 

Bootstrap change

 

This is where the biggest changes occurred.  The startup process is completely different.  First of all, library loading is no longer the responsibility of the  application, it is instead handled by jsloader.js.

 

This changes cocos2d.js massively:

cocos2d.js

(function () {
    var d = document;
    var c = {
        COCOS2D_DEBUG:2, //0 to turn debug off, 1 for basic debug, and 2 for full debug
        box2d:false,
        showFPS:true,
        frameRate:60,
        tag:'gameCanvas', //the dom element to run cocos2d on
        engineDir:'../cocos2d/',
        appFiles:['MyFirstApp.js']
    };
    window.addEventListener('DOMContentLoaded', function () {
        //first load engine file if specified
        var s = d.createElement('script');
        s.src = c.engineDir + 'platform/jsloader.js';
        d.body.appendChild(s);
        s.c = c;
        s.id = 'cocos2d-html5';
        //else if single file specified, load singlefile
    });
})();

If you haven’t seen this syntax before, it is basically an anonymous function that will execute at the end of declaration ( because of the () it ends in ).  The majority of what is going on here is the creation of a configuration file ‘c’, where a number of settings are, um, set.  tag is the name of the canvas element in your html file, engineDir is where you installed cocos2D to, appFiles are additional files you write ( in addition to your main.js ).  Basically every file you create needs to be added to this array.  It then adds an event that will be fired once the DOM has been populated, which will then create a new <SCRIPT> tag in your HTML document, then pass in the path to the jsloader, which will then load all of the cocos2D libraries, as well as anything your specified in the appFiles array.  Finally it stores the configuration settings in ‘c’ in the newly created script tag.

 

In a change I disagree with, the framework now forces you to add a file named main.js, which will be called by jsloader at the end of the loading process.  IMHO, this should be added as part of the configuration you set above.  This file replaced AppDelegate.js from the tutorials.  Let’s take a look at the new main.js:

var cocos2dApp = cc.Application.extend({
    config:document.querySelector('#cocos2d-html5')['c'],
    ctor:function (scene) {
        this._super();
        this.startScene = scene;
        cc.COCOS2D_DEBUG = this.config['COCOS2D_DEBUG'];
        cc.setup(this.config['tag']);
        cc.Loader.shareLoader().onloading = function () {
            cc.LoaderScene.shareLoaderScene().draw();
        };
        cc.Loader.shareLoader().onload = function () {
            cc.AppController.shareAppController().didFinishLaunchingWithOptions();
        };
        cc.Loader.shareLoader().preload([
        ]);
    },
    applicationDidFinishLaunching:function () {
        // initialize director
        var director = cc.Director.getInstance();
        director.setDisplayStats(this.config['showFPS']);
        director.setAnimationInterval(1.0 / this.config['frameRate']);
        director.runWithScene(new this.startScene());

        return true;
    }
});
var myApp = new cocos2dApp(MyFirstAppScene);

Things have changed a fair bit here, but the process is pretty much the same.  First thing to notice is it pulls the configuration data ‘c’ and stores it in the variable config, which is then used to setup cocos2D.  The next major thing to notice is we now create an instance of our app, and pass in the scene to start with. 

 

Now let’s take a look at the changes to MyFirstApp.cs:

var MyFirstApp = cc.Layer.extend({
    init:function()
    {
        this._super();

        var s = cc.Director.getInstance().getWinSize();

        var layer1 = cc.LayerColor.create(new cc.Color4B(255, 255, 0, 255), 600, 600);
        //layer1.setPosition(new cc.Point(s.width/2,s.height/2));
        //layer1.setIsRelativeAnchorPoint(true);
        layer1.setAnchorPoint(new cc.Point(0.5,0.5));

        
        var helloLabel = cc.LabelTTF.create("Hello world", "Arial", 30);
        helloLabel.setPosition(new cc.Point(s.width/2,s.height/2));
        helloLabel.setColor(new cc.Color3B(255,0,0));
        var rotationAmount = 0;
        var scale = 1;
        helloLabel.schedule(function()
            {
                this.setRotation(rotationAmount++);
                if(rotationAmount > 360)
                    rotationAmount = 0;
                this.setScale(scale);
                scale+= 0.05;
                if(scale > 10)
                    scale =1;
            });

        layer1.addChild(helloLabel);
        this.addChild(layer1);

        
        return true;
    }

});

var MyFirstAppScene = cc.Scene.extend({
    onEnter:function(){
        this._super();
        var layer = new MyFirstApp();
        layer.init();
        this.addChild(layer);
    }
})

 

Things have changed a bit here.  First we now extend a scene to create a new object MyFirstAppScene.  This in turn creates a layer and adds it to itself.  The onEnter event is called when the scene is activated ( via RunWithScene ).  Otherwise all of our changes are those described above ( function renames, removal, etc… ).

 

 

I hope that helps you port your existing code to the newest codebase.  All of the changes are improvements ( except perhaps the whole forced main.js thing, I still don’t like that ), so it is worth the pain.  I hope to get the tutorials all updated shortly, but unfortunately, these changes more or less will result in complete re-writes of 3 tutorials, so it might take a bit! Sad smile

Programming


GFS On YouTube

See More Tutorials on DevGa.me!

Month List