bsnes v0.039 released

FitzRoy · Post by **FitzRoy** » Thu Feb 05, 2009 12:09 am

odditude wrote:Regardless, byuu's usage is correct. Windows does not treat joysticks like keyboards and mice, and will allow even an application without focus to poll for controller input.

I'm aware of Windows' ability to make input non-exclusive, otherwise bsnes wouldn't be able to allow all types of input despite another program's claim to focus. I also don't know of any rule that excepts joypads from the definition of focus, maybe you could throw me a link to a better definition.

funkyass · Post by **funkyass** » Thu Feb 05, 2009 1:27 am

What input devices can you use to change window focus without additional software Fitz?

FitzRoy · Post by **FitzRoy** » Thu Feb 05, 2009 2:51 am

Are you trying to say that commands to lose focus are not a part of having focus? I don't know what you mean.

If focus could be seen as a shared thing instead of an exclusive thing, it makes describing the option easy.

[x] Pause emulation when main window loses all focus.
[ ] Never lose keyboard or joypad focus.

(#2's box, when checked, would make #1's box ineffectual). However, if focus is an exclusive thing handed off between programs and elements, #2 cannot be technically correct, as not losing focus should imply nothing else has it.

In a combined radio box mode:

When main window loses mouse focus:
[X] Pause emulation and lose keyboard/joypad focus [ ] Run emulation and lose keyboard/joypad focus [ ] Run emulation and retain keyboard/joypad focus

bsnes blocks hotkeys, but allows keyboard input configured to the controller, doesn't it? Oh man, this getting hard to explain...

byuu · Post by **byuu** » Thu Feb 05, 2009 11:23 am

New WIP adds a ton of refinement.

I feel it's exceeded the old UI in quality already, so I added the platform-functions (realpath, userpath, ...), so now it'll look for the multi-user config file, falling back on single-user. If you use an old config, most settings from v039 will be lost, but some will be pulled in. It now looks for bsnes.cfg and style.qss (for theming.) Slight issue with relative paths and realpath() on Linux. New initargs() function adds back support for non-ANSI paths.

Path window shows <startup path (/path/used)> rather than just <startup path>.

All buttons trigger on release (mouse up / off) rather than press (mouse down).

Revamped the centering code. All windows respect the reserved screen areas (taskbar, dock, etc) and center perfectly. They only center on the first show, after that they will remember where you placed them.

Completely rewrote the windowed / fullscreen handling code. It works properly even on Linux now. Scale max is great, perfect fit to the edges of your screen sans reserved areas. If menu+status toggle are bound to the same key, it'll only refresh the window once to reflect the new state now.

Going back to the forced size thing. I need to re-add the menu checks. You can't shrink the window smaller than your current settings, and if you make it bigger, you get black borders (since I can't disable the resize reliably on all platforms.) Makes more sense this way anyway, the menu options should reflect what you see, not what the startup state is.

It remembers the fullscreen setting automatically now. I took it a bit further, though. If you have no ROM loaded, it will show the menu+status in fullscreen to alert you there's no cart and give you a chance to select one. I also re-added command-line loading, and if you successfully load a game there, it will turn off the menu+status for you. There was a slight delay there. You see, loading a game calls snes.init() which needs the interface (video, etc drivers) setup. Those drivers rely on the UI being created. So we have to make the UI, setting the menubar visibility, before we can verify that we're going to load a game.

Yes, I can work around this! Add a first-run boolean and validate the command-line path is valid, or separate cart load from SNES init so I can load, setup GUI then start, etc etc. It's just annoying, not sure if it's worth the effort to hide the menubar 2ms sooner.

ROM slot loader and cheat path windows now both disable buttons when no cart is loaded. Major work in progress, lots of stuff left to do here. When you pick a file with the ROM loader, it doesn't steal focus to the main window anymore. When you pick a path, it clears the audio buffer to prevent audio looping. Not sure if I want to hook move / resize events, since Linux doesn't block as much as Windows. Maybe I'll #ifdef it.

Qt 4.4 has a bug with GTK+ file open, if you give it a blank path it spits out lots of errors. It needs a fully-qualified path. Going to make my old-style "remember last selected path" thing that I used in hiro/gtk to fix it later.

Verdauga Greeneyes · Post by **Verdauga Greeneyes** » Thu Feb 05, 2009 3:01 pm

byuu wrote:There was a slight delay there. ...
Yes, I can work around this! Add a first-run boolean and validate the command-line path is valid, or separate cart load from SNES init so I can load, setup GUI then start, etc etc. It's just annoying, not sure if it's worth the effort to hide the menubar 2ms sooner.

Perhaps you can turn this to your advantage: animate hiding the menu bar by making it slide up or fade out - that way you know hiding it was intentional and it looks refined.

FitzRoy · Post by **FitzRoy** » Thu Feb 05, 2009 6:31 pm

Path window shows <startup path (/path/used)> rather than just <startup path>.

This is really the only thing I disagree with. I recommended the enclosed description to explain variable default behavior in a way that never changes, so that it was a unique setting just like custom selection. Adding the result kind of defeats that, and doesn't look all the great either.

