Coincidentally, this is the same reason I don’t use managed languages like C#. I quite like knowing about things that managed code wants to hide! The increase in development time is not that important to me, I have no external deadlines to meet.

However, there are points beyond which it’s not practical for me to write the code myself, because it’s either A) incredibly complex, B) boring, C) proprietary, or D) so ubiquitous that it really doesn’t need reinventing. e.g.: writing code to decode an MP3 file into raw audio. I could *potentially* do this, but as it belongs to all four categories, I’m really comfortable with not doing it myself!

Currently in my Freepascal development I am using three 3rd Party Code libraries every day. And they are all excellent, both in terms of features and being easy enough that I can ‘plug them in’ to my own lx7 game engine with very little work. Here they are:

DirectX – by Clootie

No, not DirectX itself (that deserves a whole separate subject!), but a port of all the headers/structures/glue code necessary to use DirectX in Freepascal. This gives me low level access to every function and interface used by DirectX itself, and the port is so perfect I was able to build my own graphics engine on top of Direct3D just by studying the (C++) DirectX SDK. Nothing is missing! Everything works! You probably won’t appreciate how rare this is if you normally use C++.
http://www.clootie.ru/

BASSfpc

BASS is an Audio Library that makes it *dead easy* to play sound and music files of many different types. BASSfpc is the FPC port of this. BASS handles MP3s, WAVs, OGGs, and about a million other sound types, and it does it efficiently and with the bare minimum of code needed (literally about 4 lines of code to init the library and start playing an MP3!).
http://www.un4seen.com/

LNet

The newest addition to my Libs folder. LNet provides a set of classes to implement networking, at the very lowest level, without adding any additional features or complexity. That’s exactly what I needed, because I want to add my own features and complexity! There are many many network libraries out there, but (for Freepascal at least) LNet definately gets my vote, for being simple, class-based, and extremely elegant.
http://lnet.wordpress.com/

The rule is:

Provide gamma and volume controls, and separate music from sound.

Pretty simple. But essential! The good news is, the AAA titles pretty much universally support this now. And it’s a good thing, as I use these settings all the time.

I have an Xbox 360 but, unlike most Xbox 360s, mine isn’t connected to a TV – it plugs into a second DVI port on one of my 22” widescreen PC monitors. This is awesome because I can run it at 1680×1050 and games look beautiful! (handy bonus: I can web-surf on my other screen while waiting for Matchmaking in Halo 3)

BUT my monitor has a very different colour profile than your average TV, and games with a lot of contrasting light/dark elements can look really bad by default. Gamma controls in your game are pretty essential for me to see the graphics the way the designer intended. I’m sure there are other people in similar situations or even wildly different situations who also need gamma settings. Your game needs to support them too!! And since there’s nothing on the “con” side of the ledger that could make it a bad idea, you have no excuse!

Providing separate controls for sound/music: Music is awesome but people like to be able to hear the game sounds sometimes! Particularly in a ‘competitive’ environment, or simply when your game is providing an audio narrative (GTA4 is an excellent example – the “in-car radio” music is huge and contributes to the GTA atmosphere, but you need to turn the music volume down to be able to hear what mission you’re being given via the cellphone). If I’m playing an FPS single-player, I might turn the music up, but in multiplayer I want to use every audio cue the game gives me for competitive advantage, so I need to kill the music or at least turn it down.

Just like with the gamma controls, the good news is this is pretty universal now. But there are still Flash games that don’t separate them (and, even worse: there are plenty that have no Volume settings at all – sound is either On or Off). Sound might *add* to the game experience, but I’d like to set it so that it doesn’t completely drown out my background music, thanks! Vista and Windows 7 allow you to set the volume controls at the “application” level, which solves the problem for me specifically, but it doesn’t help anyone using XP (or anyone who doesn’t know about that feature). Support them too!

Any sufficiently complex game is going to have “assets”: data external to the main program that the game depends on to function. This includes “art assets” (textures, images, music, etc) as well as more application-specific “data assets” which contain data in a format unique to your application (e.g. Icefall has “item types” of all the different equipment players can find/buy/receive).

Handling art assets is relatively easy: you create/modify them in Photoshop (or equivalent), you save them as PNGs or JPGs, and you’re done! You might wrap them all up in a custom file format to compress/encrypt/streamline them, but that’s pretty simple and you can do that at the very end of development.

Data assets are different. There aren’t any programs around that can edit “Icefall item types” files. I need to write my own “Item Types Editor”, which understands this format and can load, modify and save it. This leads to two problems:

1. I have to spend time writing an Editor. (the actual format load/save code could be shared with Icefall itself, but there’s all the UI!).

