Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
25. April 2016


One of the major advantages to working in 3D is once you have your character modeled and rigged, creating new animations is simply a matter of defining a series of poses on a timeline.  Animations are generally defined by moving a series of bones controlling your mesh, which in turn are powered by a system called inverse kinematics.  IK is basically a fancy way of saying “move an end bone and the computer will calculate how all the other bones in the chain will respond” enabling you to animate by positioning the foot forimage example and the ankle, knee and hip will rotate appropriately.  It’s a pretty powerful way to perform animation and every single major 3D application implements IK (and FK – forward kinematics).


In the land of 2D art, the process is often quite different.  Generally the approach here is to generate a sprite sheet, which is a sequence of slightly altered versions of the same character, which played in sequence results in an animation.  If you ever done a flipbook animation at the top corner of any of your textbooks, you already have the process of traditional 2D animation down.  There are other techniques such as onion skinning and rotoscoping to aid in the animation process, but it still remains time intensive.  If only there was some way to take the 3D worlds bone based animations and apply them to generating 2D art?  Well, there is... Spine.


Today we are going to look inside Spine, look at the art generation process, how to make sprite graphics that are animation ready, define an animation, then perhaps most importantly, play that animation back in our game engine of choice.  Since Spine itself is built over top of the LibGDX library (by one of the frameworks founders to boot), therefore I suppose a LibGDX example makes the most sense.  If you are bored, the story of how Spine came to be is an interesting read.


Full disclosure, I requested a review license in order to get hands on time with Spine.  Additionally some of the assets I am using in this demonstration are part of asset packs available for purchase and aren’t my creation.  Spine is commercial software, ranging in price from $70 for the essentials version, $300 for professional and $2200 for enterprise (which is tied to your companies revenue).  There is a free trial available and capable of doing everything we are about to do below except export and run in code.  Without further ado, let’s jump in.  As is often the case on GameFromScratch, if you prefer a video version one is available here as well as embedded below.


Meet Spine

Here is the main Spine interface:



It’s actually an exercise in simplicity which I appreciate.  It also supports UI scaling, so works well on high DPI displays, something far too many applications suck at, so I also appreciate that.  The left hand viewport is where the magic happens, this is where you compose your characters and animations, while on the right hand side you’ve got your project hierarchy a scene graph of sorts.  The primary UI is across the bottom of the screen.  You can easily pan and zoom around the display using a combination or RMB and Ctrl + RMB.  There is some additional complexity hidden away behind this menu:



But most of the time, what you see is actually all that you need.  It’s a very clean and simple UI.  Notice in the top left corner it says SETUP.  This is because you are currently in Setup mode.  Once our Sprite has been assembled and our bones have been arranged ( more on this in a moment ), we can then switch in to animation mode by clicking SETUP.


In animation mode, its all about posing our character.  Notice SETUP changes to ANIMATE and our interface changes slightly.  Now we have a timeline across the bottom of the screen.  We will get back to that in a moment.


Creating Spine Ready Sprites

Creating a sprite that is ready to be animated in Spine is pretty close to traditional sprite based animation with two major exceptions.  First, you cut your image up into several different pieces.  You can draw your sprite as a single image if you wish, but once you are done you need to cut it into several different animatable pieces.  Consider the sprite from the above screenshots:


This looks like a single drawn sprite, but it’s actually made up for several pieces arranged together.  If you look in the images section of the hierarchy, you can see it’s actually composed of several different images:



Again, you can draw your sprite how you normally would, but each animatable piece will need to be cut up to proceed in Spine.  This leads to our second requirement...  you also need to draw parts of the images that are normally obscured.  Again, using this example, even if the upper arm isn’t full shown due to being obscured by the body you still need to draw the entire arm, as the visibility can change as the sprite moves, for example:



So when drawing the pieces of your sprite, you have to think about the depth as well.  Here for example are all the pieces that go together to make this character:



Rigging Your Character

