Blog for James Steele at GarageGames.com

More friendly console objects

James Steele — 2008-08-05T09:33:19+00:00

Introduction

As I started on a TGEA project last week, it occured to me that the while the DECLARE_CONOBJECT and IMPLEMENT_XXXXXXXXX macros used for console classes are perfectly ok, the process was a bit too involved for me. As it stands, you have (as I see it) four seperate steps in setting up a console object, which are;

1) Derive from the required console object
2) Declare the console object with the DECLARE_CONOBJECT macro
3) Declare a typedef to the parent class
4) Remember to use the IMPLEMENT_XXXXXXXX macro depending on the object type (datablock, netobject etc.)

That's ok if all you're doing is creating the occasional new console object, but I'm in the process of creating lots of new data block and net objects. I don't know about you guys, but I am a very lazy programmer, and I like to automate as much as I can possibly get away with, if it let's me focus on the task at hand.

So how can I reduce the number of steps required? The answer is quite simple. I can compress all of the above steps into one step, and do it in such away that it will be immediately clear to somebody reading the code that it is a specific type of console object.

How is this done? With C++ templates!

How the template classes are used

As a quick example, here is what a typical DataBlock class will look like when using the template for a DataBlock.

class MyNewDataBlock : public IDataBlock<MyNewDataBlock, SimDataBlock>
{
...
...
...
};

And that's all she wrote. This template takes care of deriving, declaring that this is indeed a console datablock object and does away the need for seperate IMPLEMENT_XXXXXXXX macro. There's no need for anything else, not even in the .cpp file. So how does this all work? First it helps if we take a look in the console/consoleobjects.h file. This is where the DECARE_CONOBJECT and IMPLEMENT_XXXXXXXX macros live.

They look a little bit like this...

#define DECLARE_CONOBJECT(className)                 \   
    static ConcreteClassRep<className> dynClassRep;      \   
    static AbstractClassRep* getParentStaticClassRep();  \   
    static AbstractClassRep* getStaticClassRep();        \   
    virtual AbstractClassRep* getClassRep() const

