There are few things worse as a programmer than to know that you shouldn’t do something, know all the reasons why you shouldn’t, but yet you do it anyway. You tell yourself that it’s more important to get things in quickly, that the code is only preliminary or temporary. You tell yourself that it’s better to get things in so you can see whether or not the whole approach will work, and that taking time on the details now would be premature optimisation.

Of course you know, deep down, that the code that is supposed to be temporary will stay, because it works. Any bad things you put in there will be left with a @todo comment next to them, and shuffled down the priority list. Which might seem like a good thing on the run-up to a deadline, but is so many times more irritating when it comes back to bite you later on.

In this particular case, the standing rule we have at the Company about programming for a fixed memory environment, even on PC, was the one I was ignoring. We were initially developing for PC, and memory handling there can be handed off to the operating system heap management and forgotten about. On every other platform though (especially PSP for which we are now porting things), you don’t have that luxury – every drop of memory has to come from the single small fixed arena, any allocations from outside of that will just fail.

So I had to spend a couple of days, going through all the allocations in the code and plumbing through proper fixed heaps so that it was clear where all the memory was coming from. Two days, and probably that in itself wiped out any gains we made in the original PC development by working fast and loose.

In summary then, no lying to yourself when it comes to weighing up pros and cons of doing something in a way that you know isn’t going to be good enough in the long term. Oh, and work to a fixed memory environment. Even on the PC. It will make your code tighter and faster, give you a clear idea of what your memory footprint is, and help reign in the inevitable problems when your memory usage runs away with you and you have to spend time tracking down who is wasting memory and where.

Virtual memory hides a lot of sins from you as a developer, but it is a crutch which you can all too easily become addicted too. It doesn’t take much to engineer systems to avoid memory fragmentation and waste, but re-engineering them once they are embedded is difficult and problematic.

So I must admit to being a bit of a luddite when it comes to embracing the new languages and technologies available for developers now. Partly this is because I’ve read (and heartily agreed with) No Silver Bullet by Fred Brooks, and partly it is because I’m much more comfortable knowing exactly what is going on ‘under the hood’ when I write software.

That being said, having good tools is a vital part of games development, and to write good tools you have to build good user interfaces on top of functional software. No amount of clean, efficient and well structured code is going to get you past that final hurdle, which is to interact with the user. I have spent too much time on too many different projects faffing around with inadequate UI libraries to want to spend any more on it now. I would say I am comfortable with MFC based development, but I would never claim that it was easy or pleasant.

So when I keep hearing other developers evangelising the merits of tools based on managed code (C#, etc.) and the .NET platform. Apparently it should take the pain out of making tools, and user interfaces, and should let me concentrate on the important things instead. Well, that was enough to tempt me in, and to give it a try.

The thing is though, our engine and game code is all based on C++, simple and clean, and we’re not going to change that (no matter how much XNA and Microsoft try to tempt us otherwise). So any tools we build have to be able to leverage all that pre-written code, and play nice with the other parts of our engine. So we needed a way to make the managed tools work with the un-managed engine, and that was where my headaches began.

Straight out of the gate, building a tool application with Visual Studio 2005 was simple and easy, and it took less than 5 minutes to have a skeleton UI that had all the right hooks for exercising some of the engine functionality needed to pre-process our assets. But then I had to figure out how to link those hooks to our pre-existing code, and that wasn’t nearly so simple. The problem was this – a C++/CLI based application (i.e. our tool UI) needs to jump through a few hoops to talk to native (C++) code. The documentation rabbits on about mixed and pure assemblies, DLL building, COM linking and a whole ream of pages about how to build a managed application. All of which is total overkill for what we needed – a simple wrapper layer between the managed UI application, and the native core code.

Now that I’ve found out how, it’s not as hard as I thought; as I work through the details, I’m going to note them down and post them here, because it was immensely frustrating to continually search for tutorials and references (I gave up on the MSDN documentation), only to find lots of people talking about how simple it was, but no-one bothering to let on how it was done.

Anyway, in lieu of a later, better post, here is what I have so far:

• Make a library DLL, making sure that it has managed (/clr) support enabled. This will form the wrapper layer
• The library DLL can statically link to the native libraries you have.
• Build a wrapper class which uses pointers to your native classes to route commands/requests to the native code. Make sure this is a managed class (it should take the form “public ref class WrapperClass” if you’re using C++/CLI)
• NB: You will have to follow the managed rules about not having native value types in your wrapper classes, but you are allowed to have pointers to native types and use new/delete as normal
• In your fully managed UI application, use the Reference system in the Common Properties for the project to add a reference to the wrapper library. This will automagically allow use of your wrapper layer classes, no need for headers or static linkage. [this is the one annoying step that really wasn’t clear from the documentation]

Anyway, a better picture should emerge from this experimentation, and I’m hopeful that once the basic pattern for managed/unmanaged tools emerges, that we’ll be massively more productive and be able to build up a nice tool-set using this new technology.