Sign in to follow this  
  • entries
    37
  • comments
    68
  • views
    46555

OGRE's resource/archive system, testing, Ruby

Sign in to follow this  

343 views

The work of splitting Asylum into three modules (platform-specific executable, engine DLL, game DLL) is complete. I did all the work on a branch I created just for this purpose, and gained hands-on experience for branching and tagging with Subversion. Forget about my previous beefs about how it's done -- now that I've actually tried it, I like it!

I've begun experimenting with OGRE's resource/archive system this morning, hoping to do some virtual file system magic with it. So far the experiments have been promising, but OGRE loves to throw whenever it encounters duplicate resource definitions. It'd be nice to be able to tell OGRE to just ignore duplicates rather than stop and refuse to continue along that track.

I need to replace the old test framework in Asylum with a better one. When I started writing Asylum, I simply had a pure virtual class from which I created actual classes containing setup and test code. Unfortunately, the recent changes to Asylum (mainly being that the test framework now runs from the engine DLL) have killed the poor thing dead.

I've used CppUnit in the past and I'm learning to use NUnit now, but those are just unit testing frameworks. I've used the old test framework to do more than just hands-off unit testing -- it's provided a way to drive the console system, for example, and I was trying to use it to explore and enumerate resources in OGRE when it decided to shuffle off its mortal coil. Anyway, I don't think that Asylum actually needs a full fledged unit testing framework yet, as most of the code is too simple to worry about things such as regression. When there's something wrong with the code, it simply doesn't build (or if it does, it goes to the problem and INT03s it right into the debugger).

However, now that I'm defining and exporting interfaces (such as the System object interface from the executable, or entities in the game DLL) I should start unit testing.

On another note, I need to find the Ruby equivalent of Boost.Python. I want Asylum to be Ruby scriptable (I have issues against Lua and Python, the holy war kind), and I want to hook it into the console so every input line is either a cvar, command, or Ruby one-liner. On the upside, it's probably easier than I think to hook in Ruby manually, as pretty much everything reflected into Ruby should stick to certain general interfaces, anyway.
Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now