Planet Gamedev

Game AI for Developers

BROADCAST: ACME Corporation's Detailed Guide to Explosive Game AI Research (October 3rd)

by Alex J. Champandard at October 02, 2014 06:01 AM

BROADCAST: ACME Corporation's Detailed Guide to Explosive Game AI Research (October 3rd)

This upcoming broadcast on Friday, October 3rd at 18:00 UTC will take place online within your browser using streaming audio/video:

“This live broadcast will cover the state of the art in multiple fields of applied AI in games, and then look at research opportunities. In particular, you'll learn about Character Behavior, Intelligent Games, Design Tools, Hardware Devices and Game Analytics. Make sure you're at least as prepared as Wile E. Coyote for explosive research!”

To subscribe for email reminders and check the exact time in your current timezone, visit this broadcast's page on AiGameDev.com.

BROADCAST: Procedural Rogue-Like Generation & AI for Tactical Battles (October 9th)

by Alex J. Champandard at October 02, 2014 06:01 AM

BROADCAST: Procedural Rogue-Like Generation & AI for Tactical Battles (October 9th)

This upcoming broadcast on Thursday, October 9th at 18:00 UTC will take place online within your browser using streaming audio/video:

“In this interview with Chris Park, you'll hear about the design and technology behind Arcen's most recent games: Bionic Dues and The Last Federation. In particular, you'll learn about procedural generation of worlds and levels for rogue-like gameplay, as well as creating simple but memorable AI enemies that create tactical experiences for the player.”

To subscribe for email reminders and check the exact time in your current timezone, visit this broadcast's page on AiGameDev.com.

Game From Scratch

Cocos2d-x Tutorial Series: Basic Sprites, Positioning, Parenting and Coordinate Systems

by Mike@gamefromscratch.com at October 02, 2014 12:54 AM

 

 

Now that we have Cocos2d-x installed and configured and our project created, we are going to take a look at basic graphics operations.  This tutorial assumes you ran through the prior part and created a project already.  I am going to assume you have a working AppDelegate, so I will only focus on creating a new scene object.   The only changes you should have to make are to change your delegate to #include a different file and change the type of scene you call createScene() on.

 

Ok, let’s jump right in with with a simple example.  First we are going to need an image to draw.  Personally I am going to use this somewhat… familiar image:

 

decepticon

 

It’s 400x360, with a transparent background named decepticon.png.  Of course you can use whatever image you want.  Just be certain to add the image to the resources directory of your project.

 

image

 

Ok, now the code to display it.

 

GraphicsScene.h

#pragma once

#include "cocos2d.h"

class GraphicsScene : public cocos2d::Layer
{
public:
    static cocos2d::Scene* createScene();
    virtual bool init();  
    CREATE_FUNC(GraphicsScene);
};

 

GraphicsScene.cpp

#include "GraphicsScene.h"

USING_NS_CC;

Scene* GraphicsScene::createScene()
{
    auto scene = Scene::create();
    auto layer = GraphicsScene::create();
   scene->addChild(layer);
    
    return scene;
}

bool GraphicsScene::init()
{
    if ( !Layer::init() )
    {
        return false;
    }
    
    auto sprite = Sprite::create("decepticon.png");
    sprite->setPosition(0, 0);
   
    this->addChild(sprite, 0);
    
    return true;
}

 

Now when you run this code:

image

 

Hmmm, probably not exactly what you expected to happen, but hey, congratulations, you just rendered your first sprite!

 

So, what exactly is happening here?  Well after we created our sprite we called:

sprite->setPosition(0, 0);

This is telling the sprite to position itself at the pixel location (0,0).  There are two things we can take away from the results.

 

1- The position (0,0) is at the bottom left corner of the screen.

2- By default, the position of a sprite is relative to it’s own center point.

 

Which way is up?

 

One of the most confusing things when working in 2D graphics is dealing with all the various coordinate systems.  There are two major approaches to dealing with locations in 2D, having the location (0,0) at the top left of the screen and having the location (0,0) at the bottom left of the screen.  This point is referred to as the Origin.  It is common for UI systems, the most famous of which being Windows, to set the origin at the top left of the screen.  It is also most common for graphics files to store their image data starting from the top left pixel, but by no means is this universal.  On the other hand OpenGL and most mathematicians treat the bottom left corner of the screen as the origin.  If you stop and think about it, this approach makes a great deal of sense.

Think back to your high school math lessons ( unless of course you are in high school, in which case pay attention to your math lessons! ) and you will no doubt have encountered this graphic.

cartPlane

This is a graphic of the Cartesian plane and it is pretty much the foundation of algebra.  As you can clearly see, the positive quadrant ( the quarter of that graph with both positive x and y values ) is in the top right corner.  Quite clearly then, to a mathematician the value (0,0) is at the bottom left corner of the top right quadrant.

 

There are merits to both approaches of course, otherwise there would be only one way of doing things!

 

This will of course lead to some annoying situations, where one API for example delivers touch coordinates in UI space, relative to the top left corner, or when you load a texture that is inverted to what you actually wanted.

 

Fortunately, Cocos2d-x provides functionality to make these annoyances a little bit less annoying.  Just be aware going forward, that coordinate systems can and do change!  Also be aware, unlike some frameworks, Cocos2d-x does *NOT* allow you to change the coordinate system.  The origin in Cocos2d-x is always at the bottom left corner.

 

Sometimes positioning relative to the middle can be ideal, especially when dealing with rotations.  However, sometimes you want to position relative to another point, generally using the top left or bottom left corner.  This is especially true if for example you want to, say… align the feet of a sprite to the top of a platform.  Changing the way a sprite ( or any Node ) is positioned is extremely simple in Cocos2d-x.  This is done using something called an Anchor Point.  Simply change the code like so:

 

   auto sprite = Sprite::create("decepticon.png");
   sprite->setAnchorPoint(Vec2(0, 0));
   sprite->setPosition(0, 0);

 

And presto!

image

 

Now our sprite is positioned relative to it’s bottom left corner.  However, setAnchorPoint() might not take the parameters you expect it to.  Yes, you are passing it in x and y coordinates that represent the location on the sprite to perform transforms relative to.  However, we are dealing with yet another coordinate system here, sometimes referred to as Normalized Device Coordinates (NDC).  These values are represented by two numbers, one for x and one for y, from 0 to 1, and they are a position within the sprite.

 

Sprite?

 

If you are new to game programming, the expression "sprite" might be new to you.   The expression was termed way back in 1981 by a Texas Instruments engineer describing the functionality of the TMS9918 chip.  Essentially a sprite was a bitmap image with hardware support to be movable.  Early game hardware could handle a few sprites, often used to represent the player and enemies in the world.  In real world examples, in Super Mario Brothers, Mario, the mushrooms, coins and such would be sprites.

