Understanding Apple's Metal graphics library. What does it mean to indie game developers?

4. June 2014

 

I’ve noticed since Apple announced Medal at the WWDC a number of people are quite confused over exactly what Metal is.  This post is an attempt to clear that up without having to dig through marketing speak or fanboy drivel.

Metal

 

There is one very important thing to start with…  Metal is not going to cause OpenGL to go away or for Apple to stop supporting OpenGL.  If you are developing a game using OpenGL today, don’t worry, absolutely nothing about your world changes!  Metal is an alternative to OpenGL, but they push different buttons, we will cover that shortly.

 

So, what exactly is Metal?  It’s a low level, less portable more optimized graphics layer for doing the same kind of things you would use OpenGL ( and OpenCL ) or Direct3D for.  That is 3D graphics rendering and parallel GPU programming.  Metal attempts to lower the amount of overhead required for performance reasons as well as reduce CPU bottlenecks ( right now GPUs are spending a lot of time waiting around for CPUs and this is bad mkay? ).  Think about it this way, if you took OpenGL or Direct3D and took away years of cruft and supported only a subset of modern hardware, do you think you could make things faster?  Of course you could, assuming programming ability of course.  That is essentially exactly what Metal does.

 

There is one other very important thing to realize here.  Metal is Apple only!  This may seem obvious, but it really needs to be pointed out.  With DirectX works across a number of video cards and OpenGL works across a number of video cards AND platforms.  Metal on the other hand works only on the newest iOS devices, specifically those with A7 processors ( and assumedly A8, A9 etc… ).  Metal doesn’t even work on Mac OS, but assume all future devices ( such as a console or TV ) from Apple to support Metal.

 

The idea of Metal is hardly anything new.  In some strange ways it’s actually a throwback to the way things used to be in the bad ‘ole days, where each vendor would ship a custom API to take advantage of their 3D hardware.  Voodoo Graphic’s GLIDE API was probably the most popular example.  It was common for game developers to create versions of their games for specific hardware.  Eventually general APIs like D3D and OpenGL won out as it was a pain in the ass supporting all these different render paths… what’s old is new again!  That said, Apple is hardly the only vendor leading us down this road, AMD recently released Mantle, which is basically the exact same thing ( a low overhead GPU API ) targeting AMD/ATI hardware.  Even Microsoft plans to go lower level in DirectX 12, but unlike Metal, it will still support a number of GPUs.

 

So, from a Programmer’s perspective, what is Metal?  It’s a new API that is part of the iOS 8 SDK.  It consists of two parts, the ObjectiveC based SDK and a scripting language creatively known as Metal Shading Language.  The Metal shading language is based on C++11 and is used to write code that will run on the GPU.

 

Should I work with Metal?

I suppose the most important question is… should you care?  To the rank and file indie game programmer truth of the matter is Metal is a bit of a non-issue.  Is it worth re-writing your code to work with Metal?  Probably not.  If you are working cross platform, almost certainly not.  Metal is just too small of a portion of the market to really justify the investment.

 

However...

 

Will you benefit from Metal?  Yes, you probably will.  While you writing a renderer that takes advantage of Metal to run as fast as possible on A7 iOS devices really doesn’t make a lot of sense, for middleware providers, that isn’t the case.  Already Unreal Engine, CryEngine and Unity have announced future support for Metal and expect most other iOS game engines to follow suit.  So, if you are using a game engine, there are almost nothing but upsides to Metal’s announcement.  If you are a middleware provider, well, yeah… Apple just created more work for you.

 

Is there a downside?

 

Well, other than the work it generates for middleware/engine providers, there is certainly one possible downside to Medal.  Until now, especially with the success/clout of iOS, Apple has been a major influencer on the development of OpenGL.  Now that they have their own vendor locked alternative, and let’s not forget Apple LOVES vendor lock in when they are the vendor, it is possible OpenGL's development becomes much less of a priority to them.  At the end of the day though, Apple simply can’t dump OpenGL as the most likely result would be a mass of people dumping Apple.

 

The only other major downside I can think of is in regards to shader programming.  Right now most game engines simply use HLSL or GLSL shader languages.  Therefore when Unity, Unreal, CryEngine, et al.  finally do add Metal support, I will be interested in seeing how they handle shaders.  This is one area of work that could be thrust back on the poor indie developers.  In this regard, only time will tell.




