My July has gotten a lot more crowded than I expected, and it’s become clear that Boxer 1.4 will not be ready in time for the impending release of OS X 10.8 Mountain Lion. So, I released Boxer 1.3.2 as a stopgap: this has a few minor bugfixes and is Developer-ID signed to be trusted by Mountain Lion's new Gatekeeper system.
I'll be very busy over the next couple of months with Real Life commitments, so Boxer’s development will be quiet for a wee while and Boxer 1.4 may not arrive until later this year. Fear not though, exciting things are on the way!
Boxer 1.3.1 is out now at a browser near you! Release notes are here: I’m afraid this update comprises boring old bugfixes and minor tweaks, with no new features to delight and astound.
1.3.1 is mainly intended as an end-of-life update for users still stuck on Leopard; bye guys! Boxer 1.4 will be along later this month, with a brand-new shader-based renderer and retina display support, ready for OS X 10.8 – and you’ll need Snow Leopard or newer to run it. (Yes, for really reals this time.)
It's been a long time since I last talked about putting Boxer in the Mac App Store. The landscape has changed significantly since then, and Apple’s current policies mean that Boxer’s probably not coming to the App Store – not until the development climate changes, for the worse or for the better.
The main thing is that as of the start of June, all apps submitted to the App Store must now run in a restrictive sandbox environment that curtails the kinds of things an app can do and removes access to certain OS features altogether.
If you follow other Mac developers, you’ve likely read a lot of rants about the ramifications of the sandbox and the kind of things it prevents apps from doing. Here are all the ways (that I know of) that the App Store would affect Boxer:
App Store apps can only access files that are within the app’s own sandboxed filesystem (which is hidden from the user) or to which the user has implicitly granted them access: this by either opening files directly with the application, or by choosing them from a file-picker, or by drag-dropping them into the application.
This restriction would mean:
MOUNT and IMGMOUNT from functioning;App Store apps can no longer open other apps directly, or talk to them via Applescript. This restriction would mean:
App Store apps cannot intercept and handle system-level key events. This restriction would mean:
App Store apps are not permitted to create or download other apps. This restriction would thwart my future plans to make gameboxes into first-class applications of their own.
This proviso is clearly intended to keep out alternative app stores like Steam and Bodega.
App Store apps are not permitted to download or support additional executable code, i.e. plugins. I have no plans to offer traditional plugins for Boxer, but it's debatable as to what actually constitutes a plugin: e.g. whether MT-32 ROMs or additional OpenGL shaders would be counted as plugins by Apple’s fickle review staff.
A case can be made that the Mac App Store terms of use are incompatible with the Grand Ole GPL, which opens Boxer up to being pulled from the App Store on spurious legal grounds. This threat has already been realised on the iOS App Store, where some GPL-licensed apps have been unceremoniously pulled after DMCA complaints from parties with axes to grind.
Compared to some apps, Boxer gets off lightly, and none of these restrictions on their own are dealbreakers for running DOS games: but they would put a dent in Boxer’s ease-of-use, and curtail future development angles, without offering me anything in return besides the increased exposure. Given that I don’t make any money off Boxer, the exposure would bring me no benefit (beyond basking in the glory of more happy users) and it would come with a much bigger support burden attached. Apple's mercurial policy changes would also leave Boxer at the risk of losing further features just to stay in the store once it’s there, or of being pulled from the store altogether at the whims of other people.
It’s very late in the lifespan of an operating system to attempt to lock it down like this, and I’ve heard it likened to putting the genie back into the bottle. Some apps are simply unable to function within the sandbox, and so there has been a miniature exodus of app developers from the App Store since the new rules went into effect. Some high-quality apps, ironically including apps that Apple themselves have promoted, are now laying fallow in the App Store without the opportunity to submit new updates, and many other popular apps will now never be able to join the App Store. It’s possible that Apple will expand the sandbox API at a later point to let some of them back in, but I don’t have my hopes up.
Fortunately Apple seem to be in no hurry to remove your Mac’s ability to run well-behaved software from outside the App Store; they’ve made moves in OS X 10.8 to codify a distinction between unapproved apps that are made by any old rabble, and apps by trusted developers that just could not be distributed in the App Store for whatever reason. This indicates they recognise the ecosystem outside their App Store is still vital to the platform; let’s hope they keep thinking that way.
So there we go! For now Boxer will stay out of the App Store: until Apple expands the range of things possible in the App Store sandbox, or until Boxer evolves to a point where those restrictions are no longer relevant, or until Apple force my hand by preventing 3rd-party apps from running on OS X at all.
Boxer levels up again, to 1.3! This version sports the volume controls I told you about last time: along with screenshotting and fast-forwarding, and a heaping helping of bugfixes. Full release notes are here, in HTML even this time.
I tried to make this release as boring as possible, but a couple of interesting improvements still snuck into it while I wasn't looking:
One of those why-didn’t-Boxer-always-do-this features: Gameboxes now remember all the drives you’ve added and queue them up next time you play, even drives that aren’t physically part of the gamebox.
Previously, Boxer would only ‘remember’ drives that were part of the gamebox you were playing. This meant that to get an outside drive to be mounted all the time, you either had to muck about with DOSBox mount commands or let Boxer physically import the drive into the gamebox. Which, you know, sucked.
So now: fire up a gamebox, add a new drive, and it’ll just be there every time you play the gamebox. You can rename or move the drive’s source folder or image, and the gamebox will still find it each time. Drag the drive out of the Drives panel and the gamebox will forget about it again. That’s that.
This finally makes it super-easy to share OSX documents with a DOS app, or share a bunch of utilities among several apps. It also frees you from having to do any drive-importing of your own: until and unless you want to share your gamebox with others.
I’m making this sound like a big fucking bright idea but seriously, why didn’t it always do this?
Boxer 1.3 now boasts the ability to paste text from OS X into any DOS program (as well as the DOS prompt, which was supported already in Boxer 1.2.2).
Pasting still has some limitations: only ASCII characters can be pasted at the moment, so accents get lost in translation. And of course, you can’t copy text back from DOS (at least, not yet.)
But it's still awesome, dammit, so I'm going to bore you about how it works:
MS-DOS has no idea what a clipboard is, so to get text into DOS, Boxer essentially has to type it in.
In MS-DOS, the characters you type start out as raw keyboard signals in the keyboard buffer: from here they're read out by the BIOS, combined and translated into BIOS keycodes (according to the current keyboard layout and state of the Shift/Alt/CapsLock keys), and stored in the BIOS key buffer.
Most DOS programs that deal with raw text (text editors, productivity apps, text-mode games) poll this BIOS key buffer regularly to check for new key input. When you paste text from OSX, Boxer takes over the BIOS key buffer: it translates each pasted character into its corresponding BIOS keycode and feeds them into the program as fast as it asks for them. This is reasonably fast and very accurate, so Boxer uses this approach when it can.
Most DOS games don’t do this though: they read keyboard signals directly from the keyboard’s own buffer, and bypass the BIOS and keyboard layout layers altogether, because they hate me. For these games, Boxer has to work out which combination of keys and modifiers would trigger each character you’re pasting, and literally type those keys into the emulated keyboard.
This is more laborious, among other things because Boxer has to carefully manage the state of the Shift key to match the case of the characters you’re pasting. It's also a lot slower: Boxer has to paste text in short, careful bursts to avoid ‘flooding’ the limited keyboard buffer, and to ensure the program has time to read each batch of typing. But it works.
Neither approach is instantaneous: it’ll take a while to paste large amounts of text, but you can cancel a long paste by pressing Esc in the middle.
OK, that’s all! Go back to what you were doing. (Downloading another awesome Boxer update, that is.)
Boxer 1.2.2 is out, hot on the heels of the previous release to fix a couple of serious crasher bugs. The full release notes are here, in RSS form as usual.
Because I’m pathologically incapable of doing a simple bugfix update, I also slipped in a new feature: a simulated numeric keypad to help out players with Macbooks or Apple Wireless Keyboards. In a nutshell:
If you don’t want to hold down Fn all the time, you can also toggle the numpad behaviour on and off with Cmd+U or
I’ve also (re)introduced paste-to-DOS, which had been around in pre-1.0 versions but was cut for being too buggy. You can now paste single or multiple lines of text at the DOS prompt, letting you easily enter command sequences and complicated paths.
In a future release I'll expand this feature to let you paste text into any DOS application - I can see that coming in really handy for text editors and parser-driven games.
Finally, after some constructive pushback in the comments for the 1.2.1 release, I’ve also reverted Boxer’s default location for the games folder back to [your home folder]/DOS Games/. I appreciate better now how many users regard the Documents folder as sacrosanct—unfortunately, OS X is pretty short on good places to put the-kind-of-objects-that-game-ROMs-are. (This will probably be revisited again when Boxer goes through app store submission, which will be Real Soon Now I Promise.)
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.
Design by 40watt.