## Pixel-perfect discrepancies in OpenGL and DirectX

Since this project has a low-res pixel-art style, it is very important that everything is presented as point-filtered textures with no anti-aliasing, or it defeats the intended look. I noticed that my Windows builds had a very “soft” look to them, while my builds on OS X were perfectly crisp with no blurriness.

OpenGL vs DirectX pixel offset discrepancy

I have a quad that covers the entire visible area with a pass-through shader on it that is used for occasional visual effects. With no effects active, it simply passes the pixels behind it onwards. This is achieved using Shader Forge’s “Scene Color” nodes. After discussing this with Shader Forge’s developer Joachim Holmér, he suggested that the issue may be a different pixel boundary in DirectX vs OpenGL. Sure enough, this was the case and I was able to account for this by using a custom “Code” node in combination with Unity’s pre-processor shaderlab macros:

It’s a simple edit, but you can see that a pixel offset is first calculated. This is 0 (none) for OpenGL and 0.5 for DirectX. This value is then used to offset the screen’s UVs by an amount calculated using that offset and the screen dimensions. I’m sure there are other ways to solve this, but this is working for me and hopefully the information is helpful regardless.

## Better parabolic motion for bounces

In a previous post, I detailed a methods of using tweens to give explosion debris some bounce and life. I knew at the time that this would be expensive for a large number of particles – but it was the right look and I at least wanted the temporary solution in the game. Consider it a living mockup, waiting to be optimized.

Recently I came across this post on gamasutra by Mohan Rajagopalan describing design philosophies and techniques behind 2D jumps. Sure enough, the parabolic arc equation was exactly what I needed for my debris bounce, which could be considered debris “jumping.” Here’s the classic formula:

$y(t) = v_0 + \frac{gt^2}{2}$

The implementation of this as a Unity component is quite straightforward , and here’s a simple version of the Update() function of the behavior:

public void Bounce(int numberOfBounces)
{
// init
startTime = Time.time;
lastYOffset = 0.0f;
bounceNumber = numberOfBounces;
bounceVelocity *= 0.5f;
}

void Update()
{
// if done with bounces, stop
if (bounceNumber <= 0)
{
return;
}

// otherwise, calculate current yoffset
if (bounceNumber > 0)
{
// apply classic parabolic formula: h(t) = vt + (gt^2 / 2)
float time = (Time.time - startTime);
yOffset = (bounceVelocity * time) + ((gravity * time * time) / 2);

// add to the current position, but subtract last y offset (additive behavior)
// since this could be moving in the y-axis from other forces as well
transform.position = new Vector3
(
transform.position.x,
transform.position.y + yOffset - lastYOffset,
transform.position.z
);
lastYOffset = yOffset;

// if hitting the "floor", bounce again
if (yOffset <= 0f)
{
BounceTimes(bounceNumber - 1);
}
}
}

One thing to note is that I subtract the previously calculated y-offset since I am adding the new y-offset to the current position each update. This allows this parabolic offset to be additive to any other motion the game object is already undergoing. This is perfect in my case, since the debris is being ejected by an explosive force, and I am just adding this to the y-axis to simulate bouncing in overhead 2D space. As stated in the original post, the root of all this is the simple fact that Unity doesn’t allow gravity in the z-axis for 2D projects.

## Object pooling for performance in Unity

Object pooling is a technique that you’re bound to need at some point in your game dev career. In fact, you may even be using some form of it (or your game engine might) without realizing it. In a nutshell, it is equivalent to caching. Rather than instantiating objects at runtime as you need them, you should instantiate everything you will need (or estimate you will need) beforehand, and pull from this “pool” when you need them. Instead of destroying objects when they are “dead,” you simply disable them and put them back into the pool.

The classic example in games are bullets: rather than instantiating a new bullet every time characters fire their weapons, and then destroying them when off screen or hitting another character, you simply disable them and move them off screen, then enable and move them back on screen as needed. Obviously, it doesn’t just apply to bullets, so keep an eye out for anything in your game that is instantiated frequently. The most common cases are projectiles and effects, such as explosions, dust, debris, etc, however you could even go as far as using it for common shared UI components for the ultimate in snappy performance.