Next up comes perhaps the most time intensive portion of working with Spine, rigging you character.  You can think of this as arranging all the various images together to create your character, while defining the underlying armature (fancy word for skeleton).  We will do a very simple skeleton, just to demonstrate the process.  You will notice in the tree view that there is a root node under our skeleton:



This is the very base of the skeleton and all bones are parented to it ultimately.  From here we need to create a root bone, it’s very common to start from the hips, which is what we will do.  Using the create tool, we will quickly create a simple leg skeleton:


Click once to set the start of the skeleton, then move the mouse and click again to set the first bone.  Now move down slightly and set another bone, like so:


In the hierarchy I rename the bones to values that make sense.


Now that we have bones, let’s attach some images to each.  From the images section you can simply drag the appropriate image onto the bone, like so:


You will be prompted if you want to go ahead with it:



The image is now parented to that bone.  By selecting the image you can now transform, rotate and resize it so it best matches the underlying bone:


You can also modifying the bone length by hovering over the tip, like so:



Now repeat for the lower bone, like so:



You end up with a hierarchy like:



Extremely simple, but the character is rigged, well, the leg is anyways.


Creating an Animation


Now that we have a very simple animatable character, let’s now switch over to ANIMATE mode.  In the tree view, you should see a section called Animations.  There may be a default one there, otherwise create one using the New Animation button that appears when animation is selected:




Keyframed animation is pretty simple in concept.  You will notice at the bottom of the screen there is now a Dopesheet view:



Your animation is composed of a set of “key” frames.  That is, you post your character and take a snapshot of the location/rotation/scale of a given bone, then advance the timeline to a different value and repeat the process.  The computer then interpolates between keyframes to create a smooth animation.  You can turn “autokey” on, so that any changes you make in the editing window automatically set a key.  Otherwise you can manually create the key by clicking the green key to the right of each transform:



Set a key for the default rotate, translate and scale values, or use Autokey.  Next advance the timeline to say 5, like so:



Next using rotations, manipulate each bone, like so:



Advance the timeline slightly more, then repeat the process all over again.  You can control the playback of your animation using these simple VCR style controls:



Here is a very simple and crude kicking animation:



Another cool thing you can do is add Events as part of your timeline, like so:



Enabling you to create events that can be fired in code, allowing you to incorporate programmatic aspects into your animations, such as playing a footstep audio effect.  We will see this process shortly.


Exporting the Animation

Now that we’ve got an animation to use in our game, it’s time to export it.  Here there are a couple of choices. 



You can export your results as a video, a sequence of images or as data.  If you chose to export as an image you can actually have some rather advanced controls, including generating a texture atlas (directly usable in LibGDX) or sprite sheet:



With results like:



This approach can be utilized in just about every single kind of game engine available today.  However, where Spine shines is when you chose to export as data instead.  This is where runtimes come in.  These are essentially libraries or code for the various game engines that enable you to use spine format natively.  Full source is available on github and runtimes exist for most 2D engines available including Unity, LibGDX, Love, MonoGame, Torque2D, Cocos2d-x and many more.  In this example I will be using LibGDX.


In this case I’m going to export to JSON and generate a texture atlas using the following settings:



Now let’s break out some code.


Using Spine In Game

As mentioned earlier Spine have several runtimes available on github.  In the case of the LibGDX project, you simply have to copy the code into your appropriate source code folder.  Assuming you created a project using the setup utility, this means copying the contents of esotericsoftware to your core\src\com directory.  Then I wrote the following code, adapted from one of their LibGDX examples.

Make sure that you’ve exported your assets and created the atlas in your working directory, most likely \core\assets.  Then use the following code:

package com.gamefromscratch;

import com.badlogic.gdx.ApplicationAdapter;
import com.badlogic.gdx.Gdx;
import com.esotericsoftware.spine.*;

public class Spine2 extends ApplicationAdapter {
    private OrthographicCamera camera;
    private SpriteBatch batch;
    private SkeletonRenderer renderer;
    private TextureAtlas atlas;
    private Skeleton skeleton;
    private AnimationState state;

