SQuba Car??

Bond...James Bond.

It's awesome yet crazy. The new submarine car is out. A car that drives on land and underwater.

Just make sure you are wearing your freshly tailored scuba suit before you decide to take a nice midday dive. :)

WHERE'S MY TELEPORTER???

Texture Cache

I created a texture caching system that separates the region definitions from the requesting a region. Below is a code snippet of it in action.

XmlDocument xml = new XmlDocument();
xml .Load("textures.xml");
TextureCache tc = new TextureCache<Texture>(xml, new CustomTextureBuilder());

The TextureCache object takes in XML and a TextureBuilder to load the textures appropriate to the application. The XML defines the regions within a texture. The TextureBuilder is an application specific object that performs the conversion of the XML data into the right Texture format. For example, in my Pong remake I am using XNA so my TextureBuilder converts the XML data into a Texture2D object wrapper.

The XML file is pretty straight forward, see snippet below. Each texture node has a collection of region nodes that define a portion of the texture that can be used in rendering. Each region is given a name that is used as a key in the texture cache.

<textures>
 <texture name="textureName">
  <region name="regionName" x="0" y="0" width="64" height="64" />
 </texture>
        <texture ...>...</texture>
</textures>

The power behind this interface is it's retrieval mechanism. Basically you ask for what you want.

Texture t = textureCache["textureName"];
TextureRegion tr = t.GetTextureRegion("regionName");

You just ask the texture cache for a texture, then ask the texture for the region you would like to render. It's that simple. Another powerful piece is the system relies on Generics so each application can have the texture cache provide application specific textures.

In the future I am looking to build a UI to create the XML definition file to simplify that process. Will keep you posted on the results of that endeavor.

Stay easy.

Announcing my XNA game dev library

So, I am at it again. To learn how to use XNA I've decided to create a little game dev library using XNA as the foundation. For more information on XNA visit this link.

My first project will be a variation of Pong. Here is a link to a screenshot of the main menu. Pong is simple and something I know how to make. My plan is to use it as proof of concept for the ideas I will be implementing in my library.

Currently, I have a basic rendering and input system. At the moment the rendering system wraps XNA, but my input system provides the ability to map input responses to any kind of input type (i.e. keyboard, mouse, gamepads, etc). The menu system currently utilizes this feature.

I will post code examples once I have more done. I am will be providing significant test coverage to ensure a clean and solid set of interfaces. Stay tuned.

Fathering 2...piece of cake?

I had assumed it would be easier to be a father to my second child. Interestingly I have been awakened by reality. Deep down I know it will be fine, but that doesn't stop me from wondering if I will be good enough to father two children.

I guess only time will tell.

Seeing my unborn child move and interact with us in the ultrasound was so fascinating. She has so much energy. I'm filled with so much joy when I feel her react to me poking the walls of her current home. That justifies these ridiculous feelings. All I want is to be the best Dad I can for her, and that she is assured by that.

Awaiting the life lessons she has in store for me.

April 24, 2008 my walk with Simone begins...

Good Programming Books

Just wanted to link a couple of books I think are must haves when coding.

Interface-Oriented Design

Refactoring


OOH OOH EEH EEH

Performancing

This a test post. I am creating this post from within Firefox. I am really loving this browser. It supports everything and is so extensible. I just found this extension ("Performancing") that allows you to post blogs from the brower. Sweet!

powered by performancing firefox

Never fear, boost is here!

I don't think I provided the link before to the Boost library, but here it is: http://www.boost.org.

I successfully used the unit test framework to test the initial version of the config file system for Block Drop. It was a cinch to setup and get running. With the test framework working, I should have more confidence to get new features out. Although, I am curious about how I am going use the unit test framework to test some of the graphics related systems. I am also wondering if there is a decent mocking toolset for C++. This would definately be a big plus so I can test the communication between the system interfaces. Looks like it is time to do more research.

Anyways, the config system was a breeze to get going. It is built ontop of the boost::program_options library. Boost does all the hard work. It provides all of the parsing/storing functionality in just two step:

1.) Define the option-value type pairs
2.) Parse the values from the config file

Here is a simple example of using the boost::program_options library.

...

#include 
namespace po = boost::program_options;

po::options_description description("Config File Options");
description.add_options()
   ("myOption", po::value<int>()->default_value(5), "My type of option")
   ("mySecondOption", po::value<std::vector<std::string>>(), "My second type of option")
   ;

po::variables_map map;
po::store(po::parse_config_file("configFile.cfg", description), map);
po::notify(map);

And that is all there is to it for loading the contents of a config file. Then whenever you need a specific value you just reference it through the map like this: map["myOption"].as(). The overloaded () operator makes it a breeze for organizing and adding options to the the list to be parsed.

