bsnes v0.036 released

[mudlord]

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?

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.

[henke37]

When in doubt, make it a build option.

[byuu]

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.

[henke37]

I can confirm that Yoshi's Safari is fixed now.
Also, I just discovered that the video breaks if I change my screen settings(i disconnected my external monitor) while the application runs. Changing the scaling fixed it, but yeah, could you please make it auto fix this tiny quirk?

[franpa]

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.

[Gil_Hamilton]

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'm curious how a "reload" button makes accurate emulation difficult versus the offscreen border. Can't you just emulate a blinded gun?


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.

And really, if you want to cheat like that, just use an infinite bullet Game Genie code or something. What's the difference?

Most of the challenge added was from the conscious decision to reload, not the actual act of reloading, which was incredibly easy.

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.

[byuu]

I'm curious how a "reload" button makes accurate emulation difficult versus the offscreen border. Can't you just emulate a blinded gun?

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.

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.

I know that slipping a hand forward so you could block the barrel with your hand was a somewhat popular lightgun trick

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.

You could also use a magnifying glass on the end to increase the collision area. Fun stuff.

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.

Oh, I agree completely. I've always considered their emulation to be rather silly.

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.

[Gil_Hamilton]

I know that slipping a hand forward so you could block the barrel with your hand was a somewhat popular lightgun trick

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.

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.
...
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.

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.

Oh, I agree completely. I've always considered their emulation to be rather silly.

Well, I appreciate that they're "better than nothing", but... how much better is debatable.

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, 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.
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.

[FitzRoy]

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?

[byuu]

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?

[Gil_Hamilton]

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?

I know a low-budget approach that works moderately well...

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.

[FitzRoy]

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.

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.

[tetsuo55]

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.

http://www.hkems.com/product/xbox/LCDTopGun.htm

The way i understand it is that it basically works like a mouse, and the coordinates are tracked with the led bar

[byuu]

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.

The speed at which the mouse moves is so slow

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.

[gllt]

Make mouse speed an adjustable option? :V

[henke37]

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.

[byuu]

Make mouse speed an adjustable option?

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 :/

What is your opinion about using the scrollwheel?

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.

---

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.

[FitzRoy]

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.

[Snark]

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.

[byuu]

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.

I can't get bsnes to recognize thumbstick 2.

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.

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?

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

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.

[henke37]

Seriously, what's the point of an arbitrary, fixed-value multipler for something, anyway?

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?

[byuu]

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?

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.

"YAY!! I scrolled the mouse wheel by 1,560 in one spin!!"

[FitzRoy]

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.

Man, this works great, way better than the mouse. Good job.

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.

[Dullaron]

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.

[byuu]

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 ...