alunbestor commented on 16 Apr 2015

My apologies for letting this issue languish without a proper response for so long.

The plain answer for why I haven't done a 2.0 release is that vital parts of the 2.0 codebase are still either broken, feature-incomplete, dated, or just plain worse than 1.3.2; that a fixed-up 2.0 would not represent a genuine improvement for users over 1.3.2; and that I have not had the time or the enthusiasm to hammer what's there into something that is a genuine improvement. There are a host of reasons for this, which I'll discuss in detail below.

First, some core features are still broken in the master branch: primarily game importing, which currently crashes if it tries to show a DOS installation window, owing to changes in the window model for regular DOS sessions. Those window changes were needed for the new full-window program launcher UI, which turned out to be an unfit UI design that needs to be rethought. That has discouraged me from fixing the game importing until a new design is in place, as otherwise it'd need to be fixed all over again.

As lavadrop noted, Boxer 2.0's rendering is noticeably laggier than Boxer 1.3.2's. I rewrote Boxer's renderer for 2.0 to use hardware shaders for rendering styles, which at the time I saw as a big win; but when I wrote that code I did not understand the foibles of OpenGL as well as I do now, and I made a number of mistakes with the rendering path that result in worse performance than 1.3.2. This is an unacceptable regression, and those mistakes are hard to fix without rewriting that whole subsystem again.

Aside from the renderer, I rewrote large swathes of the Boxer codebase to what at the time I considered modern coding standards. Most of those rewrites were more successful than the renderer's, insofar as they didn't make the application any worse, but they still left me with a legacy 32-bit-only Objective C codebase that has no migration path to Swift, nor lets me use modern ObjC features like ARC and automatic property synthesis. A codebase that will be worthless as soon as Apple decide to drop 32-bit binary support.

These rewrites did not even (though they were intended to) fix what are now serious structural problems. Boxer is riddled with hidden assumptions about view and controller hierarchy; key-value bindings all over the place that invisibly trigger action at a distance; deep coupling where all roads lead to the app delegate; implicit reliance on emulator events occurring in a specific order that not even I can keep straight; and so on. These problems stemmed from unwise design decisions I made as a neophyte Objective C programmer back in 2010, and are now blindingly obvious to me as an experienced developer. They have made Boxer's codebase brittle, hard to improve and extend, hard to debug, nearly impossible to write tests for, and increasingly frustrating to work on.

The rewrites also got me no closer to my ultimate goal, which is to split Boxer from a single-threaded app into separate processes for UI and emulation. This would allow a host of important improvements: like not stalling the emulation whenever the UI is interacted with, like being able to restart an emulator session without restarting the whole app, like finally being able to migrate Boxer to 64-bit, like being able to substitute dosbox-x or even another DOS emulator altogether. Instead, my 2.0 rework ended up wedding Boxer ever more tightly to DOSBox 0.74, making that goal even harder to achieve.

Meanwhile OS X 10.10 put a bullet through the head of the skeumorphic aesthetic that was so fashionable during Boxer's glory years. A lot of the UI work I did for 2.0 is now grossly tacky and would look immediately dated upon release. Modernising the look of the application is probably less work than it sounds - it's about taking away, rather than adding - but it's also extremely dispiriting to have wasted so much time on an aesthetic that is now definitively dead and buried.

So while I regard the 2.0 codebase as ultimately a failure, it does have a number of key improvements over 1.3.2:

The underlying launcher system (where a gamebox can have multiple named program-launch options, with custom parameters) is a lot better than 1.3.2's single 'default program' system. This will be the foundation of a simple and flexible launcher panel, once I figure out how that should be presented in relation to the rest of the UI. (The full-window launcher panel design that 2.0 currently has is not it.)

The game detection system is more robust and capable, theoretically allowing detection of multiple games within a single source, which will help with game disambiguation during importing (a big problem with Sierra CD collections, for instance). This capability is not currently used by 2.0's game importer, however.

There are classes to natively read ISOs and BIN/CUE images, which will speed up game scanning and will finally allow importing from BIN/CUEs. These are not currently used by 2.0's importer either, and it still needs a raw FAT image reader as well to provide full coverage.

The joystick controller subsystem has improved considerably behind the scenes, among other things allowing joystick buttons and axes to trigger key inputs. This requires a proper controller configuration UI to be of any use to anyone - a UI which has not been designed yet and will be a major amount of work.

There is drive shadowing, a feature which I am not convinced should be turned on by default but which is vital for some use cases (such as standalone apps, like those that GOG release). This needs a simple and clear per-game UI to control it, along with clear documentation on what it does and where all your savegame files have gone.

There is the documentation popover, which was the only wholly successful UI addition, and which provides an elegant way to view and add documentation to your games.

There is printer emulation, which is easy to use, fairly reliable, looks cool and is already benefiting a number of business application users. It is also cheesily skeumorphic; the presentation needs cleaning up to show more of what you're printing and less of tacky faux-printer chrome.

There are many new game profiles, and proper handling of OS X 10.9+'s accessibility permissions, and fixes for small but serious bugs like the import hanging forever because of busted .conf files.

So, why not port just the bits that worked back to 1.3.2 and do a release from that? Because I shot myself in the foot with all my code modernisation. The underlying code has changed dramatically, such that even the improvements I made to pre-existing features cannot be dropped into the 1.3.2 branch without significant rework. (This, people, is why you shouldn't embark on a Big Rewrite unless you're damn sure you can finish it in one sitting.)

Because of the structural problems I outlined above, I also don't want to put significant time into building anything new upon the 1.3.2 codebase. Boxer needs to be dragged kicking and screaming into the 64-bit era or it will be lost for good, and 1.3.2 is not the starting-point from which to do that. The most I would want to do from that base is a 1.3.3, that included the small bugfixes mentioned above along with Retina artwork. And that's hardly the grand update people would expect after 3 years of silence.

Thus Boxer sits wedged in a proverbial hallway, like the sofa in Dirk Gently's Holistic Detective Agency, unable to move forward or backward. And for the past few years my personal and professional life has left me with no time or energy to address that and decide what to do about it.