These days, “Sprite” is basically a bitmap image ( or portion of a bitmap, we’ll see this later ) along with positional information.  These days the concept of hardware sprites doesn’t really exist anymore.

 

I am making this sound entirely more complicated than it actually is.  Just be aware the value (0,0) is the bottom left corner of the sprite, (1,1) is the top right of the sprite and (0.5,0.5) would be the mid point of the sprite.  These coordinate system is extremely common in computer graphics and is used heavily in shaders.  You may have heard of UV coordinates, for positioning textures on 3D objects.  UV coordinates are expressed this way. 

 

Therefore, if you want to position the sprite using it’s mid point, you would instead do:

sprite->setAnchorPoint(Vec2(0.5, 0.5));

 

Another important concept to be aware of is a sprite’s positioning is relative to it’s parent.  Up until now our sprite’s parent was our layer, let’s look at an example with a different Node as a parent.  This time, we are going to introduce another sprite, this one using this image:

autobot

 

 

It’s a 200x180 transparent image named autobot.png.  Once again, add it to the resources folder of your project.  Now let’s change our code slightly:

bool GraphicsScene::init()
{
    if ( !Layer::init() )
    {
        return false;
    }
    
    auto sprite = Sprite::create("decepticon.png");
    auto sprite2 = Sprite::create("autobot.png");
    sprite->setAnchorPoint(Vec2(0.0,0.0));
    sprite2->setAnchorPoint(Vec2(0.0, 0.0));

    sprite->addChild(sprite2);
   
    sprite->setPosition(100, 100);
    sprite2->setPosition(0, 0);
   
    this->addChild(sprite, 0);
    
    return true;
}

 

And when we run this code:

image

 

There’s a couple very important things being shown here.  Until this point, we’ve simply added our Sprite to our Layer, but you can actually parent any Node to any other Node object.  As you can see, both Sprite and Layer inherit from Node, and Node’s form the backbone of a very important concept called a scene graph.  There is one very important exception to be aware of, while Nodes can be added to other Nodes, a Sprite can only have other Sprites or Sprite derived classes added as children!

 

One very important part of this relationship is the child’s position is relative to it’s parent.  Therefore sprite2’s (0,0) position is relative to the origin of sprite1 ( not the anchor, origin and anchor are not the same thing and only anchors can be changed ), so moving sprite2 also moves sprite1.  This is a great way to create hierarchies of nodes, for example you could make a tank out of a sprite for it’s base and another representing it’s turret.  You could then move the base of the tank and the turret would move with it, but the turret itself could rotate independently.

Scenegraph

 

A scenegraph is a pretty simple concept. It's basically the data structure used to hold the contents of your game. In Cocos2d-x, the scene graph is simply a tree of Node dervived objects. There exists Scene node that is pretty much an empty node with the intention of adding other nodes to it. You then add various nodes to it, nodes to those nodes, etc. An overview of how you can use this system in Cocos2d-x is available here.

 

So what do you do when you want to get a node’s position in the world, not relative to it’s parent?  Fortunately Node has that functionality built in:

Vec2 worldPosition = sprite2->convertToWorldSpace(sprite2->getPosition());

 

worldPosition’s value would be (100,100).  There is also an equivalent function for getting a world space coordinate in node space.

 

So, in summary:

  • The world is composed of Node objects, including Scene, Sprite and Layer
  • The screen origin is at the bottom left corner of the screen, always
  • Nodes are positioned, scaled and rotated relative to their anchor point
  • The default anchor point of a sprite is (0.5,0.5), which is it’s mid point
  • Anchor points are defined with a value from (0,0) to (1,1), with (0,0) being bottom left corner and (1,1) being the top right
  • Nodes can have other nodes as children.  When the parent moves, the child moves with it
  • Child node’s origin is the bottom left corner of their parent
  • Anchor point and origin are not the same thing
  • Sprites can only have other sprites as children

 

So that covers the basics of dealing with graphics.  Now that we know how to position and parent nodes, next time we will look at something a bit more advanced.



Game From Scratch

CopperCube ‘no programming required’ 3D Engine Version 5 released

by Mike@gamefromscratch.com at October 01, 2014 11:48 PM

 

Version 5 of the CopperCube engine was just released.  In their own words, CopperCube is:

 

CopperCube is an editor for creating 3D apps, games and 3D websites. Import or create your 3D models, set camera controllers, materials, behaviors, click 'publish' and your app is ready. Create everything from simple model viewers to full 3D games. As WebGL websites, Flash .swfs, Mac OS, Windows, or Android apps. You can do all this without programming.

 

 

The following are the release notes of the new features in Version 5:

 

  • Terrain support

