A new Boxer 1.0 alpha build is fresh out of the oven. Since this build has ended up focusing on UI refinement, a few gratuitous screenshots seemed in order:
Opening additional gameboxes or DOS windows will launch additional Boxer instances to handle them. More on this below.
Besides looking cleaner, the panel now highlights the default program and bumps it to the start of the list. It also slides away after clicking the default program, instead of hanging around taking up space.
button now enlarges the window to fit all the available space, instead of fitting it to a multiple of the DOS resolution.So what are you waiting for? Go grab it already.
A limitation which has dogged Boxer 1.0 from the very beginning is DOSBox’s one-shot nature. Because DOSBox is compiled into Boxer, Boxer’s memory is DOSBox’s memory; and DOSBox stores its emulation state in a vast hive of global variables, which it doesn’t bother cleaning up afterwards.
This prevents DOSBox from handling two emulation sessions at once — because each session clobbers the other one’s state — and from starting up a second emulation session after finishing the first — because the subsequent session inherits a hopelessly polluted state from the first one. Imagine a living room the morning after a student party.
This is of no concern to a hard-living Windows transplant like DOSBox, which was designed to quit as soon as the emulation exits. But it is of concern to a well-behaved native app like Boxer, which wants to stay open in the Dock, and to be able to open and reopen as many windows as it needs, just like all its other Mac chums.
Boxer was a sad panda. Until now.
Would be for Boxer to move the DOSBox emulator core to a separate child process with its own isolated memory space, and spawn instances of this emulator process for each window. This way DOSBox could shit in its own sandpit as much as it likes, it could run alongside other emulator processes without fear of cross-pollution, and it could be terminated or paused or restarted at will by the parent application (Boxer) without ruining everyone else’s day.
This was the approach that Google Chrome took for its tabs, that OpenEMU adopted for its multi-emulator cores, and that Boxer will eventually use for its DOS sessions.
However, restructuring Boxer to manage this parent-child process relationship is complex and has a lot of pitfalls. The groundwork for it is pretty far along, but it’s unlikely to be ready in time for Boxer 1.0.
Is for Boxer to simply launch more Boxers. When Boxer has a DOS window open and it gets a request to open another, it just spawns a new Boxer instance and tells that to open the window instead. If you try to open a new window after closing one, then Boxer quits and immediately relaunches to open the new window with a clean slate.
This approach has disadvantages. Each Boxer instance is a separate application as far as OS X is concerned: so they appear separately in the Dock and CmdTab switcher. Instances can’t coordinate with each other: so windows tend to open exactly over the top of existing ones, and preference changes in one don’t take effect immediately in another. This is very much a stopgap solution.
But, grubby and hackish though this is, it’s so dramatically better than before that I wanted to get it out there for people to play with right away.
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.
Design by 40watt.