I finally finished my basic scene graph, which loads from external text files. With it you can set which meshes to use, where to put them in 3D space, and what textures to load. Finishing that, I decided to tighten up the graphics a little bit. So I added lighting and a simple specular material that made the models pop. Nothing very awesome but getting there. Right now I’m learning how to write shaders in HLSL.

With this experience, I plan to make a game out of it, simpler than Roll ‘Em Out. It will likely be a Bomberman clone, just small enough to complete it in a reasonable amount of time…I’ll give myself a few weeks to finish a playable version of it.

This game still has quite a ways to go before it’s released, but I’ve played a recent demo and there is a lot of good potential in this game. Mixing in elements from Bionic Commando and World of Goo, Squishy lets you take on the role of a roundish blob with two arms that can extend in any direction. These arms let you stick on to almost anything. You can use each arm by pressing either of two keys on the keyboard, and aiming where you want your arms to go is as easy as clicking a spot on the screen. Being a squishy blob, you can also roll around along the floor or make short hops when your arms are not needed.

The latest demo of Squishy is still very early in its development stage but it already is very playable. Even though it only includes one small stage with no actual goals, the controls feel solid enough to make it very fun to play around with. The physics in the demo are also very good, giving a good sense of weight and inertia as you navigate through the level. Your character’s movement is definitely more fluid and less stiff than in Bionic Commando. I was able to cover long distances quickly Spider-man style after a few tries with the controls.  There are blocks scattered around the world that you can grab and throw. You can even pick one up while swing with your other arm, and the added weight of the block will reduce your mobility.

The gameplay is already there- it just needs needs the “meat” to make it a fully featured game. Aardvajk has been using a custom level editor to work on many levels and add new obstacles, and considering it’s all programmer art it doesn’t look too bad. The internals are already in good shape, and all that’s needed are a few coats of polish to make it really stand out from the rest of the platformer pack.

Three cool new things about this screenshot- First, the loading times are much faster. I replaced the slow vector insert() function with the much quicker why-didn’t-I-use-it-before push_back() function. Second, there is actual lighting (and therefore shading) on the models, so complex shaders and HDR can’t be too far along Finally, I’ve been logging some of the events happening on the screen such as the mesh and texture files present in the scene.

The process

At first, I thought of simply giving each model its own storage space for meshes and textures, but that would be too wasteful and the lazy way out. Each file would have to be loaded multiple times if several models used the same mesh or texture, increasing load times and memory usage. I’ll explain in some detail how I went through the process of building the scene system, but by no means is it a tutorial. As I still have a big learning curve ahead of me, some things may not be applied in the best way. So here’s how I started out with the solution:

class Model {

    private:
	WorldTransform _Transform; // Matrix transformation
	CVertBuffer* _Mesh;
	TextureResource* _Texture;
	std::string handle;

	bool _transformSet, _meshSet, _textureSet;

    public:
	Model::Model(std::string m_handle);
	Model::~Model() { }

	void setTransform(WorldTransform&);
	void setMesh(CVertBuffer*);
	void setTexture(TextureResource*);

	// These check if resources are set to null values or not
	bool transformIsSet();
	bool meshIsSet();
	bool textureIsSet();

	// return the objects
	WorldTransform WTransform();
	CVertBuffer* Mesh();
	TextureResource* Texture();

	void cleanup();
};

Each model has a single pointer, whose object it is pointing to can be changed at any time. As implied before, this allows different models to share the same resources. The program loads the resources from a simple text file so no need to recompile when you need to add or remove more. Since resources are shared, it can be a good setup for limiting yourself to a fixed amount of models when you’re positive that you won’t need more… resources can then be swapped when the context of the model changes.

Models also have a string type to store a “handle”, a unique way to identify them by name. Currently my scene graph system can’t access them by this handle, instead using the numerical order in which they’re stored in an array. This is working fine for now, but for more complex scenes it would be better not to try to memorize a number for everything.

One thing to note about this class: the WorldTransform object is not a pointer. I made it so because I couldn’t get the transformations to work if they were passed by a pointer. This is something that’ll have to be looked into.

A SceneManager object is in charge of the high-level creation and rendering of a scene (and no, I didn’t take the name from Ogre3D). It is here where the scene’s resources are actually stored. There are several vectors each dedicated to store a certain type of resource, including models. Models then borrow from the resource pool. As information is read from the text file, the SceneManager adds the proper files to the resource pool, and then the resources are assigned to models.

void SceneManager::addMesh(CMesh &_Mesh) {

    CVertBuffer _VBuffer;

    if (_Mesh.primitivesFound()) {

	// functions for setting up vertex buffers
	_VBuffer.createVBO(*D3Device, _Mesh.verts().size(),
	D3DVERTEXN::FVF, sizeof(D3DVERTEXN));
	_VBuffer.setData(_Mesh.verts());

	// Add attributes to list
	VBOList.push_back(_VBuffer);
    }
}