The editor now includes a way to create and edit terrain. There is also a terrain generator, completely with trees and grass. Terrain can be drawn with height painting tools directly in the editor, textures can be painted quickly with automatic texture blending into the terrain. There are also tools for placing grass and bushes, and for distributing meshes automatically over the terrain.
terrain support terrain rendering

  • Physics engine
    It can be switched on for the Windows and Mac OS X target in the publishing settings. There is also a new behavior available named 'Move object by physics engine' for making objects behave, collide and move like objects in the real world. Objects with the 'Collide when moved' behavior will also collide against those then and be able to move them, roll them over etc. There is also a way to react when an object collides with the world, for example to play sounds, and a way to manually apply forces to objects using scripting.
    physics simulation
  • Video Playback in 2D and 3D
    The professional version of CopperCube now includes an action to play back videos on the Windows .exe, WebGL and Flash target. Videos can be played back in 2D and 3D (like on any 3D object in a scene), it is possible to influence playback with actions (play/stop/pause) and to react when the video playback has been finished or playback failed.
    video playback
  • Network communcation
    You can now easily do HTTP requests on all targets, in order to exchange data with game multiplayer servers, PHP/MySQL database backends, or whatever you like to. This feature is available as new JavaScript function named ccbDoHTTPRequest(), but there is also an action for doing this without programming for download from the website. This feature doesn't directly provide multiplayer support for your games, but it is now possible to build this yourself on top of this.
  • Added iOS 8 WebGL support
    Apps created with CopperCube and the WebGL target now also run on Apple devices (iPhone, iPad, ...) with iOS 8.
    running on iphone and ipad
  • Shader programming
    You can create and add your own materials and shaders during runtime now using the JavaScript API. In the documentation, you will find a few examples showing you how to start. Note that this is nothing simple, and not for beginners. You need to know shader programming in order to use this feature.
    shader programming
  • Animation blending
    CopperCube now blends animations when switching between them. It is automatically enabled, but can be turned off or adjusted for every animated model manually in the editor or via script. This also means that you don't need to create perfect animation loops anymore. The engine will now automatically blend non-fitting animation loops together so that they look nice.
  • Attaching nodes to animated meshes
    This is useful for example to let characters carry weapons in their hands, to switch them dynamically, change how they look like, or for example to even attach particle systems to moving parts of an animation. Use the command "Modify Selection -> Attach node to animated joint..." for this.
    attaching to animations
  • Directional light
    This is useful for simulating light sources from a very far distance, like for simulating the sun. Directional light can now be used just as the already supported point lights both with the light mapper as well for dynamic lighting.
    directional light
  • Procedurally generated trees
    There is a new scene node type available which generates a tree (a 3d model of a plant) based on user specified parameters. It is possible to create all kind of tree types from it, be it for example a full grown pine or a dead desert bush. This feature is beta, and not very user friendly yet, but planned to be improved in future versions.
    generated trees
  • Faster Lightmapper, with Mac OS X support
    The built-in lightmapper has been rewritten and is now much faster. Additionally, it now also works with shadows on the Mac OS X version of the editor, wich previsously only produced results with diffuse lighting only.
    lightmapper of coppercube
  • Optimized WebGL performance and compatibility
    Not only did we squeeze all these features into a tiny, 180KB .js file, we also improved the performance again by about 20% in certain areas, and improved compatibility with mobile and/or touch enabled WebGL capable browsers such as Chrome for Android.
  • Custom Icons for Windows Apps
    There is now a new option to select an icon for the windows target. Note that embedding the icon in your app might slow down the publishing process by a few seconds, depending on your operating system. (This feature is not supported in the Mac OS X version of CopperCube)
  • Manual Commands for the AI
    Use the function ccbAICommand() for this, so you can send any "Game actor with Health" to a specific location, command it to attack something, or similar.
  • 15 new prefabs
    15 new prefabs added: 2 new animated characters (a soldier; a sleep walker), 2 weapons to be attached to animated characters: a shotgun and a pistol, 11 high quality, low poly prefabs created by Efe: a classic car, a bicycle, an armchair, an ancient statue, a book, a nightstand, a flowerpot, a lamp, two tables, a television.
    prefabs
...and many other changes:

 

  • There is now a new command for converting a static mesh to an animated mesh (without animation). This is useful for ditributing huge amounts of static meshes over the terrain without much memory usage, since instances of animated meshes share their data and are culled more efficiently.
  • New, better looking examples come preinstalled with CopperCube now.
  • The 'object controlled by keyboard' behavior now has a more fine tuned animation playback system
  • The 'object controlled by keyboard' behavior now has the option to 'pause' after jumping, making the jumping feature look more like in some platform games.
  • The gravity value is now set per scene, in the root object of the scene.
  • Jumping in all behaviors is much nicer and more physically correct now. But this also means that you might have to adjust your jump settings in existing projects when upgrading to CopperCube 5.
  • Game AI movement is more smoother now
  • Scripting changes: New functions:
    • ccbCreateMaterial()
    • ccbSetShaderConstant()
    • ccbAICommand()
    • ccbSetPhysicsVelocity()
    The following functions are now also available in the editor:
    • ccbGetCollisionPointOfWorldWithLine()
    • ccbDoesLineCollideWithBoundingBoxOfSceneNode()
    Changed behavior:
    • ccbEndProgram() now closes the window in WebGL and Flash
  • When cloning nodes in the editor, also children will now get unique names and ids, and relinked with the behavior of the parent
  • 3D Editor change: When changing the parent child relation of a node, the position of the node is tried to be kept at the old position
  • 3D Editor change: When moving an object which is the child of a rotated parent object, movement will still move into the direction the arrows are pointing
  • When right-clicking onto a texture in the texture browser, there is now a command to save the texture as file to disk.
  • It's possible to use the mouse wheel in the prefabs window
  • Removed feature: It is no longer possible to target Flash players older than version 11
  • When switching the perspective, orthogonal views now place the camera more nicely.
  • The path tool new works a bit nicer when adding new path nodes.
  • Lots of updates to the documentation.

 

A trial version is available for both Windows and Mac.

iPhone Development Tutorials and Programming Tips

Open Source iOS Component For Customizable Notifications With Native Notification Style

by Johann at October 01, 2014 07:04 PM

Post Category    Featured iPhone Development Resources

Last week I mentioned a component inspired by Facebook’s Slingshot app for creating customizable slide-in alerts.

Here’s an open source component that allows you to create alerts with the look and feel of native iOS 7 and 8 notifications with a number of nice features called LNNotificationsUI from Leo Natan.

Some of the features of LNNotificationsUI include:

- Pixel accurate representation of native notifications
- Displaying of notifications with customizable title, message and date
- Customizable image icons
- Swipe to dismiss support
- Support for notifications from more than one application
- Easily added to your project as an Xcode 6 framework

Here’s an animation from the readme showing LNNotificationsUI in action:

LNNotificationsUI

You can find LNNOtificationsUI on Github here.

A nice component for creating native style notifications.


Be the first to comment...

Related Posts:

FacebookTwitterDiggStumbleUponGoogle Plus

Original article: Open Source iOS Component For Customizable Notifications With Native Notification Style

©2014 iOS App Dev Libraries, Controls, Tutorials, Examples and Tools. All Rights Reserved.

OpenGL

CopperCube 5 released

October 01, 2014 11:04 AM

CopperCube, the game engine using OpenGL for apps and WebGL for website has just been released in version 5. It now includes terrain support, video playback, network communication, iOS 8 WebGL support, shader programming through scripting, animation blending, and much more. A list of the new features with images is available as well.



iPhone Development Tutorials and Programming Tips

Open Source iOS Library For Easier Implementation Of App Touch ID Authentication

by Johann at October 01, 2014 06:17 AM

Post Category    Featured iPhone Development Resources,iOS Development Libraries,Objective-C,Open Source iOS Libraries And Tools,Swift

Last week I mentioned a nice straightforward guide on the basics of implementing touch ID authentication in an app.

Here’s a library allowing you to easily use Touch ID to for app authentication called EHFAuthenticator from Christopher Truman of eHarmony.

EHFAuthenticator allows you to present the user with a view asking for authentication via TouchID, and executed a callback on successful entry.

This set of images from the readme shows a mockup of the feature in the eHarmony app:

EHFAuthenticator

You can find EHFAuthenticator on Github here.

You can read more about Touch ID authentication over on Christopher Truman’s blog.

A nice library and example on using the touch ID local authentication feature of iOS 8.


Be the first to comment...

Related Posts:

FacebookTwitterDiggStumbleUponGoogle Plus

