Hello chaps! In time for the start of summer, here comes a new Boxer 1.0 build. The highlights for this version:
The big tentpole here is of course DOSBox 0.74’s improved emulation, which should make your games Just Work Better, especially the old ones. Besides that, everything else in Boxer is just that little bit shinier and nicer-smelling. So what are you waiting for? Head on over to BitBucket and grab the new build.
With every new build, it feels like the tectonic plates of Boxer's code shift dramatically underfoot; this time, much was rewritten to make the upgrade to DOSBox 0.74 go painlessly. To that end sdlmain, a megalith of DOSBox application code that was riddled with old Boxer hacks, has now been uprooted and cast into the sea: leaving a cleaner trimmer DOSBox to get on with the emulating, and a happier wiser Boxer to get on with the applicationing. Its expulsion made porting the rest of 0.74 an absolute breeze, and should also make my post-1.0 multithreading plans much easier to achieve.
That aside, much of the code rewrite came about from my whirlwind love affair with OpenEMU, a kickass Cocoa multi-emulator project with some really funky ideas and a commitment to being a first-class Mac citizen. I was delighted to find a kindred spirit, and to discover that they had implemented stuff I'd been longing to try for months: like CALayers for rendering and OpenGL shaders for filtering. So I promptly took them for all I could get.
My tumescence was quelled however by the realization after two weeks of labour that my layer-based rendering path was prohibitively slow, and the GL shaders prohibitively ugly at large scales. Reluctantly I retreated to Boxer’s old NSOpenGLView rendering path and DOSBox's software scalers; but I snatched some small victories along the way, and the rendering in the newest build is crisper and pleasantly faster.
The rest of my vain attempt is still lying dormant in the code, and I'll be revisiting it post-1.0: a layer-based approach is key to some of my future interface plans, and GL shaders have a lot of promise if I can get them looking nice and performing well on my modest little Macbook. For the time being though, it seems that Boxer 1.0 will launch with the renderer it’s got.
Well, now I really have run out of things to rewrite, and I promise to get the hell on with some interface work already. I’m looking forward to bringing back game installation so I won’t have to make excuses anymore; once that’s in place, then Boxer 1.0 will finally be feature-complete and ready for a public beta.
So I got coked up and tore out SDL’s still-beating event system, holding it triumphantly aloft before plunging it into the cleansing fire. From now on Boxer does rendering and input entirely by itself, keeping the SDL framework around only for audio. The new build is a Cocoa zen garden and I am at peace.
While much is changed under the hood, visible improvements from this recoding bacchanalia are fairly few:
Mouse-locking and cursor behaviour in general are much improved: the DOS and OS X cursors stay in sync whenever possible when locking and unlocking, and the cursor should now hide and unhide much more faithfully.
Minimizing or hiding the application from fullscreen now works properly.
Just because I could, I added a chic blur effect behind the Inspector panel.
CtrlOptclick now simulates clicking the left and right buttons simultaneously: a ray of hope for you Syndicate fans rocking a trackpad or a Magic Mouse. (Reminder that Ctrlclick on its own simulates a right-click, and Optclick simulates a middle-click.)
As a result of this input restructuring, joystick support is officially gone and it won’t be back until after 1.0. Which isn't a great loss, since the joystick support left over from DOSBox was a nightmare to configure and never worked very well on the Mac.
Which is not to say I don’t care about joysticks: on the contrary, I love them so dearly I couldn’t bear to support the feature as it was. Once 1.0 is properly out the door, I want to do joysticks right: make them work magically and beautifully, with no initial setup but enough graceful preferences to work how you want. More on this in a future blog entry.
This has been a major code overhaul: there are many small changes in input-handling behaviour and no doubt Lots Of Fun New Bugs. As always, if something seems wrong or broken or just worse than it was before, it is your duty as an Alert Alpha-Tester to report it as a bug so that I can fix it and make the world a better place.
Another Boxer 1.0 alpha build is up, sporting some of the mouse control improvements discussed in the previous post. Boxer’s existing mouse cursor behaviour is still the default, but locking the mouse is now just a Cmdclick away: quick, intuitive and obvious. I'll be improving both behaviours further in the coming builds, but I'm already much happier with how they work.
This build also features three fewer features:
After reading Rework, 37signals’ guide to kicking yourself in the pants, I felt inspired to start viciously pruning Boxer’s feature-set for the looming release of 1.0. These were fallow features full of bugs and awkward flaws; there was no way they would be finished to my satisfaction before 1.0, were I to release before the oceans boil and all life on Earth comes to an end.
I’m casting my eye around for other fripperies to send to the guillotine, but in any case once game installation is in then I’ll institute a feature-freeze and start calling everything a beta instead.
An important usability problem has come up in this Boxer issue, and I’m belatedly considering how Boxer’s mouse handling should really work. My comment in the issue goes into more detail, but the short version is this:
To me, the best solution is to go back to what DOSBox does: ignore the mouse altogether until its locked. Clicking the mouse inside the DOS view would lock it and Cmdclick (or CmdL) would unlock it. The statusbar would tell you what how to lock and unlock the mouse, so there’d be no how-the-hell-do-I-get-my-mouse-back confusion.
What do you think? Are there other better solutions? Ways to reduce the friction of the proposed solution? Please share your thoughts, here or in the issue itself!
Whatever solution is chosen would become the default for new and existing users. The current behaviour is still appropriate and natural for many programs (such as adventure games and productivity apps) but it’s broken enough of the time that it shouldn’t be the default; I’m ambivalent about continuing to offer it as an option, since that would complicate support (two separate application behaviours instead of one) and doing so means adding interface clutter.
Having stabilized the code long enough to squeeze another build out, I’ve been trying my hand at making things for a bit instead of breaking things.
The last core feature yet to be reimplemented in Boxer 1.0 is game installation: AKA game importing, AKA making a new gamebox out of whatever you’ve got. I’d been flitting cautiously around this feature for a long time, like a thirsty yet apprehensive gazelle, while I figured out how to present it.
In Boxer 0.8x, installing a game was as uncomplicated as could be. You dragged the game onto the "Drop games here" icon, and Boxer worked out what to do with it from there:
If the game looked like it needed installing first (e.g. it came on a CD), then Boxer launched the most likely-looking installer program, and hoped that it would copy its own files into the new gamebox.
If the game looked like it was already installed and ready to go (e.g. like you downloaded it from somewhere) then Boxer converted the game files directly into a gamebox and handed it to you on a platter.
In a nutshell, was this: Boxer would decide entirely for itself what to do, and it would often get it wrong. It didn’t tell you what it was doing, or let you direct it otherwise, and when it screwed up you’d be left with a 300MB paperweight.
Simply, is a proper UI. The game installation process needs to tell you first how it thinks it should proceed, and let you adjust that decision based on what you know about the game. Ideally, offering you this control over the process should make the process seem less confusing and unreliable, not more so; and ideally, the default choice should still be right almost all of the time‚ so that you can trust Boxer to take care of things for you.
We start off with a dropzone, explaining what Boxer can eat. I’m of two minds about dropzones in UIs: they often make it harder to choose files than a simple Open panel, promising an awkward shuffle of Finder windows and swearing at one’s trackpad.
However, an Open panel always feels to me like directing a task, whereas dropping things onto a dropzone feels more like participating in a task, and I think that sense of involvement with the application is important.
In Boxer’s case, the game folder or volume is usually ready on the Desktop or close at hand in the Downloads folder, making drag-dropping fairly painless. And clicking directly on the dropzone will display a standard Open panel, for the cold of heart.
After dropping in the game folder to import, the dropzone slides to one side to become this import confirmation panel: showing you what’s getting imported, and where it will go.
The Change… button beneath the From icon displays an Open panel for choosing a different source folder. The Change… button beneath the To icon displays a Save panel for choosing the name and destination folder for the new gamebox. The destination folder defaults to your last saved location (usually DOS Games), and the initial name for the new gamebox is auto-generated from the source folder’s name.
In future, Boxer might automatically retrieve cover art for the game at this point; for now, you can at least drop your own cover art onto the nascent gamebox to replace the default gamebox icon.
Pushing the More Options button slides out these more specific import options: indicating just how Boxer thinks it should import the game, and letting you tweak its decision before proceeding.
The import panel remembers if you had toggled More Options, and keeps it open for you next time.
This is by no means the final interface, and it exists only in mockups at this stage. But I think it makes a good start on its goals: providing enough information and control over a tricky process, while retaining the simplicity that made this a killer feature in earlier Boxers.
What do you think? Post your insights, suggestions and criticisms in the comments!
Design by 40watt.