void SceneManager::addTexture(TextureResource &_Texture) {

    if (_Texture.isSet()) {

	TextureList.push_back(_Texture);
    }
}

void SceneManager::assign(unsigned order, unsigned tID, unsigned mID) {

    if (order < ModelList.size()) {

	// Let's avoid going out of bounds, shall we
	if (tID < TextureList.size())
	    ModelList.at(order).setTexture(&TextureList.at(tID));

	if (mID < VBOList.size())
	    ModelList.at(order).setMesh(&VBOList.at(mID));
    }
}

The first two functions are examples of how scene resources are added. They start with a simple check if information has been properly loaded to the object. For a TextureResource object, it’s a texture image. The Mesh object is a little more complex since it stores a set of vertices to be added to a vertex buffer (one of the ways that DirectX renders polygons to the screen).

The last function is an assignment of a texture and a model from the resource pool to a model already on the list. Here’s where you can see that I am just using numbers to identify everything. Eventually it will be replaced with finding the right objects by a handle. When I make the switch from number IDs to handles, accessing objects would go from O(1) time to O(n) time but it’s a reasonable price to pay for some much needed simplicity.

It’s a straightforward system and it’s not without its setbacks. But it should be able to hold up well for creating not-so complex scenes, as there are no other efficient rendering techniques in place like quadtrees or spatial relationships. Animating a lot of things is also not a big concern for me now.

I know that there are .x files made specifically to work with DirectX (and they carry much more information than vertex, normal and texture coordinates) but .obj files appear already suitable for adding static, non-deformable models. They are just loading far too slow for practical real-time uses, such as loading entire levels from a game. So I have already thought up some ways to create a binary file format that stores the same information as text from an .obj, but in a more concise manner.

Some screenshots of my newbie-ish model viewing program show its strange variation in loading times.

The first model I tested was a character model of Hsien-Ko (from Darkstalkers) that I made two years ago. This file is 95kb in size. Loading a low-poly version of the character took almost 0.4 seconds. Still quite slow for a single mesh totalling less than 1,200 polygons.

This model of a half-finished body of a Shelby Mustang (also made by me) took just over a second to load. It is roughly 238kb in size.

It’s also important to know that the loading times are not the same everytime the program is run, so these two examples are just approximations. Doing some quick math with these time measurements, we can assume that the program can read 2,670 polygons per second.

However, it’s not as simple as that. The file structure of an .obj model contains the coordinates of unique vertices and indexes the polygon faces by the vertex numbers. Which means that a model with 300 unique vertices will almost always have more than 300/3 triangles, as many vertices are going to be shared. This means most of the overhead of reading the file is involved with the longer lists of indexed polygon faces.

Everything the program reads is taken as a string, and then converted to appropriate numerical types. My guess is that this is the second most time consuming process for parsing the file, next to reading all the lines. Reading raw bytes with less conversion would be quite faster. Not sure by how much, but if the new file were reduced by only half of the original size, loading times could be even less than half as long as what they are now.

This idea of a binary version of an .obj model is not something I plan to take on just yet, nor do I think I’m the first person who has thought of it. But when I get into the serious stages of making a game I’ll have to figure it all out.

I decided to take a short break on Roll ‘Em Out and learn some new things. Programming on a Mac was a refreshing experience, and XCode was really easy to use. And if you don’t want to use XCode you have your Terminal command line too in all its Unix-y goodness. Porting the game from Windows was a snap, thanks to Mac frameworks that already exist for SDL, and graphics running on OpenGL. This is where I was working on my game for the past month, but after being burned out by a lot of physics testing I decided to give it a break.

Additionally, I started to miss working on a Windows environment, as crazy as that sounds. Well, the actual reason I wanted to go back was to learn DirectX. This topic at the Chaos Rift forums got me interested in trying it out. See, if OpenGL 3.0 is heading towards more of a rehash of its older 2.1 implementation and the OpenGL ARB is not listening to the professionals in the game industry, might as well try the alternative as sort of a safety net. Code::Blocks IDE (what I typically use) and DirectX wouldn’t make the best combination so I installed Visual Studio 2008 Express. So I continue to code but back on a different platform, on a different IDE and a different graphics library.

Back to the progress that I’ve made: DirectX was a struggle to learn in the first two or three days but after that it was all like picking up familiar concepts in new ways, and quickly got accustomed to the debugger tools that came with MSVC++ (a real time saver). That is not to say I didn’t encounter any major problems. Here’s how the 9 days panned out, to the best of my memory.