The Monkeyboy Framework wraps this interface into its Configuration class which is meant to overriden by any system that uses the framework so that each new application can define its own configuration file and option-value pairs.

So Block Drop has a class called BlockDropConfiguration that inherits from the Monkeyboy Framework Configuration class. Here is how it defines its configuration file and option-value pairs:

BlockDropConfiguration::BlockDropConfiguration()
   : Configuration(std::string("blockDrop.cfg"))
{
   this->optionsDescription.add_options()
       ("title", po::value<std::string>(), "Title of the application")
       ("width", po::value<int>()->default_value(800), "Width of the application window")
       ("height", po::value<int>()->default_value(600), "Height of the application window")
   ;
}

Now the main Block Drop class owns an instance of the BlockDropConfiguration class and uses it to initialize its subsystems. Here is a sneek peek at it initializing the graphics subsystem.

...

class BlockDrop : GameDemoApplication
{
   BlockDrop::BlockDrop() {
       configuration.parse();
       configuration.loadGraphicsProperties(graphicsSystem);

       ... //Add more subsystem initialization calls
   }

   ...

private:
   BlockDropConfiguration configuration;
   Graphics graphicsSystem;
};

I decided on this approach since the configuration class is specific to the application so it should know what the graphics system needs to be initialized. I figured at the time of creation this appeared the be the easiest approach. I am open to input on this as well if anyone has any thoughts on a different approach.

OOH OOH EEH EEH

Boost Library Unit Test Framework

Alright, I know I have been away for a long while, but I'm back. And once again, so is Block Drop. This has been a project of mine that has been in development for a long time. It has experienced numerous architecture and platform changes. Mostly because of my interests changing so frequently. But that's okay, because it gives me a reason to learn something new.

Since we employ XP practices at work, I wanted to encorporate some of those practices to my Block Drop project. The first I intend to use is Test Driven Development (TDD). My first task was to find a good unit testing framework for C++. I narrowed the search down to CPPUnit and the boost::unit_test_framework. Both appeared to lack the ease of use as some of the Java test frameworks, but they seemed the easiest to get going and work with from my perspective.

I am thinking I will choose the boost library version because I intend to use the other features the boost library offers (i.e. smart_pointers, program_options, and possibly others). This will also bring the number of included libraries down.

OOH OOH EEH EEH

Updates

Lights! Camera! Action!

Okay, the camera system is almost complete. I am working out some of the jerkyness in the movement of the camera. There are two types of cameras: Basic and Player. The basic camera provides the basic orientation operations on a camera, such as, pitch, yaw, roll, and move. The Player camera is broken up into three different cameras: First Person, Third Person, and Spacecraft. All Player cameras are attached to a player object. I will elaborate on each camera once the system is complete...so stay tuned!!

Do you see what I see???

I simplified the interface of the graphics system so it is much easier to get DirectX up and running. The graphics system manages the DirectX interface and device as well as the MBLib graphics renderer. Each of these components are accessible through this system.

That is all for now. Once the camera system is complete, I plan to update the terrain demo adding a dynamic camera that switches between the different camera modes. So, I'll see you then.

OOH OOH EEH EEH

Errors

Let me know if you come across any errors when running the demos. That way I can make sure the system is as stable as possible. It should be, I test the systems before uploading them, but you can never do enough tests... Thanks in advance.

OOH OOH EEH EEH

Dynamic Vertex Buffers

Here is a screenshot of a demo application I created to show the new dynamic features of the vertex/index buffer interface. It displays a patch field the uses a sine wave to calculate the new positions of each vertex on each interation of the application loop. The effect is a rippling effect from the center of the patch to the end. Also, the red diffuse color is adjusted to become more intense at the high wave peak and less intense at the wave down peak. All of these effects are scaled by time to create a smooth animation. You can enjoy the demo by clicking here

I have modified the vertex/index buffers to support both static and dynamic propertics. The demo above show the nature of using dynamic vertex buffers. This allows the client to modify the vertices in the vertex buffer at any time. There are two conditions to be aware of, an overwrite vertex buffer and a nooverwrite vertex buffer.

The overwrite vertex buffer will discard the vertices in the vertex buffer and write the new vertices starting at the beginning of the buffer. Since the Graphics Processing Unit (GPU) will be expecting this to occur, it will return a new pointer into the buffer for the client to add vertices to and then discard the previous vertices.

The nooverwrite vertex buffer will only return a pointer to the available space remaining in the vertex buffer to add the new vertices to. The catch is, if there isn't enough space to add the new vertices, then the vertex buffer will move into overwrite mode and will function like an overwrite vertex buffer. The vertex buffer will return an error when this occurs to let the client know it is no longer protecting the original vertices. This will give the client an opportunity to either continue rendering without crashing or to recreate the vertex buffer to add more space to it. The best approach when using a nooverwrite vertex buffer is to check for enough space before adding the vertices.

