Monthly Archives: October 2014

More about swift…

Okay so when you use a language daily, you begin to really pick up some opinions and feelings about it that tend to really stick with you. With swift, I definitely have some of those.

Let me focus on just two… of the things that really irk me about the freaking swift language.

Number one – Casting

This is my number one gripe with the swift language. The compiler just wont shut the hell up and do what I was intending. Now I know that apple has designed the language to absolutely not allow any implicit casting, and I understand their reasons behind this, but man, you’ve taken one benefit, and added 10-fold the costs. Requiring explicit casting takes code in swift that should look extremely simple and adds about 3-4 explicit constructor-casts to it causing the code to display as bloated, confusing ill-intended crap. What really bothers me is that this is the case even for upgrading types such as assigning a float into a double. Another problem is that in the C world (all of the APIs that we work with on a daily basis) there might be 4 or 5 different integer types (int, Sint32, GLuint, etc) and multiple float types (GLfloat, float, CGFloat, etc). Casting between these in C/C++/Objc is completely harmless 99% of the time and therefore done implicitly. In swift, I have to pepper this code with constructor casts every, single, freaking time.

In C++, you could allow implicit types by overloading the constructor so that an expression such as int x = someFloat would be the same as a constructor for int that takes a float as an argument. Swift badly needs this.

For now I’ve gotten to the point where I’ve added very simple computed properties to the various types in swift to at least make some of this casting more painless. Just a few of those extensions are below.

//
//  CastingHelpers.swift
//  Gangster Driveby
//
//  Created by Mike Farrell on 10/27/14.
//  Copyright (c) 2014 Mike Farrell. All rights reserved.
//

import Foundation

//swift is driving me crazy
extension Int
{
  var f: Float
  {
    return Float(self)
  }
}

extension Int32
{
  var f: Float
  {
    return Float(self)
  }

  var e: GLenum
  {
    return GLenum(self)
  }

  /*func c<T: IntegerLiteralConvertible>() -> T
  {
    return T(integerLiteral: i)
  }*/
}

extension Sint16
{
  var f: Float
  {
    return Float(self)
  }
}

extension UInt
{
  var f: Float
  {
    return Float(self)
  }
}

extension Double
{
  var f: Float
  {
    return Float(self)
  }
}

extension Float
{
  var cg: CGFloat
  {
    return CGFloat(self)
  }
}

// CastingHelpers.swift

// Gangster Driveby

// Created by Mike Farrell on 10/27/14.

import Foundation

//swift is driving me crazy

extension Int

{

var f: Float

{

return Float(self)

}

extension Int32

{

var f: Float

{

return Float(self)

}

var e: GLenum

{

return GLenum(self)

}

/*func c<T: IntegerLiteralConvertible>() -> T

{

return T(integerLiteral: i)

}*/

}

extension Sint16

{

var f: Float

{

return Float(self)

}

extension UInt

{

var f: Float

{

return Float(self)

}

extension Double

{

var f: Float

{

return Float(self)

}

extension Float

{

var cg: CGFloat

{

return CGFloat(self)

}

This makes it so that code that would have to look like

glDisable(GLEnum(GL_DEPTH_TEST))

let f: Float = 3.0
let f2 = f*Float(sin(0.5))

glDisable(GLEnum(GL_DEPTH_TEST))

let f: Float = 3.0

let f2 = f*Float(sin(0.5))

Can be…

glDisable(GL_DEPTH_TEST.e)

let f = (3.0).f
let f2 = f*sin(0.5).f

glDisable(GL_DEPTH_TEST.e)

let f = (3.0).f

let f2 = f*sin(0.5).f

Number two – Stability (source kit crashes)

Google swift and “sourcekit” and you’ll see, this is nowhere NEAR an actual finished language. Apple has rushed this out the door and I’m honestly sorry that I’ve decided to use it to make a game. Imagine typing code and then every half hour you get 30 seconds of a frozen spinner before ”sourcekit crashed” appears in your IDE. If you’re lucky, it’ll stop for another 5 minutes, but if you aren’t it’ll happen in a loop and you have to go delete your “ModuleCache” dir and quit and restart xcode and start working again…. until about an hour later. This is NOT how I prefer to work. I like the “idea” of swift, but its just way too unstable to use. I’m going to finish this game with it, and then probably stay away from swift for any real projects for another year or so until apple fixes this extremely annoying stability problem.

These two things may seem small, but they’re enough to waste 10 minutes of time for every hour I work on this game, and for me, that’s just completely unacceptable.

Its midnight..

Leave a reply

Recently worked alot of basic walking pattern AI for the bystander game objects, a practice range which will precede the first “day” (level) in the game, and some cool shader effects using particles for the gangster car kicking up dust while driving through the desert.

Too tired to describe more.

Pictures! Please forgive the quality of the video(s).

AI Walking Video

Quick update

Leave a reply

Yesterday was a lot of work. I worked really hard to obtain a higher frame rate for the game, because I know that my postprocessing effects will be costly. Sometime certain obvious things take a few days to sink in. It’s funny how I was looking everywhere to try to improve my fill-rate and bandwidth performance when I knew the problem was a polyon issue. Drawing the entire scene twice (once for lightmap/shadow pass and again for actual rendering) was really stupid. I was doing this because certain elements in the shadow maps such as the walking men were dynamic, thus the scene needed to be redrawn into the shadowmap every time. However, the mass majority of the polygons in the scene where static. The solution of this was to pre-render this static geometry into one shadow map, and render the dynamic geometry into a separate one, and then adapt all of my shaders to take an optional second shadow texture. This wasn’t easy since much of my architecture wasn’t designed for multiple shadowmaps per light. But I got it working.

The above boosted my framerates back into a very acceptable range so I’m happy. It’s a little annoying, that for some reason on OSX Yosemite, I can no longer turn off Vsync in a windowed mode. So I’ve been having to go fullscreen during debugging to see my max framerates which are hovering now well-over 100.

As far as swift goes, I’m now on the fully released Xcode 6.1 and I’m having far less problems with the source kit crashing which is great. The IDE is generally still a lot slower than its predecessor which I hope improves with time. as I’m writing more and more code in Swift, certain features are starting to really prove useful to me as I get used to the language. Among these are the tuples, willSet/didSet, and operator overloading. On the ObjC side, I’ve had to rely on this bulky MathVector class to do my vector maths. With swift I’ve been able to add all of the math operators I need directly to my low-level C structs via an extension. This has already saved me alot of work and made the math code that I’ve written for the game alot cleaner.

Here’s an example of the vector math extension code in swift

extension float3: Printable
{
  static var zero: float3
  {
    return float3(x: 0, y: 0, z: 0)
  }

  init(_ x: Float, _ y: Float, _ z: Float)
  {
    self.x = x;
    self.y = y;
    self.z = z;
  }