Original article: Open Source iOS Library For Easier Implementation Of App Touch ID Authentication

©2014 iOS App Dev Libraries, Controls, Tutorials, Examples and Tools. All Rights Reserved.

Icare3D Blog

Maxwell GM204 OpenGL extensions

by Cyril Crassin (noreply@blogger.com) at September 30, 2014 11:00 PM

NVIDIA just launched the Maxwell 2 architecture with GM204, and this is I believe, an incredible chip. The Maxwell 2 architecture is both highly energy efficient (~2x perf/watt of Kepler in games), and provides a lot of very exciting new graphics features (some of them are exposed in Direct3D). These features are exposed in form of new OpenGL extensions in the R344 driver that was released today, and the specification for all NVIDIA supported GL extensions can be found here. NVIDIA also released new SDK samples using these extensions.

Quick description of the new extensions

Multisampling

This feature adds a lot of flexibility to the multi-sampled rasterization, and decouples the rasterization sampling frequency (which can be set explicitly) from the actual framebuffer storage. It enables rasterization to operate at higher sampling frequency than the number of samples in the target color render buffers, and it supports both depth and stencil testing at this frequency, if the corresponding depth and stencil buffers are sampled accordingly (it must be a multiple of the number of samples in the color buffers).
There are still some constraints; All color buffers must have the same number of samples, and the raster sample count must match the depth and stencil buffer sample count if depth or stencil test is enabled, and it must be higher or equal to the color buffer sample count.

A new “coverage reduction stage” is introduced in the per-fragment operations (after the fragment shader in early-z mode, after the depth-test in late-z), which converts a set of covered raster/depth/stencil samples to a set of covered color samples. There is an implementation-dependent association of raster samples to color samples. The reduced "color coverage" is computed such that the coverage bit for each color sample is 1 if any of the associated bits in the fragment's coverage is set, and 0 otherwise. This feature can be used in conjunction with the coverage to color feature (cf. below), in order to get the FS output coverage mask automatically transformed into a color by ROP. According to AnandTech, it seems that when rasterizing with explicit multisampling and no render-target, GM204 allows evaluating primitive coverage at 16x MSAA.

Note that EXT_raster_multisample is equivalent to "Target-Independent Rasterization" in Direct3D 11.1, which allows using multiple raster samples with a single color sample, as long as depth and stencil tests are disabled, and it is actually a subset of NV_framebuffer_mixed_samples which is more general and exposes more flexibility.


This allows using ROP to automatically convert the post depth-/stencil-/alpha- test coverage mask into a color and write it into a color render target. This is performed before the new coverage reduction stage (cf. NV_framebuffer_mixed_samples). This can be useful for deferred shading.


This extension allows the fragment shader to get the post depth-test coverage mask of the current fragment as input (gl_SampleMaskIn[]) when operating in early-depth mode (for which only sample passing the depth-test are set), unlike the standard GL 4.5 behavior which provides the pre- depth-test coverage (actual triangle coverage).


The standard GL behavior for FS output coverage mask (gl_SampleMask[]) is to AND it with the actual primitive input coverage mask. This extension disables this operation, which allows the fragment shader to fully override the primitive coverage, potentially setting coverage bits that were not set in the input mask. This is actually very nice, because it allows dynamically routing color output values into arbitrary sample locations inside a multisampled render target.


Allows applications to explicitly set the location of sub-pixel samples for multisample rasterization, providing fully programmable sampling patterns. It seems that the sub-pixel positions are snapped to a 16x16 sub-pixel grid, and sampling patterns can be defined within a grid of 2x2 adjacent pixels.


Rasterization

This is a really great feature. It allows rasterization to generate fragments for any pixel touched by a triangle, even if no sample location is covered on the pixel. A new control is also provided to modify the window coordinate snapping precision in order to allow the application to match conservative rasterization triangle snapping with the snapping that would have occurred at higher resolution. Polygons with zero area generate no fragments. Any location within a pixel may be used for interpolating attributes, potentially causing attribute extrapolation if outside the triangle. This can be useful for binning purpose for instance (one pixel per-tile).


This extension exposes an hardware-accelerate critical section for the fragment shader, allowing hazard-free read-modify-write operations on a per-pixel basis. It also allows enforcing primitive-ordering for threads entering the critical section. It provides new GLSL functions beginInvocationInterlockNV() and endInvocationInterlockNV() that defines a critical section which is guaranteed to be executed for only one fragment at a time. Interlock can be done per-pixel or per-sample if multi-sampled rasterization is used. This is useful for algorithms that need to access per-pixel data structures via shader load and store operations, while avoiding race conditions. Obvious applications are OIT and programmable blending for instance.


This allows rasterizing the axis-aligned screen-space bounding box of submitted triangles, disregarding the actual triangle edges. This can be useful for drawing a full-screen quad without an internal edge for instance, or for more efficiently drawing user interfaces.


Geometry processing

This extension allows to write more efficient geometry shaders in the case there is a one-to-one mapping between input and output primitives, and per-vertex attributes are simply copied from the input primitive to corresponding outputs in the vertices of the output primitive, and the geometry shader is only used to set per-primitive attributes (like gl_Layer ... ).


Texturing

This extension improves on ARB_sparse_texture, which separate the allocation of virtual address space from physical memory for textures, and provides the ability to sparsely allocate the physical backing-store of 2D/3D/2DArray textures on a per-tile basis. This new extension adds the ability to retrieve texture access residency information from GLSL, to specify minimum allocated LOD to texture fetches and to return a constant zero value for lookups into unallocated pages. It also adds support for multi-sampled textures.


Exposes a new sampler parameter allowing to perform a min or max reduction operation on the values sampled inside a texture filtering footprint, instead of the regular linear interpolation.


Atomics 

This extension provides a set of new atomic operations operating on 2 and 4 components vectors of 16b floating point values for images, bindless pointers to global memory and storage buffers.


List of new extensions


iPhone Development Tutorials and Programming Tips

Tutorial On Using The New Visual Effect Classes In iOS 8 To Create Great Looking Blurs

by Johann at September 30, 2014 09:06 PM

Post Category    Featured iPhone Development Resources,iOS Development Tutorials,Swift

In the past year I’ve mentioned the RNFrostedMenu and RNBlurModalView for creating great looking blurred menus and modal views from Ryan Nystrom.

Here’s a nice tutorial from Ryan on creating blurs, and utilizing the new visual effects classes found in iOS 8.

The topics covered in the tutorial include:

- How the typical Gaussian blur algorithm works
- How to use blurs to improve your app’s design
- Taking a screen snapshot and applying a blur
- Adding vibrancy to a blur (with UIVibrancyEffect)
- Creating different blur effect styles (with UIBlurEffect)

