Salutations chaps and chapettes! Boxer 1.2.1 has been kicked into the street, shivering and bloody. You can grab the new release here, and as usual the full release notes are here (RSS). This release is still 10.5- and PowerPC-compatible, as it contains Serious Bugfixes. The next feature release won’t be however.
The big things for this version are a flicker-free renderer, GOG game-import fixes, and the removal of the first-run games folder choice.
Back when I tore out DOSBox’s old renderer and wrote my own, I was inordinately proud of an Apple-specific rendering optimisation I put in: one which mapped the emulator’s framebuffer directly to an OpenGL texture, saving on potentially expensive writes when new frames are ready.
So proud I was of it, that I blinded myself to three things:
It significantly increased frame-tearing, as Boxer was frequently rendering the previous frame to the display while the emulation was writing over it with the next frame;
Many Mac GPU chipsets didn’t handle the trick very well, causing stuttering or weird rendering artifacts in fullscreen mode;
The actual performance improvement was negligible because these are 20-year-old games for god’s sake, not Wipeout HD.
So in 1.2.1 I swallowed my pride and rewrote the frame updates in a more traditional way: to my chagrin, it turned out very similar to how DOSBox does it. With tweaks to sync up rendering with the display’s vertical refresh rate, Boxer now renders completely free of frame-tearing. If you play games with lot of scrolling (like platformers or pinball) you’ll notice the difference straight away.
The moral of this story: sometimes the smart solution isn’t very smart.
This update also fixes a serious (and stupid) bug in 1.2 whereby Boxer would crash at the end of importing a GOG game that had BIN+CUE disc images, resulting in a broken game import. If you’ve encountered this, try reimporting games now.
However, Boxer still won’t import certain newer GOG releases correctly: Rayman Forever being exhibit A. Fixing these will require fairly major rewrites to Boxer’s import system, which I hope to do for the next update if I don’t slit my wrists first.
I finally pulled my thumb out of my ass and removed the initial first-run window that asks where to keep your DOS games. This now defaults to Documents/DOS Games – though the folder can still be changed later from the Preferences window, or just moved somewhere else via Finder. This change has no impact on existing game folders, it only affects people who are running Boxer for the first time.
I’ve been planning this for a while, because I felt humiliated having to ask the user for a commitment before they’ve tried out the app, and because this is a key part of the shift to a ‘post-filesystem’ game browser model. That shift won’t prevent you from accessing your games from the filesystem or organizing your games how you wish — the goal is just to eliminate the need for everybody to care about where things are located.
Anyway! I should be getting on with the game browser in the next major update, though there may be another minor release before then.
Since November I’ve been settling into my new career as an iOS games developer at TicBits! Crossing over into games and iOS development alike have been major long-term goals of mine, and I’m able to work with a great bunch of people, so this has been the perfect opportunity (and one that Boxer helped me get, incidentally). My first game will be out shortly, so look forward to borderline-inappropriate cross-promotion in the coming weeks.
Game development as a day job has meant learning to balance my creative juices between that and Boxer, which is why it’s taken 3 months for me to get a straightforward bugfix release out the door. I think I’ve finally got the hang of this though (the key: weekends) so there should be more substantial updates from here on in 2012.
Incidentally, 1.2.1 is the version I’ll finally be submitting to the Mac App Store: I’ll keep you posted on how that process goes.
Trick or treat everyone! Boxer 1.2 is out now with a laundry list of new features and fixes.
The tentpole feature for this release is Roland MT-32/CM-32L emulation, possible thanks to the sterling work of the Munt project. Boxer switches on the emulation whenever a game is playing MIDI music intended for the MT-32. Put on some early-90s Sierra or Origin games and you’ll hear some of the best music ever composed for the DOS era.
Something you may not know is that some games sent cheeky messages to the MT-32’s LCD display when they started up. Boxer shows these in a nifty overlay bezel while you’re playing.
And not only is there MT-32 emulation, but Boxer’s pre-existing support for real MT-32s just got a whole lot better too. Boxer now detects if you have a real MT-32 plugged in, and will pipe MT-32 music to it automatically: no configuration-file hackery needed.
MT-32 emulation requires ROMs that are not quite legal, so Boxer doesn’t come with these out-of-the-box. You’ll have to download the ROMs yourself, and drop them onto Boxer’s Audio Preferences to activate the emulation. But you guys are no strangers to Google I’m sure.
Boxer also supports CM-32L/LAPC-I ROMs: these have an extra bank of sound effect samples, providing better sound in games that can make use of them.
Boxer 1.2’s Good Old Game importing has been much improved, fixing import problems with a slew of releases — including recent ones like Ultima Underworld and Wing Commander III.
Boxer now respects the GOG game’s DOSBox configuration file: it extracts necessary emulation settings and startup commands, and uses them to set up drives and default programs automatically. This means Boxer 1.2 should Just Work with almost every DOS game from GOG. (Previous versions of Boxer would ignore the configuration file, and just guess at the drive layout: which meant a lot of the time Boxer would get things wrong, especially with newer releases.)
There are undoubtedly exceptions however, and I could use some help tracking down GOG games that Boxer still doesn’t import correctly. See this thread for details.
Note that Boxer cannot open GOG’s Windows-only installers yet: you’ll still need Windows to extract the game files themselves. I hope to nail this one in an upcoming release.
Boxer 1.2 now makes CD swapping easy for multi-CD games, removing another longstanding irritation.
When the game asks you for the next CD, just insert it into the DVD drive (if it's a real disc) or drag it into the DOS window (if it’s a disc image), and it’ll replace the previous disc at the same drive letter. No more dicking around removing and re-adding drives — it just Does the Right Thing.
You can then switch back and forth between the new CD and the old one with CmdShift⇠/⇢ — or pick a CD directly from the newly redesigned Drives Inspector.
You can also import extra CDs into the gamebox with the Drives Inspector — this makes them always available to swap between.
This release fixes a mountain of OS X Lion bugs. If you were getting odd drive-ejected notifications, or having drives disappear on you in the Drives Inspector, or you got a funny rash in an intimate area, well that won’t happen anymore.
Boxer now disables OS X’s function key and arrow-key shortcuts while you’re playing: no more switching Spaces by mistake! This may require a tweak to your Universal Access preferences to let Boxer do this: see Boxer’s Keyboard Preferences for details. Your keyboard’s own built-in function key shortcuts will still take effect unless you hold down Fn while you press them. Unfortunately that functionality is part of the keyboard itself, and out of Boxer’s control.
If your game uses Ctrl ⌃click for its own nefarious purposes, you can now change Boxer’s right-click shortcut from the Mouse Inspector to prevent conflicts.
Boxer’s source code repository and issue tracker have moved to GitHub; other supporting repos will be following shortly.
Boxer 1.2 will be the last OS X 10.5-compatible release, for real this time. Apple have made it too painful to continue supporting legacy versions while developing on Lion, and so 1.2 will be the end of the line for 10.5 and PowerPC support. I’ll still make 1.2.x bugfixes, but all feature development will be 10.6-and-up from now on.
That pretty much covers it I think. So get downloading and get playing!
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?
Design by 40watt.