	public void create () {
		camera = new OrthographicCamera();
		batch = new SpriteBatch();
		renderer = new SkeletonRenderer();
		renderer.setPremultipliedAlpha(true); // PMA results in correct blending without outlines.

		atlas = new TextureAtlas(Gdx.files.internal("skeleton.atlas"));
		SkeletonJson json = new SkeletonJson(atlas);
		SkeletonData skeletonData = json.readSkeletonData(Gdx.files.internal("skeleton.json"));
		skeleton = new Skeleton(skeletonData);
		skeleton.setPosition(0, 0);

		AnimationStateData stateData = new AnimationStateData(skeletonData);
		state = new AnimationState(stateData);

        // Set up an animation listener so we can respond to custom events or completion
        final AnimationState.TrackEntry track = state.setAnimation(0, "kick", false);
        track.setListener(new AnimationState.AnimationStateListener() {
            public void event(int trackIndex, Event event) {
                // Check for the "half" event we defined in the editor
                    System.out.println("Half way baby");

            public void complete(int trackIndex, int loopCount) {
                // or the complete event (not END!) when done, fire the idle animation instead

            public void start(int trackIndex) {

            public void end(int trackIndex) {

	public void render () {
		state.update(; // Update the animation time.
		renderer.draw(batch, skeleton);

	public void dispose () {


When you run this code...



In the above code example you can see how you can handle an event you defined in Spine.  Otherwise it’s pretty simply to load and play animations on a character developed in Spine.  There is a comprehensive API, I’ve only touched on a very small part of it here due to space (this is already pretty long...).  There are also several features I never got to mention such as free form deformation ( useful for shapes such as capes ), swappable skins, place able props, etc..  If you are doing 2D animation, Spine is certainly a product you should check it.  Spine is by no means the only option when it comes to 2D animation in games, Spriter and Creature are two other popular alternatives.  It is however a very good option.


The Video

Art, Programming , ,

24. April 2016


The following is a recap of major events in the world of game development for the week ending April 17th, 2016.  I do a weekly video recapping the news available here with this week’s video embedded below.  This post is a collection of links mentioned in the recap.




The Video

GameDev News

23. April 2016


Version 5.1 of the popular V8 JavaScript runtime was just released.  V8 started life as a high performance JavaScript runtime intended to power the Chromium (Google Chrome) web browser.  As it is one of those silent behind the scenes technologies we just take for granted, it’s perhaps useful to start with a description of V8 itself before continuing.  Here is Google’s own description of the V8 project:

V8 implements ECMAScript as specified in ECMA-262, 5th edition, and runs on Windows (XP or newer), Mac OS X (10.5 or newer), and Linux systems that use IA-32, x64, or ARM processors.

V8 compiles and executes JavaScript source code, handles memory allocation for objects, and garbage collects objects it no longer needs. V8's stop-the-world, generational, accurate garbage collector is one of the keys to V8's performance. You can learn about this and other performance aspects in V8 Design Elements.

JavaScript is most commonly used for client-side scripting in a browser, being used to manipulate Document Object Model (DOM) objects for example. The DOM is not, however, typically provided by the JavaScript engine but instead by a browser. The same is true of V8—Google Chrome provides the DOM. V8 does however provide all the data types, operators, objects and functions specified in the ECMA standard.

While providing a fast JavaScript runtime for a browser is important, it’s V8’s embeddability that has perhaps been it’s most important contribution.  Notice how JavaScript outside the browser has been more and more popular of late?  Most of this can be attributed to NodeJS.  Well Node itself is built on top of the V8 runtime.  Almost every single HTML5 based tool or engine I’ve discussed recently such as Cocos Creator, Superpowers or QICI Engine are in turn powered by Node.  Many modern tools are also built on top of Node as well including Visual Studio Code, Atom and MongoDB.  Sufficed to say V8 is increasingly important to game developers, and all developers in general.


So that’s a brief overview of V8 and hopefully explains why it might be of some importance to you, even if you don’t develop directly in JavaScript.  Now let’s get back to the details of the release.  So what does 5.1 bring?

Improved ECMAScript support

V8 5.1 contains a number of changes towards compliance with the ES2017 draft spec.
Symbol.species allows you to override which constructor is used to construct objects when calling methods on a subclass of Array, RegExp, and other built-in classes.
instanceof customization
Constructors can implement their own Symbol.hasInstance method, which overrides the default behavior.
Iterator closing
Iterators created as part of a for-of loop (or other built-in iteration, such as the spread operator) are now checked for a close method which is called if the loop terminates early. This can be used for clean-up duty after the iteration has finished.
RegExp subclassing exec method
RegExp subclasses can overwrite the exec method to change just the core matching algorithm, with the guarantee that this is called by higher level functions like String.prototype.replace.
Function name inference
Function names inferred for function expressions are now typically made available in the name property of functions, following the ES2015 formalization of these rules. This may change existing stack traces and provide different names from previous V8 versions. It also gives useful names to properties and methods with computed property names:
class Container {
   [Symbol.iterator]() { ... }
let c = new Container;
// Logs "[Symbol.iterator]".
Analogous to other collection types, the values method on Array returns an iterator over the contents of the Array.

Performance improvements

Release 5.1 also brings a few notable performance improvements to the following JavaScript features:
  • Executing loops like for-in
  • Object.assign
  • Promise and RegExp instantiation
  • Calling Object.prototype.hasOwnProperty
  • Math.floor, Math.round and Math.ceil
  • Array.prototype.push
  • Object.keys
  • Array.prototype.join & Array.prototype.toString
  • Flattening repeat strings e.g. '.'.repeat(1000)


5.1 has a preliminary support for WASM. You can enable it via the flag --expose_wasm in d8. Alternatively you can try out the WASM demos with Chrome 51 (Beta Channel).


V8 implemented more slices of Orinoco:
  • Parallel young generation evacuation 
  • Scalable remembered sets 
  • Black allocation

The impact is reduced jank and memory consumption in times of need.


You can read the full release notes here.The WASM announcement is perhaps the most interesting and confusing part of the release, so we will go into a bit of detail now.  So what exactly is Web Assembly?  Well:

WebAssembly is a low-level, portable bytecode that is designed to be encoded in a compact binary format and executed at near-native speed in a memory-safe sandbox. As an evolution of existing technologies, WebAssembly is tightly integrated with the web platform, as well as faster to download over the network and faster to instantiate than asm.js, a low-level subset of JavaScript.

So, essentially it’s a byte code for the web.  You can read more about the topic here if you are interested.

GameDev News

22. April 2016


Phaser, the popular HTML5 based 2D game engine, just released version 2.4.7.  This may sound extremely familiar and that’s because I just recently announced the 2.7 RC release.  Generally there is a fair bit of a time between a release candidate and a final release so I figured I would mention the release candidate.  Oops.  Guess not in this case. 


Anyways, Phaser 2.4.7 is one of the final releases of the Phaser 2.x series, when it will be replaced with Lazer (Phaser 3.x).  The final release for Phaser 2.x is scheduled to be 2.5, after which no new features will be added and it will be maintenance only.  For being so far along in the frameworks lifecycle, it’s actually rather shocking how large this release is:

New Features
  • Added P2.Body.thrustLeft which will move the Body to the left by the speed given (thanks James Pryor)
  • Added P2.Body.thrustRight which will move the Body to the right by the speed given (thanks James Pryor)
  • Polygon now takes an array of arrays as a new type when constructing it: [[x1, y1], [x2, y2]] (thanks @ShimShamSam #2360)
  • Text has a new property maxLines which is the maximum number of lines to be shown for wrapped text. If set to 0 (the default) there is limit. This prevents wrapped text from overflowing on a fixed layout (thanks @slashman #2410)
  • outOfCameraBoundsKill is a new boolean property that all Game Objects with the InWorld component has. If autoCull and this property are both true then the Object will be automatically killed if it leaves the camera bounds (thanks @jakewilson #2402)
  • Group.getByName searches the Group for the first instance of a child with the nameproperty matching the given argument. Should more than one child have the same name only the first instance is returned.
  • BitmapData has a new property frameData which is a Phaser.FrameData container instance. It contains a single Frame by default, matching the dimensions of the entire BitmapData, but can be populated with additional frames should you wish to create animations from dynamic BitmapData textures.
  • FrameData.destroy will nullify the local arrays used to contain Frame instances.
  • SoundManager.muteOnPause is a new boolean that allows you to control if the Sound system gets muted automatically when a Phaser game pauses, such as when it loses focus. You may need to set this to false if you wish to control the audio system from outside of your Phaser game, i.e. from DOM buttons or similar (#2382)
  • You can now pass a TilemapLayer as a Texture to a TileSprite. A limitation of this is that if you pass it to a TileSprite it will make a fill pattern from the TilemapLayer at that instant it's passed, and it won't keep track of the layer in future should it update (thanks @jdnichollsc #1989)
  • Camera has a new property: lerp. This is a Point object, that allows you to control the amount of horizontal and vertical smoothing to be applied to the camera when it tracks a Sprite. It works both with and without deadzones, and is turned off by default. Set it to low values such as 0.1 for really smooth motion tracking (thanks to @WombatTurkey for the idea of adding this)
  • Camera.shake is a new function that creates a camera shake effect. You can specify the intensity, duration and direction of the effect. You can also set if it should shake the camera out of bounds or not.
  • Camera.flash is a new function that makes the camera 'flash' over the top of your game. It works by filling the game with the solid fill color specified, and then fading it away to alpha 0 over the duration given. This is great for things like hit effects. You can listen for the Camera.onflashComplete Signal.
  • Camera.fade is a new function that makes the camera fade to the color given, over the course of the duration specified. This is great for things like transitioning from one State to another. You can listen for the Camera.onFadeComplete Signal.
  • Camera.resetFX resets any active FX, such as a fade or flash and immediately clears it. Useful for calling after a fade in order to remove the fade from the Stage.
  • Phaser.Camera.ENABLE_FX is a const that controls if the Camera FX are available or not. It's true by default, but if you set it to false before boot then it won't create the Graphics object required to process the effects.
  • The Arcade Physics Body has two new properties: left and top. These are the same as Body.x and Body.y but allow you to pass the Body to geometry level functions such as Circle.contains.
  • World.separate has been optimized to cut down on the number of calls to intersectfrom 3 calls per Game Object collision check, to 2. So if you were colliding 50 sprites it will reduce the call count from 150 to 100 per frame. It also reduces the calls made to seperateX and seperateY by the same factor.
  • Two immovable bodies would never set their overlap data, even if an overlap only check was being made. As this is useful data to have this has been changed. Two immovable bodies will still never separate from each other, but they will have their overlapX and overlapY properties calculated now.
  • P2.Body.offset is now used and applied to the Sprite position during rendering. The values given are normal pixel values, and offset the P2 Body from the center of the Sprite (thanks @Mourtz #2430)
  • TypeScript definitions fixes and updates (thanks @jamesgroat @kiswa)
  • Docs typo fixes (thanks @thiagojobson @hayesmaker @EJanuszewski)
  • Removed a console.log from the TilingSprite generator.
  • Sound.position can no longer become negative, meaning calls to AudioContextNode.start with negative position offsets will no longer throw errors (thanks @Weedshaker #2351 #2368)
  • The default state of the internal property _boundDispatch in Phaser.Signal is now false, which allows for use of boundDispatches (thanks @alvinlao #2346)
  • The Tiled parser only supports uncompressed layer data. Previously it would silently fail, now it detects if layer compression is used and displays a console warning instead (thanks @MannyC #2413)
  • The Tiled parser now removes the encoding parameter so that a subsequent process doesn't try to decode the data again (thanks @MannyC #2412)
  • Ensure a parent container is a Group before removing from its hash (thanks @rblopes #2397)
  • The Game Object Input Handler now checks to see if the Object was destroyed during the onInputDown phase, and bails out early if so (thanks @zeterain #2394)
  • The Destroy component will now call TweenManager.removeFrom, removing any active tweens from the TweenManager upon the Game Objects destructions (thanks @PokemonAshLovesMyTurkeyAndILikeYouTwo #2408)
  • Tween.update will now return false (flagging the Tween for destruction) should the property every become falsey. This can happen if the object the Tween was tracking is destroyed, nulled or generally removed.
  • TweenData.repeatTotal is a new property that keeps track of the total number of times the Tween should repeat. If TweenData.start is called, as a result of the Tween repeatCount being > 0 then the child tween resets its total before re-starting.
  • The Debug canvas now listens for the ScaleManager.onSizeChange signal and resizes itself accordingly when running under WebGL. This means if your game size changes the Debug canvas won't be clipped off (thanks @francisberesford #1919)
  • Camera.follow now uses the Targets world property to seed the camera coordinates from, rather than its local position. This means Sprites that are members of offset Groups, or transformed display lists, should now be followed more accurately (thanks @rbozan #2106)
  • PluginManager.destroy is now called by Game.destroy.
  • Game.forceSingleUpdate is now true by default.
  • Video now uses MediaStreamTrack.stop() instead of MediaStream.stop() where possible, as the later is now deprecated in some browsers (thanks @stoneman1 #2371)
  • The Physics Manager will now throw a console warning if you try to enable a physics body using an unknown physics engine type (thanks @jakewilson #2415)
  • The Tileset class will tell you the name of the tileset image throwing the uneven size error (thanks @jakewilson #2415)
  • Emitter.start when used with a false explode parameter would cumulatively add particles to the current total. With quantity 10 the first call would emit 10 particles, the next 20, and so on. Calls to start will now reset the quantity each time. This is a behavior change from earlier versions, so if you relied on the old way please account for it in your code (thanks @BdR76 #2187)
  • You can now pass in your own Canvas element to Phaser and it will use that instead of creating one itself. To do so you must pass a Game Configuration object to Phaser when you instantiate it, and set the canvas property of the config object to be the DOM element you wish to use, i.e.: { canvas: document.getElementById('yourCanvas') }(thanks @Friksel #2311)
  • When loading Video with the asBlob argument set it now uses a 'blob' type for the XHR loader, and doesn't cast the resulting file as a Blob upon load. This fixes loading videos as blobs on Chrome for Android (thanks @JuCarr #2433)
  • When the Loader loads audio via the Audio tag, instead of Web Audio, it used to use Phaser.GAMES[].load as the callback handler, which would stop it from working if you had multiple Loaders set-up within Phaser. It now uses a local reference to _this instead (thanks @SBCGames #2435)
Bug Fixes
  • The mouseoutglobal event listener wasn't removed when the game was destroyed (thanks @stoneman1 #2345 #2344 #2342)
  • Fixed issue with IE crashing on this.context.close in the Sound Manager (thanks @stoneman1 #2349)
  • Phaser.World.centerX and Phaser.World.centerY only worked if the bounds had an origin of 0, 0. They now take into account the actual origin (thanks @fillmoreb #2353)
  • SoundManager.destroy now validates that context.close is a valid function before calling it (thanks @brianbunch #2355)
  • SoundManager.destroy doesn't close the context if it's being stored in PhaserGlobal (thanks @brianbunch #2356)
  • Fix typo in p2 BodyDebug.componentToHex that made most debug bodies appear reddish in color (thanks @englercj #2381)
  • Previously when a sprite was tinted and a new texture was loaded then the tint did not apply to the texture and the old tinted texture was used (thanks @CptSelewin #2383)
  • Negative lineSpacing in Text objects will no longer crop the bottom pixels off lines of text (thanks @gaelenh #2379 #2374)
  • BitmapData.copy, and by extension draw, drawFull, drawGroup, etc, would incorrectly handle drawing a tinted Sprite if it was using a frame from a texture atlas (thanks @PhaserDebugger #2405)
  • Text that used fonts which had numbers in their names wouldn't be correctly rendered unless you explicitly set the font property after creation. You can now pass font names with numbers in them as the font style object correctly (thanks @And-0 #2390)
  • Tween.update wouldn't dispatch an onLoop signal for Tweens with just one child, such as those created via with -1 as the repeat value (thanks @ForgeableSum #2407)
  • Arcade.Body's speed property was only set when the body moved, it now updates regardless (thanks @mark-henry #2417)
  • Camera.position would return the view rectangles centerX/Y coordinates, instead of view.x/y (which is what Camera.x/y returns), so it has been updated to return view.x/y instead (thanks @kamparR #2120)
  • Passing a BitmapData to a TileSprite as a texture would fail if the BitmapData had not been previously added to the cache. It now uses the new frameData property (thanks @mzamateo @lucap86 #2380)
  • When setting a global volume for the SoundManager it would previously incorrectly calculate the volumes of AudioTag based Sound objects that were not played at volume 1. The new approach uses Sound.updateGlobalVolume which adjusts the Sound volume to be a percentage of the global volume. So if the global volume is 0.5 and the Sound volume is 0.5, the Sound will play with an actual volume of 0.25 (thanks @VitaZheltyakov #2325)
  • when using an AudioTag would ignore the muted state of the SoundManager and play regardless. It now checks the SoundManager.mute state on play, and sets the volume accordingly (thanks @brianbunch #2139)
  • Graphics objects can now have a Physics Body directly attached to them, where-as before it would throw an error due to a lack of anchor property (thanks @NLilley #2400)
  • A Game Object with fixedToCamera = true that was then set for Input, and enabled for dragging from its center (input.enableDrag(true)) would throw an error upon being dragged (thanks @solusipse #2367)
  • P2.World.updateBoundsCollisionGroup wouldn't use the boundsCollisionGroup mask if you passed true as the argument, only if it was left undefined.
  • P2.World.updateBoundsCollisionGroup didn't set the _boundsOwnGroup private var, meaning the World.setBounds method wasn't able to restore previously set collision masks automatically (thanks @jmp909 #2183)
  • P2.World.setBounds has been re-written completely. If the World is resized it no longer removes the P2 body instances and re-creates them. Instead it checks to see which walls are required and then just moves the position of the shapes instead, or updates them, or creates or destroys them as required. This is far more efficient, especially in a game which sees a lot of world bounds changes (i.e. resizes responsively in browser)
  • BitmapText would throw an error if you passed in a number as the text property to the constructor. It worked if you used the text accessor directly because it cast the value to a string, but the constructor missed out this step (thanks @lewispollard #2429)
  • Dragging a Sprite while the camera was moving would slowly cause the Sprite position to become out of sync the further the camera moved. A Sprite being dragged now tracks the camera position during the drag update and adjusts accordingly (thanks @jeroenverfallie #1044)
Pixi Updates

Please note that Phaser uses a custom build of Pixi and always has done. The following changes have been made to our custom build, not to Pixi in general.

  • DisplayObjectContainer.getLocalBounds destroys the worldTransforms on children until the next stage.updateTransform() call. This can make a number of things break including mouse input if width, height or getLocalBounds methods are called inside of an update or preUpdate method. This is now fixed in our Pixi build (thanks @st0nerhat #2357)
  • PIXI.CanvasRenderer.resize now applies the renderSession.smoothProperty to the Canvas context when it resizes. This should help with unwanted canvas smoothing (thanks @sergey7c4 #2395 #2317)

You can read the full release notes here.

GameDev News ,

20. April 2016


One of the advantages to moving to a subscription model is we now see continuous project improvement instead of a massive dump of features every couple of years.  Maya has taken the approach of extending via the extensions releases.   They just released the second set of extensions for Maya 2016.

New features include:

  • a new render setup system enabling artists to group and configure objects as they prefer
  • new animation blend shape system with updated UI
  • new tools for creation of blend shapes
  • new post space deformation system (PSD) enable sculpted changes on a per pose basis
  • new quick rig system via HumanIK
  • new xgen system for hair creation
  • added motion graphics toolset, procedural geometry system


For a comprehensive demonstration of new UV and modelling changes watch the following (extremely quite...) video:


You can read more about this release here.

Art, GameDev News ,

Month List

Popular Comments