You can find the tutorial here.

A nice guide on creating blurs.


Be the first to comment...

Related Posts:

FacebookTwitterDiggStumbleUponGoogle Plus

Original article: Tutorial On Using The New Visual Effect Classes In iOS 8 To Create Great Looking Blurs

©2014 iOS App Dev Libraries, Controls, Tutorials, Examples and Tools. All Rights Reserved.



Physics-Based Animation

Parallel Particles (P^2): A Parallel Position Based Approach for Fast and Stable Simulation of Granular Materials

by christopherbatty at September 30, 2014 04:09 PM

Daniel Holz

Granular materials exhibit a large number of diverse physical phenomena which makes their numerical simulation challenging. When set in motion they flow almost like a fluid, while they can present high shear strength when at rest. Those macroscopic effects result from the material’s microstructure: a particle skeleton with interlocking particles which stick to and slide across each other, producing soil cohesion and friction. For the purpose of Earthmoving equipment operator training, we developed Parallel Particles (P2), a fast and stable position based granular material simulator which models inter-particle friction and adhesion and captures the physical nature of soil to an extend sufficient for training. Our parallel solver makes the approach scalable and applicable to modern multi-core architectures yielding the simulation speed required in this application. Using a regularization procedure, we successfully model visco-elastic particle interactions on the position level which provides real, physical parameters allowing for intuitive tuning. We employ the proposed technique in an Excavator training simulator and demonstrate that it yields physically plausible results at interactive to real-time simulation rates.

Parallel Particles (P^2): A Parallel Position Based Approach for Fast and Stable Simulation of Granular Materials

iPhone Development Tutorials and Programming Tips

Open Source iOS Library For Creating Complex Table Views That Uses Storyboards Prototype Cells

by Johann at September 30, 2014 06:18 AM

Post Category    Featured iPhone Development Resources,iOS Development Libraries,Objective-C,Open Source iOS Libraries And Tools

I’ve mentioned a number of libraries and components for creating complex table views such as STXDynamicTableView which provides  many different custom cell types for photo feed layouts.

Here’s a library call AMBTableViewController that makes use of Prototype Cells within the Xcode Storyboard tool for managing complex table view layouts. An extensive example is included.

The features of AMBTableViewController include:

- Separation of table view code into different sections
- Hide/show, add/remove sections and rows
- Dynamic cell heights
- Storyboard proptotype cell support
- A blocks based syntax

Here’s an image showing some prototype cells in the storyboard view used by AMBTableViewController, and a created table view:
AMBTableViewController

You can find AMBTableViewController on Github here.

A great library for creating complex table view layouts.


Be the first to comment...

Related Posts:

FacebookTwitterDiggStumbleUponGoogle Plus

Original article: Open Source iOS Library For Creating Complex Table Views That Uses Storyboards Prototype Cells

©2014 iOS App Dev Libraries, Controls, Tutorials, Examples and Tools. All Rights Reserved.

iPhone Development Tutorials and Programming Tips

An Open Source Swift Based Websockets Client Library

by Johann at September 29, 2014 06:37 PM

Post Category    Featured iPhone Development Resources,iOS Development Libraries,Open Source iOS Libraries And Tools,Swift

Some time ago I mentioned the objective-c based SocketRocket Websockets client libary.

Here’s an open source library Swift based websocket client library called StarScream from Dalton Cherry.

StarScream features a nice clean syntax, support for secure websocket connections (tls/wss), and is automatically non-blocking with everything happening in the background.

This example from the readme shows how to create a socket and the callback once a connection is made:

var socket = Websocket(url: NSURL(scheme: "ws", host: "localhost:8080", path: "/"))
socket.delegate = self
socket.connect()

func websocketDidConnect() {
    println("websocket is connected")
}

You can find StarScream on Github here.

A great library for using Websockets.


Be the first to comment...

Related Posts:

FacebookTwitterDiggStumbleUponGoogle Plus

Original article: An Open Source Swift Based Websockets Client Library

©2014 iOS App Dev Libraries, Controls, Tutorials, Examples and Tools. All Rights Reserved.



Geeks3D Forums

Index Buffer Compression for Vertex Cache Optimization

September 29, 2014 05:32 PM


- Vertex Cache Optimised Index Buffer Compression
  http://conorstokes.github.io/graphics/2014/09/28/vertex-cache-optimised-index-buffer-compression/
  https://github.com/ConorStokes/IndexBufferCompression

- Simple lossless(*) index buffer compressio...

Game From Scratch

Cocos2d-x Tutorial Series: Installation, Creating a Project and Hello World

by Mike@gamefromscratch.com at September 29, 2014 02:48 PM

 

 

Welcome to the GameFromScratch.com Cocos2d-x tutorial series.  Cocos2d-x is a cross platform, C++ based port of the popular Cocos2D ObjectiveC game development library. Using the most recent version of Cocos2D-x you can target Windows, Mac, Linux, iOS and Android.  Previous versions enabled you to target even more targets including Blackberry and Tizen.  The history of Cocos2D-x is actually very important, as it factored in many of the design decisions that the library has taken.

 

This series will walk through the all aspects of using Cocos2d-x to create a game.  This particular part covers the process of getting Cocos2d-x installed, creating an initial project and looks at a bare bones Hello World example.

 

Cocos2D History

 

As I mentioned earlier, the history of Cocos2D is fairly important to understanding how it works, so we are going to start of with a quick, hopefully not-boring, history lesson.  I promise you, this will be the only history lesson in this entire series!  Unless of course I do more of them…  If you want a more thorough history, you can always check out the wiki.

 

Ok… history time.

 

Way back in 2008, Cocos came to be, named after the town of Los Cocos, Argentina, in case you were wondering where exactly the name came from.  It started from a gathering of Python developers in, you guessed it, Los Cocos.  As you may be able to guess from the fact it was started by a bunch of Python developers, Cocos started off being written in Python.

 

Then came along this little phone named the iPhone, and a version of Cocos2D was ported to ObjectiveC for use on iOS, the aptly named cocos2d-iphone.  A number of Cocos2d-iphone developed apps started appearing on the iPhone, including StickWars, which hit number 1 on the App Store.  Now we hit the fast forward button on history and see that Cocos2d is ported to a number of platforms.

 

One of those ports was of course Cocos2d-x, which was a port of Cocos2D to C++, the subject of our tutorial here.  Cocos2d-x itself also spawned a number of ports, including HTML and XNA.  Along the way a number of tools were developed as well, including an editor named CocosStudio (itself the spawn of a number of child projects ) and CocosCodeIDE and IDE for Lua and JavaScript scripting in Cocos2d-x.

 

