Boxer

Developer diary: plans and progress reports.

The best-laid plans of mice and men Sunday 25th April 2010

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:

Boxer’s windowed mouse handling sucks.

So what to do?

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.

Commentary

  1. I have always locked the mouse when playing games that need it. So for me this issue has never bothered me. It just needs practice and it becomes second nature to lock it.

    CritAnime Sunday 25th April 2010

  2. Personally I’ve always found it irritating to realize a game needs locking and then have to consciously remember to press CmdL - even though I designed the app it doesn’t seem to stick in my brain, and always feels like an irritation.

    One alternative solution is to retain the existing behaviour but just make it easier to lock the mouse: Cmdclick to lock and unlock, which is logical and which you can do without taking your fingers off the mouse/touchpad. This would be advertised by a message in the statusbar, so that new users can get quickly used to the idea.

    That doesn’t solve the problem of games scrolling off into oblivion when the mouse is unlocked though.

    Edit: for some reason I’ve been forgetting that Optionclick already locks the mouse: this was a leftover DOSBox feature that Boxer never acknowledged in the UI. I think Cmdclick is more appropriate as a combo though, since Cmd is not recognised as a keypress by DOS.

    Alun Bestor Sunday 25th April 2010

  3. You could do what VMWare and VirtualBox do with guest OS mouse handling when specific virtualised HID drivers aren't installed... the mouse only interacts with the host OS, until you click in the VM window; then mouse input is captured by the VM, until a keystroke is pressed to unlock it. You could have the instructions appear in the status bar only when the mouse is locked, to avoid clutter. Also, how about automatically locking the mouse when going into fullscreen?

    As for the scrolling-to-oblivion, how about moving the Dosbox mouse coordinates to the middle of the Dosbox screen when unlocking?

    John Sunday 25th April 2010

  4. VirtualBox and VMware Fusion both have grab/ungrab keystrokes for the mouse/cursor (for when their Additions or Tools are not active). VBox allows the user to specify the keystrokes with the default being Right-Cmd. I personally like the VBox default of a single key.

    I do find annoying (being polite) is a cursor that jumps wildly from "where was un-grabbed" and "where now grabbed". I would prefer that the cursor, when being grabbed, continue where it was last un-grabbed within the DOS window.

    ChipMcK Sunday 25th April 2010

  5. VirtualBox's "cursor lock" behavior drives me nuts - 95% of the time, I don't want my cursor locked; I want to switch between it and Mac OS. Task switching is probably less common with games than with VirtualBox, but still - it's counter-intuitive and unlike most native Mac OS apps. OpenTyrian does this too, which makes sense if you're using mouse controls, but is totally useless if you're using keyboard controls.

    It'd be awesome to have an icon in the status bar of DosBox for this (maybe a little lock icon or something). You could activate cursor lock with either the keyboard or option-click (or maybe a special per-game setting, or a global setting in preferences.) This would leave more space for other status bar messages. (Sidenote: my favorite status bar message is in Jeskola Buzz. When it's not doing anything, it says, "Ready to rok.")

    Thanks for developing such a handy app - Boxer rocks, and I can't wait for 1.0. :)

    Ryan Monday 26th April 2010

  6. Alun, I say try do something that's never been done before. Have the mouse stay locked unless the user moves the cursor to the edge of the window and deliberately yanks the cursor again to unlock the mouse.

    If well executed, I don't think anyone will accidently poke the cursor out of the window.

    Like I said, it's never been done before but I do feel like it would be the best solution.

    Just to make everything clear, I'll repeat the conditions:

    1. The cursor must be at the edge of the window.
    2. The user must make a somewhat exaggerated movement again in the same direction to pull the mouse out of the window (and unlock the mouse)

    Of course, keep the key combination available considering my solution isn't instantaneously discoverable.

    The best way to describe how this would feel to a user is trying to pull something stuck in jello out of the jello...if you don't pull hard enough, it won't come out, but if you yank on it hard enough you'll pull it out.

    Of course, I know nothing about OS X input but I suppose that it shouldn't be too hard considering it's just a cursor acceleration concept.

    Sludge Vohaul Monday 26th April 2010

  7. Correction to (1) above:

    1. User must bring the cursor to the edge of the window.
    Sludge Vohaul Monday 26th April 2010

  8. Ryan: there already is a lock button in the Boxer 1.0 statusbar, which highlights when the mouse is locked and can be clicked to lock it. However, it’s out-of-the-way and isn't intended as the primary way to lock the mouse. I'm not fond of statusbar messages myself, but I think some kind of message is necessary for communicating a shortcut like Cmd-click — it would only need to appear while the mouse is actually over the window.

    Sludge: that’s a very intriguing idea and I'd like to give that a try to see how well it works. For cursorless games, it would need some kind of indication when the user is close to the window edge though: e.g. the standard OS X cursor fading in.

    Alun Bestor Monday 26th April 2010

  9. [b]Sludge[/b]: I'm sure this might work well, for some games -- but for games, in which you jerk around the mouse repeatedly to perform quick maneuvers, like turning around or steering air/spacecraft -- the cursor would end up outside of the window and the player would end up dead.

    I think the best of both worlds would be (in windowed mode!) to have a bezel (like the volume, brightness one) pop up when the player seems to hit the window border repeatedly, telling the user how to unlock his mouse.

    Visual feedback would further help to understand what just happened to his mouse. For example a small "shock-wave" radiating from the mouse. Just like it is used in some tutorial videos to highlight mouse clicks.

    Manuel van Dyck Tuesday 27th April 2010

  10. Manuel Van Dyck: Not so. Mouse steering in DOS games is almost always governed by the delta of the cursor and the center of the game screen and not mouse acceleration. A cursor on the edge of the game screen (or window in our case) being pushed further into that direction won't make your spacecraft steering more rapidly.

    Did you have any specific game in mind when you posted your message? X-Wing? Play it again...you'll see what I mean.

    Sludge Vohaul Tuesday 27th April 2010

  11. Ah yes, but mouse control in shooters like Doom does indeed rely on continuous input, not mouse delta.

    Besides which, the tearaway behaviour wouldn't be very appropriate for games where steering is based on delta, since it would require you to enter a hard turn in order to free the mouse from the screen. This would be mitigated somewhat by auto-centering the mouse again after it is unlocked, but a key-combo would still be better for those cases (since you could unlock the mouse while it remains at the centre of the screen.)

    Alun Bestor Tuesday 27th April 2010

  12. I never played Doom or Doom 2 with a mouse and never knew anyone that did. Probably a testimony that mouse-support in DOS games was never fantastic. And most people played flight sims and space sims with a joystick.

    It would be interesting to compile a list of DOS games that made extensive use of the mouse to weigh the advantages and disadvantages of mouse-locking. It would be a shame if Doom and X-Wing would (games that, I'm pretty sure, most people played using keyboards and joysticks) would dictate how Boxer's mouse-locking would work.

    Sludge Vohaul Thursday 29th April 2010

  13. In the third scenario where the mouse scrolls the viewport could you move the Dosbox cursor in by 1 pixel when the real cursor leaves the window? This would prevent wild scrolling of the viewport once the real cursor is outside the window.

    Alternatively I like the idea of locking the cursor into the viewport with cmd-click and if unlocked dosbox simply ignores it.

    ldemon Wednesday 30th June 2010

  14. 1 pixel probably isn't enough - I suspect most of these games have a border region several pixels wide that triggers the scrolling behaviour, the exact width depending on the game.

    A safer bet would be to return the mouse to the center of the screen once it leaves the window (and once all mouse buttons are released to finish a drag.) But I suspect that would look and feel a bit weird.

    Ignoring the mouse while its unlocked is what the original DOSBox defaults to nowadays, and it is by far the safest route. I'm reluctant to embrace it wholeheartedly because I really like the convenience that the integrated mouse provides, for cursor-based games that don't have scrolling (and do track absolute position properly.)

    I'm loath to add options willy-nilly, but this one may be divisive enough to be worth a toggle in the preferences.

    Alun Bestor Thursday 1st July 2010

  15. Hello. F117 was the first game I used with Boxer and it played great. A couple things on using Boxer may help me... 1. Using Filevault appears to make Boxer not work (had to turn it off for Boxer to work) Is there a work-around and how do you make an INSERT keystroke ? F117 uses INSERT to toggle an option.

    David Saturday 3rd July 2010

  16. Could you describe what specific problem you were having with FileVault, and were you using Boxer 1.0 or one of the older 0.8x releases? If it's complicated to explain in a comment, please send me an email about it (that’s my preferred way to handle support issues as it's easier to go into detail and to follow up.)

    As far as INSERT goes there is no equivalent key on Mac keyboards, so currently no way to trigger it, but I'll see about adding another "Send Key"-menu shortcut for it. While we’re on the subject, are there any other keys that people have had problems using in Boxer?

    Alun Bestor Saturday 3rd July 2010
Add your two cents

Design by 40watt.