I thought you would naturally go for all out accuracy. It surprised me you were considering playability in your emulator design, since I thought the whole point of BSNES was pure accuracy.Would you prefer we treat peripherals like special chips and just worry about speed and playability, or treat it like the base unit and worry about all-out precision?
bsnes v0.036 released
New WIP.
This adds all the aforementioned fixes. I got the speed hit to ~1% with no light gun, and ~7% with.
All three light gun modes allow you to go offscreen by 16 pixels in either direction, and Super Scope's offscreen flag is now supported. Mouse still needs the speed bits supported.
I also modified the cursor just a bit by adding dots to each side of the circle. Makes it look a lot better. Not sure if I should add a shadow around the cursor or not. It really helps on red screens, but it seems kind of obtrusive to the view everywhere else.
Oh, and the cursor works as expected in hires and/or interlace modes now.
Also, x_axis, y_axis, button_NN is now mouse.x_axis, mouse.y_axis, mouse.buttonNN. joypadNN.button_NN and joypadNN.axis_NN are now joypadNN.buttonNN and joypadNN.axisNN. So be sure to update the config file again. Hopefully for the last time.
I have not added the new input changes just yet, so the mouse button 0 still auto-assigns in the GUI. Use the spacebar or enter to bring up the assignment window for now. That also means that joypad analog axes won't work well for mouse simulation still.
Other than what I mentioned above, please let me know if you spot any bugs this time around. Especially regarding the shots not going where you expect them to. I didn't test Yoshi's Safari myself, but it should be fine now.
This adds all the aforementioned fixes. I got the speed hit to ~1% with no light gun, and ~7% with.
All three light gun modes allow you to go offscreen by 16 pixels in either direction, and Super Scope's offscreen flag is now supported. Mouse still needs the speed bits supported.
I also modified the cursor just a bit by adding dots to each side of the circle. Makes it look a lot better. Not sure if I should add a shadow around the cursor or not. It really helps on red screens, but it seems kind of obtrusive to the view everywhere else.
Oh, and the cursor works as expected in hires and/or interlace modes now.
Also, x_axis, y_axis, button_NN is now mouse.x_axis, mouse.y_axis, mouse.buttonNN. joypadNN.button_NN and joypadNN.axis_NN are now joypadNN.buttonNN and joypadNN.axisNN. So be sure to update the config file again. Hopefully for the last time.
I have not added the new input changes just yet, so the mouse button 0 still auto-assigns in the GUI. Use the spacebar or enter to bring up the assignment window for now. That also means that joypad analog axes won't work well for mouse simulation still.
Other than what I mentioned above, please let me know if you spot any bugs this time around. Especially regarding the shots not going where you expect them to. I didn't test Yoshi's Safari myself, but it should be fine now.
you could just, ya know, NOT remove a monitor from your computer while playing a game? o_o yea it does occur when changing refresh rate in Windows too and is also fixed by adjusting the scaling. I doubt it is worth fixing or working around though.
Core i7 920 @ 2.66GHZ | ASUS P6T Motherboard | 8GB DDR3 1600 RAM | Gigabyte Geforce 760 4GB | Windows 10 Pro x64
-
- Buzzkill Gil
- Posts: 4294
- Joined: Wed Jan 12, 2005 7:14 pm
I'm curious how a "reload" button makes accurate emulation difficult versus the offscreen border. Can't you just emulate a blinded gun?byuu wrote: I have to admit that a button assignment is damn convenient, though. Even if it does make the game five times easier than it should be. Then again, I should also say that a button to reload the gun would be difficult for proper cycle-timed emulation of the guns, if we ever go that route.
I know that slipping a hand forward so you could block the barrel with your hand was a somewhat popular lightgun trick(on handguns, anyways... good luck trying that with the Super Scope), so it's not exactly an unfaithful reproduction.
Most of the challenge added was from the conscious decision to reload, not the actual act of reloading, which was incredibly easy.And really, if you want to cheat like that, just use an infinite bullet Game Genie code or something. What's the difference?
I've always found the mouse cursor to be a very poor substitute for a light gun. It's a lot slower and less intuitive.
But then I also stand as far back as possible with a lightgun, so it takes very slight movements to cover the screen. I seem to be in the minority there.
Well, it's honestly not too terribly difficult. It just wouldn't model the hardware. I'd have to add another input poll for a fake "reload" button, and when that's set, it'd still send the trigger message, but suppress the counter latching.I'm curious how a "reload" button makes accurate emulation difficult versus the offscreen border. Can't you just emulate a blinded gun?
Just seems like a code would be more productive. Maybe we can find one that makes it reload even when you shoot onscreen, but only if your bullet count is zero.
Yeah, and pointing the NES Zapper at a light bulb was a big one, too. That one doesn't detect the CRT cannon; only luminance. So when you shoot, the screen turns all black for a frame or two, but with white sprites where the "valid trigger points" are. So if you hold the Zapper at a light bulb, it appears as though you land every hit.I know that slipping a hand forward so you could block the barrel with your hand was a somewhat popular lightgun trick
You could also use a magnifying glass on the end to increase the collision area. Fun stuff.
Oh, I agree completely. I've always considered their emulation to be rather silly.I've always found the mouse cursor to be a very poor substitute for a light gun. It's a lot slower and less intuitive.
I can't get past stage 18 in Lethal Enforcers' training mode with the mouse (how many training levels are there?!), after ~12 or so, you simply cannot move the mouse fast enough to hit all the targets. The levels themselves are easy enough, though.
Unfortunately, there's no other real option. Even if there are light gun style devices for PCs (no doubt using sensor bars for LCDs), they're just far too uncommon to be worth supporting.
-
- Buzzkill Gil
- Posts: 4294
- Joined: Wed Jan 12, 2005 7:14 pm
The Zapper trick only works on a few games, though. Developers quickly started adding a black frame before the hit box frames to stop that nonsense. Just check for black before you start checking for hits, and voila! no more bulb cheat.byuu wrote:Yeah, and pointing the NES Zapper at a light bulb was a big one, too. That one doesn't detect the CRT cannon; only luminance. So when you shoot, the screen turns all black for a frame or two, but with white sprites where the "valid trigger points" are. So if you hold the Zapper at a light bulb, it appears as though you land every hit.I know that slipping a hand forward so you could block the barrel with your hand was a somewhat popular lightgun trick
...
Or check all the hit boxes in a multi-target game instead of stopping at the first confirmed hit. Multiple hits in one shot should flag a cheater fast.
Well, I appreciate that they're "better than nothing", but... how much better is debatable.Oh, I agree completely. I've always considered their emulation to be rather silly.I've always found the mouse cursor to be a very poor substitute for a light gun. It's a lot slower and less intuitive.
If I recall, there's ONE set, and it uses beam scan, just set up for the progressive scan of a VGA monitor instead of NTSC/PAL's interlaced scan.Unfortunately, there's no other real option. Even if there are light gun style devices for PCs (no doubt using sensor bars for LCDs), they're just far too uncommon to be worth supporting.
If I recall, support is trivial since the gun controls mouse cursor.
Obviously, it's an older product, since the CRT is dead.
The MAME cab community loved them, but they're the only ones.
It occurred to me today that the pc mouse as the peripheral on which to simulate these cursor devices might not be as appropriate or important as joystick axes. Perhaps the focus should shift to the joypad.
a) multiple peripherals would require multiple mice or multiple controllers, and the former is much more difficult to set up and use.
b) some peripherals had more buttons than a typical mouse can accommodate
c) certain ultra-portable platforms don't have mice and would be completely dependent on joystick axes support if the emulator was ever ported to them
d) linux/windows mouse handling differences more difficult to reconcile?
a) multiple peripherals would require multiple mice or multiple controllers, and the former is much more difficult to set up and use.
b) some peripherals had more buttons than a typical mouse can accommodate
c) certain ultra-portable platforms don't have mice and would be completely dependent on joystick axes support if the emulator was ever ported to them
d) linux/windows mouse handling differences more difficult to reconcile?
Yeah, I definitely want to support both as input types. Biggest problem is that it really does suck using the joypad axes to control these devices. The games are multiple times harder to play this way.
Oh, and that reminds me ... I should break out my Wacom tablet and try some Super Scope games with that. I bet that'd be fun.
Any rich people here with one of the LCD tablets, or a touchscreen monitor?
Oh, and that reminds me ... I should break out my Wacom tablet and try some Super Scope games with that. I bet that'd be fun.
Any rich people here with one of the LCD tablets, or a touchscreen monitor?
-
- Buzzkill Gil
- Posts: 4294
- Joined: Wed Jan 12, 2005 7:14 pm
I know a low-budget approach that works moderately well...byuu wrote:Yeah, I definitely want to support both as input types. Biggest problem is that it really does suck using the joypad axes to control these devices. The games are multiple times harder to play this way.
Oh, and that reminds me ... I should break out my Wacom tablet and try some Super Scope games with that. I bet that'd be fun.
Any rich people here with one of the LCD tablets, or a touchscreen monitor?
Instead of gamepad thumbsticks, get a real analog joystick. Use it in an absolute positioning setup.
With a little practice, you can do shooting stuff fairly accurately that way. Try it in MAME if you don't believe me(load one of the games that uses a positional gun instead of a light gun, AKA the kind that have the guns on a big post in the control panel instead of free-floating).
It's not as good as it could be, but it's reasonably decent. Also try it with Star Wars, which used a flight yoke-ish thing to control the targeting cursor originally.
It's not like that couldn't be improved. The speed at which the mouse moves is so slow, it's hard to imagine a joystick couldn't be made to perform as well. I can't comment on the difference because it's not working for me at all at the moment.byuu wrote:Biggest problem is that it really does suck using the joypad axes to control these devices. The games are multiple times harder to play this way.
http://www.hkems.com/product/xbox/LCDTopGun.htmbyuu wrote: Unfortunately, there's no other real option. Even if there are light gun style devices for PCs (no doubt using sensor bars for LCDs), they're just far too uncommon to be worth supporting.
The way i understand it is that it basically works like a mouse, and the coordinates are tracked with the led bar
New WIP. Not really worth grabbing if you have a previous one, progress is very slow but steady here.
First, I kept the just-in-time cycle-accurate Super Scope / Justifier latching support; but optimized things to reduce the overhead even more. It's now ~0.5% speed hit with no light gun, and ~1.2-1.5% with.
Next, I rewrote ruby::input and the DirectInput driver to scan at O(1) instead of O(n). With that, I increased the max # of joypad buttons per controller to 128 (the # doesn't affect speed anymore -- 128 is just a hard limit with DirectInput), and gained a ~2% speedup over the old method.
Renamed the mouse axes again, to just "mouse.x" and "mouse.y", sorry.
Added a blocker for mouse.button00, but as the new input system merges key_down/key_up/axis into one single-pass scan, it's now mapping mouse motions, and if not that, lousy analog joypads that return sporadic values.
Hey, it's a WIP release for a reason, right? Getting there, my idea is to have the input driver return information about what "type" of input each symcode is, and then pass masks from the input configuration mapping to control which types of input are considered valid for each of the different types of controls.
Not sure if I want to allow the Mouse/SS/Justifier axes to be mapped by swinging the mouse fast in a given direction (the threshold now is any movement at all, I'd make mapping it require +100/-100 in any direction so you have to move it fast to map it), or use a dropdown box for that.
Oh, and I added the glow shadow I was talking about earlier to the light gun cursors. If you do decide to try out the WIP, let me know what you think of that.
The Linux port is pretty much 100% busted at this point. I have to port all of the SDL / X input drivers over to the new system.
Ah, and if anyone's bored and has a five button mouse, try mapping top thumb to left, bottom thumb to right, left click to B, right click to Y, and middle click to start; and then play Super Mario All Stars - Mario 1. 100% control via mouse alone = good times :D
I made it to 4-2 on my first life.
First, I kept the just-in-time cycle-accurate Super Scope / Justifier latching support; but optimized things to reduce the overhead even more. It's now ~0.5% speed hit with no light gun, and ~1.2-1.5% with.
Next, I rewrote ruby::input and the DirectInput driver to scan at O(1) instead of O(n). With that, I increased the max # of joypad buttons per controller to 128 (the # doesn't affect speed anymore -- 128 is just a hard limit with DirectInput), and gained a ~2% speedup over the old method.
Renamed the mouse axes again, to just "mouse.x" and "mouse.y", sorry.
Added a blocker for mouse.button00, but as the new input system merges key_down/key_up/axis into one single-pass scan, it's now mapping mouse motions, and if not that, lousy analog joypads that return sporadic values.
Hey, it's a WIP release for a reason, right? Getting there, my idea is to have the input driver return information about what "type" of input each symcode is, and then pass masks from the input configuration mapping to control which types of input are considered valid for each of the different types of controls.
Not sure if I want to allow the Mouse/SS/Justifier axes to be mapped by swinging the mouse fast in a given direction (the threshold now is any movement at all, I'd make mapping it require +100/-100 in any direction so you have to move it fast to map it), or use a dropdown box for that.
Oh, and I added the glow shadow I was talking about earlier to the light gun cursors. If you do decide to try out the WIP, let me know what you think of that.
The Linux port is pretty much 100% busted at this point. I have to port all of the SDL / X input drivers over to the new system.
Ah, and if anyone's bored and has a five button mouse, try mapping top thumb to left, bottom thumb to right, left click to B, right click to Y, and middle click to start; and then play Super Mario All Stars - Mario 1. 100% control via mouse alone = good times :D
I made it to 4-2 on my first life.
The scale is based on my gaming optical mouse (it was the only 5-button mouse I could find without a tilt wheel; fuck those things), so the DPI scaling I use is pretty high. I'm having trouble getting it to move at the speed of your regular mouse universally, because I don't know what the speed of the mouse is to interpret the mouse movement results.The speed at which the mouse moves is so slow
I still think that the superscope turbo mode should be a menu option, leaving the scroll wheel button free for mapping as the pause button. About the scrollwheel, it could be a neat thing to use it as the toggle for the turbo mode.
What is your opinion about using the scrollwheel?
I am thinking of scrolling down to turn it on and scrolling up to turn it off.
What is your opinion about using the scrollwheel?
I am thinking of scrolling down to turn it on and scrolling up to turn it off.
We already require that for the vsync option. No other emulators need a speed setting for the mouse, so I'd like to avoid that if possible :/Make mouse speed an adjustable option?
Meh, I don't care. I'll map it as another axis. Fairly impractical though, your range is very limited (~3-4 ticks per poll, tops), and it doesn't hold state like a button (plus it has two possible directions), so I imagine it'll be pretty useless.What is your opinion about using the scrollwheel?
---
Well, I can't seem to find anything to help scale the mouse ratio. How about we spin off the "Input" panel to "Input Assignment" and "Input Configuration"?
The former would have just the type+subtype dropdowns, the listbox and buttons at the bottom. The latter would have the out-of-focus settings, as well as tolerance settings for mouse movements, joypad movements and resistance, and anything else that comes up along the way.
I wouldn't try splitting off anything yet, there has to be a better way.
Maybe you can make axis and mouse movement detection/mapping exclusive to the peripheral sections, blocking them on the controller. They're so sensitive that it's hard to setup the basic controller without one of them beating you to the punch.
Something very strange is happening to me, perhaps you can help me figure it out. I'm using an official Dual Shock 2 controller with an adapter. The controller has two thumbsticks and an "analog" button that enables them. When the analog button is enabled, thumbstick 1 essentially duplicates the dpad assignments and then some while the dpad moves to something called the "hat switch" that only recognizes extremities. When I go to bsnes and dick with the controller mapping, moving thumbstick 1 hard in the up direction results in "joypad00.up" being detected instead of an axis, as if it were the dpad. Here's the wierd part. If I wiggle it infinitesimally up, it instead detects "joypad00.axis01". When I try to set this axis to my scope cfg, the screen cursor refuses to move for me at all. It just stays in the middle of the screen.
I can't get bsnes to recognize thumbstick 2.
An idea that I had that would get these things working for everyone and every platform, would be to create 4 mappable directions that could be assigned to a dpad (diagonals would be possible). The pace would be constant, and changeable in the advanced section. I honestly think that would work pretty well without all the headache of trying to mess with this axis stuff. Check out T2 - The Arcade Game, the actual game used this sort of thing. Is it as good as a mouse when you can get one to work? No, but it's easier and this isn't exactly counter-strike. If you wanted to complicate it a little, it might be advantageous to create a second "turbo" rate of movement that is mappable to a shoulder button and takes effect when it is held down. Then you've got a rate that is slow enough for refined movement, and fast enough to fly around the screen.
As for the super scope cursor, I haven't seen a game using a pure red background to necessitate a shadow, but it does look okay.
Maybe you can make axis and mouse movement detection/mapping exclusive to the peripheral sections, blocking them on the controller. They're so sensitive that it's hard to setup the basic controller without one of them beating you to the punch.
Something very strange is happening to me, perhaps you can help me figure it out. I'm using an official Dual Shock 2 controller with an adapter. The controller has two thumbsticks and an "analog" button that enables them. When the analog button is enabled, thumbstick 1 essentially duplicates the dpad assignments and then some while the dpad moves to something called the "hat switch" that only recognizes extremities. When I go to bsnes and dick with the controller mapping, moving thumbstick 1 hard in the up direction results in "joypad00.up" being detected instead of an axis, as if it were the dpad. Here's the wierd part. If I wiggle it infinitesimally up, it instead detects "joypad00.axis01". When I try to set this axis to my scope cfg, the screen cursor refuses to move for me at all. It just stays in the middle of the screen.
I can't get bsnes to recognize thumbstick 2.
An idea that I had that would get these things working for everyone and every platform, would be to create 4 mappable directions that could be assigned to a dpad (diagonals would be possible). The pace would be constant, and changeable in the advanced section. I honestly think that would work pretty well without all the headache of trying to mess with this axis stuff. Check out T2 - The Arcade Game, the actual game used this sort of thing. Is it as good as a mouse when you can get one to work? No, but it's easier and this isn't exactly counter-strike. If you wanted to complicate it a little, it might be advantageous to create a second "turbo" rate of movement that is mappable to a shoulder button and takes effect when it is held down. Then you've got a rate that is slow enough for refined movement, and fast enough to fly around the screen.
As for the super scope cursor, I haven't seen a game using a pure red background to necessitate a shadow, but it does look okay.
I'm not against the preliminary mouse support in bsnes per se.. if you know you're going to eventually work on it some more and make it more accurate (so that the variable mouse speed is supported for example) but if you know or suspect you're not going to work on the mouse in the future support should be dropped imo.
As it is, it's really more functional than accurate..nothing wrong with that in itself but others Snes emulator aleady offer that so (again >>>) imo there's no point in adding it just to catter to users.
As it is, it's really more functional than accurate..nothing wrong with that in itself but others Snes emulator aleady offer that so (again >>>) imo there's no point in adding it just to catter to users.
I want to fry~~ Sky Hiiiiiiiiigh~
Let's go-o-o-O~ togeda~
Let's go-o-o-O~ togeda~
I fixed up the SDL and X input drivers to work with the new model, so the Linux port builds again.
For the sake of testing, this WIP disables the "mouse acquired" requirement, and raises the divider on motion to 5000 from 5. In other words, this release will work with gamepad thumb sticks, but not with mice.
Having a lot of trouble coming up with a way to get both working cleanly. But yeah, you can at least see how it works now.
You want to set the X axes to "joypad00.axis00", and Y axes to "joypad00.axis01". Use the config file, input assignment is still screwed.
You think that's stupid ... the scroll wheel increments in ticks of 120 per one physical tick of the mouse. Always 120, it's a fixed constant. Using DIPROP_GRANULARITY to get it from the mouse tells you the driver doesn't support that operation, but there's a Windows #define called WHEEL_DELTA for it.
Seriously, what's the point of an arbitrary, fixed-value multipler for something, anyway?
For the sake of testing, this WIP disables the "mouse acquired" requirement, and raises the divider on motion to 5000 from 5. In other words, this release will work with gamepad thumb sticks, but not with mice.
Having a lot of trouble coming up with a way to get both working cleanly. But yeah, you can at least see how it works now.
You want to set the X axes to "joypad00.axis00", and Y axes to "joypad00.axis01". Use the config file, input assignment is still screwed.
DIJOYSTATE2 has lX and lY, but that's it. I guess making that an array would be too easy. I'll have to dig through and hope one of the 20 other oddly named variables (lHX, lRX, lRLX, etc) refer to the other analog stick.I can't get bsnes to recognize thumbstick 2.
You think that's stupid ... the scroll wheel increments in ticks of 120 per one physical tick of the mouse. Always 120, it's a fixed constant. Using DIPROP_GRANULARITY to get it from the mouse tells you the driver doesn't support that operation, but there's a Windows #define called WHEEL_DELTA for it.
Seriously, what's the point of an arbitrary, fixed-value multipler for something, anyway?
If we could come up with some way to map both analog bi-directional inputs and single push button controls together, then yes we could do something like that. I think it would be too difficult to play like that, but whatever. The flexibility would be nice at any rate.An idea that I had that would get these things working for everyone and every platform, would be to create 4 mappable directions that could be assigned to a dpad
I know you were being sarcastic, but I don't see how video game high scores (meant to make you feel good about yourself) relate to programming.You can't have looked at scores in videogames lately. Good luck not getting at least 100 points for something. But things are worse on pinball games. One million points as the lowest reward?
"YAY!! I scrolled the mouse wheel by 1,560 in one spin!!"
Man, this works great, way better than the mouse. Good job.byuu wrote:I fixed up the SDL and X input drivers to work with the new model, so the Linux port builds again.
For the sake of testing, this WIP disables the "mouse acquired" requirement, and raises the divider on motion to 5000 from 5. In other words, this release will work with gamepad thumb sticks, but not with mice.
Having a lot of trouble coming up with a way to get both working cleanly. But yeah, you can at least see how it works now.
I can easily compare the dpad to the thumbstick, too, and it's no contest. 8 directions isn't enough. Thumbstick is buttery smooth.
My mouse, by the way, is an infrared gaming mouse that is set to 1000hz polling and 1800dpi. It moves fast on my desktop, but in bsnes it was slow as molasses. I can see that it's even better when it works, though (using zsnes). A lot easier to snipe all the crap flying at you in Yoshi's Safari. Couldn't get Lethal Enforcers to work in zsnes, it glitches out the cursor.
byuu are you setting it up mouse, joy pad and gun into 3 parts?
I meant 3 check boxes. (Only enable 1 and the rest disabled.)
This will help better? Just wondering if all 3 enabled is screwing the settings up.
I meant 3 check boxes. (Only enable 1 and the rest disabled.)
This will help better? Just wondering if all 3 enabled is screwing the settings up.
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT
Sorry, was a bit under the weather lately.
Anyway, new WIP, very little changed.
Updated nall::sort from insertion sort to merge sort* [O(n log n)], and then used that to add a "Keep cheat code list sorted by description" checkbox to the cheat code editor. I'll admit this probably isn't very useful, I really just wanted an excuse to implement a proper sorting algorithm and get rid of the embarassing O(n^2) sorting code I had in my template library. It's actually the first time in 11 years of programming that I've ever used a sort function in an application, believe it or not. I'll make it an advanced mode option if it really bothers people (eg as feature bloat.) It was only ~12 extra lines of code.
(* not using quick sort as I need a stable sort for my purposes (eg two descriptions that are the same, but with different codes -- it shouldn't bounce around every time the list changes or you toggle the sort option), and it's nice avoiding the worst-case O(n^2) issue with quick sort.)
Updated the mouse acquired check to work, but only on mouse input. Not that it matters much since I still don't have a method for distinguishing between mouse and joypad movement deltas. Eg this build only works with joypads, not mice.
Moved the endian stuff from bsnes/src/lib/bbase.h to nall/endian.hpp. I've been trying to eliminate bbase.h for quite a while now. Getting pretty close, just some Windows POSIX wrappers and typedefs left.
Hid a bunch of the new config file options from the advanced panel. The idea, of course, is to hide anything that can already be controlled from the GUI anyway.
Sigh, no way I can make an October 14th release this year. Way too much stuff is broken.
Dullaron, no, that's not the problem at all. See the input driver thread for more info.
FitzRoy, wow, 1800dpi. Yeah, my mouse can do that, too; but I leave it at 1000dpi. That's odd, the work mouse is only 400dpi and its slower there than my 1000dpi. I'd have expected 1800dpi to be way too fast for you. I'm at a loss, maybe I'll take a look at how other emulators handle mouse movement ...
Anyway, new WIP, very little changed.
Updated nall::sort from insertion sort to merge sort* [O(n log n)], and then used that to add a "Keep cheat code list sorted by description" checkbox to the cheat code editor. I'll admit this probably isn't very useful, I really just wanted an excuse to implement a proper sorting algorithm and get rid of the embarassing O(n^2) sorting code I had in my template library. It's actually the first time in 11 years of programming that I've ever used a sort function in an application, believe it or not. I'll make it an advanced mode option if it really bothers people (eg as feature bloat.) It was only ~12 extra lines of code.
(* not using quick sort as I need a stable sort for my purposes (eg two descriptions that are the same, but with different codes -- it shouldn't bounce around every time the list changes or you toggle the sort option), and it's nice avoiding the worst-case O(n^2) issue with quick sort.)
Updated the mouse acquired check to work, but only on mouse input. Not that it matters much since I still don't have a method for distinguishing between mouse and joypad movement deltas. Eg this build only works with joypads, not mice.
Moved the endian stuff from bsnes/src/lib/bbase.h to nall/endian.hpp. I've been trying to eliminate bbase.h for quite a while now. Getting pretty close, just some Windows POSIX wrappers and typedefs left.
Hid a bunch of the new config file options from the advanced panel. The idea, of course, is to hide anything that can already be controlled from the GUI anyway.
Sigh, no way I can make an October 14th release this year. Way too much stuff is broken.
Dullaron, no, that's not the problem at all. See the input driver thread for more info.
FitzRoy, wow, 1800dpi. Yeah, my mouse can do that, too; but I leave it at 1000dpi. That's odd, the work mouse is only 400dpi and its slower there than my 1000dpi. I'd have expected 1800dpi to be way too fast for you. I'm at a loss, maybe I'll take a look at how other emulators handle mouse movement ...