The benefits to object pooling are: fewer game hiccups and lag due to expensive instantiation and destruction, and better estimation of memory needs up front since pooled objects are always loaded. If you have a lot of objects, you will definitely notice and feel these improvements right away. The only downside is from the developer’s perspective: it requires more attention to initialization of variables in objects as they are enabled and disabled, rather than created and destroyed. In Unity, this means you should handle this logic in OnEnable() and OnDisable() in game objects. Similarly, rather than creating and destroying, you are enabling and disabling the pooled objects.

There are many object pooling scripts in the Asset Store, but it’s easy enough to create your own if you understand the concept. As with all in-house solutions, you can tailor it slightly to better fit your exact needs when crafting your own. I’m including the full script here in case you’d like to use it in your own projects (or improve upon it). Some notes about my implementation:

• The ObjectPool.cs script is attached to an empty game object in the scene.
• It’s developed as a singleton, so it has a static reference: ObjectPool.shared
• It’s designed to store any number of pooled object types, with each containing a game object, the amount to start in the pool, and whether or not the amount can dynamically grow or not. You set these up simply on the game object (see the screenshot example below).
• To facilitate storing anything, the main data structure is a Dictionary full of Lists, with the keys of the dictionary being the names of the prefabs / game objects to be stored.
• GetPooledObject() returns a regular instantiated prefab if there is no associated pool, so it’s safe to call from scripts that don’t know if there’s a pool or not.

Note: This hasn’t really been stress tested too much, but so far it seems to be working great. I’m not sure if making it too flexible (a Dictionary of Lists) is actually more expensive than instantiating and destroying, thus defeating the purpose, but I imagine it isn’t and I’ll run some tests later.

using UnityEngine;
using System.Collections;
using System.Collections.Generic;

[System.Serializable]
public class PooledObject
{
public Object objectToPool;
public int pooledAmount = 20;
public bool canGrow = true;
}

public class ObjectPool : MonoBehaviour
{
public static ObjectPool shared;
public PooledObject[] pooledObjectTypes;

private Dictionary<string, List<GameObject>> pool;

void Awake()
{
// set up singleton reference
if (shared == null)
{
shared = this;
}
}

void Start()
{
// set up the pool and instantiate all initial objects
pool = new Dictionary<string, List<GameObject>>();
for (int i = 0; i < pooledObjectTypes.Length; i++)
{
PooledObject pooledObjectType = pooledObjectTypes[i];
for (int i2 = 0; i2 < pooledObjectType.pooledAmount; i2++)
{
}
}
}

{
GameObject pooledObject = Instantiate(newObject) as GameObject;
if (shared.gameObject.transform != null)
{
pooledObject.transform.parent = shared.gameObject.transform;
}
pooledObject.SetActive(false);
return pooledObject;
}

public void DisableAllPooledObjects()
{
foreach(string key in pool.Keys)
{
foreach(GameObject pooledObject in pool[key])
{
pooledObject.SetActive(false);
}
}
}

public List<GameObject> GetPooledObjects(Object gameObject)
{
if (!pool.ContainsKey(gameObject.name))
{
return null;
}
return pool[gameObject.name];
}

public GameObject GetPooledObject(Object gameObject)
{
// return a regular non-pooled version if there is no pool for this type
List<GameObject> pooledObjects = GetPooledObjects(gameObject);
if (pooledObjects == null)
{
Debug.Log("Returning non-pooled instance of: " + gameObject.name);
return (Instantiate(gameObject) as GameObject);
}

// return first available inactive pooled object
for (int i = 0; i < pooledObjects.Count; i++)
{
if (!pooledObjects[i].activeInHierarchy)
{
return pooledObjects[i];
}
}

// grow the pool if needed and return the new object
for (int i = 0; i < pooledObjectTypes.Length; i++)
{
if (pooledObjectTypes[i].objectToPool.name == gameObject.name)
{
if (pooledObjectTypes[i].canGrow)
{
}
else
{
return pooledObjects[0];
}
}
}

// return null if none was created
// this should be handled by the caller script
return null;
}
}