So, why does this all matter?

 

Well, it’s important that you be aware that Cocos2d-x is a port of an Objective-C library which itself was a port of a Python library.  Each language and platform has had an effect on the development of Cocos2d-x, for better or worse.  You will run into some concepts and think “why the hell did they do this?”.  More often than not, it’s Cocos2D’s history that provides the reason.

 

One final important thing to realize with Cocos2d-x, a number of the most active developers behind the project are not primarily English speakers.  Cocos2D-x is extremely popular in China for example.  This is by no means a negative, but we aware sometimes language can be a bit of a barrier when looking for help and reading documentation.

 

 

What Version are you using?

 

At the point I am writing this, I am using Version 3.3beta 0 to create tutorials, and as new versions are released I will try to stay with the most recent version.  This is because I am trying to future proof this series as much as possible.  In all honesty, I know this is going to be quite annoying as well, when I created by cocos2d-html5 tutorial series, the number one problem was version changes.  Cocos2d-x is a library that get’s refactored quite a bit, so if you are far in the future and some code I provided doesn’t work, this is probably why.  Always make sure to read the comments at the bottom of each part, it may contains clues to the problem you are facing.

 

So then, what version should you use?  That answer is a bit trickier.  You have a choice between Cocos2d 2.x, 3.0 or 3.x right now.  The 2.x version is obviously the older version and less actively developed, if at all (edit – according to this thread, 2.x is no longer being supported).  That said, 2.x also supports the most platforms, including Windows Phone, Marmalade, Tizen, Blackberry and more.  Additionally, as of writing, every single book targets 2.x.  3.2 is the (currently) stable release of the most current version, while 3.x is the development version.

 

Again, I will be using the most current version as I go, and if history has taught me anything, this is going to lead to tons of issues! ;)  Warning, Here be dragons!

 

HTBD

 

 

 

Setting Up Cocos2D-x

 

In order to get started with Cocos2d-x, you need to have a couple things installed already, depending on platform you are developing on. 

 

Obviously you need a C++ compiler.  If you are working on Windows, Visual Studio 2013 is currently the recommended version.  You can download a free version named Visual Studio Express for Windows Desktop  ( note, there is also a version called Visual Studio Express for Windows, you do NOT want this version… yeah, brilliant naming by Microsoft there eh? ).  Of course if you have a complete version installed it will work fine as well.  You can also use older versions of Visual Studio, back to 2010 I believe, but this series will assume you are using the most recent version.

 

On Mac OS, Xcode is the obvious solution.  It’s also free, so that’s nice.  As of writing Xcode 6 is currently in late beta, but will work just fine.  Xcode 5 should also work just fine.  Personally I am not a huge Xcode fan and use AppCode for development on Mac, but it is not a free tool.  You may see it on occasion in screenshots, so I figured I would put it out there.  By default Xcode does not install the command line tools, so I would install those as well, you can find instructions here and official documentation here.

 

You also need to have Python installed.  Don’t worry, Python isn’t used to code in Cocos2d-x, but some of the tools require it, including the tool you use to create your project, so obviously this install is pretty important.  Another important note, so I’m going to use bold and shout at you for a second.  YOU NEED TO INSTALL PYTHON 2.7x!  The newest version, Python 3.x does not work and you will be wasting your time.  So go ahead download Python 2.7.x here.  On Windows you want to make sure Python is added to the PATH environment variable.  If it isn’t, you can get instructions here.

 

Finally if you are intending to develop for Android, you need to have a version of the Android SDK, ANT and Android NDK installed.  You need at least version 9 of the NDK ( 10 is the current as of writing.  EDIT – NDK 10 currently doesn’t work!  Read here for details.  Here for the ticket.  There is a work-around, but using NDK 9 is probably your easiest bet ) to work with Cocos2d-x.  Now to make life slightly more complicated, if you are on Windows, the Android NDK also requires Cygwin 1.7 or higher to be installed.  Fortunately, Cygwin has no further requirements.  When downloading the Android SDK, do not download the ADT package, but instead scroll further down the page and install using the “Get the SDK for an existing IDE” link.  As an FYI, the SDK is the Java SDK along with the tools needed for Android development, the NDK is the C++ toolchain for Android development, while Ant is a Java build system.

 

Please note, Cocos2d-x and be used with other IDE’s such as Eclipse or Qt Creator, but I will not be covering the process in this tutorial.

 

Oh and of course you need to download cocos2d-x itself!  Simply download and extract the library somewhere on your system.

 

 

Creating a Cocos2d-x project

 

Ok, now that you’ve got everything installed and configured, it’s time to create a project.  Open up a terminal window or command line and change to the directory you extracted cocos2d-x.

 

MacOS  Cocos2d Config and New Project Instructions:

 

Enter:

./setup.py

source ~/.profile

cocos new -l cpp -p com.gamefromscratch.gamename -d ~/Documents/Projects/cocos2d gamename

Ss6

 

Windows Cocos2d Config and New Project Instructions:

 

Open a command prompt and CD to the directory you extracted Cocos2D to.  Run the command:

python setup.py

 

If you get an error about not being able to find Python, that PATH is not configured correctly.  Depending if you have certain environment variables set or not, the install may now ask you the install directory of your Android NDK, SDK as well as Ant, provide them.  If you’ve not installed the NDK and SDK before now, do so before performing this step.

 

The next step depends on your operating system version.  If you are running Windows XP ( and possibly Vista ), you now need to restarted your computer for the changes to take effect.  If you are running Windows 7 or 8.x, simply close your command prompt and open a new one.

 

Now type:

cocos new -l cpp -p com.gamefromscratch.gamename -d C:\path\to\game\here gamename

 

Creating a New Project:

 

The tool to create cocos projects is “cocos” and it resides in [cocosSDKfolder]/tools/cocos2d-console/bin.  -l is an L by the way, this is where you specify the language for the project you want to create.  The options are cpp and lua currently, in this case we want cpp.  -p is for specifying the package, mostly for Android I assume.  This uses Java’s standard reverse domain name format.  Don’t worry if you don’t have a website, make something up.  The -d parameter is the directory where you want to create the project.

 

Now that our project is (hopefully!) created, lets take a look at what it’s created for us.

 

Ss1

 

Here you can see it has created a number of key directories for you, we will take a closer look at each one.

 

Each folder prefixed with proj. is where project files and platform specific code goes, be it android, iOS and Mac, linux, Windows or Windows Metro ( or.. what was previously known as Metro ). 

 

