The first, titled "Three Big Lies: Typical Design Failures in Game Programming," puts forth that many of the biggest issues we face as programmers is of our own design. Essentially, we are guilty of over abstracting and over modeling.  They argue that since all programming boils down to data transformations, we should just focus on the data.  "World Modeling" may be a nice way to ease new programmers into the field, but it is not necessarily the most efficient approach.

The second presentation focused on a design paradigm that I have worked very hard to create for many of my own projects.  "A Dynamic Component Architecture for High Performance Gameplay," essentially lays out a system for modeling game objects through composition of relatively flat hierarchies of components.  Where more traditional approaches create individual objects with complex inheritance systems.  The author not only explains the benefits of the system, but also a sample of his API and many examples of how it helps improve their system.

If these articles don't challenge the way you program, then either you are a genius and have already made these revelations, or you're an idiot.  Enjoy.

1. Rename patch.exe to patsh.exe.
2. Then create patch.bat in the same directory containing the following command:
   @patsh.exe %*

You will never notice a difference, and Windows 7 can go politely F*** itself.

[Updated: 10/13/2009]
After writing this article the SOCI team has resolved some of these issues, so some of these steps are no longer necessary.

Step 1: Setup SQLite

Step 1.1

Download the SQLite 3.6.18 source and library files.

• Source
• Libraries

Step 1.2:

Unarchive the SQLite archives into a directory, mine will be c:\usr\sqlite3

Step 1.3:

Create the sqlite3.lib file by using Visual Studio's lib command:

LIB /DEF:sqlite3.def

Step 2: Setup SOCI

Step 2.1:

Download the head of SOCI's git repository

Step 2.2:

Decompress the file into another directory, mine will be c:\usr\soci

Step 2.3:

Soci requires stdint.h but Visual Studio 2008 does not provide it, so simply download pstdint.h and rename it to stdint.h in the soci\src\core directory.

Step 2.4:

Open the directory soci\build and copy msvc80 to msvc90.

Now open the msvc90\dll directory.

Through Visual Studio 2008, open the soci_dll.sln file and allow it to convert it with the default parameters.

Step 2.5: Build SOCI's Core and SQLite3

SOCI's core project should build without errors, but the sqlite project will have several.

Step 2.6: Fixing Build Errors

Now SOCI's core project should build without errors, but the sqlite3 project will definitely fail. It will give two specific errors:

fatal error C1083: Cannot open include file: 'sqlite3.h': No such file or directory

and

error C3163: '_vsnprintf': attributes inconsistent with previous declaration

Both are relatively easy to fix.

Step 2.6.1: Fixing SQLite3 include paths

In Visual Studio, navigate to View->Property Manager, then in the pane that shows up, expand the sqlite3 project, then expand "Debug | Win32" then "soci_dll" then double-click on the "soci" object. Select "User Macros" on the sheet you find there.

Find SQLITE3_INCLUDE_DIR and SQLITE_LIB_DIR and change them to the directory created earlier, "c:\usr\sqlite3"

Step 2.6.2: Fixing _vsnprintf

[Update 10/13/2009]
This step is no longer needed.

Expand the core project and look for soci-platform.h and find a line that says "HAVE_VSNPRINTF"

This is redefining something that VS2008 provides already and confuses the hell out of the compiler. Just comment it out, or change it to look like:

// Define if you have the vsnprintf variants.
#if _MSC_VER < 1500
#	define HAVE_VSNPRINTF 1
#	define vsnprintf _vsnprintf
#endif

Step 2.7 Building SOCI's sqlite3_test project

This project will be riddled with errors unless you have boost installed. I personally don't use it, so had to comment out large chunks of common-tests.h.  Specifically, comment out the area at the top where it includes the boost headers. Also comment out the contents of test26, test28 and test30.

Also add this line at the bottom of soci-platform.h:

#undef SOCI_USE_BOOST

Finished

Now you should have a working copy of SOCI 3.0.0 with SQLite3 support in Visual Studio 2008. Congratulations!

Download: SimpleFileWatcher 2009.09.14

This utility sends us lots of crash dump files and until now we've always had to dig back through our archives to find the corresponding symbols and source code. But today I decided to rid us of the headache and set up a Symbol Server that could automatically determine our version and load it into Visual Studio 2008. The documentation can be a bit lacking at times, so I will try to illuminate the path that I took.