Day 1

Downloaded and installed MSVC++ and the DirectX SDK. Played around with the SDK demo programs. Then went on to GameDev and Two Kings to read some basic tutorials.

Day 2

Looked at more tutorials and samples. Started copying my game state engine code that I use in Roll ‘Em Out and a few other projects. Got the game code with SDL (without graphics) running soon after correctly linking. I now have a fully working environment I can use in Visual Studio. Cool beans.

Day 3

Frustration begins. Trying to integrate the Win32 API to replace SDL was not very successful to say the least. It’s very verbose and also has a separate block for callback functions that didn’t know where I would place in my StateManager class. Screw it, I’m going back to SDL. On the good side, I figured out how to place a Direct3D device in each game state, so switching states made the window change background colors.

Day4

Basic polygon rendering and learning how to use vertex buffers. At this point I replaced the OpenGL code of my Display class with some DirectX code. Vertex buffers are very important for DirectX, as it doesn’t have an “immediate mode” like OpenGL does.

I was also learning how to apply textures, but I noticed that changes in the code somehow didn’t change anything that was displayed since the last crash. It was like the image was stuck in video memory. I’m sure I didn’t make some function calls correctly.

Day 5

More frustration. This DirectX thing is like jumping into a stick shift Mustang after being used to automatic most of the time. I really have to manage the resources well, because my test program must have crashed at least a hundred times that day.

I ported my simple polygon-rendering script reader (it basically takes a text file that contains endpoints for quads) and started seeing “phantom” shapes. Anything more than a few boxes on screen and the program crashed when I switched game states or quit. Some “safe release” functions helped stopped the crashes on quit, but it was still unstable.

Day 6

Despite the setbacks, I figured I got the basic texturing code right. I just sucked at cleaning up resources. Worked on a SceneManager class to make the rendering commands a bit more fluid, however that would be explained in a future post.

Tried to import some old code I made to parse an .obj model file. This was haflway done- the least I could do is render just the vertices and vertex colors. It worked with a simple cube, but when I attempted to load a character model I made myself, it crashed at startup.

Day 7

Here I decided to make loading an .obj file my first real goal for a DirectX program. Made some debugging messages to help me out. They were in the form of annoying alert popups so I couldn’t really use them in loops. However I learned that the model was loading fine, but the program refused to render it.

Day 8

Found the problem! It was in the DrawPrimitives function. The debugger couldn’t catch it, but I entered one of the variables wrong. The variable tells the program how many primitives to render from the buffer. I used the number of vertices as the variable. Well, since I was using triangles and there are 3 vertices per triangle, I was making the program render three times more polygons than it should. This made it search out of bounds for the buffer, stopping the program. Now I think I got how to drive stick shift. Pretty soon I’ll be able to try something supercharged.

Day 9

My .obj loader works, and added SDL input functions in order to make the model spin or zoom. Still have to figure out the best way to use matrix transformations, as I can’t get them to work independently more than one model at a time. Also added lighting code from a tutorial. For a while I was seeing a blank screen but realized I didn’t set the vertex format to include normals. It’s all fixed now.

I guess today would be day 10. Nothing really in progress today, as I wanted to get on the more creative side and make/export a few 3D models, and test them out with my .obj viewer. Also, there’s a lot of stuff that went on behind the creation of this program. I wanted to make my rundown of the past nine days as brief as possible, but my involvement got more intense as the days went on.

So what’s next for me? Probably explaining the .obj viewer in more detail, and some of the procedures I used. Then take my viewer to do something more useful like loading a simple game world. Who knows if the next week will be as productive as the last…we’ll just have to wait for that.

Keep in mind that this video is over a year old. Also, I stopped working on it shortly after making this video, and didn’t start again until last month. Things that have changed since the making of this video:

• Better collision detection (had to basically re-write a lot of code and remove some junk code that wasn’t doing anything at all)
• More realistic reactions to landing/bouncing on slanted surfaces
• A simple level loader that reads text files to draw polygons and load textures

Right now work on the game is on hold again, but only because I want to get back into learning a better way to write code to render graphics, and copied a lot of the code for a small “sandbox” program to test out physics. When I get the physics down to a satisfactory point, I will port that code back into the game.

A bit about me: I’m Chris, known in some parts online as CC Ricers, and currently work as a contractor for a web development company. My work is for the most part technical, and I have also gotten involved with learning and programming in C++ in my spare time. Besides typing away on my computer, I also DJ as a hobby and have a growing collection of drum & bass and house music.

I also maintain GameSnooper, a little website I built as an experiment. Right now, it’s nothing more than a portal to a random assortment of daily video game news. But when I get to work on some new features for the site, I’ll let you know here.