#define IMPLEMENT_CONOBJECT(className)                                       \
    AbstractClassRep* className::getClassRep() const { return &className::dynClassRep; }           \
    AbstractClassRep* className::getStaticClassRep() { return &dynClassRep; }                      \
    AbstractClassRep* className::getParentStaticClassRep() { return Parent::getStaticClassRep(); } \
    ConcreteClassRep<className> className::dynClassRep(#className, 0, -1, 0, className::getParentStaticClassRep())

#define IMPLEMENT_CO_NETOBJECT_V1(className)  \                    
    AbstractClassRep* className::getClassRep() const { return &className::dynClassRep; }                \   
    AbstractClassRep* className::getStaticClassRep() { return &dynClassRep; }                            \   
    AbstractClassRep* className::getParentStaticClassRep() { return Parent::getStaticClassRep(); }       \   
    ConcreteClassRep<className> className::dynClassRep(#className, NetClassGroupGameMask,    NetClassTypeObject, 0, className::getParentStaticClassRep())


#define IMPLEMENT_CO_DATABLOCK_V1(className) \
    AbstractClassRep* className::getClassRep() const { return &className::dynClassRep; }                 \    
    AbstractClassRep* className::getStaticClassRep() { return &dynClassRep; }                            \    
    AbstractClassRep* className::getParentStaticClassRep() { return Parent::getStaticClassRep(); }       \
    ConcreteClassRep<className> className::dynClassRep(#className, NetClassGroupGameMask, NetClassTypeDataBlock, 0, className::getParentStaticClassRep())

There is nothing terribly complicated here. The DECLARE_CONOBJECT macro just declares a static member variable, some static methods to access it and a virtual method to get the type from a class instance. All of the IMPLEMENT_XXXXXXXX macros are almost the same as each other, except in the flags passed to the constructor of dynClassRep.

The only really tricky part is that the IMPLEMENT_XXXXXXXX macros pass the class name, but this is no real issue. We can use the the compilers built-in rtti for this, although it may present a few issues on non-Microsoft compilers (more on this later).

So let's dive right on in. All of the IMPLEMENT_XXXXXXXX macros share a common functionality that we can exploit in a single base template that we shall call IConsoleObject. The template looks like this

// Define the base console object template
template<typename C, typename P, int F0=0, int F1=1, int F2=0>
class IConsoleObject : public P
{
public:
    typedef P Parent;

    static ConcreteClassRep<C> dynClassRep;         

    static AbstractClassRep* getParentStaticClassRep()
    {
        return &P::dynClassRep;
    }

    static AbstractClassRep* getStaticClassRep()
    {
        return &dynClassRep;
    }

    virtual AbstractClassRep* getClassRep() const
    {
        return &dynClassRep;
    }
};


// Instansiate the static member for the template
template<typename C, typename P, int F0, int F1, int F2>
IConsoleObject<C,P,F0,F1,F2>::ConcretClassRep<C> IConsoleObject<C,P,F0,F1,F2>::dynClassRep(typeinfo.name()+6, F0, F1, F2);

There's nothing overly complicated here. The template has a bunch of arguments which are;

C - The class you are deriving
P - The parent (or base) class that you are deriving from. This must be a console object of some sort.
F0, F1, F2 - Flags passed to the dynClassRep constructor. The default values are set to those in the

IMPLEMENT_CONOBJECT macro.

I won't explain what all of the things in the template do, as this isn't what the post is about.

I explained earlier that I use the compilers built-in rtti. This is done with the typeino structure, where I get the class name from, happily relacing the #classname string insertion in the original macro. In Microsoft compilers, I can use this structure with rtti turned off, and the compiler will happily store the string returned from this in the const data section. Other GCC-based compilers are likely to complain though, so you will have to turn on RTTI and live with the extra few hundred KB in executeable size.

Datablocks and Network objects

We can just use the IConsoleObject template as it is, for DataBlocks and NetObjects. We just replace the F0, F1 and F2 parameters with the NetClassGroupGameMask, NetClassTypeDataBlock and NetClassTypeDataBlock flags. But as I noted earlier, I'm a very lazy person. Having to type in those parameters sounds like too much work for my little fingers.

Instead, I have another two templates which specificaly implement Network and Datablock objects. They look a little like this;

template<typename C, typename P>
class INetObject : public IConsoleObject<C, P, NetClassGroupGameMask, NetClassTypeObject>
{};


template<typename C, typename P>
class IDataBlock : public IConsoleObject<C, P, NetClassGroupGameMask, NetClassTypeDataBlock>
{};

And that's it. I have all of these templates in a single header which is included in the relevant files in my project.

Finaly..

I know this probably seems a little bit extreme just so a programmer can avoid a few small steps in creating console

objects, but those steps can quickly add up on a large project. It also helps make it clear exactly what kind of console object somebody is dealing with, without having to hunt for for the relevant IMPLEMENT macro. You could argue that the name of the class might make it clear too, and this is true. But not everybody uses the same naming conventions, and it can be hard to enforce coding standards on a project with team members you never/rarely see face-to-face.

This is just something from my own little box of tricks that I thought I would share. From my point of view, it makes life with Torque a little bit easier and so it's well worth having.

"Tanks for all the memories"

James Steele — 2006-06-07T20:10:37+00:00

Okay, so I grit my teeth to tackle the network replication this evening.

At first I was a bit baffled by some strange behaviour such as wheels not turning, the engine hanging without explanation after loading a mission etc. But after looking at some of the existing replication code in wheeledvehicle, I managed to solve these issues. Also, sitting on the can (my favorite thinking place) helped too :)

I'm still not sure how I'm going to get around the lack of IFL support in the Blender plug-in though. It would be really nice to have the treads animating, as it would really finish off the very cool looking suspension animation of the tracks.

Anyhow...I plan on starting a resource for implementing tracked vehicles sometime this weekend. I want to create a resource that will work for any clean TGE 1.4 install, so that anybody can use it almost instantly.

But for now...here are some screenshots. They mainly show (apart from my crap modelling and texturing skills) the deformation of the inner wheels/tracks to the terrain. I may buy a license for FRAPS so I can rig an A.I. tank up and show it in motion at a later date.

Troublesome Tanks!

James Steele — 2006-06-06T21:30:37+00:00

IFL's not supported in Blender! I could just write the code and pray that it works for now, but that feels just plain wrong. Oh well...maybe I'll get the network replication done tomorrow, and that I can start preparing an actual resource for doing tracked vehicles in Torque if I have the time.

Still no pictures...feeling very lazy.

PS3 not so broken after all...

James Steele — 2006-06-06T10:17:02+00:00

Before I start with this, I make no appologies for being a firm supporter of Sony's hardware efforts on the PS3. I realise that extremely powerful and complex hardware does not by default mean you'll have a great games. But at the same time, I don't see anything wrong with making advances in this area.

I can deal with all of the anti-Sony sentiment going on right now. I mean, it's only natural. Sony came along almost a decade ago, and changed the games industry beyond recognition. It started a trend towards catering for the mainstream consumer, making video games something cool to play and no longer just the realm of kids drooling infront of thier TV in a darkeneded bedroom.

All of a sudden, it wasn't okay to make niche games. We now had to worry about market penetration, production values, and god knows how many other details we never really had to worry about before. No longer could we make games that we thought would be fun for us to play, hoping that other would feel the same too.

That had been reveresed. Now we had to make games that the lowest common denominator found fun, and hoped that we might want to play them too. All because of Sony. All because of thier push towards main-stream consumerism. Damn them to hell. They've ruined our industry.

So why does it surprise me that I see articles like =http://www.theinquirer.net/?article=32171]this? At a first glance, Charlie Demrjian seems to know what he's talking about. But after a little close inspection, you find that the guy is quite blantantly writting an article based on a knee-jerk reaction. His opening paragraph says it all;

"earlier on the flight to Japan, my row-mate said 'if you think that's interesting, wait till you see this. Cell is hurting, badly'."

At this point, I think it's fair to say that ol' Charlie has already made up his mind that the PS3 is a piece of decicated panda doo. He's shown a slide with some bandwidth numbers on them, one of which is horribly low. So what does Charlie do? Does he investigate further? Does he bother to find out the context of the slide? Does he do his job to invesitgate this fully and report without bias?

Nope. Good ol' Charlie instead writes a sensationalist article titled; "PS3 hardware slow and broken".

Maybe if Charlie wasn't so eager to bash Sony, he would have done some research and found that;

* Sony always refers to VRAM and "Local Memory" when dealing with the graphics chip.
* The 16MB/s transfer speed refers to transfering data from VRAM to Main RAM.
* There are very few occasions when you would actually want to do this with the Cell.
* The RSX provides a nice high bandwidth from VRAM to Main RAM anyhow...so why the need to duplicate this functionality in the Cell? Isn't the hardware already expensive enough?

I tell you folks, I'm getting a little sick of this. I understand people no liking Sony, but c'mon...has it gotten so bad that reporters are now jumping on the bandwagon too?

[/rant]

Getting more tank like every day...

James Steele — 2006-06-05T21:53:12+00:00

Just a quick update on the tank stuff. I'll organise some screenshots tomorrow along with more info as it's a wee bit late for me right now.

Stuff done

* Proper wheel radius and track thickness used in inner-wheel ray-casts
* Maximum ray-cast length take from drive wheel suspension and radius limits
* Inner-wheel rotations match tank movement (speed determined from drive wheels)
* Slapped a texture on the tank, inner-wheels and tank tracks. (as in...I threw a texture onto the model from a distance large enough to have to worry about, wind speed, direction and the curvature of the Earth. The results were not pretty folks...)

Still to do

Network replication
I have a feeling I'll need to reorganise my code a bit as right now, the whole inner-wheel ray-cast and animation is performed inside of ProcessTick, regardless of client/server considerations. I'm not sure what I'll have to change exactly, as the whole network replication business is still a wee bit fuzzy for me.

Track texture animations
Pretty self explanatory. Just need to create, and uses the texture animations as well as fiddling about with speed values.

On a side note...
If it is ever within your power, do not...I repeat, do NOT let me need any 3D modelling software. There's a reason that I'm a programmer and not an artist folks, and you'd be doing the world a big favour if you keep me away from that sort of thing.

Looking at the UV layout on my tank and just the general geometry (especially for the tracks... *shudder*) all I can think is; the horror! the horror!!!

More tomorrow. Sleep now.

Tracked vehicle update

James Steele — 2006-06-01T21:23:03+00:00

Okay, so implementing all of the tracked vehicle stuff is taking me a wee bit longer than I first thought. Not because I'm running into any difficulties, but because I'm feeling a little lazy right now. Work is a bit demanding at the moment, and it is sort of leaving me feeling drained when I get home in the evenings.

But there has be progress! I haven't been completely lazy., only a little bit. :)

Completed Tasks
* New Tracked Vehicle class derived from WheeledVehicle and working the same as original prototype.
* Setup inner-wheel imposters on data block
* Get inner-wheel imposters following the terrain.

Stuff still to do
* Work out which inner-wheel nodes are on the left and right sides
* Properly calculate the maximum extension length of the inner-wheel nodes (currenty a hacked constant)
* Work out the radius of the inner wheels
* Take into account for the thickness of the tracks when animating the inner nodes in code.
* Rotate inner-wheel nodes to follow motion of vehicle
* Track animation
* Network replication for the inner-wheel nodes

The most interesting part of this should be the track-animations. Everything else is pretty straight forward, and I should get most of this done over the weekend (especially as Monday is a holiday here in Austria).

But for now...here is a screen shot (clicking on the image will open a larger version). It shows the tracked vehicle with the inner-wheels following the world. I know it; a little hard to make out detail because of the lack of textures, but I'll probably do something about that this weekend too.

*** edit ***
It would seem that I can't wrap a url tag around an image tag, so you'll just have to click on the link :)

www.whereintheworldisrusty.com/pics/projects/tank001.jpg

A tank! My lego collection for a tank!

James Steele — 2006-05-30T11:40:40+00:00

Actually...never mind. I've got it covered.

Looking back at my older posts, I think it's fair to say that tracked vehicle dynamics have been featuring quite prominently on my posts. I needed tracked vehicles (well..tanks more specificaly) for an idea that I had, so I looked around for a quick and easy sollution.

Like many other people, I found the Brave Tree Tank Pack and decided to give it a go. Despite it being an excellent add-on, it didn't quite do what I wanted. It faked the motion of a tracked vehicle without using any sort of rigid-body dynamics. This was something of a requirement for me, so I decided to see what else could be done.

The first attempt...

Given my previous experiences in implementing vehicle dynamics in games, I figured it wouldn't be too hard to implement some sort of tracked vehicle ontop of the existing vehicle dynamics frame work. I started out fairly well, but about the time I was ready to implement the constraints code for the tracks themselves, I realised that perhaps this wasn't the right way to go about it.

My goal, which I had lost sight of, was to get a rigid-body vehicle that behaved like a tracked vehicle. Not to actually have a proper tracked vehicle dynamics. If my previous experiences had taught me anything it was that; rigid-body simulation does not equal gameplay.

Unfortunately, it was about this time that work started demanding more of my already scant free-time. It was also becoming very stressfull, and the last thing that I wanted to do was to sit down and code after very gruelling 60+ hour weeks.

Then in October of last year, I moved half-way across the world again, back to Europe. The move put a big halt on any free-time programming activities until my stuff arrived in February this year. Up until recently, much of my spare time had gone into setting up a home, work and climatising myself to living with somebody.

Then not long ago, things had settled enough for me to go back to my pet-project....

The second attempt...Rusty has an idea

I started my project from scratch. I was going to approach it in a slightly different manner this time, and implemented some fairly cool things (turrets, dialogs etc.) before I moved onto my tracked vehicles again.

As I mentioned earlier, I realised that I had gone about implementing tracked vehicles the wrong way. So how should I go about it?

Torque already has a pretty good wheeled vehicle tool-set. Although it lacks some features, it's flexible and easy to set-up. The more I thought about it, the more I realised that with a little modification, I could just use the wheeled vehicle class to FAKE the behaviour of a tracked vehicle.

The idea...

The general idea, was that I could just use a wheeled vehicle that doesn't show the drive wheels. That is, the WheeledVehicleTire class used, would not have a shape assoicated with it and would use a radius defined in script.

The inner wheels/tank tracks would just be eye-candy. They would just deform to the terrain, but not provide any actual suspension support or drive forces. Instead, all of those are provided by the unseen normal wheels.

Prototyping...

So I set about prototyping my idea. In order to fake the tracked vehicle behaviour, I needed to be able to do the following.

* Make the rear wheels steer in the opposite direction, at some extreme angles to mimic the turning behaviour of a tracked vehicle.

* Let the wheels have fairly large traction budgets to mimic the "infinite traction" that caterpillar tracks seem to have.

I was more interested in prototyping the driving behaviour at this point, and not how the the candy would look. Besides, I was fairly confident that any problems with the eye-candy could be gotten around quite easily.

So I modelled a quick tank like shape with normal hub nodes in Blender, and exported it to Troque. I then created a new class called TestAPC and added it to my mission.

My first test went okay. The steering worked as intended with no source alterations, but it just didn't feel like a tank. It would slide around too much when turning, and it had very little traction when climbing or braking.

I spent the better part of two hours messing about with the traction, power, suspension and other settings in script. All of a sudden I had something that behaved sort of like a tracked vehicle, and with no source changes!

It had some issues with control though, as the wheeled vehicle class uses the pitch/yaw inputs for steering and acceleration. I wanted the wheels to instantly steer to the left or right if the appropriate key was pressed and center themsleves if the key had been released.

A quick hack in the wheeled vehicle class did the trick for that. So now I have an extremely fun "tracked" vehicle running around my test missionm using rigid=body dynamics.

It has one or two minor issues though;

* The vehicle jitters for a few seconds when it comes to a rest - This has somethig to do with the extremely large forces I use on the drive wheels. I think I probably have the traction dampending term a little too low at the moment, as it looks like a spring system that is osscilating a little until it comes to a rest.

* [i]The vehicle can become "hung-up" on edges. Despite having eight wheels, they're a little far apart, and if the vehicle drives slowly over and extreme edge (i.e. the ramps used in the racing example) it becomes stuck. There are several sollutions to this problem;

1. Have more wheels that are closer together.
2. Implement a moving sphere routine instead of relying on a ray-cast so that I'm checking for contact on the entire radius of the wheel, instead of a single contact point below the wheel center.
3. User bigger wheels

What next?

Last night, I started rigging my tracked vehicle for the track/inner wheels. It's exported into Torque and works just fine with my existing source.

So now I have to create a new class derived from WheeledVehicle which will also deform the inner-wheels with the terrain. I also need to remove my debug wheel geometry which was used for the drive wheels, so I could easily see what was going on with the drive forces.

This should all take a couple of evenings, girlfriend allowing.

I'll post some screenshots when I have more to show, along with another update in my progress.

turrets, turrets and more turrets...

James Steele — 2006-05-19T07:51:32+00:00

Rantings and ravings...

It would appear that even with a nice fast computer, I'm still pretty woefull when it comes to finding time to work on my own projects. A relationship and the stresses of working in the big bad games industry sort of leave little time and little enthusiasm for coding in the evening and weekends.

But that has sort of changed. I'm still in a relationship and still stressed at work, but I have my enthusiasm back. I actually feel motivated to get stuff done in my own time, and tackling parts of Torque that before seemed intimidating is now a fun challenge.

In the last week or so, I've achieved a lot given the time I've spent working on stuff. I've finaly gotten my head around the scripting language (typeless languages can be confusing for us good ol' coders who know the joy of writting self-modfying code in 68k assembler), I've gotten my head around the GUI framework, as well as querying the simulation.

