Remember Sammy Jankis Thursday 15th July 2010

Today’s new build is all about gameboxes and game configuration:

• Changes on the CPU inspector panel (speed, core optimization, framerate) are now remembered for each gamebox, making the panel actually useful;
• Half a dozen new auto-configurations have been added since the last blog post;
• Boxer now auto-detects games outside of gameboxes again;
• Gamebox configuration files have been stripped down to only store overridden settings, not auto-detected settings;
• Gameboxes now generate a unique identifier for themselves, stored in a new gamebox metadata file.

This build also fixes a number of recent UI bugs in OS X 10.5 which had busted the program panel and drive list. There’s no reason not to be downloading the new build right now dammit.

The inevitable long-winded feature tour

These improvements were all blockers for 1.0 final, and are more pieces of the game-installation IKEA wall unit screwed firmly in place. While none of these features are very visible, they do pave the way for exciting new things in Boxer’s future.

So, yet another metadata file?

Yup, gameboxes have been extended to add a new metadata file, Game Info.plist, which is stored in the gamebox’s root folder alongside DOSBox Preferences.conf.

In future Boxer versions, this file will store things like the game’s developer, publisher, year, genre, Mobygames page etc. This metadata would be used for Spotlight and Quicklook integration, and for a snazzy game manager UI I’ve been thinking about for a while.

For the moment however, this file only stores the game’s unique identifier.

Unique identifier, you say?

Many long-planned Boxer features have needed a way to unambiguously identify gameboxes, in order to associate external data with them: data that cannot be stored inside the gamebox itself for whatever reason.

For this purpose, Boxer now creates and stores a “unique” identifier for each gamebox, by generating an SHA-1 hash out of every executable file inside it. I put “unique” in quotation marks, because this approach has the desirable effect that the hash will be the same each time it is generated, and the same for anyone in the world running that version of that game.

This latter fact is crucial for another long-planned Boxer feature: integration with an online game repository. The idea is a kind of CDDB for games: to let Boxer automatically retrieve user-submitted metadata and configurations for newly-minted gameboxes. More on this in a future blog post!

A word on game detection

Boxer has had automatic game detection for most of its life, and it works by scanning the folder or gamebox you opened for files that match known games. This behaviour has been improved in this build to detect games outside of gameboxes once again, the same as Boxer 0.8x does.

Boxer has to be careful about how deep it scans for games, though. If you open a floppy disk, CD-ROM or gamebox then Boxer will scan the whole file heirarchy inside it, since it is known to be a manageable size. The rest of the time however, Boxer will only scan the base folder it is opening and will not search into any subfolders.

This is necessary to avoid massive slowdowns if you open (for example) your Home folder in Boxer. However, this does make Boxer less reliable at detecting games outside of gameboxes, since it may stop looking too early.

For historical reasons, Boxer 0.8x would save the autodetected configuration into the gamebox. Boxer 1.0 no longer does this: Boxer runs the auto-detection at every launch regardless, so it would be redundant to store it, and a stored configuration could get in the way of future corrections to the autodetected version. The gamebox configuration file is now meant solely for persisting a user’s own adjustments of the emulation settings.

Ah yes, persisting settings

When you adjust emulation settings from the CPU panel, Boxer works out what DOSBox configuration parameters would represent the changed settings and then writes those parameters back to the gamebox’s own configuration file.

Boxer now also compares against the parameters that are in the game’s auto-detected configuration file; if any are the same, they are stripped from the gamebox configuration file instead. This way, Boxer won’t store redundant settings.

Not all emulation settings are created equal of course. Some, like CPU speed and core optimization, concern the game itself and should apply to anyone playing it; these do belong in the gamebox configuration file. Others, like framerate or window size, are about your own Mac and your own personal preferences, and should only apply to you.

Such settings are not stored inside the gamebox configuration file anymore: instead, Boxer stores them inside its own application preferences, keyed to each gamebox by its unique identifier. This way, they don’t come along for the ride if you pass the gamebox on to someone else.

• Filed under Development, Alphas