General Update

There's something about Blogger and Wordpress and what not that is distinctly not mine.  There isn't anything particularly bad about being not mine but, when it comes to personal projects, that sense of ownership is important to me.  I think that's why I keep falling out of touch with these blogs I keep trying to make.

The solution, of course, is to create my own website, and that's what I'm working on now.  I will hopefully be a bit better at keeping that one up to date.  Progress on that project is a bit slow, I've decided to use Wt (I've played around with Django in the past but, it's not for me) and, it's seems like there is quite a bit of learning to do.  That said, I'm confident I'll have something up and running without too much delay.

For now though, updates:

SBEngine and Starbase are a thing of the past.  While I consider myself proficient with C# it's not the language I choose to work in.  Generally, I like to avoid garbage collection.  I like to know where my memory is at all times (or at least have the ability to figure it out if I ever lose track.)  Getting Scaleform to fit nicely into the Wii's memory while working on Disney Infinity was something of a nightmare due to the garbage collection.

Even then, personal projects are something of a conundrum.  I love the idea of writing something completely from scratch but, I don't think there's enough time to warrant it.  In the time it takes to program one game from scratch I could program 3 or 4 using some existing libraries.  I think there's a future in games for policy based libraries but, I don't think that I need to be the one to program them.  Then again, if I take everything else and implement my own Physics library...

So, with what I haven't been up to out of the way, what have I been up to?

Not too much really.  From a few months after starting at Heavy Iron until a couple of months ago I was doing large amounts of overtime for Disney Infinity.  My non-work life took a step back and that includes all personal projects.  I suppose this post is really the beginning of my return to working on my own stuff.  Hopefully this time I'll do a better job of keeping a blog up to date, whether it be this one or the next one.

Cheers

Physics(Again)

I haven't had that much time to sit down and code away but, there were a couple things I wanted to mention.

First, multiple inheritance:  it's wonderful.  There's this idea that language features that can result in you shooting yourself in the foot are bad.  I disagree with this.  Language features don't shoot programmers' feet, programmers shoot programmers' feet.  Using a language feature is a privilege.  That feature doesn't owe you anything so if you use it without fully understanding it, too bad.

This does of course mean that if you should never use it in an environment where others may not know it or expect to see it.  As with every feature it has a time and a place, much like how you should be careful about using the ?: operation as it can result in difficult to read code.

Now, I've been shot in the foot before, I'm actually really great at it.  But if you look closely, no two bullet wounds (or at least no.. four, I'm going with four) upon my foot look the same.  And as this project is devoid of other people's feet entirely, I get to experiment.

This brings us back to MI, people have shot themselves in the foot with this before.  Some people with C-style casts and forward declarations, others with diamond inheritance and I'm sure there are many more interesting ways I just haven't run into.  This has resulted in this idea that it's dangerous.  And it is, I suppose. But, more importantly, it's versatile.  The main point I'm getting at is Policy Based Class Design which often relies on MI (and templates.)

My initial idea for the Policy Based Class Design bastardization in C# was to hide all the routing to interfaces in routing interfaces which the PhysicsEngine would inherit from.  This required that those interfaces had either a pointer to an implementation (which isn't allowed) or a function (or property) that would retrieve that pointer, allowing the functions of IBroad, for instance, to be overloaded to a simple routing to that pointer.  This isn't possible because first, interfaces can't have data members and second, properties/functions have to be public, which I don't want.  The solution would be multiple inheritance of classes but, that's not supported in C#.  For shame.

This means I'll have to do the routing within the PhysicsEngine which will cause an even greater level of coupling with implementations and a lower ease of extending.

The second thing I wanted to talk about is the first implementation: the spatial hash grid.

I had considered doing a few different Broad Phases initially, one of them being the Quad Tree which I've already done a couple time.  I settled on the spatial has grid for a few reasons.

0)  It implements all of the extension interfaces I've thought of (IBroad, ICull, IAdjacency).  It does this better than any other implementation I've thought of as each of these are very fast.  The first weeding for all 3 implementations is O(1) (hash grid cells) and the second weeding in O(n) for very low numbers of n (the number of PhysicComponents in the hash cell.)

1) It's scale-able.  The Spatial Hash Grid, perhaps more than any other implementation, scales very well.  You can configure it to use more memory and that will decrease the processing time needed (the n mentioned before will drop) or to use less memory which will increase the processing time.  This is good for an engine that will (eventually) deploy to the Vita (and ps certified smart phones) as well as the Xbox and the PC.