  subscript(index: Int) -> Float
  {
    get
    {
      assert(index < 3 && index >= 0)
      switch(index)
      {
      case 0:
        return x
      case 1:
        return y
      case 2:
        return z
      default:
        break
      }

      return 0
    }

    set
    {
      assert(index < 3 && index >= 0)
      switch(index)
      {
      case 0:
        x = newValue
      case 1:
        y = newValue
      case 2:
        z = newValue
      default:
        break
      }
    }
  }

  var length: Float
  {
    return sqrtf(dot(self))
  }

  var lengthSquared: Float
  {
    return dot(self)
  }

  var xz: float2
  {
    return float2(x, z)
  }

  func normalized() -> float3
  {
    let len = self.length
    return float3(x/len, y/len, z/len)
  }

  func dot(rhs: float3) -> Float
  {
    return x*rhs.x + y*rhs.y + z*rhs.z
  }

  func cross(rhs: float3) -> float3
  {
    var r = float3.zero
    r.x = (y * rhs.z) - (z * rhs.y);
    r.y = (z * rhs.x) - (x * rhs.z);
    r.z = (x * rhs.y) - (y * rhs.x);

    return r
  }

  public var description: String
  {
    return "(\(x), \(y), \(z))"
  }
}

func + (lhs: float3, rhs: float3) -> float3
{
  return float3(lhs[0]+rhs[0], lhs[1]+rhs[1], lhs[2]+rhs[2])
}

func += (inout lhs: float3, rhs: float3)
{
  lhs = lhs + rhs
}

func - (lhs: float3, rhs: float3) -> float3
{
  return float3(lhs[0]-rhs[0], lhs[1]-rhs[1], lhs[2]-rhs[2])
}

func -= (inout lhs: float3, rhs: float3)
{
  lhs = lhs - rhs
}

func / (lhs: float3, rhs: float3) -> float3
{
  return float3(lhs[0]/rhs[0], lhs[1]/rhs[1], lhs[2]/rhs[2])
}

func /= (inout lhs: float3, rhs: float3)
{
  lhs = lhs / rhs
}

func * (lhs: float3, rhs: float3) -> float3
{
  return float3(lhs[0]*rhs[0], lhs[1]*rhs[1], lhs[2]*rhs[2])
}

func *= (inout lhs: float3, rhs: float3)
{
  lhs = lhs * rhs
}

func * (lhs: float3, scalar: Float) -> float3
{
  return float3(lhs[0]*scalar, lhs[1]*scalar, lhs[2]*scalar)
}

func *= (inout lhs: float3, rhs: Float)
{
  lhs = lhs * rhs
}

func == (lhs: float3, rhs: float3) -> Bool
{
  return (lhs[0]==rhs[0] && lhs[1]==rhs[1] && lhs[2]==rhs[2])
}

func != (lhs: float3, rhs: float3) -> Bool
{
  return !(lhs == rhs)
}

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

extension float3: Printable

{

static var zero: float3

{

return float3(x: 0, y: 0, z: 0)

}

init(_ x: Float, _ y: Float, _ z: Float)

{

self.x = x;

self.y = y;

self.z = z;

}

subscript(index: Int) -> Float

{

get

{

assert(index < 3 && index >= 0)

switch(index)

{

case 0:

return x

case 1:

return y

case 2:

return z

default:

break

}

return 0

}

set

{

assert(index < 3 && index >= 0)

switch(index)

{

case 0:

x = newValue

case 1:

y = newValue

case 2:

z = newValue

default:

break

}

var length: Float

{

return sqrtf(dot(self))

}

var lengthSquared: Float

{

return dot(self)

}

var xz: float2

{

return float2(x, z)

}

func normalized() -> float3

{

let len = self.length

return float3(x/len, y/len, z/len)

}

func dot(rhs: float3) -> Float

{

return x*rhs.x + y*rhs.y + z*rhs.z

}

func cross(rhs: float3) -> float3

{

var r = float3.zero

r.x = (y * rhs.z) - (z * rhs.y);

r.y = (z * rhs.x) - (x * rhs.z);

r.z = (x * rhs.y) - (y * rhs.x);

return r

}

public var description: String

{

return "(\(x), \(y), \(z))"

}

func + (lhs: float3, rhs: float3) -> float3

{

return float3(lhs[0]+rhs[0], lhs[1]+rhs[1], lhs[2]+rhs[2])

}

func += (inout lhs: float3, rhs: float3)

{

lhs = lhs + rhs

}

func - (lhs: float3, rhs: float3) -> float3

{

return float3(lhs[0]-rhs[0], lhs[1]-rhs[1], lhs[2]-rhs[2])

}

func -= (inout lhs: float3, rhs: float3)

{

lhs = lhs - rhs

}

func / (lhs: float3, rhs: float3) -> float3

{

return float3(lhs[0]/rhs[0], lhs[1]/rhs[1], lhs[2]/rhs[2])

}

func /= (inout lhs: float3, rhs: float3)

{

lhs = lhs / rhs

}

func * (lhs: float3, rhs: float3) -> float3

{

return float3(lhs[0]*rhs[0], lhs[1]*rhs[1], lhs[2]*rhs[2])

}

func *= (inout lhs: float3, rhs: float3)

{

lhs = lhs * rhs

}

func * (lhs: float3, scalar: Float) -> float3

{

return float3(lhs[0]*scalar, lhs[1]*scalar, lhs[2]*scalar)

}

func *= (inout lhs: float3, rhs: Float)

{

lhs = lhs * rhs

}

func == (lhs: float3, rhs: float3) -> Bool

{

return (lhs[0]==rhs[0] && lhs[1]==rhs[1] && lhs[2]==rhs[2])

}

func != (lhs: float3, rhs: float3) -> Bool

{

return !(lhs == rhs)

}

Leave a reply

2.5 million polygons

“well there’s your problem…”

Game Development in Swift

Leave a reply

First Impressions

So let me start off by saying, Swift is FAR from finished. I know Apple is calling it “released”, but that’s a load of garbage. My two main annoyances with swift from the previous post reign true, alongside a new victor: the infamous can-go-to-hell sourcekit crash. This problem occurs so frequently on the latest Xcode to GM candidate, that I came very very near abandoning Swift as the language for this game entirely yesterday. If it wasn’t for a post that I found on the Apple developer forums related to deleting the “ModuleCache” dir within XCode’s DerivedData, I would have probably had to abandon swift which is really sad considering how much effort apple has put into it already. Let me just say that a craftsman is only as good as his tools, and when it comes to XCode 6 alongside Swift, at this point I’d be very very cautious using it for anything that you absolutely must count on to be finished in a reasonable timeline. This goes without saying that apple seriously needs to re-evaluate what they consider to be a GM release.

Either way… Because my project is an experiment and has no real pressure of any release deadline (apart from the fictional one I’ve set for myself), I will continue using Swift as the language. After using it to put together the stuff that I’m going to show today, I must say that I definitely like coding in Swift compared to Objective-C for class design. It’s a much less uglier language for the most part. Some things still tick me off such as continuos need for explicit casting. But overall, I can see its appeal as a language choice over Objective-C. I say over ObjC because if you are stuck using Objective-C, you’re already stuck with an OSX/iOS-only application. So you might as well make things easier on yourself and use Swift instead where possible (once it matures).

Lastly, I’m not setting out to use every single feature swift has to offer. I likely won’t touch a lot of them. The whole point here is to get the game done and to use the language as exercise to see what it offers to me to put together A 3D game in the OOP-style that I’m used to using. My background is in C++, so I’ll likely find certain features more useful such as nested type capabilities.

The Game Architecture

So writing about programming is always more complicated than writing about 3D modeling or artwork. At the beginning of this project, I stated that I would care more about the game than the programming itself. That has already proven difficult for me, since my years of experience programming always leads me to architect a good solution for the task at hand. One of the things I can’t stand in a game (or program in general) is over-architecture. So what I present below hopefully won’t change that much moving forward. Which leads me to say that I really want to focus on the game now. Now that I’m in the main stretch of developing this thing, I need to put all efforts on the game development itself. This means I might be ramping down temporarily the number of posts on this blog until the game begins nearing completion. I hope to be at that phase within the next two weeks.

Graphics Engine

As I’ve mentioned in the past, the game will take the form of a series of swift classes that are going to be built on top of my existing Objective-C codebase. This is the same codebase that powers my Verto Studio 3D modeling tool that I’ve used to put assemble the 3D assets. Because Swift is designed to interoperate with ObjC pretty easily, this shouldn’t be a problem. A closely-related C++11 mirror of the lowest layer of this system is available open-sourced at https://github.com/mlfarrell/VGLPP.

I loosely refer to all of this code as a “graphics engine”. It contains routines for working with OpenGL 3.2 to draw 3D graphics primitives (VGL layer), and load/render 3D scenes and models (VOM / Object-Model) layer. In the Objective-C code, these layers blur a bit but you get the idea. The important classes that I interact with in the game (in the swift code) are as follows. Because this system is quite large, this list is not exhaustive.

Objective-C Classes (Graphics Engine)

VGL Layer

VertoGLUserShaderEffect (subclassable to provide shader effects)
VertoGLStateMachine (GL 1.1-like state and state delegation)
VertoGLSystem (delegation and control for the behavior of the entire VGL system)
VecTypes (C structs for low-level OpenGL-needed things like float3, float4, float16, etc).
MatTypes (C structs for low-level OpenGL-needed math things like mat3, mat4, etc).

VOM Layer

SceneManager (3D Scene)
Entity (3D Model type)
EntityMaterial (Material properties)
Texture2D (Texture map)
RenderPassManager (Multipass rendering manager)

The Game Classes

After one day, here’s the basic architecture I have for the game. The idea here follows the same concept I’ve used for many years now: a game loop class with three methods that manage input (processEvents), processing(processLogic/update) and output (rendering). At any given time, the game loop will be in one of many game states. These states dictate how the game loop behaves. Currently the planned game states are Splash (loading up), Menu (the title menu), Driveby (the actual gameplay), and Game over. The game states are managed and executed from the game loop using a new GameStateRunner protocol type. The game state holds on to a single object conforming to the GameStateRunner protocol and forwards the processEvents, processLogic and render methods to it accordingly. This allows me to nicely separate and organize my code into special GameStateRunner conforming classes. The interesting thing here is that swift actually allows me to embed some logic into the game state enum itself which I’ve already found useful to allow it to load and construct the GameStateRunner objects for me. Confused yet? Awesome!

Objective-C Classes (Driveby Gangster Game)

GameLoop (base class that interacts with SDL C-API and sets up OpenGL, this stuff is just simpler to do in C (which Objective-C is fully backwards compatible with compared to swift)
SkeletalAnimationShaderEffect : VertoGLUserShaderEffect

Swift Classes (Driveby Gangster Game)

Subclassing or Protocol conformance denoted with colon notation

GangsterGameLoop : GameLoop
DrivebyGameStateRunner : GameStateRunner
TitleMenuStateRunner : GameStateRunner
SplashStateRunner : GameStateRunner
GameOverStateRunner : GameStateRunner
GameObject (base class game object for all visual objects in the game)
GameObjectSkeletalAnimated : GameObject (any game object that has a skeletal animation)
GameObjectPlayer : GameObjectSkeletalAnimated (the game player / protagonist)
GameObjectEnemy : GameObjectSkeletalAnimated (enemies in the game)
GameObjectBystander : GameObjectSkeletalAnimated (bystanders in the game)
GangsterSceneManager : SceneManager (game-oriented scene manager subclass)

Now the good news is, above should be just about it. All of the shadow stuff, shaders, texturing, rendering of the game scene is all saved in the Verto Studio file and should load and render just like I had it in the editor when I load it into the game via SceneManager’s load methods. The skeletal animation support (apart from the special shader effect subclass) is also all entirely provided by my graphics engine so I shouldn’t have to tinker too much with that stuff besides optimization.

Now this post has already gotten crazy long and it would be too much to include the source code of all of the above classes in this post. So instead I’m going to provide snippets of some of the base classes so you can understand how the system will work.

The Game Loop subclass in Swift

//
//  Simple3DGameLoop.swift
//  Quick 3D Game
//
//  Created by Mike Farrell on 8/30/14.
//  Copyright (c) 2014 Mike Farrell. All rights reserved.
//

import Foundation

public class GangsterGameLoop: GameLoop
{
  enum GameState
  {
    case Splash
    case Menu
    case Driveby
    case GameOver

    func load(#gameLoop: GangsterGameLoop) -> GameStateRunner!
    {
      switch self
      {
      case .Driveby:
        var state: GameStateRunner! = nil
        autoreleasepool
        {
          state = DrivebyGameStateRunner(gameLoop: gameLoop)
        }

        //reset shared scene manager to the main scene
        if let drivebyState = state as? DrivebyGameStateRunner
        {
          drivebyState.scene.becomeSharedSceneManager()
        }

        return state

      default:
        return nil
      }
    }
  }

  private var lastTime: CFAbsoluteTime = 0

  private var fps = 0, actualFps = 0
  private var fpsTimer: NSTimer? = nil
  private var gameStateRunner: GameStateRunner? = nil
  private var gameState: GameState = .Splash

  private var vsyncOn = true

  //MARK: - Construction and setup -

  override init()
  {
    super.init()
  }

  deinit
  {
    fpsTimer?.invalidate()
  }

  func load()
  {
    lastTime = CFAbsoluteTimeGetCurrent()
    fpsTimer = NSTimer.scheduledTimerWithTimeInterval(1.0, target: self, selector: "fpsTimer:", userInfo: nil, repeats: true)

    gameState = .Driveby
    gameStateRunner = gameState.load(gameLoop: self)
  }

  public override func initOpenGL()
  {
    super.initOpenGL()

    glEnable(GLenum(GL_DEPTH_TEST))
    glClearColor(0, 0, 0, 1)

    load()
  }

  public override func shutdown()
  {
    //force-dealloc these things synchronously before the GL context goes down
    gameStateRunner = nil

    super.shutdown()
  }

  //MARK: - Game loop

  public override func processLogic()
  {
    let delta = (CFAbsoluteTimeGetCurrent()-lastTime)*60.0
    lastTime = CFAbsoluteTimeGetCurrent()

    gameStateRunner?.processLogic(delta: Float(delta))
  }

  public override func keyDown(keysym: SDL_Keycode)
  {
    switch Int(keysym)
    {
    case SDLK_v:
      toggleVsync()
    default:
      break
    }
  }

  public override func processEvents()
  {
    super.processEvents()
    gameStateRunner?.processEvents()
  }

  public override func render()
  {
    glClear(GLbitfield(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT))

    gameStateRunner?.render()
    fps++    
  }

  //MARK: - Misc
  func fpsTimer(timer: NSTimer)
  {
    actualFps = fps
    println("FPS: \(actualFps)")
    fps = 0
  }

  func toggleVsync()
  {
    vsyncOn = !vsyncOn
    SDL_GL_SetSwapInterval(vsyncOn ? 1 : 0)
    println("Vsync is \(vsyncOn)")
  }
}

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

// Simple3DGameLoop.swift

// Quick 3D Game

// Created by Mike Farrell on 8/30/14.

import Foundation

public class GangsterGameLoop: GameLoop

{

enum GameState

{

case Splash

case Menu

case Driveby

case GameOver

func load(#gameLoop: GangsterGameLoop) -> GameStateRunner!

{

switch self

{

case .Driveby:

var state: GameStateRunner! = nil

autoreleasepool

{

state = DrivebyGameStateRunner(gameLoop: gameLoop)

}

//reset shared scene manager to the main scene

if let drivebyState = state as? DrivebyGameStateRunner

{

drivebyState.scene.becomeSharedSceneManager()

}

return state

default:

return nil

}

private var lastTime: CFAbsoluteTime = 0

private var fps = 0, actualFps = 0

private var fpsTimer: NSTimer? = nil

private var gameStateRunner: GameStateRunner? = nil

private var gameState: GameState = .Splash

private var vsyncOn = true

//MARK: - Construction and setup -

override init()

{

super.init()

}

deinit

{

fpsTimer?.invalidate()

}

func load()

{

lastTime = CFAbsoluteTimeGetCurrent()

fpsTimer = NSTimer.scheduledTimerWithTimeInterval(1.0, target: self, selector: "fpsTimer:", userInfo: nil, repeats: true)

gameState = .Driveby

gameStateRunner = gameState.load(gameLoop: self)

}

public override func initOpenGL()

{

super.initOpenGL()

glEnable(GLenum(GL_DEPTH_TEST))

glClearColor(0, 0, 0, 1)

load()

}

public override func shutdown()

{

//force-dealloc these things synchronously before the GL context goes down

gameStateRunner = nil

super.shutdown()

}

//MARK: - Game loop

public override func processLogic()

{

let delta = (CFAbsoluteTimeGetCurrent()-lastTime)*60.0

lastTime = CFAbsoluteTimeGetCurrent()

gameStateRunner?.processLogic(delta: Float(delta))

}

public override func keyDown(keysym: SDL_Keycode)

{

switch Int(keysym)

{

case SDLK_v:

toggleVsync()

default:

break

}

public override func processEvents()

{

super.processEvents()

gameStateRunner?.processEvents()

}

public override func render()

{

glClear(GLbitfield(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT))

gameStateRunner?.render()

fps++

}

//MARK: - Misc

func fpsTimer(timer: NSTimer)

{

actualFps = fps

println("FPS: \(actualFps)")

fps = 0

}

func toggleVsync()

{

vsyncOn = !vsyncOn

SDL_GL_SetSwapInterval(vsyncOn ? 1 : 0)

println("Vsync is \(vsyncOn)")

}

Using the ability to embed a “load” method directly in the game state enum is probably the most “swift-esque” thing I’ve done sofar. Moving onto the GameStateRunner protocol and sample implementation.

//
//  GameState.swift
//  Gangster Driveby
//
//  Created by Mike Farrell on 10/15/14.
//  Copyright (c) 2014 Mike Farrell. All rights reserved.
//

import Foundation

protocol GameStateRunner
{
  func processLogic(#delta: Float)
  func processEvents()
  func render()
}

// GameState.swift

// Gangster Driveby

// Created by Mike Farrell on 10/15/14.

import Foundation

protocol GameStateRunner

{

func processLogic(#delta: Float)

func processEvents()

func render()

}

//
//  DrivebyGameState.swift
//  Gangster Driveby
//
//  Created by Mike Farrell on 10/15/14.
//  Copyright (c) 2014 Mike Farrell. All rights reserved.
//

import Foundation

class DrivebyGameStateRunner : GameStateRunner
{
  private unowned let gameLoop: GangsterGameLoop
  private var t: Float = 0

  var scene: GangsterSceneManager! = nil
  var gameObjects: [GameObject] = []
  var player: GameObject!

  init(gameLoop gl: GangsterGameLoop)
  {
    gameLoop = gl

    NSKeyedUnarchiver.setClass(GangsterSceneManager.self, forClassName: "SceneManager")

    let path = NSBundle.mainBundle().pathForResource("street scene", ofType: "vssproj")
    scene = GangsterSceneManager(contentsOfFile: path)
    scene.activeCamera.distance = 20.0
    scene.occlusionCulling = true
    scene.skeletalEffect = SkeletalAnimationShaderEffect()
    scene.optimize()

    //load game objects
    loadModels()

    println("entities: \(scene.entities.count)")

    player.model.pos = float3(x: 20, y: 3, z: 10)

    //shadow map resolution
    //scene.sceneShadowMappingPass()?.setDimensionsWidth(8192, andHeight: 8192, andTextureFormat: GLenum(GL_FLOAT))
  }

  private func loadModels()
  {
    let scale: Float = 0.1

    //load models
    let gangsterPath = NSBundle.mainBundle().pathForResource("gangster", ofType: "vssproj")
    let gangsterScene = SceneManager(contentsOfFile: gangsterPath)

    var result = gameLoop.loadAnimatedModel("walk.dae", intoScene: scene)
    var modelInfo = AnimatedModelInfo(animatedModelEntity: result["entity"] as Entity, aiScene: result["aiScene"] as AssimpSceneWrapper,
                                      globalInverseTransform: gameLoop.globalInverseTransform())
    var obj: GameObjectSkeletalAnimated = GameObjectEnemy(model: gangsterScene.entities.firstObject as Entity, animatedModelInfo: modelInfo)
    obj.model.scale = float3(x: scale, y: scale, z: scale)

    gameObjects.append(obj)
    obj.addToScene(scene)

    //for now
    player = obj

    let bystanderPath = NSBundle.mainBundle().pathForResource("bystander", ofType: "vssproj")
    let bystanderScene = SceneManager(contentsOfFile: bystanderPath)
    obj = GameObjectBystander(model: bystanderScene.entities.firstObject as Entity, animatedModelInfo: modelInfo)
    obj.model.pos = float3(x: -20, y: 3, z: 20)
    obj.model.scale = float3(x: scale, y: scale, z: scale)

    gameObjects.append(obj)
    obj.addToScene(scene)
  }

  private func isKeyDown(code: SDL_Scancode, _ key: UnsafePointer<Uint8>) -> Bool
  {
    return key[Int(code.value)] != 0
  }

  func processEvents()
  {
    let key = gameLoop.keyState
    let activeCamera: CameraView = scene.activeCamera

    if isKeyDown(SDL_SCANCODE_EQUALS, key)
    {
      activeCamera.distance -= 1
    }
    if isKeyDown(SDL_SCANCODE_MINUS, key)
    {
      activeCamera.distance += 1
    }
    if isKeyDown(SDL_SCANCODE_LEFT, key)
    {
      player.model.translate(float3(x: 0, y: 0, z: 1))
    }
    if isKeyDown(SDL_SCANCODE_RIGHT, key)
    {
      player.model.translate(float3(x: 0, y: 0, z: -1))
    }
    if isKeyDown(SDL_SCANCODE_UP, key)
    {
      player.model.translate(float3(x: -1, y: 0, z: 0))
    }
    if isKeyDown(SDL_SCANCODE_DOWN, key)
    {
      player.model.translate(float3(x: 1, y: 0, z: 0))
    }
  }

  func processLogic(#delta: Float)
  {
    t += 0.1*delta

    let activeCamera: CameraView = scene.activeCamera
    activeCamera.viewMode = CAM_FREE
    activeCamera.theta = sinf(t*0.05)*30

    var bbox = float3.zero
    player.model.getBBox(&bbox)
    var pos = player.model.pos
    pos.y += 0.1*bbox.y/2
    activeCamera.setSphericalPos(pos)

    for obj in gameObjects
    {
      obj.update(delta: delta)
    }
  }

  func render()
  {
    scene.render()
  }
}

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

// DrivebyGameState.swift

// Gangster Driveby

// Created by Mike Farrell on 10/15/14.

import Foundation

class DrivebyGameStateRunner : GameStateRunner

{

private unowned let gameLoop: GangsterGameLoop

private var t: Float = 0

var scene: GangsterSceneManager! = nil

var gameObjects: [GameObject] = []

var player: GameObject!

init(gameLoop gl: GangsterGameLoop)

{

gameLoop = gl

NSKeyedUnarchiver.setClass(GangsterSceneManager.self, forClassName: "SceneManager")

let path = NSBundle.mainBundle().pathForResource("street scene", ofType: "vssproj")

scene = GangsterSceneManager(contentsOfFile: path)

scene.activeCamera.distance = 20.0

scene.occlusionCulling = true

scene.skeletalEffect = SkeletalAnimationShaderEffect()

scene.optimize()

//load game objects

loadModels()

println("entities: \(scene.entities.count)")

player.model.pos = float3(x: 20, y: 3, z: 10)

//shadow map resolution

//scene.sceneShadowMappingPass()?.setDimensionsWidth(8192, andHeight: 8192, andTextureFormat: GLenum(GL_FLOAT))

}

private func loadModels()

{

let scale: Float = 0.1

//load models

let gangsterPath = NSBundle.mainBundle().pathForResource("gangster", ofType: "vssproj")

let gangsterScene = SceneManager(contentsOfFile: gangsterPath)

var result = gameLoop.loadAnimatedModel("walk.dae", intoScene: scene)

var modelInfo = AnimatedModelInfo(animatedModelEntity: result["entity"] as Entity, aiScene: result["aiScene"] as AssimpSceneWrapper,

globalInverseTransform: gameLoop.globalInverseTransform())

var obj: GameObjectSkeletalAnimated = GameObjectEnemy(model: gangsterScene.entities.firstObject as Entity, animatedModelInfo: modelInfo)

obj.model.scale = float3(x: scale, y: scale, z: scale)

gameObjects.append(obj)

obj.addToScene(scene)

//for now

player = obj

let bystanderPath = NSBundle.mainBundle().pathForResource("bystander", ofType: "vssproj")

let bystanderScene = SceneManager(contentsOfFile: bystanderPath)

obj = GameObjectBystander(model: bystanderScene.entities.firstObject as Entity, animatedModelInfo: modelInfo)

obj.model.pos = float3(x: -20, y: 3, z: 20)

obj.model.scale = float3(x: scale, y: scale, z: scale)

gameObjects.append(obj)

obj.addToScene(scene)

}

private func isKeyDown(code: SDL_Scancode, _ key: UnsafePointer<Uint8>) -> Bool

{

return key[Int(code.value)] != 0

}

func processEvents()

{

let key = gameLoop.keyState

let activeCamera: CameraView = scene.activeCamera

if isKeyDown(SDL_SCANCODE_EQUALS, key)

{

activeCamera.distance -= 1

}

if isKeyDown(SDL_SCANCODE_MINUS, key)

{

activeCamera.distance += 1

}

if isKeyDown(SDL_SCANCODE_LEFT, key)

{

player.model.translate(float3(x: 0, y: 0, z: 1))

}

if isKeyDown(SDL_SCANCODE_RIGHT, key)

{

player.model.translate(float3(x: 0, y: 0, z: -1))

}

if isKeyDown(SDL_SCANCODE_UP, key)

{

player.model.translate(float3(x: -1, y: 0, z: 0))

}

if isKeyDown(SDL_SCANCODE_DOWN, key)

{

player.model.translate(float3(x: 1, y: 0, z: 0))

}

func processLogic(#delta: Float)

{

t += 0.1*delta

let activeCamera: CameraView = scene.activeCamera

activeCamera.viewMode = CAM_FREE

activeCamera.theta = sinf(t*0.05)*30

var bbox = float3.zero

player.model.getBBox(&bbox)

var pos = player.model.pos

pos.y += 0.1*bbox.y/2

activeCamera.setSphericalPos(pos)

for obj in gameObjects

{

obj.update(delta: delta)

}

func render()

{

scene.render()

}

Lastly, a sample lineage of the early GameObject class implementation.

//
//  GameObject.swift
//  Gangster Driveby
//
//  Created by Mike Farrell on 10/14/14.
//  Copyright (c) 2014 Mike Farrell. All rights reserved.
//

import Foundation

class GameObject
{
  ///Graphical 3D model used to render the game object
  let model: Entity

  ///Per-object time in seconds since spawn
  var time: Float = 0

  ///Scene that the model is currently rendered in
  weak var scene: GangsterSceneManager? = nil

  init(model m: Entity)
  {
    model = m
  }

  deinit
  {
    if(scene != nil)
    {
      removeFromScene(scene!)
    }
  }

  ///Process logic updates for the game object
  func update(#delta: Float)
  {
    time += delta/60.0
  }

  func addToScene(scene: GangsterSceneManager)
  {
    self.scene = scene
    scene.entities.addObject(model)
  }

  func removeFromScene(scene: GangsterSceneManager)
  {
    scene.entities.removeObject(model)
  }
}

// GameObject.swift

// Gangster Driveby

// Created by Mike Farrell on 10/14/14.

import Foundation

class GameObject

{

///Graphical 3D model used to render the game object

let model: Entity

///Per-object time in seconds since spawn

var time: Float = 0

///Scene that the model is currently rendered in

weak var scene: GangsterSceneManager? = nil

init(model m: Entity)

{

model = m

}

deinit

{

if(scene != nil)

{

removeFromScene(scene!)

}

///Process logic updates for the game object

func update(#delta: Float)

{

time += delta/60.0

}

func addToScene(scene: GangsterSceneManager)

{

self.scene = scene

scene.entities.addObject(model)

}

func removeFromScene(scene: GangsterSceneManager)

{

scene.entities.removeObject(model)

}

//
//  GameObjectBystander.swift
//  Gangster Driveby
//
//  Created by Mike Farrell on 10/15/14.
//  Copyright (c) 2014 Mike Farrell. All rights reserved.
//

import Foundation

class GameObjectBystander : GameObjectSkeletalAnimated
{
  override init(modelReference m: Entity, aiScene ais: AssimpSceneWrapper)
  {
    super.init(modelReference: m, aiScene: ais)
    setupMaterial()
  }

  override init(model m: Entity, animatedModelInfo: AnimatedModelInfo)
  {
    super.init(model: m, animatedModelInfo: animatedModelInfo)
    setupMaterial()
  }

  func setupMaterial()
  {
    //use random materials for the suit for bystanders    
    let suitMaterial = model.submeshes[1].mat
    suitMaterial?.diff = ColorMaker.float4FromHue(CGFloat(drand48()), saturation: 0.2, brightness: 0.8)

    let shinyColor = Float(drand48())
    suitMaterial?.spec = makeFloat4(shinyColor, shinyColor, shinyColor, 1)
  }

  override func update(#delta: Float)
  {
    super.update(delta: delta)
  }
}

// GameObjectBystander.swift

// Gangster Driveby

// Created by Mike Farrell on 10/15/14.

import Foundation

class GameObjectBystander : GameObjectSkeletalAnimated

{

override init(modelReference m: Entity, aiScene ais: AssimpSceneWrapper)

{

super.init(modelReference: m, aiScene: ais)

setupMaterial()

}

override init(model m: Entity, animatedModelInfo: AnimatedModelInfo)

{

super.init(model: m, animatedModelInfo: animatedModelInfo)

setupMaterial()

}

func setupMaterial()

{

//use random materials for the suit for bystanders

let suitMaterial = model.submeshes[1].mat

suitMaterial?.diff = ColorMaker.float4FromHue(CGFloat(drand48()), saturation: 0.2, brightness: 0.8)

let shinyColor = Float(drand48())

suitMaterial?.spec = makeFloat4(shinyColor, shinyColor, shinyColor, 1)

}

override func update(#delta: Float)

{

super.update(delta: delta)

}

That was alot. The end.

Why most indie games are 2D games.

Leave a reply

Why Most Indie Games are 2D Games

Okay so do you want to know why most indie games are in 2D? Read the posts from the last month or so in my blog. In summary, you’ll notice that 90% of all that work was asset creation. Keeping in mind, this is supposed to be a small-scale single-level 3D mini game. Artwork, modeling, texturing, more artwork, more texturing, more modeling.. etc. Simply stated, asset creation for 3D games is LONG, HARD work.. and in my case, I didn’t even do it all myself (I had a character modeler/animator help me with my single base character model, and I’ve relied quite a few times on turbosquid). Even still, compared to 2D game development, this process can be extremely time consuming. If this was a 2D platformer, most devs would have had at least basic assets for a “level 1″ finished probably in the first day, and would have been programming the actual game long before now. I’ve always tried to ignore this fact but its true. Look at the number of delays, setbacks, and ultimate release date shifts that have plagued recent AAA game projects project and you’ll see that rapid 3D game development is not an easy task even for seasoned developers.

Most independent game developers have certain skillsets that usually fall into the domains of programmer or artist. Now I know there’s stortywriting, sound effects, music, etc. But just about everything involved in a game’s development really splits into the two big umbrellas of either programming or creative (artwork, asset creation, etc). The problem here is that as one advances in their particular domain, and starts to get really good at one aspect of the field, they often have to leave the other side of things to somewhat wither. To become a really good programmer, I mean a really good programmer, you need to get obsessed with your craft. That means even if you were a decent artist, you probably won’t keep up your artistry skillset as much. The same goes for becoming a very good artist, and even a 3D artist.

As the industry has made the shift into large-scale theatric AAA games, more and more specialized craftsmen/craftswomen are needed to spend 8-hour days on something as simple as the texture of a claw of a single enemy in a single dungeon of a game. The sheer manpower that AAA studios can throw at a game allows for the large attention to detail that 3D games require to feel right. Even a “simple” game like mario 64 likely required dozens of artists to pan and pan over every keyframe of mario’s animations to make sure it was perfect. Now don’t get me wrong, this was also true of the SNES/Genesis 2D era. However, attention-to-detail, or lack thereof in these kind of games comes with less of a penalty, and certainly less of a time commitment.

It’s a hard pill to swallow since my dream of making games that started at a young age, has always predominantly been a dream of 3D game development. But you know what? I still love 3D game development. It’s supposed to be hard. The hard… is what makes it great. Tom Hanks is right.

So where does that leave the indie developer with respect to 3D game development? Well when you have a team of only 2-3 people (or in my case, 1 people), you CAN succeed at independent 3D game development. The absolutely crucial difference here is to understand and accept your limitations as an independent. For starters, no matter who you are, limit your freaking scope. Understand that you simply can’t make an AAA-length 3D game in any reasonable amount of time. If you’re 1 person, and a hobbyist with almost zero budget (like me), set a goal for a game that requires at most 1-2 3D environments with very few (if any) unique character models. If you are weak with art but you have the funds, consider using services like turbosquid to procure assets. If you are weak with 3D programming, consider (after buying a few books) using a 3D engine such as unity or unreal instead of building your own.

Above all, plan out the scope of your game to a t. Then, give yourself a pre-determined amount of time to finish the game project… and.. quadruple it.

Driveby Gangster Update – a Dive Into Swift

Over one month in to my planned “2 week” 3D game project, 90% of my assets are done! I still need a 3D tommy gun and an old-timey driveby gangster car. But I’m going to start actually programming (imagine that) the very simple AI that will drive the walking of most of the bystanders in the game. I’ve got my work cut out for me since most of the game logic code I’ve written to this point is all throwaway “get-it-to-work” POC code. I now need to organize and get a basic heirarchical game-architecture together. More fun, as I mentioned in my first post, I’ll be doing most of the game classes and logic in swift. Swift, despite being officially released, still has its problems. Namely for me, the speed of the IDE (for things like auto-completion) while typing in swift is the biggest gripe I have with the language so far. That problem is followed by a close-second of annoying cryptic compiler errors that have nothing to do with the underlying problem of “I’m expecting an Int32, but you gave me an Int”. Either way, I’m keeping my promise to write the game in swift as an experiment to see if the language is truly something I’ll want to leverage for game development in the future.

Debugging framerates..

Leave a reply

Things…

Leave a reply

Despite the activity on this blog, I’ve actually been quite hard at work on this game. The last few days have been filled with quite a bit of shadow mapping optimization which has proven to be much more complicated than I originally thought. Shadows are probably a good chunk of the reason why most people go with pre-built game engines instead of developing their own, but I finally got shadows working reasonably well!

I’ve also spent quite a few days trying to get the frame rate up for the actual game by optimizing the rendering engine. I’ve made some small strides here but honestly the main cost in terms of performance seems to be the grand total accumulation of just “alot of OpenGL api usage” to draw roughly 250 separate objects in the scene. When I turn off the root call (entity render) for the entire scene, the framerate goes sky-high, but when I comment out smaller parts or optimize entire sections of code such as my prepare to draw methods (setting up uniform state), I get very small gains. This leads me to throw up my hands and say “screw it” at least for awhile. I get roughly 60 fps when close to buildings (thanks to occlusion queries) and about 30 when viewing the whole street on my Geforce 650 m card. That’s going to have to be good enough for what should remain a small game project. I really don’t want to get sucked into too much more low-level OpenGL optimization for this project. Surprisingly, my older laptop from 2009 gets 20 fps (still pretty decent) and the iPad Air gets a very decent rendering performance too. Perplexing… but I’m all-around pleased so I’m moving on from performance optimization for now…

After all this craziness, my next step is to finally start texturing the character model and making sure he still animates properly when textured. My character artist wasn’t able to texture the model so now this falls onto me. This hopefully shouldn’t be too bad. I’m planning on doing the UV texturing within verto to avoid more problems with 3D file format conversion. It should work out fine, as long as I make sure I absolutely do not modify the vertices of the model when I do the texturing, as this will break the references inside of the animation skeleton structures. Fun stuff. More to come soon…

Shadowing almost done

Leave a reply

Not much to say today except that I got shadowing almost done for the entire street scene. This was a lot of work but it was worth it because it really ads that finishing touch that makes this feel like it was done in a real 3D game engine and not just a one-off homebrew 3D indie game….. even though that’s exactly what it is.

The ways of shadows

Leave a reply

Ahh shadows. I’ve been putting this off because lets face it, 3D shadow mapping is not frickin easy. There are countless advanced algorithms for 3D shadow mapping to make shadows look as pretty as possible on our discrete-centric graphics hardware. Some of them are crazy complicated and quite difficult to implement. I’ve been messing around with 3D graphics programming for over 10 years now and let me say that shadows have always been just out of reach for me. This week, I decided to put an end to that.

As a plan, I’ve decided to keep things as simple as possible. I’m making a game here, not a game engine, so I wanted to get shadows working reasonably well, and get back to the game programming aspect of this project.

The basic outline of the simplest shadow mapping technique:

Render the scene from the perspective of the infinitely far direction light (shadow pass) into a shadow-depth texture.
Render the scene normally using the depth-information from the shadow-depth texture to determine whether or not a particular pixel is visible to the light or not (in shadow or not).

The Shadow Pass

Above, it sounds simple. In practice, there are many caveats. For starters, its absolutely critical to get the most of out of the “shadow-depth” texture in terms of resolution as possible. Thus, when rendering the shadow pass, we want to contain the entire scene into the light’s view with the constraint that we show as much (are as zoomed in) as possible. If we zoom in too little, we hurt the resolution of the shadow map. If we zoom too much, we risk clipping the scene resulting in some shadows being lost. Furthermore, we want to render this step with as simple of a shader as possible, to avoid unnecessary wasted computation on the GPU.

Going back to the optimal viewport containment (zooming) issue, this boils down to computing the optimal Ortho-box that the scene will be contained in. We’ll use this box as the parameters to the ortho projection matrix given during the light/shadow rendering pass. Optimally bounding the scene with this box presents a problem due to the fact that the box is in light-view-space coordinates, and all of our scene bounding boxes are in world-space. Trying to work through this last night, I resorted to pencil and paper.

The algorithm essentially involves grabbing the light’s “viewing” transformation which consists of a simple lookAt transform and applying it to the 8 corner vertices of the world-space bounding box of the entire scene. Once I have these coordinates in light-view-space, hopefully a computation of a new axis-aligned bounding box of these 8 points will be the ortho-box I’m looking for. It turns out, that this worked quite well.

The actual code of this algorithm ended up looking more like this..

  if(lightPos.w == 0.0f)
  {
    float3 lightInvV = make_float3(lightPos.x, lightPos.y, lightPos.z);
    lightInvV = float3Normalize(lightInvV);

    mat4 depthViewMatrix = mat4MakeLookAt(boxPos.x+lightInvV.x, boxPos.y+lightInvV.y, boxPos.z+lightInvV.z, boxPos.x, boxPos.y, boxPos.z, 0, 1, 0);

    //transform the bounding region into light-space
    GrowableArray *boundingRegionVerts = [box generateVertices];
    [self applyTransform:depthViewMatrix toVerts:boundingRegionVerts];

    //calculate light-space extremma to properly bound the region in light-space
    //(axis-align the new region to light-space)
    Box3D *lightSpaceBox = [self calcLightSpaceBoundingRegionWithVerts:boundingRegionVerts];
    boxPos = lightSpaceBox.pos;
    boxSz = lightSpaceBox.dims;

    mat4 depthProjectionMatrix = mat4MakeOrtho(boxPos.x-boxSz.x/2, boxPos.x+boxSz.x/2,
                                               boxPos.y-boxSz.y/2, boxPos.y+boxSz.y/2,
                                               boxPos.z-boxSz.z/2, boxPos.z+boxSz.z/2);
    mat4 depthMVP = mat4Multiply(depthProjectionMatrix, mat4Multiply(depthViewMatrix, depthModelMatrix));    
    shadowMatrix = depthMVP;

    return depthMVP;
  }

if(lightPos.w == 0.0f)

{

float3 lightInvV = make_float3(lightPos.x, lightPos.y, lightPos.z);

lightInvV = float3Normalize(lightInvV);

mat4 depthViewMatrix = mat4MakeLookAt(boxPos.x+lightInvV.x, boxPos.y+lightInvV.y, boxPos.z+lightInvV.z, boxPos.x, boxPos.y, boxPos.z, 0, 1, 0);

//transform the bounding region into light-space

GrowableArray *boundingRegionVerts = [box generateVertices];

[self applyTransform:depthViewMatrix toVerts:boundingRegionVerts];

//calculate light-space extremma to properly bound the region in light-space

//(axis-align the new region to light-space)

Box3D *lightSpaceBox = [self calcLightSpaceBoundingRegionWithVerts:boundingRegionVerts];

boxPos = lightSpaceBox.pos;

boxSz = lightSpaceBox.dims;

mat4 depthProjectionMatrix = mat4MakeOrtho(boxPos.x-boxSz.x/2, boxPos.x+boxSz.x/2,

boxPos.y-boxSz.y/2, boxPos.y+boxSz.y/2,

boxPos.z-boxSz.z/2, boxPos.z+boxSz.z/2);

mat4 depthMVP = mat4Multiply(depthProjectionMatrix, mat4Multiply(depthViewMatrix, depthModelMatrix));

shadowMatrix = depthMVP;

return depthMVP;

}

Below is a sample result of a shadow pass done using my cheap and simple bounding algorithm ran on our street scene (vantage of the light). Note that this is stored into a depth-component texture attached to the depth-attachment of an offscreen FBO.

Goooood.

The Shadow-Application (main) Pass

During the main rendering pass, I needed to modify my shaders to include the application of the shadows from the light-map. Alongside the light-map texture, I needed the a variant of the same “MVP” model-view-projection used to transform a world-space position into projected light-view-space coordinates. This matrix is commonly referred to as a “bias shadow matrix” because its optimized to express the result in a normalized texture-coordinate form that GLSL texture routines are expecting. In short, it simply applies the lighting-transform, divides the coordinates by 2 and then shifts them by 0.5.

          mat4 biasMatrix = make_mat4(
                                      0.5, 0.0, 0.0, 0.0,
                                      0.0, 0.5, 0.0, 0.0,
                                      0.0, 0.0, 0.5, 0.0,
                                      0.5, 0.5, 0.5, 1.0
                                      );          
          biasMatrix = mat4Multiply(biasMatrix, lightMatrix);

mat4 biasMatrix = make_mat4(

0.5, 0.0, 0.0, 0.0,

0.0, 0.5, 0.0, 0.0,

0.0, 0.0, 0.5, 0.0,

0.5, 0.5, 0.5, 1.0

);

biasMatrix = mat4Multiply(biasMatrix, lightMatrix);

Armed with the shadow matrix and the shadow map texture, I generate the needed shadow coordinate information in vertex shader. I also compute a shadow bias to combat a well-known phenomenon known as “shadow acne” essentially caused by z-fighting from the shadowmap texture.

struct Light
{
  /*....*/  
  mat4 biasShadowMatrix;
};

uniform Light lights[1];

in highp vec4 position;
in mediump vec3 normal;

out float shadowBias;
out vec4 shadowCoord;

void main()
{
  //Compute transformed normal
  vec3 eyeNormal = normalize(normalMatrix * normal);

  float cosTheta = dot(eyeNormal, normalize(lights[0].position.xyz));
  float bias = 0.005*tan(acos(cosTheta));
  shadowBias = clamp(bias, 0.0, 0.01);  
  shadowCoord = lights[0].biasShadowMatrix * position;

  //......
}

struct Light

{

/*....*/

mat4 biasShadowMatrix;

};

uniform Light lights[1];

in highp vec4 position;

in mediump vec3 normal;

out float shadowBias;

out vec4 shadowCoord;

void main()

{

//Compute transformed normal

vec3 eyeNormal = normalize(normalMatrix * normal);

float cosTheta = dot(eyeNormal, normalize(lights[0].position.xyz));

float bias = 0.005*tan(acos(cosTheta));

shadowBias = clamp(bias, 0.0, 0.01);

shadowCoord = lights[0].biasShadowMatrix * position;

//......

}

Lastly, in the fragment shader, I sample the shadow texture to determine whether or not the shadow coordinate of the given fragment is visible or not to the light. I can vary the visibility factor to be as dark or light as I want to achieve the desired effect. Note that I’m using a shadow sampler here. This special hardware sampler takes multiple samples of the shadow map for me and interpolates the results automatically to produce a smoother shadow edge.

uniform sampler2DShadow shadowMap;

in vec4 shadowCoord;
in float shadowBias;

void main()
{
  vec4 highlight = vec4(0.0);
  lowp vec4 color = vec4(1.0);

  float visibility = 1.0;

  //sample the shadow map to determine the shadow color (1.0 or 0.3, interpolated)
  vec3 coord = vec3(shadowCoord.xy, shadowCoord.z-shadowBias);
  visibility *= max(texture(shadowMap, coord), 0.3);

  vec4 lightColor = computeLight(normalize(va_normal), ec_pos, 1.0, lightColorOtherSide, highlight);
  color.a = material.alpha;

  color *= visibility;  
  fragColor = (gl_FrontFacing) ? color*lightColor : color*lightColorOtherSide;
}

uniform sampler2DShadow shadowMap;

in vec4 shadowCoord;

in float shadowBias;

void main()

{

vec4 highlight = vec4(0.0);

lowp vec4 color = vec4(1.0);

float visibility = 1.0;

//sample the shadow map to determine the shadow color (1.0 or 0.3, interpolated)

vec3 coord = vec3(shadowCoord.xy, shadowCoord.z-shadowBias);

visibility *= max(texture(shadowMap, coord), 0.3);

vec4 lightColor = computeLight(normalize(va_normal), ec_pos, 1.0, lightColorOtherSide, highlight);

color.a = material.alpha;

color *= visibility;

fragColor = (gl_FrontFacing) ? color*lightColor : color*lightColorOtherSide;

}

The results of all of this craziness is something quite nice. Shadows casted in my scene that can lie across curved surfaces. This was quite a bit of work but I think it’ll be quite worth it since now my graphics engine is shadow-capable. Down the road I’d like to add point-light shadow capability via rendering into shadow cubemaps and general shadow capability for Verto Studio, but for now, directional light shadows satisfies the needs of my game project.

Parse Error

Michael L. Farrell's Game Dev Blog

Monthly Archives: October 2014

More about swift…

Number one – Casting

Number two – Stability (source kit crashes)

Its midnight..

Quick update

Game Development in Swift

First Impressions

The Game Architecture

Graphics Engine

Objective-C Classes (Graphics Engine)

The Game Classes

Objective-C Classes (Driveby Gangster Game)

Swift Classes (Driveby Gangster Game)

Why most indie games are 2D games.

Driveby Gangster Update – a Dive Into Swift

Debugging framerates..

Things…

Shadowing almost done

The ways of shadows

The Shadow Pass

The Shadow-Application (main) Pass