That’s right boys and girls: after 2 years in development and 4 months in beta, Boxer 1.0 is finally here.
You can see a list of what’s new in the update feed; this isn’t a huge update if you’re coming from one of the Release Candidates, and by any measure RC2 was already final-quality. But hey, now it’s official!
For those early adopters among you, Boxer 1.0 is now compatible with OS X 10.7 Lion developer previews—although full screen transitions are currently disabled in 10.7 as they conflict with Lion’s own full screen handling.
To my giddy delight and my server's abject horror, Boxer got pimped by Kottke.org and Daring Fireball this week: two of the biggest rallying points for afficionados of good Mac software. As a result Boxer has gotten a lot of uniformly rave press and brought thousands of new users into the fold. Welcome one and all, and happy gaming!
If you see other articles pop up about Boxer then do please let me know, because I am a vampire who feeds on attention.
Since the initial 1.0 public beta a few months ago, Boxer has seen major improvements to game importing, game compatibility, rendering, full-screen mode, games folder handling, you name it; and tons of smaller fixes and UI polish along the way. It now sports built-in Apple Help too, searchable straight from the Help menu.
And since the venerable Boxer 0.87, well… let’s just say this is a whole new app. One I can finally be proud of.
Now that 1.0 is out I can finally get back to sane release numbering, and can work honestly on new features rather than furtively sneaking them in under a “feature freeze”.
I have the following tentpoles in mind for Boxer 1.1:
The number one must-have feature is joystick support: this will probably initially be limited to CH Flightstick Pro emulation, with Thrustmaster and dual-joystick emulation added later on.
Along with that, I want better handling of multi-CD games to let you cycle through CDs painlessly. I’ll also be making Boxer rip game CDs to disc images, to improve copy protection compatibility and to let audio tracks come along for the ride.
Last but not least, I’m hoping to roll in MT-32 emulation, because my inner 10-year-old pines for the dulcet Sierra melodies of a bygone era.
From here on in, I'm hoping that releases will be frequent and improvements incremental, rather than major feature dumps once in a blue moon. That means you shouldn't expect these features in 1.1, but by 1.1—they’ll come out one by one as I go.
After 2 years of alpha and beta hell, I’m also hoping to avoid beta cycles altogether. However, we’ll see if that wish survives contact with…
…yeah. I’ll be bringing Boxer to the App Store sooner or later, once I get over my dread of one-star-reviews-from-people-I-can’t-contact-to-find-out-what-went-wrong. But Boxer will remain free and open source on the App Store, and I’ll continue to distribute a Sparkle-updated build separately via this site, for at least until I phase out OS X 10.5 support (which won’t be for quite a while yet, don’t worry!)
Boxer would probably need a few tweaks in order to pass the App Store submission process:
The default location for the DOS Games folder would need to change to ~/Application Support/Boxer/DOS Games/, since Apple aren’t keen on apps cluttering up the Home or Applications folders with their own junk. This may mean I'd remove the option to choose the folder’s location altogether.
I'd need to pull out some private API calls, which means no spinning windows and blur effects. Oh, the humanity.
Due to the nature of the App Store review process, updates may be nowhere near as frequent as I’d like. Hopefully though, keeping a separate distribution channel would allow me to release low-key incremental updates in between the App Store ones.
More on that topic when the time comes.
OK boys and girls, Boxer 1.0 beta is finally here. This is the big one: Boxer 1.0 is now feature-complete and does everything Boxer 0.8x did and more. It’s also purest awesome.
I’ll be writing a series of blog posts over the next few days going into detail about the new tentpole features. In brief though:
Game Importing is back. Boxer once again imports games painlessly from CDs or folders into new gameboxes. Besides looking awesome, this feature now gives you more control over how games are installed, guides you gently through the installation process, and lets you customise the gamebox at the end. No mess, no fuss.
The Games Folder is back. Boxer once again creates a folder to keep your games in – dressing it up with sample games and a new-and-improved game shelf appearance, if you like (or leaving it plain if you don’t.) Naturally, Boxer will recognise and use any game folder you have from a previous version of Boxer.
Boxer now introduces itself with a classy Welcome panel. This lets you jump to your games folder, import new games or fire up a plain old DOSBox session without faffing around in menus. If you prefer, you can turn this off in the preferences, or make Boxer open your games folder at startup instead (like it did in older versions.)
Enough talk. Go grab the new version and get playing! (And be a good citizen and tell me about all the bugs you find.)
You know how back in July, I said all that remained was reimplementing game importing and the games folder? Well, it turned out that those two things were 80% of Boxer. These features are core to the Boxer experience, and reimplementing them properly — awesomely — ended up being a whole heaping bowlful of work.
Along the way of course, I got burned out on coding and fought off a crippling Minecraft addiction. But hey, that’s all behind us now.
In this week’s episode, the Inspector panel gets some more sweet hot lovin’. Download the new build here, and read more below.
Now that Boxer stores per-user-per-gamebox settings, we can have some much-needed tweaks for mouse behaviour:
A slider for mouse speed, to fix games that get it wrong and don’t let you adjust it in-game. This applies only while the mouse is locked: while unlocked, Boxer sticks to OS X’s mouse speed to keep the OS X and DOS cursors in sync.
A toggle to ignore the mouse until it’s locked. When enabled, the mouse does nothing until you click on the window, at which point it is automatically locked. (This is analogous to DOSBox’s original “autolock” mode.)
This latter setting is vital for games where moving the mouse also moves the game view: Boxer’s regular behaviour can be frustrating as hell, if the game goes spinning or scrolling off into oblivion while you reach for a menu.
I’ve been humming and hawing for some time over how to present the option. It’s clear that it’s necessary, but it may be worth going further and making it the default; or making it Boxer-wide instead of per-gamebox, like rendering settings; or making it per-gamebox instead of per-user, like CPU settings. Time will tell where it should best live.
For the moment though, I feel that Boxer’s regular mouse behaviour does a good job for most games; and I find I only want to change it for one or two that misbehave. So for me, it strikes the best balance to have it as a per-user-per-gamebox option that’s disabled by default.
I’ve been primping and preening it to within an inch of its life. Besides aesthetic improvements, I’ve put in buttons to add, eject and manipulate drives, making the panel’s functionality more obvious and accessible.
The biggest addition though is the ability to import drives into the gamebox straight from the Drives panel. This copies an entire volume or disc image into the gamebox, so it comes along for the ride and gets mounted whenever you play the game.
Of course, this is just like Boxer 0.8x used to do when installing games, and will be a key feature of Boxer 1.0’s upcoming game installer too. It’s not often that you’ll need to use it outside of game installation; but I want to ensure that anything you can do during installation, you can do afterwards too.
This will hopefully be the last alpha build before Boxer 1.0 goes beta. That will be a Boxer feature-complete and mere weeks away from a final release. After one-and-a-half years, the time is nigh.
There’s two core features left to (re)implement before then: game installation, and the DOS Games folder. I’ll be working furiously through August to get these ready, and I’m very excited for what we’ll have to play with at the end of it.
Today’s new build is all about gameboxes and game configuration:
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.
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.
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.
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!
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.
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.
A new Boxer 1.0 alpha build is fresh out of the oven. Since this build has ended up focusing on UI refinement, a few gratuitous screenshots seemed in order:
Opening additional gameboxes or DOS windows will launch additional Boxer instances to handle them. More on this below.
Besides looking cleaner, the panel now highlights the default program and bumps it to the start of the list. It also slides away after clicking the default program, instead of hanging around taking up space.
button now enlarges the window to fit all the available space, instead of fitting it to a multiple of the DOS resolution.So what are you waiting for? Go grab it already.
A limitation which has dogged Boxer 1.0 from the very beginning is DOSBox’s one-shot nature. Because DOSBox is compiled into Boxer, Boxer’s memory is DOSBox’s memory; and DOSBox stores its emulation state in a vast hive of global variables, which it doesn’t bother cleaning up afterwards.
This prevents DOSBox from handling two emulation sessions at once — because each session clobbers the other one’s state — and from starting up a second emulation session after finishing the first — because the subsequent session inherits a hopelessly polluted state from the first one. Imagine a living room the morning after a student party.
This is of no concern to a hard-living Windows transplant like DOSBox, which was designed to quit as soon as the emulation exits. But it is of concern to a well-behaved native app like Boxer, which wants to stay open in the Dock, and to be able to open and reopen as many windows as it needs, just like all its other Mac chums.
Boxer was a sad panda. Until now.
Would be for Boxer to move the DOSBox emulator core to a separate child process with its own isolated memory space, and spawn instances of this emulator process for each window. This way DOSBox could shit in its own sandpit as much as it likes, it could run alongside other emulator processes without fear of cross-pollution, and it could be terminated or paused or restarted at will by the parent application (Boxer) without ruining everyone else’s day.
This was the approach that Google Chrome took for its tabs, that OpenEMU adopted for its multi-emulator cores, and that Boxer will eventually use for its DOS sessions.
However, restructuring Boxer to manage this parent-child process relationship is complex and has a lot of pitfalls. The groundwork for it is pretty far along, but it’s unlikely to be ready in time for Boxer 1.0.
Is for Boxer to simply launch more Boxers. When Boxer has a DOS window open and it gets a request to open another, it just spawns a new Boxer instance and tells that to open the window instead. If you try to open a new window after closing one, then Boxer quits and immediately relaunches to open the new window with a clean slate.
This approach has disadvantages. Each Boxer instance is a separate application as far as OS X is concerned: so they appear separately in the Dock and CmdTab switcher. Instances can’t coordinate with each other: so windows tend to open exactly over the top of existing ones, and preference changes in one don’t take effect immediately in another. This is very much a stopgap solution.
But, grubby and hackish though this is, it’s so dramatically better than before that I wanted to get it out there for people to play with right away.
Design by 40watt.