10) I haven't done it before.  I love learning.

Oh, numbered items, how you allow for geeky programmer jokes.

When I have a bit more time I'll discuss the spatial hash grid on it's own.  I should figure out a way to keep track of what blog topics I've promised to post about...

Physics

I did a quick UML of the Physics Engine portion of SBEngine.  I love the idea of UML but, I really need to brush up on it.  I'll do that at some point, make sure my arrows are pointing from A to B instead of B to A and what not.  That doesn't really matter for now, what does matter is that it's all diagrammed out and it's going to be interesting to implement.


The main component of any Physics Engine is the Collisions.  Collisions are traditionally split into two phases: Broad and Narrow.  The Broad phase does fast, inaccurate calculations to weed out the collisions that definitely won't happen, the narrow phase does slow, accurate calculations and passes the results to be handled elsewhere (generally by the Objects that collided).  The Broad phase is further broken down into Partitioning/Sorting and Bounding Volume Collisions.

Now, the Narrow phase and BVC subphase both accomplish what they set out to do and little more.

The Partitioning/Sorting phase, though, can accomplish much more than what it set out to do (weed out impossible collisions.)  What it can do, however, is dependent upon the implementation.  For instance, finding out what is next to a specific object (for AI reasons) is very easy in a Spatial Hash Grid, a little harder in a QuadTree and very annoying in Sort & Sweep (Don't worry, the specifics aren't important now, and I'll cover them in another post sometime.)  So how do we approach this from a design perspective.

What we want is a Physics Engine class that you can configure.  The Physics Engine should be the Gateway into everything.  That said, you should be able to pick what the underlying Broad Phase implementation is but, you shouldn't have to get that implementation every time you want to get the implementation specific function.  Ideally the Physics Engine's interface would change depending on the implementation that you choose.

How I wanted to do this:


template < class BroadPhaseImplementation >
class PhysicsEngine : public BroadPhaseImplementation{
...
};

This is policy based class design.  What's good about it?  It fits this problem perfectly.  If I want to route Drawing through a culling process in my HashGrid, I just expose the public function in HashGrid.  That way that funtion will be in PhysicsEngine<HashGrid> but not in PhysicsEngine<NotHashGrid>.

What I'm going to end up doing:


Now, a large reason I'm building this engine is to have something out there for XNA/PSM development.  This means I'm going to have to use C# and C# does not allow inheritance of their template-equivalent generics.  This means I've had to go about it in a much less 'open' manner.

Every PhysicsImplementation will inherit from the PhysicsImplementation interface.  They'll also potentially inherit from different strategies (like a IGetAdjacency strategy).  The Physics Engine will inherit from all of Strategy interfaces.  If the Implementation supports a particular strategy any call to that strategies functions (PhysicsEngine.GetAdjacency() for instance) will be routed to the implementation.  If the implementation doesn't support it, it'll throw an exception.

Why is this worse:


Runtime errors instead of compile time errors is the big thing.  If you tried calling a function that HashGrid had on a Sort&Sweep PhysicsEngine in the Policy based design, it just wouldn't compile.  In this case it will compile but it will through a run time error.

Extensible; if a new implementation comes to the forefront that happens to allow something that no other implementation before it does, I'll have to create an interface for it, a router for it, have it and the PhysicEngine inherit from the interface.  In the policy based design I could just add the function to the implementation and be done with it. 

I'll post the UML when it's a bit more correct.

SB Engine

The Intro

I’ve decided that I want to develop a game for multiple platforms.  That decision came over time, let’s take a look at its evolution.

First, I needed to develop a prototype.  This was for a class and the prototype had to be in XNA.  I ended up creating a space combat prototype.  It was tons of fun, though it deviated a lot from the initial design.  It ended up as a game in which you would mine an asteroid during a ‘rest’ period and then fight off a wave of enemies followed by another rest period.  The asteroid mining would give you some resource which you could upgrade your ship with.  As a prototype it is great, as a game it is obviously lacking.  I’ll talk more about the prototype (called StarBase hence the SB Engine in the title, more on that later) in another post. 

For now, all that’s important is:

A)  I liked a lot about the game and it inspired me enough to make me want to develop a different, similar game.

B)  I enjoyed creating the quad tree physics the most and it would have completely blown up the Xbox 360 without it (due mainly to a lack of multithreading.)

