Parallax Occlusion Mapping – Advances in shader land

Today was cool… at least the first part of it was, before I spend 5 hours tracking down a bug in some of the game code.

I stumbled onto a pretty cool little article geared towards a very awesome technique called “parallax occlusion mapping”. This is essentially bump mapping with some extra samples taken at each pixel to provide a realistic depth (or parallax) effect to the surface. This provides the illusion of realistic surface detail all while shading a single polygon. The article was somewhat dated and targeted for Direct3D instead of OpenGL, but I was able to port it over to GLSL 150 for OpenGL 3.2.

Here’s the original article:
http://www.gamedev.net/page/resources/_/technical/graphics-programming-and-theory/a-closer-look-at-parallax-occlusion-mapping-r3262

And here’s my port of the shader code for anyone who is interested.

 

Some of this code is “massaged” by Verto Studio’s code converter when ran on mobile.  It’s definitely a pretty cool effect!  It requires 3 texture maps to work currently, a standard diffuse (color texture) map, a normal map, and a displacement or height map.  Lucky for me, there’s a sick little program called “crazy bump” for mac that can generate both normal maps and displacement maps from any standard diffuse texture map!

 WebGL demo

For those who want to see the shader effect in action, I got a WebGL demo which runs on chrome and safari (firefox and IE don’t work).

It’s an expensive effect however, so I’m not sure yet if I can work it in for Driveby Gangster.  Either way, it’ll definitely be a nice little addition to the shader arsenal.  If I do actually put it into use, I hope to eventually add self-shadowing effects as well.

What I’ve been doing

Tons of stuff has been accomplished as of late.  I’ll just list a few of em here.

  • I programmed a cool “breaking glass” shader for the street scene shop window so that when you shoot at it, it breaks
  • I made a “spark” particle shader for when you shoot at metal, and also programmed separate bullethole decals to appear depending on the surface you strike.
  • I bit the bullet and grabbed maya for finishing up some of the character animation stuff including animations for aiming the gun and getting hit by bullets
  • I started on and nearly finished a very awesome “beach” scene for the game.  This broke one of my cardinal rules about keeping the stuff simple, but I’m accepting the risk because a game with the same level over and over again is a pretty bad user experience.
I apologize again for the lack of quality updates on here, but I’ve definitely been prioritizing working on and finishing the game over keeping this blog up to date.  It’s a tradeoff I guess.

For the beach scene I modeled a cool sailboat for it entirely from scratch using verto.  I have big plans for this sailboat that I’m going to keep secret for now.

One thing that I’m really excited about was a small effort that took me two days. I managed to compile the entire C++ code base to JS using emscripten.  This means that I can display simple verto studio scenes in the web browser!  A quick demo of this, for people running on webgl enabled browsers, should display below…

 

Another youtube series

I’ve done so much since my last update. I have a bunch of screenshots on my desktop just waiting to be uploaded here.  I’ll try to submit a “real” update this weekend.

I just wanted to post to mention that I have uploaded a new tutorial series on YouTube regarding learning shader programming!   The playlist for the series is here:  https://www.youtube.com/playlist?list=PLT6WFYYZE6uJco3V9_Ssq2VPRIXCPUEsE

Free the code

One of the reasons why love game programming so much is that it forces you to do things that would otherwise seem quite ridiculous. I have always liked to shoot first and ask questions later when it comes to implementing an idea. Sometimes it’ll just pop in my head and then I will start working on it and before I know it…it’s done. The last week and a half has been more work than I ever wanted to do but the result is awesome. A very large portion of my entire Verto Studio graphics engine and code base has now been rewritten in C++ and is now portable to any operating system.

This means I can now load and render my Verto Studio files on Windows, Linux, anything I want without any strict dependencies on Mac anymore.  As a game developer, this is an awesome feeling and I am beyond stoked.  I worked very hard on the Verto Studio tech over the last three years and to finally free it from OSX/iOS is great.

I’ve moved on the actual swift code of the in-progress Driveby Gangster Game project and hopefully I’ll have that done soon next week.  All-in-all I’d say the extra week of work was definitely worth it.

Screens!!

Too much talk about code lately on here.