The cocos2d folder however is where the cocos SDK itself is copied.  This is a complete copy of Cocos2d, including docs, libraries, headers, etc.  Just a warning, this folder is 250MB in size and will be created for each cocos2D project you create using cocos new!  You can set up your projects to use a common install of cocos2d-x, by specifying the engine path when calling cocos new.  Just be aware, if you are tight on space and are going to be making a number of cocos2d-x projects, you may want to look into this further.

 

The resources folder is a common repository for all the various assets that your game will use, such as graphics, sound, etc.  The Classes folder is perhaps most important of all, this is where your non platform specific code goes!  Right now the contents should look like:

Ss2

 

These code files create a simple application to get you started, although we are ultimately going to replace the contents.  The expression AppDelegate comes from Mac programming, so if you are a Windows or Linux developer, it might be a bit alien to you.  An AppDelegate is a helper object that goes with the main window and handles events common to applications such as starting up, minimizing and closing.  You won’t really spend much time here, that instead is where the Scene file comes in.  We will look at code shortly so each piece will make a bit more sense.

 

Now let’s look at the platform specific portions for both win32 and ios_mac.

 

win32:

Ss3

 

ios_mac:

Ss4

 

As you can see, each folder contains all the platform specific code, resources and most importantly, project files for each platform.  In the case of ios_mac, it further contains platform specific folders for each platform.

 

All platforms have their own unique entry point ( main, WinMain, etc ) and different ways of handling different things.  Most of this is just relevant on start up and cocos2d-x takes care of this for you.  However at some point in the future you may need to add platform specific code, such as perhaps an ad network that only works on iOS.  This is where you would add platform specific code.  That said, 99% of your game logic should be put in the common Classes folder.  This make’s it so you can write your code in one platform, then simply open up the project files for another platform and run your game.  This is how you are able to handle many platforms with a single code base using cocos2d-x.

 

Getting Started — MacOS/XCode

 

To get started developing on MacOS, double click the .xcodeproj in the folder proj.ios_mac.  This should automatically load Xcode for you.  Now at the top bar you should be able to select which project you want, iOS or Mac.  As iOS requires the simulator or a device to execute, initially developing on the Mac can be a great deal quicker.

 

Ss5

 

Getting Started — Windows/Visual Studio

 

To get started developing on Windows, double click the .sln file in the folder proj.win32.  This will load Visual Studio for you.  Simply press Play (Local Windows Debugger) to start the compilation process:

image

 

Once you’ve selected, simply click the Play icon.  Your project will now compile and a few minutes later you should see:

Ss7

 

If you are new to C++, don’t worry, the first compilation is always the nastiest.  From now on when you press play, the compilation should be many times faster.

 

You can also run directly from the terminal using the cocos utility, like so:

 Ss8

Use -p ios to run iOS.  This command requires you to have installed the command line tools mentioned earlier.  Running from the terminal makes it so you don’t have to open the Xcode IDE if you prefer.

 

 

Hello World

 

Now let’s take a look at the minimal useful cocos2d-x application.  While the cocos new created project creates a Hello World application of sorts, it’s a pretty sloppy starting point.  First, it has needlessly complications for an app that is supposed to be a minimum example, it’s commented in a manner that only makes sense if you come from an Objective-C background and finally, it even uses deprecated methods.

 

Therefore we are going to look at a cleaner Hello World sample.  We simply replace the code in each file with the code I provide below.  Don’t worry, all of the functionality we hack out will be covered in future tutorials.

Let’s start with the AppDelegate class.

 

AppDelegate.h

#pragma once

#include "cocos2d.h"

class  AppDelegate : private cocos2d::Application
{
public:
    AppDelegate();
    virtual ~AppDelegate();

    virtual bool applicationDidFinishLaunching();
    virtual void applicationDidEnterBackground();
    virtual void applicationWillEnterForeground();
};

 

 

AppDelegate.cpp

#include "AppDelegate.h"
#include "HelloWorldScene.h"

USING_NS_CC;

AppDelegate::AppDelegate() {

}

AppDelegate::~AppDelegate() 
{
}

bool AppDelegate::applicationDidFinishLaunching() {
    auto director = Director::getInstance();
    auto glview = director->getOpenGLView();
    if(!glview) {
        glview = GLViewImpl::create("Hello World");
        glview->setFrameSize(640, 480);
        director->setOpenGLView(glview);
    }

    auto scene = HelloWorld::createScene();
    director->runWithScene(scene);

    return true;
}

void AppDelegate::applicationDidEnterBackground() {
}

void AppDelegate::applicationWillEnterForeground() {
}

 

The biggest change I have made from the default implementation is to remove all but the barest requirements of an application.  You may notice I’ve also replaced the include guards with pragma once statements.  Some people will find this controversial because pragma once isn’t standard and therefore unportable.  This may be true, if you are using a compiler from 1985.  If on the other hand you are using any modern C++ compiler, pragma once is supported.  Include guards and pragma once perform the same task, except pragma once is more concise and less error prone.  If you want to switch back to include guards, feel free.  From this point on, I will however, not be using them.

 

OK, back to the code itself.  Our AppDelegate header is pretty straight forward, it declares a constructor, destructor and three methods, applicationDidFinishLaunching, applicationDidEnterBackground and applicationWillEnterForeground.  All three of these methods are pure virtual functions from ApplicationProtocol, from which Application ( and in turn AppDelegate ) inherit, so we must provide an implementation of each, even if it’s empty.

 

Now onto AppDelegate.cpp.  First we start off with the macro USING_NS_CC; which is just short for “using namespace cocos2d”.  Personally I don’t see a big win in using a macro over typing using namespace cocos2d, but generally I find many uses of macros unagreeable.  This however is the style the cocos team went with, so I will follow along.  As you can see, both or constructor, destructor, applicationDidEnterBackground and applicationWillEnterForeground all have empty implementations, so applicationDidFinishLaunching is where all of our logic resides.

 

If these names seem a bit long winded to you, they have been taken directly from the iOS world.  Basically the enterBackground/enterForeground methods are called when your application gains and loses focus, while applicationDidFinishLaunching is called when your application is loaded ( at the end of the loading process ).  Here we get an instance of the Director singleton, then use it to either get the GLView, or create a GLViewImpl, which is a default implementation of GLView.  Basically GLView is the OpenGL representation of your window or screen, depending on what kind of device you are running.  We then set the resolution of the window ( this is not required, I just wanted a smaller resolution for screen shots ) by calling setFrameSize() then set the view as active by calling Director’s setOpenGLView().  Now that we have a window, we create an instance of our scene calling createScene() and once again, use the Director to set this scene active using runWithScene().

 

Aren't Singletons bad?

