Boxer

Developer diary: plans and progress reports.

A new month, a new build Tuesday 1st June 2010

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.

Behind the scenes

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.

So what happens now?

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.

Commentary

  1. Via the automatic update of Boxer there comes the message "The update is improperly signed". Have I done something wrong?

  2. No, it’s not your fault - I’d only managed to screw up the 20100601 build even more by leaving out a necessary update signing key, which meant that build can't auto-update itself (as you’ve found). Because of this, you’ll need to download the new 20100602 build yourself from the page linked above.

    From now on I’m going to start releasing things in the morning, instead of late at night.

  3. Ran for hour plus. Nothing unexpected. But then, I am not dong anything intense.

    Great product; I do enjoy using it!

  4. I've just uploaded a new point-release which fixes some important mouse bugs that came to light in the previous build. In particular, the mouse now behaves properly again in Windows 3.1 (and probably lots of games) while locked or in fullscreen mode.

    This restores the locked mouse behaviour to how it was in DOSBox and older Boxer versions, while still retaining all the improvements I've made since. Which makes me happy, since I don't have to worry about breaking a game behind someone's back any more.

  5. I had the same thing with some of the other alpha's so it could be just a setting I'm overlooking but I have some difficulty's getting around in dos because the keys on my apple keyboard are mapped differently ( the ":" key and the "/" key for example ). Is it a bug in the beta or can I fix it somewhere else.

    Loving the product! Can't wait for that neat install feature!

  6. Hi Raymond, this is a keyboard layout problem - what OS X keyboard layout are you using? You can find this out from System Preferences -> Language & Text -> Input Sources.

  7. Hi Alun! Thank you for Boxer, it's awesome!

    One thing I really like in the alpha is the "Fancy Smoothing" rendering style. Is that like HQ4x? I have tried to emulate that with countless settings in DOSBox, to no avail. I wanted to simply scale up the HQ2x (640x400) to the 13 Inch Macbook's native res (1280x800). If I use HQ2x in 0.87 it will not scale up to the monitor resolution, but stay fixed at 640x400. If I used HQ3x, same, and it wouldn't fill the whole screen. HQ4x seems to exist in DOSBox (I haven't tried DOSBox separately), but did not have any effect in Boxer 0.87.

    Anyways, that's a great addition. Do you think it's possible to scale the HQ2x up in 0.87 with some obscure settings perhaps?

    Some concerns with the alpha: - typing "ver" showed DOSBOx version 0.73, while the Boxer about box says 0.74 - the CPU cycle and frameskip shortcut didn't work, I hope you'll keep them because it's handy in fullscreen not to switch to the Inspector and also more practical for racing games where if you stop controlling the vehicle you can't really appreciate the effect of the cpu cycle finetuning (because the vehicle stops by the time you click in the Inspector window, hope that makes sense) - There were only 4 rendering styles in the alpha, and the DOSBox config file didn't seem to be updated or used anymore (the one from the gamebox). I hope you will continue to support "advmame2x", I think it was better than the Cmd-1 rendering style in the alpha (which messes up the original pixellated art too much imho, whereas HQ4x "fancy smoothing" is sharper).

    I'm reverting back to 0.87 for the time being because of the sexy shelves :)

    Do you have a changes list somewhere for BOXER 0.88 BETA that appears on the home page?

    PPS: After trying the alpha it seems I have lost the "Boxer" window style, when I run a game with 0.87 I no longer have the Boxer UI, the menu bar says "DOSBox" instead of "Boxer", there is no Inspector for example. Is there a hidden setting file somewhere that I could erase to "reset" to 0.87 fully?

  8. Hi Fabrice, there's a lot to reply to there and I don't understand you fully on some points, but here goes:

    Rendering styles vs. scalers

    • “Fancy Smoothing” in Boxer 1.0 uses HQ2x filtering at small window sizes, switching to HQ3x filtering at larger window sizes and in fullscreen.
    • “Fast Smoothing” uses AdvMAME2x at small window sizes and AdvMAME3x at larger sizes.

    There is no way to control when Boxer switches between the two sizes; it’s entirely transparent to the user, and Boxer does not intend to provide fine-grained user control over scaler behaviour. That's also why the scaler setting in conf files is no longer used.

    I will be adding additional rendering styles to future Boxer versions, but Boxer’s system is not meant to be representative of (or compatible with) DOSBox's scaler options.

    That's all beside the real question: is AdvMAME3x actually worse-looking than AdvMAME2x for most games? Personally I feel it looks better, but I am interested to know what users think, and I’m open to changing the “Fast Smoothing” style so that it uses AdvMAME2x all the time.

    (Regarding fullscreen scalers in 0.87: there is no way to make a scaler fill the screen properly in 0.87 or DOSBox; the old DOSBox renderer simply doesn't allow it.)

    Other stuff

    The incorrect version number that VER reports at the DOS prompt is a DOSBox bug: the original DOSBox 0.74 also reports itself to be “0.73” this way. I'll try to remember to fix this in the next build.

    The removal of the speed up/down shortcuts is temporary, and I'll add them back in in a future build. The problem is that Boxer 1.0 currently has no way to give you feedback when you change the speed outside the Inspector panel. I had intended that the speed changes would show a notification bezel inside the window indicating the current speed, but as discussed in the original post this will have to wait until the renderer can actually display such notifications.

    There's no changelist for the 0.88 beta, but the only real changes were some extra game configurations and updating the shelf art to fit OS X 10.6. At some point soon I'll release a final maintenance release of Boxer 0.88 that uses DOSBox 0.74, and will put together a proper changelist for that. (That will, hopefully, be the last 0.8x release ever.)

    On your final comment, it sounds like you're confusing the two different versions of Boxer and how they each work:

    • Boxer 0.87 is just a UI-less wrapper around the standard DOSBox application - once you launch a game with it, it starts up DOSBox and so what you see is DOSBox's own UI (Boxer 0.87 never had its own).
    • Boxer 1.0 is a standalone application with its own UI, and its own internal version of the DOSBox emulation core.

    Launching a game with Boxer 0.87 will give you DOSBox's UI; launching a game with Boxer 1.0 will give you Boxer 1.0's UI. Hope that clears things up!

  9. Guys i used to be seduced by the sleek, smooth and siren beauty of the graphical filters but i have seen the light. Now i relish playing games in there full pixelated glory, it just ain't the same without those grainy pixels. Smoothing is evil pixels are not.

    All joking aside, man i can't wait to get my hands on version 1.0. I am way to lazy without the automatic game installer, but there are quite a few games i want to try out.

  10. Fortunately Boxer 1.0 also has the best pixels in the business ;) I've taken extra care with Boxer's renderer to ensure that upscaling is as crisp and sharp as possible regardless of rendering style.

  11. Thank you for the thoughtful reply Alun, clears a lot of things up!

    In case that's helpful to other readers wanting to use hq3x in fullscreen on a 13 inch Macbook (1280x800) : set fullresolution=original, and scaler=hq3x in the DOSBox configuration file. It does not fill the entire screen, but close! There is only a 32 pixel gap around the picture. Previously I had fullresolution=1280x800 and that wouldn't allow hq3x to scale up.

    Totally understand about making the scaler/rendering styles user friendly. Also I understand you're creating much more than a DOSBox frontend ;) I was just a little worried that you'd drop other interesting render styles in favor of stripping down the options.

    Now that you mention it, it does appear that advmame2x is better than advmame3x, in my opinion. If I reduce the window size, the Might and Magic menu text looks nice. That is the letter "tips" are square. If I scale it up, the letters really change in appearance, the tips are rounded, so the font becomes more like Microsoft's infamous "Comic Sans" font. So while there is nothing wrong with advmame3x as such, the rendering style looks different between small window and large window. This doesn't seem to happen with HQ2x/HQ3x, where the style remains similar, only sharper and finer at higher resolution.

    I like HQ2x/HQ3x better because it maintains some of the pixellated appearance, but really improves the text. When you have grainy backgrounds like stone/parchment, advmame3x makes it look a bit strange, it tends to be more "faithful" to the original picture with hq3x I think.

    Come to think of it it would be awesome if it could be detected when a game renders a font, as you could use a different, even slower algorithm specific for smoothing the fonts.. but I suspect that won't work unless the game uses the MS DOS font right? AFAIK, those are just textures and each game renders text in their own custom way. Not sure how you could detect that a graphic is a font.

    Hmm do you reckon someone 's ever made a render style for flat panels that emulate the CRT look ? CRT's used to blur the graphics, so that the technique of mixing pixels worked wonders. If I remember well there was an article about smoothing fonts for flat panels I think it took advantage of the placement of the red/blue leds on a flat panel to simulate sub-pixels. I wonder if anyone's come up with a render style for old games that uses a similar approach?

    Off with my ramblings, thank you so much for Boxer! I'm hooked!

    @KRISTJAN: Hehe I am really tempted to play without filters, but the thing is flat panels just dont render the graphics faithfully. Graphics were low color, but really smooth on my Amiga back in the days. Some artists like Bitmap Brothers really mastered pixel art on CRT's, their games just dont look right on a flat panel.

  12. Posted Crash Report over at BitBucket from today's download

Add your two cents

Design by 40watt.