PlayCanvas WebGL game engine is open sourced

4. June 2014

 

Today it was announced that PlayCanvas Game Engine has been open sourced.  PlayCanvas is a WebGL HTML5 game engine that runs across supported browsers, or on mobile devices using a solution such as CocoonJS.  Given yesterdays announcement that Safari for Mac and iOS 8 are both going to support WebGL, it is becoming much more viable.

 

Playcanvas logo

In their words, PlayCanvas engine is:

 

 

In case you haven’t come across the PlayCanvas Engine before, it’s a JavaScript library engineered specifically for building video games. It implements all of the major components that you need to write high quality games:

  • Graphics: model loading, per-pixel lighting, shadow mapping, post effects
  • Physics: rigid body simulation, ray casting, joints, trigger volumes, vehicles
  • Animation: keyframing, skeletal blending, skinning
  • Audio engine: 2D and 3D audio sources
  • Input devices: mouse, keyboard, touch and gamepad support
  • Entity-component system: high level game object management

 

It sounds very similar in scope to the Turbulenz engine I looked at last year.  One major difference is PlayCanvas includes a complete visual editor that runs in the browser:

 

Playcanvas

 

The code is now available on GitHub.

You can read the documentation here as well as the API reference here.

 

Keep in mind though, even though PlayCanvas is now open source, it is not completely free ( although a free tier exists ).  You can check out the pricing tiers here.




Game development tutorial: Swift and SpriteKit - Part 1 A Simple iOS/Mac OS App

3. June 2014

 

With Apple’s recent release of the Swift programming language I have decided I have to check it out.  One of the biggest reasons I’ve stayed away from Apple’s various SDKs is my dislike of Objective-C.  Swift on the other hand is quite a nice little language at least from my experiences so far.

 

Keep in mind a couple thing while reading this.  I am new to Swift ( everyone is, it’s a day old! ) and am new to Apple’s various SDKs and Frameworks.  Therefore I give no promises that anything in this tutorial series is actually the proper way of doing things.  Frankly it works on my computer and that’s about the extent of a warranty I can give! :)  I have heard great things about SpriteKit, the 2D game library Apple released with iOS 7, so I am working with it.

 

Let’s jump right in with some code.  The following is a Mac OS app, but should work equally well on iOS devices.  Keep in mind, to run Swift code you need to have Xcode 6, which is currently in beta.  Obviously you need to have a Mac to follow around.  There are “cloud based” virtual Mac services you can use as well, but my experiences weren’t great.

 

To get started I used one of the provided templates then replaced most of the code.  There used to be a SpriteKit template, but now it has been rolled into “Game”.

In Xcode select File -> New -> Project

Then select OS X -> Application and choose Game, then click Next:

Game

 

In the next dialog, name your application, be sure to select Swift as the programming language and SpriteKit as the Game Technology, click Next.

 

Game2

 

In the next dialog you select where you want to create the project and whether or not you want to create a git archive.  In this case I am not, but if you are working with a team or want version controlling, allow it to create a git repository.

 

When done, click Create and your project will be created.  When I run the generated project, I actually get:

 

Game3

 

Well, that’s not good!  Truth is though, I want to start simpler than the included project, so we are going to replace all the code anyways.  The starter template seems a bit odd to me, extending behaviour that should have probably been built in in the first place.  Let’s get rid of the complexity and strip it down to basics.

 

When you look at the project hierarchy Xcode has created, you will see a number of generated files.  Swift code files end with the extension .swift ( well, that makes sense… ).  It’s these that we are going to replace.  The generated project should look something like:

 

Game4

 

For each file listed below, edit your source to match:

 

AppDelegate.swift

 

import Cocoa

import SpriteKit

 

class AppDelegate: NSObject, NSApplicationDelegate {

    

    @IBOutlet var window: NSWindow

    @IBOutlet var skView: SKView

    

    func applicationDidFinishLaunching(aNotification: NSNotification?) {

            let scene = GameScene(size:self.skView.bounds.size)

            scene.scaleMode = .AspectFill

            

            self.skView!.presentScene(scene)

        }

    func applicationShouldTerminateAfterLastWindowClosed(sender: NSApplication) -> Bool {

        return true;

    }

}

 

