Boxer 1.1.1 is now released, bringing a gallon of improvements to joystick support and fixing several painful Lion bugs. Along the way I’ve added some pretty new notification bezels, see:
1.1.1 also removes a major irritation from Boxer’s disk-image support: the programs panel now lists programs inside disk images, and lets you set them as the default program. This really helps with CD-ROM games that leave all their programs on the CD: previously, if the game didn't put any programs on the hard drive, Boxer would force you to launch the game from the DOS prompt or write your own batch file. Ugh! No longer.
This required a change to the gamebox format: the path to the default program is now stored in Game Info.plist, instead of as a symlink. (Symlinks can’t be resolved if they point to paths that don’t exist, you see.)
In 1.1.x I’m focusing on refining what’s already here, rather than adding new visible features. Boxer’s codebase has become pretty shambolic in places, so this is my chance to clean house and fix some longstanding niggles. Most Pony Features will be saved up for 1.2.
The 1.1.x branch will likely be the last Boxer version that supports Leopard. Apple are making it increasingly harder to keep developing for older OS versions on newer ones, most of my user base is on Snow Leopard now, and I’ve been getting blue balls from all the time-saving new Snow Leopard and Lion goodies I’m not able to use because of Leopard. So one of my goals with 1.1.x is getting it to a mature state to leave behind on Leopard.
One new feature may make it into 1.1.x which won’t be visible at all: shadowed gameboxes. After import, a gamebox would be treated as read-only like an OS X app: all file modifications would be saved to a separate per-user “shadow” gamebox instead.
The main benefit is that it would keep your gameboxes in a pristine just-imported condition: one that can safely be shared between users on the same machine, or backed up or distributed, without worrying about savegames and cache files and other per-user detritus. It would also make it possible to launch gameboxes from read-only locations, without having games fail because they can’t write files.
For 1.2 I want to bring in the iPhoto-style game browser I’ve discussed in the past. This will be key to getting Boxer into the App Store: the old where-do-you-want-your-games approach just isn’t gonna cut it, and it feels like the games folder implementation isn’t a good fit for Lion anymore.
That’s going to be a lot of big hard UI work, because I don’t want to ship something that isn't as good as or better than Finder for managing your games. But moving to a game browser model will simplify Boxer’s UI, preferences and import workflow, and generally just fit better on the modern Mac.
Very little will actually change behind the scenes: Boxer will respect any older games folder you have, gameboxes will keep being gameboxes, you’ll still be able to browse your games from Finder and so forth. If you’re happy with how Boxer does things now, there’s nothing to worry about.
1.2 will probably also introduce preferences for tweaking your joystick controls. I’m thinking about how to bring button-to-key mappings into the fold: both to complement the existing joystick emulation (to let you make use of all those extra buttons on your gamepad) and to allow joystick-alike control for games that didn’t support the joystick at all.
My intention has been to keep any controller mappings global, to avoid stepping into the UI quicksand that is control-scheme profile management (which I regard as the point where tweaking stops being fun and starts being too much like fucking work). But controller-to-keyboard mappings obviously need to be per-game, since keyboard controls differ so much from game to game. If anyone has an example of an emulator that does per-game control schemes sanely, please speak up.
Boxer 1.1 is out now. The headline features for this version are 10.7 Lion compatibility and – long in the making – joystick support.
It’s been a mad dash to get Boxer 1.1 ready before Lion lands in July, since Boxer 1.0.2 was broken as hell on it. Upgrade right now if you haven’t already.
Lion brings with it a new fullscreen idiom which Boxer now supports, along with systemwide “application resume”: Boxer will try to start up in exactly the state it was when you quit it, albeit games will be ‘rebooted’ rather than resuming (no save-states for us quite yet).
Lion’s discreet changes to OS X’s UI style have made Boxer look rather frumpy in places, so over the next few sub-versions I’ll be making Boxer more Lion-like on Lion: switching from the black Inspector window to a creamy white one, for instance.
The big star for this version though, is that you can now finally use your gamepad, flightstick, wheel or even iPhone to play joystick games in Boxer again.
Boxer supports any HID game controller recognised by OS X. You can add or swap game controllers on the fly, and Boxer will automatically detect and use them.
Some devices (like the XBOX 360 Controller) need extra drivers before OS X will recognise them; some devices aren’t compatible with OS X at all, including certain gameport-to-USB adapters. When in doubt, consult the manufacturer.
Like DOSBox, Boxer emulates regular 4-button DOS joysticks along with CH Flightstick Pro and Thrustmaster FCS flightsticks—with the addition of a new racing wheel emulation mode especially for driving games.
You can switch joystick modes on the fly, and your choice is remembered per game, per user. As always, Boxer’s built-in help has more detail about all of these options.
That’s right, Boxer also supports Joypad: a free iOS app that lets you use your iPhone or iPod Touch as a game controller for your Mac. Start up Joypad on your iOS device, launch Boxer, and the two will connect automatically. Let the anachronistic fun commence. Boxer’s Joypad support is built-in, so you don’t need their separate OS X client.
Even better, each of Boxer’s joystick modes presents its own custom Joypad layout. The racing wheel mode even uses the iPhone's tilt controls for steering–which turns out to work remarkably well.
One thing Boxer doesn’t do (yet) is give you a way to modify how the inputs from your real controller are mapped to the emulated joystick; Boxer does this automagically based on the features of your game controller. It’s smart and it’ll keep getting smarter; but it will often, inevitably, get it wrong.
I plan to add an easy-to-use joystick mapping panel in Boxer’s preferences to let you tweak Boxer’s mappings. Before that though, I need to know as much as possible about where Boxer gets it wrong, so I know what is required of a mapping UI. That’s where you come in: let me know how well your game controller works (or doesn’t work) in Boxer.
As always, Boxer’s goal is zero configuration: you plug in your game controller and it Just Works, naturally and intuitively. Rather than focus on giving you options, I’m focusing on making Boxer’s automagic mapping as good as it can be: to ensure you never have to tweak the mappings unless you want to.
Judging from the discussion upon Boxer’s future post-1.0, passions run pretty high about the Mac App Store. This was originally a comment there, but I’m expanding it into a post of its own, as I want everyone’s thoughts upon it.
App Store skeptics: rest assured that I’m none too taken with the MAS either, and it doesn’t make my life as a developer any easier. The only reason I would stop distributing Boxer separately is if/when it gets simply too hard for me to maintain two separate distributions, and I plan to stick that out as long as possible.
However: the App Store’s not going anywhere, and it will eventually become the only port-of-call for most Mac users looking to find quality software. If Boxer is to be rescued from obscurity, then it needs to be available there sooner or later, however else it continues to be available.
Moreover, most of the restrictions Apple have placed on the behaviour of apps in the App Store make sense and are beneficial to the health of the OS. Private API usage is simply A Bad Idea; centralised application updates are A Good Idea (awkward though this currently is through the MAS); and fostering an overt concern over the physical arrangement of files on one's hard disk is an anachronism that belongs back in the 90s.
To recap, Apple’s app store guidelines mandate that applications keep their supporting folders in ~/Library/Application Support/, and never create folders within the system’s folder space (Home, Documents, Applications etc.) without asking first. Currently Boxer’s default DOS Games folder location is ~/DOS Games/, which would have to change.
I fully recognise the usefulness of choosing the location of this folder—e.g. to be on an external disk or a Dropbox folder—and Boxer will continue to support this. But, it would be saner and safer for Boxer to default to a suitable Apple-friendly location automatically, and let you migrate it afterwards, rather than demanding up-front where and how you want to organise your collection. It’s worth noting that the only real reason Boxer does so now is to draw attention to the sample games it has given you.
One instance came to light post-1.0 of a user choosing their Documents folder itself as the game storage location, and Boxer overriding its icon and appearance as a result. Choosing a system folder is now prevented in Boxer 1.0.1, but this demonstrates how risky and error-prone it can be, to give users the choice of where to put required folders whose contents are controlled by an application.
Boxer's long-term plan is to offer an in-app game browser to work alongside the Finder model. The browser would unify the welcome, import and games-folder UIs; allow you quicker access to recent games; and allow you to display your DOS games by metadata: genre, publisher, year etc.
This is quite clearly Apple’s preferred approach for apps that deal with document-like objects, and would render their physical location irrelevant: which would be a necessity if their actual location is buried deep within a library folder and beyond the reach of Finder. As a further complication, OS X 10.7 Lion hides the Library folders altogether from Finder, and can optionally sandbox an app’s files so they don’t even live there anymore. This, I have grave reservations about.
The rise of the App Store distribution model, and the push towards an iOS-style sandboxed approach to the filesystem, are going to see a lot of pushback from Mac developers and Mac users alike in the coming year. As someone who grew up with the old paradigms, I’m reluctant to change and can’t tell to what extent the new paradigms will actually improve and simplify the Mac desktop experience.
My concern is to make sure Boxer continues to work the way the Mac works; but without alienating users who prefer the way the Mac used to work. Above all, I don’t want to discard the old when embracing the new—except where the old really did suck.
So, what do you think?
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.
Design by 40watt.