You may notice in the above code that Director is very important to the operation of Cocos2d-x.  Director is an implementation of a design pattern known as a Singleton, or as some would say, an anti-pattern.  If you’ve spent much time on programming forums, you will see thread after thread calling Singletons evil.  In a nutshell, a singleton is a delayed, but guaranteed to be instantiated global variable in a pretty dress.  Sometimes too, a global variable is just what you need, which is why you will find a number of game engines make use of singletons to provide globally available interfaces.  At this point the matter is pretty much moot, if you use Cocos2d-x, you use Director, or you don’t use Cocos2d-x.

One of the major source of bugs with Singletons, especially in C++, is multithreading.  When you have this global instance being access from all kinds of locations and controlling so many things, how do you handle concurrent requests?  Well have I got good news for you!  You don’t. :)

That’s because Cocos2d-x isn’t thread safe.  Or more accurately, Cocos2d-x’s memory management ( anything derived from cocos2d::Ref ) and OpenGL rendering aren’t thread safe.  To make this clear, you can use threads in a Cocos2d-x application, but you need to be very careful what those threads interact with.  Other than the threading problems, some of the biggest problems that come from using Singletons are related to code maintenence, as you are coupling so many systems together.  Fortunately, this is the cocos2d-x team’s problem to deal with, not yours.  Unless of course you are on the Cocos2d-x team that is.

 

Now let's take a look at our scene, HelloWorldScene.

 

HelloWorldScene.h

#pragma once

#include "cocos2d.h"

class HelloWorld : public cocos2d::Layer
{
public:
    static cocos2d::Scene* createScene();
    virtual bool init();  
    
    CREATE_FUNC(HelloWorld);
};

 

HelloWorldScene.cpp

#include "HelloWorldScene.h"

USING_NS_CC;

Scene* HelloWorld::createScene()
{
    // 'scene' is an autorelease object
    auto scene = Scene::create();
    auto layer = HelloWorld::create();

    scene->addChild(layer);

    return scene;
}

bool HelloWorld::init()
{
    if ( !Layer::init() )
    {
        return false;
    }
   
    auto label = Label::createWithSystemFont("Hello World", "Arial", 96);
    label->setAnchorPoint(cocos2d::Vec2(0.0, 0.0));
    this->addChild(label, 1);

    return true;
}

 

In our header once again I’ve replaced the header guard with pragma pack.  We are declaring our scene class HelloWorld, which inherits from Layer which is a Node which can receive input events, such as touch, keys and motion.  We declare createScene() which returns a static Scene pointer.  As you may recall, we called this method earlier in AppDelegate to create our scene.  We also override the method init that we inherited from Node and is where we do our initialization logic.  Finally there is a bit of macro magic in the form of CREATE_FUNC(HelloWorld).

Let’s take a quick look at exactly what this macro is doing:

 

#define CREATE_FUNC(__TYPE__) \
static __TYPE__* create() \
{ \
    __TYPE__ *pRet = new __TYPE__(); \
    if (pRet && pRet->init()) \
    { \
        pRet->autorelease(); \
        return pRet; \
    } \
    else \
    { \
        delete pRet; \
        pRet = NULL; \
        return NULL; \
    } \
}

 

Granted, it’s not always the easiest code to read, as this is code for generating code, but essentially after this macro runs, we’ve got:

static HelloWorld* create(){
    HelloWorld *pRet = new HelloWorld(); 
    if (pRet && pRet->init())
    { 
        pRet->autorelease();
        return pRet; 
    } 
    else 
    { 
        delete pRet; 
        pRet = NULL; 
        return NULL; 
    }
} 

 

So, essentially, the macro is creating a create() function that allocates an instance of our class, calls the init method that we provided and then, most importantly, calls autorelease() we inherited from Ref.  I will cover why this is important in a few minutes, depending of course on how fast you read. :)

 

Now on to HelloWorldScene.cpp.  The createScene() method is pretty straight forward.  We create a Scene object, then an instance of our HelloWorld class ( which inherits from Layer ) and add our layer to the scene then return the scene ( which our AppDelegate then passed to Director->runScene() ).

In init() we perform the bulk of our logic.  First we call our base classes init function ( which is very important to do ), then create a Label using createWithSystemFont(), which predictably enough, using the built in system font (in this case Arial ) to create the Label’s text.  We then set the Labels anchor point to the bottom left, which means this node will be positioned relative to it’s bottom left corner.  I will cover anchor points in more detail in the next tutorial, so ignore this for now.  Finally we add the freshly created Label to our layer.  Finally we return true to indicate that initialization worked as expected.

 

Now if run our “game”, we should see:

image

 

 

Aren't we leaking memory like mad?

So you may have noticed we create all kinds of pointers using create() calls, but never once called delete.  As you can see in the code generated by the CREATE_FUNC, we are creating a new instance of our class, but we never do delete it.  Aren’t we leaking memory here?  Thankfully the answer is no and the reason is in the call to init() and autorelease() that the macro made and why it was so important we called our base classes init() in our own init method.

This is another legacy of Cocos2d-x’s Objective-C roots.  Objective-C provides a form of memory management via ARC, Automatic Reference Counting.  Basically each time something references an object, it’s count is increased, each time something reference an object goes away, the count is decreased, when the count hits zero, the object is released.  In many ways, this is pretty much the same functionality C++ smart pointers provide, but Cocos2d predates the standardization of smart pointers.

There is more to their usage that we will cover later on.  For now though, you can safely assume any cocos2d object created with a create() function, that inherits from Ref, does not need to be delete.  In fact, such objects must not be deleted!

 

In the next part we will take a look at working with graphics in Cocos2d-x.  Don’t worry, it will be much less verbose and much heavier in code!

iPhone Development Tutorials and Programming Tips

Top iOS Development Resources For Week Ended September 28th, 2014

by Johann at September 29, 2014 06:00 AM

Post Category    Featured iPhone Development Resources,News

Welcome back to our feature of the most popular new and updated iOS developer resources mentioned on the site from the last two weeks.

The top resource this week is a PSD template with many components, and example s with over 30 screens using the latest release of the iOS 8 GUI.

Here are the resources:

1. Apple Watch UI PSD Template – An extensive Apple Watch user interface design template in Photoshop’s PSD format.(share on twitter) (featured here)

2. INTUAnimationEngine – A library for creating advanced animations with support for frame-by-frame callbacks,  many easing functions and more. (share on twitter) (featured here)

3. Shapes – A library making it easier to create and animate custom shapes with helpers built in for custom components.   (share on twitter) (featured here)

Thanks for Reading!


Be the first to comment...

Related Posts:

FacebookTwitterDiggStumbleUponGoogle Plus

Original article: Top iOS Development Resources For Week Ended September 28th, 2014

©2014 iOS App Dev Libraries, Controls, Tutorials, Examples and Tools. All Rights Reserved.