GameScene.swift


 

import SpriteKit

 

class GameScene: SKScene {

    override func didMoveToView(view: SKView) {

        /* Setup your scene here */

        

        let sprite = SKSpriteNode(imageNamed: "beach.png")

        sprite.position = CGPoint(x:0,y:0)

        sprite.anchorPoint = CGPoint(x:0.0,y:0.0)

        sprite.size = view.bounds.size

        self.addChild(sprite)

    }

}

 

 

You can completely delete the file GameScene.sks.

 

Additionally, I dragged an Image file “beach.png” into my project file from Finder.  You can use any image you want, just be sure to update the filename in GameScene.swift accordingly.  When dropping the image file, make sure you select Copy if needed, and that the image is being put in the proper target, like so:

 

Game5


 

 

Now when you run the program ( Play icon in top left of your Xcode window ), you should see:

Game6

 

Of course, in your case it should display whatever image you selected.  Let’s take a quick look at what we’ve done here.

 

In our AppDelegate, we handle the applicationDidFinishLaunching event.  Once our app is launched, we create an instance of our GameScene class, set the fill mode to AspectFill and make our newly created scene active for our SKView.  This small function implementation demonstrates a few Swift concepts, i’ll start from the beginning.

Notice the line:

let scene = GameScene(size:self.skView.bounds.size)

 

How we pass in the name of the variable parameter (size), as well as a value (self.skView.bounds.size).  When declaring a function in Swift you have to option of making the user name the parameters or not when they call the function.  That is, when you are declaring a function, you can specify an internal and external parameter name and if you provide an external parameter name, the user must provide the name when calling the function.  Consider the function:

    func printSomething(item:String){

        println(item)

    }

For that function, you can simply call it like:

    printSomething("Hey")

 

However, if you declared the function using an external parameter name, like so:

    func printSomething(thingToPrint item:String){

        println(item)

    }

 

You then need to call the function like so:

    printSomething(thingToPrint:"Hey")

 

If you are familiar with Flash, TypeScript or Haxe, the syntax for functions in Swift should look pretty familiar.  It’s basically

func functionName ( externalVarName localVarName:DataType ) -> ReturnType { FunctionBody }

 

The next line containing new Swift syntax is:

scene.scaleMode = .AspectFill

 

Scale mode is simply an enum defined like so ( in SKScene )


enum SKSceneScaleMode : Int { case Fill case AspectFill case AspectFit case ResizeFill }

 

That line is functionally the same as:

scene.scaleMode = SKSceneScaleMode.AspectFill

 

 

The final line here that might be a bit confusing is 

self.skView!.presentScene(scene)


Specifically the exclamation mark after skView.  This has the somewhat scary name of “implicitly unwrapped optionals”.  See, all types in Swift must have a value, either at declaration or construction.  The exception to this rule is Optional Types.  If you’ve worked in C# this concept ( and syntax ) should look familiar to you, although in C# they are called nullable types.  An optional type declaration looks like this:

var myVariable:String?


 

This is declaring a type that can either have a value, or the special value “nil”.  For an optional type you can “implicitly unwrap” it, using the ! postfix operator, like so:

println(myVariable!)

 

When you do this, you are promising that myVariable currently has a value.  If it doesn’t, you will get a runtime error.

 

The GameScene class is much more straight forward and uses very few new Swift features.  We are loading a SKSpriteNode from file, once again you see an example of an external parameter name here, “imageNamed”.  We then set the image pivot point to the bottom left corner, just because I like the image pivot point being the bottom left corner!  SetPivot works in texture coordinated, so 0,0 is bottom left, while 1,1 is top right.  We size our image to be the same as the view, then finally add the sprite to the SKScene using addChild().  

 

And that is our very first simple application created in Swift displays a sprite on screen using SpriteKit.

 




Apple announce iOS 8 SDK. Includes Metal, an OpenGL replacement and the Swift programming language

2. June 2014

EDIT:  For a better understand of Apple’s Metal API and what it means for OpenGL, click here. 

So finally we are getting some developer related announcements out of the Apple Developer Conference.  For game developers, todays announcement is a dozy.  iOS 8 SDK includes 4,000 new API calls but most importantly includes Metal, a new lower level graphics API similar to AMD’s Mantle.  The idea is to get closer to the metal ( thus the name ) and remove the overhead of OpenGL:

 