I've been thinking a little more about this section and had an idea that could make it a lot better. It elaborates the program's actual behavior for each type of file far better than what I had previously. It would have had to be talked about in the readme, this avoids that.

Game file navigation starts in:
<the last folder from which a game was loaded>

Save file detection and generation occurs in:
<the same folder as the loaded game>

Patch file detection occurs in:
<the same folder as the loaded game>

Cheat file detection and generation occurs in:
<the same folder as the loaded game>

Export data file generation occurs in:
<the same folder as the running executable>

One thing that I think is unavoidable and desirable to have in the readme is supported/unsupported filetypes and what they stand for in regards to the hardware, so keeping things like RAM and UPS isn't really necessary. It could all be explained in the readme.

funkyass · Post by **funkyass** » Thu Feb 05, 2009 6:39 pm

FitzRoy wrote: Oh man, this getting hard to explain...

Its because you barely have a grasp on the subject.

Focus only applies to the keyboard and mouse - the only devices that can change focus - the only devices where their actions only make sense in the currently focused window. You can use software to change focus, but thats besides the point.

you can't word it any better than the following:

When BSNES is not the active window:
* Continue playing using a game controller.
* Leave the current game running.
* Pause the current game.

FitzRoy · Post by **FitzRoy** » Thu Feb 05, 2009 6:49 pm

Focus only applies to the keyboard and mouse - the only devices that can change focus - the only devices where their actions only make sense in the currently focused window. You can use software to change focus, but thats besides the point.

User interfaces like Windows are built around the keyboard and mouse. A joypad is pretty much for games, bought on the side, and there was never really a standard for button layout, either. It's still a peripheral that can have focus, right? I don't know what being able to hand off focus with it using default OS mappings means to the conversation.

funkyass wrote: you can't word it any better than the following:

When BSNES is not the active window:
* Continue playing using a game controller.

But doesn't bsnes allow you to continue playing using the keyboard as well? Game controller makes me think it's referring to the PC joypad, not the system joypad assigned to the keyboard or PC joypad.

* Leave the current game running.

This is kind of vague, both #1 and # 2 leave the current game running. You aren't actually saying whether the game can be played with a certain input or not.

funkyass · Post by **funkyass** » Thu Feb 05, 2009 7:08 pm

FitzRoy wrote:
funkyass wrote: you can't word it any better than the following:

When BSNES is not the active window:
* Continue playing using a game controller.
But doesn't bsnes allow you to continue playing using the keyboard as well? Game controller makes me think it's referring to the PC joypad, not the system joypad assigned to the keyboard or PC joypad.

no, if bsnes is not the active window, get this, its not receiving anything from the mouse or keyboard, see odditude's previous post.

FitzRoy wrote:
* Leave the current game running.
This is kind of vague, both #1 and # 2 leave the current game running. You aren't actually saying whether the game can be played with a certain input or not.

Refer back to my previous post.

FitzRoy · Post by **FitzRoy** » Thu Feb 05, 2009 8:34 pm

funkyass wrote: no, if bsnes is not the active window, get this, its not receiving anything from the mouse or keyboard, see odditude's previous post.

No, if I set bsnes to allow input, the default keyboard assignments will work in a game even if I'm typing in another window.

You're apparently not wanting it to do this, but that's a suggested behavior, not how it currently operates.

Panzer88 · Post by **Panzer88** » Thu Feb 05, 2009 8:40 pm

I'm actually with fitzroy on this, it's an option so it's not like it hurts anyone.

FitzRoy · Post by **FitzRoy** » Thu Feb 05, 2009 8:56 pm

Panzer88 wrote:I'm actually with fitzroy on this, it's an option so it's not like it hurts anyone.

I'm not arguing for or against anything, I'm just telling him the way it is so he can reconstruct his suggestion accordingly.

And yes, I do not know whether joypads are supposed to follow the mouse/keyboard focus, or if there is no such thing as joypad focus and all programs can simultaneously poll joypad. I don't know if there's some unspoken rule to have one or the other.

creaothceann · Post by **creaothceann** » Thu Feb 05, 2009 9:20 pm

Keyboard and mouse activity causes Windows to send messages. By default these messages go only to the window that has the focus.

Joysticks and -pads are accessed via DirectX, which is completely separate (and probably uses callbacks). Someone who knows more about it could tell if there's an option that causes DirectX to adhere to the "focus concept", but I think it's not the default.

Post by **odditude** » Thu Feb 05, 2009 9:34 pm

creaothceann wrote:Keyboard and mouse activity causes Windows to send messages. By default these messages go only to the window that has the focus.

Joysticks and -pads are accessed via DirectX, which is completely separate (and probably uses callbacks). Someone who knows more about it could tell if there's an option that causes DirectX to adhere to the "focus concept", but I think it's not the default.

Any device accessed via DirectInput8 can actually be instructed to behave in any manner with regards to focus; the only exception is that keyboard and mouse can't be set to application-exclusive access while the app in background. See http://msdn.microsoft.com/en-us/library ... 85%29.aspx.

funkyass · Post by **funkyass** » Thu Feb 05, 2009 10:03 pm