Step 1:
Download Debugging Tools for Windows. This provides you with symstore.exe which will be important for creating the symbol store.

Step 1.5:
Add the Debugging Tools directory to your path, so we have access to symstore.exe.

Step 2:
Create a folder on your build server and share it such that you have something like \\BuildServer\Symbols available to your workstation.

Step 3:
For each build, execute a command like

symstore.exe add /r /p /f U:\Project\Bin\*.* /s \\BuildServer\Symbols /t "My Project" /v "Build 42"

Where U:\Project\Bin is the directory with your .pdb files, \\BuildServer\Symbols is obviously the symbols directory, "My Project" is the name of the project, and "Build 42" is the description of the version.

Step 4:
Open Visual Studio 2008,  go to Tools->Options->Debugging->Symbols. Set your cache directory to something like C:\SymbolCache, then add the location of the new symbol store: \\BuildServer\Symbols.

Step 4.5:
At this point, it would be advisable to add the Microsoft Symbol Store to the locations list too: http://msdl.microsoft.com/download/symbols.

This should facilitate debugging crash dumps without tracking down the symbols. Also, check out the Source Server which will access your VCS system to pull out the correct source code files for you automatically too.

SimpleFileWatcher

And the new release:

SimpleFileWatcher v.2009.05.14

toLua++ was the route we decided to go with our last system, but this had caveats.  The system required us to maintain extra "doctored" copies of our headers that could be used for generating the binding code.  This duplicated data caused headaches more than once.  That aside, there were problems with memory bloat, and memory leaks. From what I understand, these issues are known and have yet to be delt with.

LuaBind is probably the most used (rivaled only by toLua++) binding system right now.  It has a few glaring issues of its own though.  Most notably is its heavy use of the boost library.  Boost is a fantastic set of facilities, but it is just too bloated for a project not already reliant on it. This requirement caused builds to take significantly longer due to its heavy use of meta-template programming (something boost users are apparently comfortable with.)  LuaBind also makes my Lua IDE, Decoda, practically unusably sluggish. I'm not sure what is affecting it, but I assume it has something to do with the inflated symbol files it has to parse.

A few runners up that I'm currently considering now are LuaBridge and SLB (Simple Lua Binder). Both of these libraries are essentially building a LuaBind clone without the boost dependency. LuaBridge hasn't been updated in over 18 months, and is as well as dead, so the plan of action would be to pick up where the original author left off.  While the author of SLB hasn't posted any updates in months, he has been committing code regularly to the googlecode repository. Right now I'm hoping SLB pans out, but we will see.

Anyone else have a good recommendation?

Get the new version here:
FileWatcher 2009.03.04

The library comes with two samples. OgreDemo.cpp shows a simple example of reloading textures on the fly using the Ogre3D engine. SimpleDemo.cpp just watches a directory and outputs the file names when a file changes.

Some example code:

// Create the object
FW::FileWatcher* fileWatcher = new FW::FileWatcher();
 
// add a directory watch
FW::WatchID watchid = fileWatcher->addWatch("..\\media", new UpdateListener());
 
...
 
// somewhere in your update loop call update
fileWatcher->update();
 
// where UpdateListener is defined as such
class UpdateListener : public FW::FileWatchListener
{
public:
    UpdateListener() {}
    void handleFileAction(FW::WatchID watchid, const String& dir,
                                    const String& filename,
                                    FW::FileWatcher::Action action)
    {
        std::cout << "File (" << dir + \\ + filename << ") has event "
                        << action << std::endl;
    }
};

Download version 2009.02.17

That said, I have had some sizeable stumbling blocks with Hikari.  Many of these problems are merely results of fundamental incompatibilities with the Spark Engine.  Hikari's implementation creates an Ogre material and performs buffer blits between the Flash COM buffer and the Ogre material.  This is all well and good, if it is done syncronously with Spark's render thread, which it is not.  So it seems Hikari will have to be altered to work within Spark's rendering paradigm.

Overall I would give Hikari a 3.5/5 with a much higher possibility.  One of its major caveats is that it uses the Internet Explorer browser plugin interface as opposed to something more portable like the NPAPI which would allow it to be cross-platform, though I hear this is something the developer is working on.