Gaming on iOS takes a huge leap forward in iOS 8 with Metal, a new graphics technology that maximizes performance on the A7 chip. With its dramatic 10 times improvement in draw call speed, Metal enables leading game providers for the first time to bring console-class 3D games to mobile devices. For casual games, iOS 8 now features SceneKit, making it easy to create fun 3D games, along with major enhancements to SpriteKit, including field forces, per-pixel physics and inverse kinematics.

 

10 times performance improvement over OpenGL?  That sounds like marketing BS to me or describes an edge case.  If OpenGL was that bloated it would have died off year ago.  The important take away is it’s A7 only, so newest iPad and iPhones are the only ones that support it.  Unity, Crytek and Unreal are all expected to support it so it should be pretty transparent to most developers.

 

The other major announcement was Swift:

 

Swift is a powerful new programming language for iOS and OS X® that makes it easier than ever for developers to create incredible apps. Designed for Cocoa® and Cocoa Touch®, Swift combines the performance and efficiency of compiled languages with the simplicity and interactivity of popular scripting languages. By design, Swift helps developers write safer and more reliable code by eliminating entire categories of common programming errors, and coexists with Objective-C® code, so developers can easily integrate Swift into their existing apps. Xcode® Playgrounds make writing Swift code incredibly interactive by instantly displaying the output of Swift code.

 

The iOS beta software is available now for registered Apple developers.  XCode 6 is required to support the Swift programming language.  You can learn more about Swift here.  I LOVE new programming languages, so I will certainly be taking a closer look.  Some Apple toted features of swift are:

 

Swift has many other features to make your code more expressive:

  • Closures unified with function pointers
  • Tuples and multiple return values
  • Generics
  • Fast and concise iteration over a range or collection
  • Structs that support methods, extensions, protocols.

 

… interesting.  I hate ObjC, so an alternative is certainly appreciated. 

, ,




TypeScript in WebStorm

2. June 2014

 

So far in working with TypeScript I’ve exclusively used Visual Studio and that hasn’t been entirely trouble free.  There are many people out there that wont have access to Visual Studio ( working on Mac or Linux perhaps? ) or simply wont want to.  Thankfully there is a great alternative, WebStorm.  Granted WebStorm isn’t free, although there is a 30 day trial.  It is however a very well spent $50 if you are working in JavaScript ( or TypeScript ).  This post looks at working in TypeScript with Webstorm.

 

First step of course it download and install WebStorm.  The trial is fully functioning by the way.

During the install, if you havent already, you will be prompted to install Java 6.  Don’t worry, WebStorm takes care of the process for you.

Next you need to install Node.  Node.js is a JavaScript environment that works outside of the browser.  I’ve worked with Node a number of times on this site.  Install Node using the default settings.

Now open up a terminal/command prompt and type npm install –g typescript

The results should look like:

image

 

This installed the TypeScript language.  We are now ready to go.

 

When you open a project with a typescript file a file watcher should kick in automatically.  If not, its easy enough to define one.

Select File->Settings.  ( This menu has a different location on MacOS I believe )

On the left hand side, locate File Watchers:

image

 

On the right hand side, if none exist for TypeScript, click plus.  If one exists, make sure its checked.

image

Then select TypeScript from the list:

image

 

Default values should be correct:

image

 

If you have any problems at this point, make sure that Node was installed correctly and that you installed TypeScript, these are the most common problems.

 

Now with a File Watcher created, whenever you save a change to a TS file, it while automoatically compile the JS file.  Like so:

image

 

From this point on you will be able to see full syntax highlighting as well as code completion:

image

 

 

Additionally, you can set a breakpoint in WebStorm:

image

 

And assuming you’ve enabled the WebStorm plugin, you can debug in Chrome:

image

 

Which then allows you to perform the standard debugging tasks in WebStorm:

image

 

If you are coming from Visual Studio, there is one major difference to be aware of.  In Visual Studio, adding a file to your project makes it available for code completion.  In WebStorm this isn’t the case.  If you include a library, such as Phaser, you need to add a reference identifier at the top of your ts file, like so:

 

/// <reference path="phaser.d.ts"/>

 

Then code completion will work properly.

Programming ,