what odditude posted is windows specific, but it covers the overall gist. The keyboard and mouse only focus on the active window.

There is no need for me to rephrase anything.

henke37 · Post by **henke37** » Fri Feb 06, 2009 8:07 am

I don't have time to check, but does this saved position logic account for the fact that the position can suddenly be invalid if people have messed with their screen settings?

creaothceann · Post by **creaothceann** » Fri Feb 06, 2009 11:55 am

The previous screen size could also be saved with the previous center of bsnes' window (e.g. "prev_ScreenWidth=1024", "prev_CenterX=512"). From there bsnes can calculate the new position.

byuu · Post by **byuu** » Fri Feb 06, 2009 3:33 pm

henke37 wrote:I don't have time to check, but does this saved position logic account for the fact that the position can suddenly be invalid if people have messed with their screen settings?

The centering is done the first time the window is shown, so it uses the resolution at that time.

The bigger problem is that my video drivers don't compensate for that event. Best case means you'll have no video output, worse case means the whole program will crash.

It never seemed like a very common usage scenario.

oddigy wrote:Any device accessed via DirectInput8 can actually be instructed to behave in any manner with regards to focus; the only exception is that keyboard and mouse can't be set to application-exclusive access while the app in background.

This is what I do on Windows and Linux. It didn't seem right to treat joypads specially, even if they are generally ignored by most other apps. But then, what if you also have another game / emulator open? Easier to make all input devices act the same.

FitzRoy · Post by **FitzRoy** » Fri Feb 06, 2009 3:44 pm

odditude wrote:Any device accessed via DirectInput8 can actually be instructed to behave in any manner with regards to focus; the only exception is that keyboard and mouse can't be set to application-exclusive access while the app in background. See http://msdn.microsoft.com/en-us/library ... 85%29.aspx.

Foreground/background is what I was looking for, thanks. Foreground apps acquire keyboard input, but not exclusivity. Background apps cannot have mouse/keyboard exclusivity, but they can prevent foreground apps from having it if both foreground and background app use the nonexclusive flag. If the foreground app uses the exclusive flag, a nonexclusive background app will be denied what a nonexclusive foreground app would have granted. Is this right? Jesus christ, that's complicated. I would make keyboard/mouse exclusive only, but they make a good point about remote controls and joypads for background apps.

So funkyass is wrong that "only" the foreground app can have keyboard focus, a background app can also have it, just not exclusively. And I was improperly using "mouse focus" before. Windows has exclusive mouse focus, which is only ceded to bsnes when bsnes captures it for mouse/scope games.

EDIT:
Time for a new suggestion. Maybe do as funkyass was expecting and lose all rather than some keyboard focus when in the background. The selective keyboard focus is a bit confusing, and really, when you think about, the option was supposed to allow 1 person to work on a keyboard program while another person gamed on a joypad:

[] Pause emulation when the main window is in the background

That would be the only option needed, when unchecked emulation would run and still accept pc joypad input.

I also think the pc mouse assignment buttons should be removed for snes joypad config, they have no purpose for anything but snes mouse/scope.

_willow_ · Post by **_willow_** » Fri Feb 06, 2009 6:47 pm

RAW input for WinXP, Vista

Better to use RAW input (keyboard, mouse) whatever case. In short, you are making direct connection to the input device drivers and drivers signaling for state changes via WM_INPUT message regardless of the windows foreground-background logic. On top of this you can build your own rules.

DOLLS (J) [!] · Post by **DOLLS (J) [!]** » Sat Feb 07, 2009 1:36 am

_willow_ has given good advice.

byuu · Post by **byuu** » Sat Feb 07, 2009 1:39 am

_willow_ wrote:RAW input for WinXP, Vista

Cool, didn't know about that. But is it worth the effort to rewrite the DirectInput keyboard+mouse driver for? I'd still most likely need DI for joypad support.

Wouldn't hurt to have the extra input driver option, of course.

_willow_ · Post by **_willow_** » Sat Feb 07, 2009 3:02 am

A bit of my personal experience..
Did not tried joypad with WM_INPUT input. And keyboard as well. But i do liked RAW mouse a lot, it's guaranteed to be unscaled, non accelerated (no desktop cursor ballistics applied), with instant polling. I used it for FPS game. The whole WM_INPUT designed for excellent input response. Another good point for you being virtually one layer down the desktop machine, this way desktop limits becoming just a "hints", you may mix desktop\raw inputs if you want to.

Be warned though, it's a WinXP+ feature only.

BlackStar · Post by **BlackStar** » Sun Feb 08, 2009 10:11 am

DirectInput uses WM_INPUT events, if available, and falls back to normal input processing if not. In other words, it doesn't make sense to rewrite your DInput interface to use WM_INPUT directly.

The only drawback of DInput is that it spawns a separate thread just for input processing. This creates overhead - but I don't think it really matters in the grand scheme of things.

FirebrandX · Post by **FirebrandX** » Mon Feb 09, 2009 1:15 pm

creaothceann wrote:
byuu wrote:New cheat code editor
The "enabled" in the cheat code editor heading is not really necessary, is it? Makes the colun needlessly big.

Getting you back for correcting me. It's column.