So what have I done exactly?

Gotten familiar with blender

This is a big thing for me at the moment. I had a colleague and friend who said he would help out with concept art, as well as modelling & texturing. But he had to drop out because of work pressure (given that we work for the same company I can understand this) as well as his desire to work on his own stuff.

So...I made programmer art! It's amazing what a couple of boxes stuck together can represent if you imagine hard enough ;o) I can model, texture and rig geometry now, not to mention gettng to grips with the export process.

Implemented turret emplacements

I found a turret resource by Paul Dana here on GG about implementing turrets in Torque. It served as a guide as I went about implementing my own version, helping me learn a LOT about the low-level (cpmpared to script code) workings of attaching to control objects, netowrk replication and a whole load of other things.

This used a skinned and textured turret model I had built in Blender.

A big thanks to Paul Dana for the Turret Tutorial, which is as relevant now as it was three years ago when he released it

Unit selection dialog

I got to grips with the GUI stuff. Over the space of three evenings (about 9 hours work in total) I had created the dialog resource from scratch and learning as I went, written the interaction code in Torque Script (becoming more competant working in TS as I went) and also got the dialog working as intended.

As long as objects are added to a specific set of SimGroups, I can now switch player control to any selected Unit in a mission.

Stuff still to do...

* Check to see if a selected unit is in use by another player via the server
* Work out how to spawn an object to a specific SimGroup
* Build a better APC stand-in model (the current one sucks big time...that's programmer art for you)
* Check out the cost of one or two art houses...
* Implement the weapons for the turrets, as well as mountable objects for the APC

Back from the dead

James Steele — 2006-02-02T08:47:34+00:00

With my PC arriving yesterday, it looks like I'm back in business. It suffered a broken side panel in the move though, but after letting it warm up a little for the condensation to dry up it booted up first time! All I have to do now, is get used to the German keyboard.

I guess I'll be making a proper start on the tracked vehicle code this week, girlfriend and weather permitting. I promised quite a few people that I'd make a start and share the source when I had something before Christmas, so I feel bad for keeping them waiting.

I guess that's it for now. Some of us have to work for a living :)

Thursday Dec 8 18:31

James Steele — 2005-12-08T18:31:26+00:00

How tank-like is your tank?

It's pretty interesting to see how may people were interested in my previous plans on implementing proper physics for tracked vehicles, especially tanks. Sadly I don't have my old source because, as I mentioned previously; my PC is somewhere between here and Australia.

But all is not lost.

I'm in the process of re-implementing my tank-physics code, albiet in a slightly different manner. I may turn this into a resource in the near future but for now, the code is only available upon request. That is, once I actually get it running. I'm writting it as we speak, but my laptop is so slow at building the Torque code so it's taking me a wee bit longer than I would like.

There's nothing running yet...but there will be soon, and I'll show some screenshots when I have anything to show :)