2. If I ever change the “item types” format, all the data I’ve previously created is now in jeopardy. (What I typically do is modify the ’save’ code only, run the editor and  load each asset (old-code), and re-save it (new-code), then when that’s done I can modify the ‘load’ code.

Depending on the type of data asset, using Asset Text Files may be superior. I DON’T mean your game should store all of it’s data assets in plain text (yuck!). Here’s what I mean:

Whip up a simple plaintext ’syntax’ that stores all of the information you want to include in your data asset. Then,  instead of creating an “Editor” with bulky UI code, create a command line utility that can parse your plaintext files and spit out your compiled data asset files. If you borrow your main game code for load/save, all you have to write is the text parser, and that can be as easy as you like: you’re dictating the syntax it has to interpret.

The BEST part of this system is that it makes changing the format of the assets later on very very easy. Oops, I forgot a field for my item types? No worries. Add the extra field to your text file sources (bringing to bear the full power of your fantastic Programmer Text Editor / IDE you’re using – the programmers’ Photoshop), a quick change to the asset compiler to recognise the new format, and hit execute.

You get other benefits too: you can put ‘logic’ into your compiler without having to put it in you main game. (e.g. scale the values, dictate whatever “optional” or “Default” fields, anything!

It doesn’t work for everything (e.g. Icefall’s “Level Map” is huge and an Editor really is the right option for that) – but when it’s appropriate, I have found it works brilliantly.

Textures are used for everything, from the mouse cursor, menus, fonts, buttons, to the game world itself, spells/action icons, monsters, equipment… everything.

Although my own main PC has 512MB of video (texture) RAM, not everyone does! And
following on from my minimum requirements post, I don’t really want someone’s video card memory size to be a limiting factor if everything else meets the requirements, so Icefall needs a way to manage things when there are more textures than there is video memory.

I don’t want each bit of code that uses textures to worry about whether they’re loaded or not, so the logical choice is to encapsulate all of the texture handling into one place: I call the class that handles this the TContentManager (”content” because it also handles sounds, fonts, music, etc.).

When the game code asks the TContentManager for a texture: the first thing it does is look to see if that texture is already available in video memory: if so, it just hands out a reference. Easy! If not, it retrieves the filename for that texture from Icefall’s ResourceDatabase, and attempts to load the texture from disk. If that fails, it looks at why it failed: if it’s D3DERR_OUTOFVIDEOMEMORY, the next step is to unload some other texture and try again, repeating until the load succeeds or we have no loaded textures left. (If it still doesn’t load, or if the texture load fails for some other reason, it’s goodbye Icefall).

Programmatically:

function TContentManager.GetTexture(ID: TTextureID): TLXTexture;
var
   HRes: HRESULT;
   NewTexture: TLXTexture;
   FileName: String;
begin
   if TextureLoaded(ID) then
      exit(Texture[ID]);

   FileName := ResourceManager.Textures[ID].FileName;
   repeat
      HRes := LXLoadTexture(FileName,NewTexture);
      case HRes of
         D3D_OK:
            Texture[ID] := NewTexture;
         D3DERR_OUTOFVIDEOMEMORY:
            UnloadTexture(0);
      else
         // Fatal error!
      end;
   until TextureLoaded(ID);
   result := Texture[ID];
end function;

UnloadTexture is a method that unloads a texture. It takes a TTextureID as a parameter, but passing 0 in this case tells the method we want it to choose a texture to unload itself. This is where it gets interesting.

Before I got to this, I originally had set up a few states so that they explicitly called TContentManager.UnloadTexture to release textures when the game left that state (e.g. the game would unload the ‘Option-selection’ texture when the player closed the Options dialog). However, this turned out to be sub-optimal for several reasons:

• Players might well leave and re-enter states (like Options) several times to accomplish whatever it is they’re trying to do.
• It doesn’t make use of extra video memory: it keeps loading from disk (or the disk-cache anyway) while the extra video memory stays idle.
• I had to explicitly declare what textures I was done with. Not a problem really but ‘just another thing’ that I had to do when changing states.

So now I no longer explicitly release anything. UnloadTexture always chooses the texture to unload that was least-recently used (a linked list makes this a very fast and efficient check – no timers or array scanning involved). In practise “least recently used” turns out to be about 97% optimal (when simulated against a 100% optimal algorithm which is permitted to see the future when deciding what to unload) so it’s virtually perfect – substantially better than my explicit declarations were.

If for some crazy reason the user doesn’t want Icefall consuming all of their video RAM*, I can chuck in a call to IDirect3DDevice9.GetAvailableTextureMem and trigger UnloadTexture if it’s below some specific amount. Alternatively, I could keep a sum of the amount of texture memory I’m using, and trigger UnloadTexture if that amount threatens to exceed 32MB or whatever (I haven’t decided yet).

The point is, if you find yourself manually balancing resources, it’s probably an excellent idea to profile your resource usage and see if you can find a pattern that will let you just automate the whole thing**. You’ll save yourself much time and your code will be cleaner and more flexible.

*Note: this only actually matters on Vista or Windows 7. Under the Windows XP model, multiple applications can’t share texture memory anyway. As soon as an application takes focus, DirectX invalidates all texture resources belonging to everything else (forcing them to reload from system-memory or disk when they get restored). The WDDM (Windows Display Driver Model) in Vista “understands” video memory, and can share it amongst applications. This is one of the reasons DirectX 10+ can’t be backported to XP: XP has no concept of video card resources.

**If you’re creating a game frame-rate locked or just frame-rate dependent, you might still need to explicitly acquire and release resources (e.g. between levels), because a 10ms pause at an unexpected point in your game could be noticeable or detrimental. Either that, or move the resource acquistion to another thread and have low-quality ‘emergency’ textures to display while the real ones load… this is a very common technique for FPS games.

To me, that is not only a frighteningly ignorant and dangerous way to develop software (you’re not going to discover caveats & usage notes by browsing RegEdit!) but of course this is not the supported way to do it (how could any sane developer think otherwise?), and of course that app would have broken immediately on any new of Windows had MS not added a compatibility shim to watch for that program checking that buggy key, and substituting in a quick call to obtain the real value…

This isn’t backyard programmers writing in VBA in Excel to accomplish some one-off business task, either.. it’s commercial software that did this, written by professional developers and sold to unsuspecting customers for big cash. Scary stuff.

The only question worth pondering here is: was this ‘grab something promising out of the Registry’ technique better or worse than just hard-coding “C:\Windows\Fonts\” into the application? (I’m not 100% sure but it seems very likely there’s a shim out there for programs that did that, too.)