## Multiple character sprites using one animation controller

Update 2015.02.26
So, this post is actually a terrible way to go about this. When I was going down this path, I wasn’t aware of the built-in ways to handle something like this. Namely, you just need to create a single character’s animator controller and animation clips to feed it. Then you can create an “Animator Override Controller” that derives from that base animator for each additional character, and simply replace all the clips with unique ones. Part of this blog is to document the journey through my first Unity project, and, well, this is one of those learning experiences.

If you have several characters that your players can choose from, but all share a similar tree of Mecanim states and animations, you can use a single animation controller for all of them. Note that part of the process requires creating layers to “sync” to the master layer, and this is a Unity Pro-only feature. Here’s a quick example of some common player states, and how the process works:

With your animation states set up, make sure that you have created animation clips for each character for each of the states. For example, for the “player_fire” state, you would have animation clips such as “character1_fire”, “character2_fire”, “character3_fire”, etc. Have your first animation clip assigned to the state above.

With the first character all set up, simply add more layers in the animation controller for each character that you have. In the other layers, make sure you have “Sync” enabled (Pro-only feature). This syncs all the states with the top master layer, so all layers share the same states. Then you can simply click a layer to edit, and for each of the states, assign a different animation clip. In this example, I’ve added 4 other characters:

The last step is in your code. You can loop through all the layers in your animator, and set all their layer weights to 0 except for the chosen character, which should be 1. Here’s an example function that does this:

void SetCharacterLayer(int characterLayer)
{
Animator animator = GetComponent();
for (int i = 0; i < animator.layerCount; i++)
{
float layerWeight = (characterLayer == i) ? 1f : 0f;
animator.SetLayerWeight(characterLayer, layerWeight);
}
}

## Simple and flexible scrolling behavior

One of the staples of 2D games pioneered in the old school days is seamless scrolling. More specifically, having an endless scrolling behavior that seems infinite. This is usually applied to background layers, and when you combine different layers with varying speeds, you can achieve a very nice parallax effect that sells depth on a flat screen. I’ll be honest – I’m a sucker for anything with sensible parallax. To me, the effect never gets old and instantly makes smaller worlds feel expansive.

The technique is very, very simple. Perhaps it’s one of the first effects that many beginner game programmers are introduced to. It’s also probably one of the most satisfying results you’ll get in a very short amount of time.

In essence, if you create 2 copies of your scrolling layer and place them side by side, you can have them both scrolling in the intended direction, and when one of them is completely off screen, simply move it to the opposite edge. You can see the illusion illustrated here. If you pay attention to the center camera and the two hills, you can see that they appear to be seamless.

In Unity, it’s simple enough to create a small behavior script that gives the game object a speed to be scrolling at, and to snap back to the other side when off screen. If you apply this script to two identical side-by-side game objects, you can get this seamless behavior. The nice thing about the approach in Unity is that you just need to translate the objects in your Update() method, but you don’t need the offscreen-check performed every update. You can use the MonoBehaviour callback OnBecameInvisible() to handle this:

using UnityEngine;
using System.Collections;

public class Scrolling : MonoBehaviour
{
public float xSpeed;
public float ySpeed;

void Update()
{
transform.Translate(new Vector3(xSpeed, ySpeed, 0f));
}

void OnBecameInvisible()
{
Vector3 newPosition = transform.localPosition;
Vector3 viewportPoint = Camera.main.WorldToViewportPoint(transform.position);

// move to opposite edge of screen (horizontally)
if (xSpeed != 0 && (viewportPoint.x < 0f || viewportPoint.x > 1f))
{
newPosition.x = -transform.localPosition.x;
}

// move to opposite edge of screen (vertically)
if (ySpeed != 0 && (viewportPoint.y < 0f || viewportPoint.y > 1f))
{
newPosition.y = -transform.localPosition.y;
}

// move to the new position
transform.localPosition = newPosition;
}
}