Also, to run the demo your video card must support the use of dynamic vertex buffering. The demo doesn't use extensive error handling. I will update the code to be a bit more user-friendly, but its main purpose is to demonstate the use of the Dynamic Vertex Buffer interface. Enjoy!

That's all for now...I am coming with more updates, so stay tuned!

OOH OOH EEH EEH

Terrain Demo is here!!

Okay, it is here as promised. The screenshot is of the initial version of my terrain class (MBGraphics_Terrain). It creates the terrain based on values in a height map. The height map is broken up into sectors to provide optimal performance pushing vertices down the graphics pipeline.

The lighting in the screenshot is simulated. That will change once I get the DirectXGraphics lighting system operational. Also, the camera is locked at that angle. That will also change. I am currently working on the camera system to provide a player control camera under different perspectives. My next post will provide more information into the design of that system.

Enjoy this screenie for now...it's time to feed the monkey's belly!!! OOH OOH EEEEH!!!

OOH OOH EEH EEH

Vertex/Index Buffer Demo

Okay, it is time for an update on the MBLib. I am currently working on the mesh interface of the MBGraphics component. I have created a simple mesh interface (MBGraphics_Mesh). Its purpose is to manage the locations in the vertex and index buffers of where an objects data is stored. This works well with batch loading and rendering of mesh objects. The idea is to be able to sort mesh objects by the vertex buffers they reference. This way when the renderer loads a vertex buffer all mesh objects that reference that vertex buffer and are visible by the camera will be rendered at that time. This will increase rendering performance because vertex buffers are not being switched out frequently causing the rendering pipeline to stall.



Above is a screenshot of a demo that shows the use of the mesh and the vertex/index buffer interfaces. It displays two mesh objects, a cube and a prism, and rotates them on unique axes. The vertices and indices of each mesh object share the same vertex/index buffers. Each mesh stores its location into these buffers so the render knows how to draw them to the display.

There is still some work that needs to be done with the mesh interface. There will be a high level manager that manages all mesh objects needed by an application. The idea behind this is to have one mesh be used by multiple objects. This is often referred to as "instancing". This cuts back on the memory usage because each object references a single mesh in memory.

Also to be added are some utility operations for loading mesh model formats such as 3DS, OBJ, and Milkshape3D models. I am still debating on coming up with a universal format that converts those formats into a proprietary one, or just relying on those. I am not totally sure of the pros/cons of either decision, but I will keep you posted after I do more research.

Also, the terrain interface is still being designed. I will post a description of the interface and a demo once that is completed.

Well, that's all I have for today...back to the lab

OOH OOH EEH EEH

I added the vertex/index buffer interface to the MBGraphics component of the MBLib library. It is divided into two sections: pools and buffers. I wanted this interface to be very simple at getting up and running while maintaining high standards in performance.

Pools

There are two pools: MBGraphics_VertexBufferPool and MBGraphics_IndexBufferPool. The purpose of the pools is to have a central location for managing the existence of and access to the buffers needed by an application. The client is able to interface with a particular buffer through the buffer's id. All buffer ids are supplied to the client when they are allocated in the pool. From there it becomes the responsibility of the client to organize and manage them.

Buffers

There are two buffers: MBGraphics_VertexBuffer and MBGraphics_IndexBuffer. The vertex buffer is used to store vertex information about a mesh object. The index buffer is used to reference vertices loaded in a vertex buffer describing how those vertices are supposed to be connected. A vertex buffer can be used without an index buffer, but it is highly advantageous to use an index buffer to cutback on the memory usage. Index buffers must reference a vertex buffer (at this point in time) in order to be used by the renderer.

Another important advantage is all buffers take advantage of the Direct3D Managed Pool system. This take the responsibility of having to recover lost vertex data during lost device situations. The disadvantage is because Direct3D maintains a system copy of the data, the memory use is doubled. I chose this route because I wanted the use of this system to be simple, and one less thing the client has to worry about is a big plus to me.

Conclusion

This system is still a work in progress, but I am very pleased at its current state. It is fast and very simple and flexible to use. Once the MBGraphics component of the MBLib has been completed, i will provide a series of brief tutorials on how to use it. I speculate this component being the largest out of all the other planned components. Stay tuned! There is plenty more to come...


OOH OOH EEH EEH

MBGraphics Library

Alrighty! My MBGraphics library is in development now. I have very big plans with this portion of the MBLib. Currently I have created a simple renderer and vertex buffer interface.

Currently the renderer clears the display to the desired clear color, activates a vertex buffer, and renders basic primitives (points, lines, and triangles).