Here’s some latest screenshots.  Before my decision to switch languages, I completely finished off the “practice mode”

I also recorded a gif during my testing with the bullet collision detection against arbitrary polygons in the scene.

Swift is fired

So it had to happen…

The more I work on this game the more I realize that I kind of like it… and that means there’s certain things need to change.  For starters, it’s definitely running longer than I expected it to (the original two-week estimate now sounds pretty “out there”).  For this reason, I need to shave down on the programming time. It has become pretty obvious to me that for every 1/2 hour that I spend writing code in swift for this game, 10 minutes of it is spent screwing around with the language and that is friction then I can no longer accept.  So I’m dropping swift for this game.

Since I’m switching languages and I’m going to be rewriting some code, I decided to open things up quite a bit and go back to C++.  It’s going to cost me roughly a week or two to rewrite things, but the benefit is going to be huge.  For starters, since this game depended on my very large and very complicated Objective-C graphics engine (Verto Studio), I now have the “opportunity” to continue rewriting all of this code in C++ (this was originally started on my github as VGLPP).  This means that this game and any other game that I want to use with the ported engine will be able to run on ANY platform including windows.  This is a major win for me since making a game for OSX/iOS only isn’t really that smart.  I’ve been wanting to do this for awhile and my frustrations with swift finally pushed me to do it.

So that’s what I’m going to be up to for awhile.  As I’ve mentioned on twitter, I’ll be streaming roughly twice a week on my twitch channel for anyone who is curiuos about the process and wants to follow along.  http://twitch.tv/vertostudio3d

I’ve already gotten quite a bit done and have surpassed my biggest barrier for doing this which was finding a reasonable way to parse verto studio files (spat out by NSKeyedArchiver/NSCoder objective-c mechanisms) in a portable way in C++.  TinyXML and a little of reverse engineering did the trick.

With respect to all of the “benefits” swift and Objective C were providing over a lower level language such as C++, I’ve essentially found a reasonable replacement for each one thanks to C++11′s new features.

Basic Outline of Porting to C++ 

Swift/Objc C++11
Strong Pointer (Reference Counting) std::shared_ptr
Weak Pointer (Reference Counting) std::weak_ptr
Blocks & Closures Lambda Functions
Protocols Multiple Inheritence
Dynamic Typechecking via “isKindOfClass” C++ typeid / RTTI

So you get the idea, nothings really out of reach with C++. It’s still more annoying and I’m not 100% thrilled with dealing with things like templates, header files and verbose syntax again, but I’ll take it over an unstable language any day.

Lots of code… lots

I’ve been less active on here because I’ve been writing quite a bit of code.  Like I said previously, I’m in the main swing of developing this game.  This is where things start to get crazy.  Namely, I’ve added quite a bit of classes to the project to handle everything from basic collisions and 3D math extensions to generating and displaying 3D text on the screen.  I feel like (despite my previous post regarding Swift) things are keeping organized quite well and I haven’t strayed too far from my original architecture plan.  I’ve spent most of my time working on the PracticeGameStateRunner class which runs the “Target Practice” initial level in the game.  This mini level serves as a point for the player to learn the very simple controls and game mechanics of the game… and it’s serving excellently as a sandbox for me to test these all during development as well.  

I’ll cover just a few pieces of code today to show the changes that I’ve made regarding the game State Runner protocol, and some cool stuff that I’ve been able to do with “smart” enums in swift.  There’s a lot more I can talk about that I don’t want this post to go on forever.

Some Code

State runner protocol.  Now I have some stuff in there to quickly respond to “game controller” and mouse events, all stemming from the game loop class.

Mesh Line Collider – a badly needed construct to determine whether or not a bullet-trajectory would intersect a polygonal mesh in the scene or not (and if so where).  I tried porting this over to ObjC before swift and it was a nitemare.  Swift’s version is definitely simpler thanks to operator overloading and multiple return values.  Note the unsafe pointer craziness in swift which is considerably easier to deal with in C.  (ported from http://geomalgorithms.com/a06-_intersect-2.html)

Cool little WIP controller button enum nested in the game loop class

 

Some Screens

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.

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

Can be…

 

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..

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