C)  I made a cool bloom Shader for the lasers which I’ll post about (both my implementation and what I’d do differently.)

D)  I enjoyed XNA.

For a short period of time I considered going back to C++ and making an engine mainly from scratch (I can do that because I'm a student and it'd look good.  You shouldn't do it if you want to make a game.)  I ended up dismissing the idea and went back to XNA, then I heard about PSM and decided to take the challenge of going both routes.

The Thrilling First Act


With all of this in mind I decided that I should look into extending the game; well, more starting from scratch while keeping some of the main concepts alive.  The main reason I decided to go to C# instead of C++ is that it's a lot easier to translate high level ideas into C#.  The quad tree I made would have taken a bit longer in C++ for instance, it probably would have run faster but, it would have been programmed slower.

I'll discuss the specific parts of the engine later on but, for now I'm going to talk about the cross platform nature of the Engine and what that entails.

The first step is going to be figuring out the interface of the Engine.  Some parts will not require porting: the physics for instance will be all coded by me for reasons I'll get into in another post, the Game concept class (such as GameEvent) and many other subsystems which dance the line between Engine and Game.  Some parts will need to be ported, most obviously the Input, the Graphics and the Sound.  This will require me to make an abstraction layer.

The second step will be getting a build system set up.  As fun as it is to open VS, build the XNA project then open PSSuite (based on Mono) and build the PSM project, having an automated process will make my life much, much easier.

The third step will be... Actually coding those parts.  More on that later.

It's going to be very fun.  I just hope I make it through alive.

Warning Level 4

I became a better programmer recently.  Very recently in fact.  It happened the second I finished C++ Coding Standards by Herb Sutter and Andrei Alexandrescu (Not Alexander Andreiscu as I keep forgetting!)  Two brilliant people who I will one day match!  I hope.

I've always loved picturing learning programming as a constant wave between thinking you know nothing to thinking you know everything and back again.  This book gave me about a dozen full 'waves' as it told me what I didn't know and then taught me it.  Besides that it also pushed good Coding Standards which I'll strive to meet.  The obvious one from the title, is warning level 4, warnings as errors.  It touches on a lot of things you know you should do and then presents the (very compelling) reasons why you should do it.

A few things that really stood out to me:

Item 30.  Avoid overloading &&, || and , (comma)

I probably should have known that the order of operations would be lost.  But it's really easy to assume they'll be kept.  This was a really good fact to pick up, especially considering I've been programming in Scala a fair bit (I love that language) in which you can take advantage of order of operation in operator overloading.

Item 44.  Prefer writing nonmember nonfriend functions.

This isn't something that came as a shock but, the arguments for it really stood out to me.  I'm still a student and as a student I've been told that objects are awesome.  Use objects.  Everything should be in a class (okay, maybe not that far but definitely far enough to assume that last one.)  I'll admit that one of that bad things I've always done is keeping operator overloads that should be nonmember functions in the class.  I always thought it made more sense.  I knew I shouldn't do it but, I always figured I'd wait until the next project to start doing it correctly.  Well, the next project starts now, and those operators (along with a bunch of other functions) are being taken out of the class.

Item 49.  Avoid calling virtual functions in constructors and destructors.

Because they aren't virtual there... Whaaat?  Now, I don't think this is something I've ever done (or thought of doing for that matter.)  But if I did, I definitely wouldn't have expected that.  And pure virtual functions cause undefined behaviour.  Feels a bit minefield-y.  One of the solutions is a factory function, definitely going to be my approach in the future!

Items 92- 95. Cast wisely

These were the ones that really changed the way I look at what I was taught.  For instance, I was taught to use C-style casts on pointers.  This is bad.  Don't do this.  There are three (four including const) casts that are possible.

dynamic_cast<NewType>(object) is the safest and will never be used by C-style casts.  It performs safety checks at compile time and run time.  It does incur an overhead but, one should not optimize prematurely.  Use it as much as you can.  Worst come to worst, it's easy to write a function that will use dynamic cast only in debug.  If the cast fails it returns a null pointer.

static_cast<NewType>(object) is the second safest and is at least portable.  It has no runtime overhead.  Aside from that it is very like dynamic_cast.

reinterpret_cast<NewType>(object) is not for everyday programming (depending on what you do everyday, I suppose.)  In short, it's functionality is implementation specific.  It's unsafe, unreliable and can result in crashes and undefined behaviour.

As stated on http://www.cplusplus.com/doc/tutorial/typecasting/ :

"The conversions that can be performed by reinterpret_cast but not by static_cast have no specific uses in C++ are low-level operations, whose interpretation results in code which is generally system-specific, and thus non-portable."

 So basically, you don't need it unless you know exactly what it's doing.

Now how does this relate to C-style casts?

Well

#include "Derived.h"
void fun(Base* base){
  Derived * myDerived = (Derived*) base;
}

and

#include "Base.h"
class Derived;
void fun(Base * base){
  Derived * myDerived = (Derived*) base;
}

Are completely different.  The first will use a static_cast and everything will be okay (if you pass in a Derived* to base).  The second will use reinterpret_cast and, as we now know, reinterpret_cast should not be used here.  Why is it used?  Because the compiler has no idea that Derived is Derived from Base, it just knows that it's a class.  This becomes a huge problem when multiple inheritance is used as it could result in a pointer of type Base2 pointing at the Base1 implementation in Derived.

There are tons of other create points in the book and I recommend it to everybody.  If anybody notices anything wrong in this post please point it out.

Quick note, I understand that reinterpret_cast is useful for somethings, the book realizes this as well and provides Exceptions for almost all of the Items.

A Return

It's been way too long since I posted anything here.  It's come to my attention that a professional presence on the web is going to be a boon and so, this is my start.  I'll probably be migrating to a more appropriate website set up but, this will do for now.

Update

UDK

I've programmed quite a bit of UDK since my last post, having joined a team working on a game called Game Wizards.  The game is looking good and I hope to have a link to a trailer up soon.

It was a great experience.  Most of the programming was done in unrealscript which looks to become deprecated over the next few years.  I'm torn on how I feel about this.  

Unrealscript was a poorly designed language.  I get the impression that it was created with designers in mind, much of the language indicates this (such as the indefensible case insensitivity) but, it ended up being used for tasks it shouldn't have been used for. Unrealscript made it easy for designers to change behaviour using default properties.  Near every other point where unrealscript diverged from traditional languages was a detriment.  I'll not miss the language at all.

That said, I am somewhat sad to see something I so recently learned possibly becoming irrelevant in a few short years.  The experience with working with such a large code base (as we extended mainly from UT functionality) will serve me well, though.

Templates

Another place where I've spent much of the past months is working on templates.  I don't have the experience in the game industry in order to tell if they're underused but, I believe they present a great opportunity for optimization of runtime performance if they can be properly applied to games.  Few areas of software development prioritize runtime performance more than the game industry and so I hope to spend some time doing some research into the application of templates in games.

As is, I created a simple linear algebra math library utilizing them.  It was a rushed implementation and is definitely not breaking any ground other libraries haven't already broken.  That said, the experience was extremely interesting and enlightening.

Shaders

Graphics in particular has become extremely interesting to me.  I did a few shaders (fresnel lighting, bloom post processing effect) and found them very interesting.  The openGL framework I created to run them was an educational experience as well.  It's use is very different from traditional C++ libraries due to it's C background.  I plan on using the framework to implement examples from GPU gems.

I've done a lot of work besides this over the past while but these were the recent highlights.  Look forward to posting more frequently with much more interesting points.

DirectX -> UDK

So, I actually learned quite a bit about DirectX. I like to think I remember some of it... And I probably do. But most of it has slipped my mind. The simple fact is that it's not something I'm going to have to deal with. I at least got a decent insight into how it is put together and found that pretty interesting. The little bit that I learned about Shaders interested me quite a bit and, I might one day learn more of them and become a Shader programmer. But, I'm really not that good at aesthetics and, while that's not all that Shaders deal with, it is at least something of enough import to keep me away.

Anyways, from that I decided to finally go back to UDK. I tried it before and it didn't go great but, I'm ready to put in the time to learn now and I think it will go much better. This will also make it easier for my wife to do all the art for it as she's worked with it before and, once I get the hang of it it'll be easier to write a few prototypes in it. Not to mention it's a very marketable skill... Very marketable.

A few things have become very evident, though. For one, I will have to DLL bind quite a bit which means learning a lot about DLLs and what not, which is something I really should do anyways. And two, this is going to be very, very different from programming from Scratch. Or even from something like Ogre or Leadwerks. It should be easier but, I can just imagine it being much more annoying and frustrating as well.

But again, it's an important skill in the field I want to enter. And it should -should- be easy enough.

One things for sure, going to be reading a lot of code.... a lot.