The vertex buffer interface creates a static buffer of vertices. The interface is setup to be extended into a dynamic vertex buffer to allow the client manipulate the vertices. At present, you can add vertices to the vertex buffer just as long as the buffer hasn't reached its maximum capacity. The idea I have behind encapsulating the Direct3D vertex buffer interface is to aid in batch loading of vertices. I want it to be able to load all vertices that use the same Flexible Vertex Format (FVF). This will help performance when rendering mesh objects because we can sort the objects and render them all at once without having to reset the stream source for each object.

I am also desiging a VertexBufferPool interface to manage a number of vertex buffers. I want this to extend over to the mesh loading interface as well. The idea is that each mesh that shares the same FVF will manage an ID to the vertex buffer provided by the VertexBufferPool.

Also, the main graphics querying interface is being designed. That will allow a client to query the number of video cards attached to the system and theirhardware capabilities. It's priority will be to manage both the main Direct3D interface and Direct3D device.

Once those interfaces have been completed, I will post a sample application using the components of the MBLib (MBApp, MBWin, and MBGraphics). That's all for now, so stay tuned for more updates.

OOH OOH EEH EEH

Monkeyboy Library

What is MBLib?
MBLib is a Win32 library that helps simplify the process of making graphics and game demos. Currently there are two modules available: MBApp and MBWin.

MBApp provides a base application interface that organizes the process used for each demo applicaton. MBWin provides a basic window class to get a simple Win32 window up and running with minimal effort. Together, they make it a cinch to launch a basic Win32 application with a functional window. Below is an example of a simple application that uses the MBLib:

// BEGIN demo.cpp

#include "MBApp_application.h"
#include "MBWin_window.h"

class DemoApp : public MBApp_ApplicationInterface
{
public:
    DemoApp(HINSTANCE inst_) : MBApp_ApplicationInterface(inst_){}
    ~DemoApp(){}

    virtual bool DoInitialize()
    {
        if(m_win.Create(string("Demo App")))
            return false;
        m_win.Display();
        return true;
    }

private:
    MBWin_Window m_win;
};

// User-defined factory method definition needed by the MBApp library to create the
// appropriate application interface.
MBApp_ApplicationInterface* CreateApplication(HINSTANCE inst_)
{
    return new DemoApp(inst_);
}

// END demo.cpp

And that is all there is too it. That program there will create a basic Win32 window that has a caption bar, minimize, maximize, and close buttons and also the ability to use the ESC key to terminate the program.

The goal of MBLib is to make this process simple, with extra emphasis on "SIMPLE".

How can I get it?
MBLib can be downloaded from here. Once downloaded, unzip it to a desired location keeping the file structure intact. The include directory houses the necessary header files needed for compilation, and the lib directory houses the necessary library files needed for linking.

What's to come...
In the works is the graphics and input libraries. There progress will be updated here on the site when they become available. Presently, the idea, since the target platform is Microsoft Windows, is to wrap the DirectX API into a simple to use interface to launch application more effectively and easily. So stay tuned for more to come...

OOH OOH EEH EEH

Block Drop

Okay, I know, it has been a grip since my last post, but I am back. I have spent enough time hiding behind the excuse of organizing my life when I was really playing City of Heroes. Great game!!!

Anways, I am at work right now, but tonight I will provide some updates. I have updated the Block Drop treatment and am reorganizing the design document to describe the new features. I am even more excited about the game with the addition of the new design directions.

Ultimately, once I get the majority of the design done, I will start recruiting teammates to help me complete it.

Well, stay tuned for my post later.

OOH OOH EEH EEH

Champion of Truth and Justice

I know, monkeyboy has not been in the tree for sometime now! Well, I don't think any of you would either if you had your own copy if City of Heroes. I mean, the citizens of Paragon City are quite demanding, but it is a pleasure serving them. Below are some screenshots of my latest Halloween Adventures. Big ups to the City of Heroes dev team, fantastic job on the new updates.

Enjoy!

	Trick or Treat Ambush Pic #1
	Trick or Treat Ambush Pic #2
	Costume Upgrade
	Archvillian Dr Vahziloks getting mind zapped

OOH OOH EEH EEH

Back to the grind

Well boys and girls, I am back to the grind. This fall quarter is now under way! Boooooooo....

There has been a lot that has happended these last two weeks. I will post much more later today on some of those happenings. Right now, class is about to begin.

So long!!

OOH OOH EEH EEH

And it all comes to an end

Ahhh! I am so ready to enjoy the end of this quarter. I can now concentrate a bit harder on "Block Drop", work on my bowling swing, and just max out with my wife and daughter. Man, this is a much needed time to just RELAX.

Just as a heads up, you may not hear from me for about 2 weeks. Monkeyboy is gonna climb up the nearest tree and snooze.

So I will see you all upon my return! Peace out!

OOH OOH EEH EEH!