bsnes v0.039 released

[DancemasterGlenn]

I'd add it, defaulted to on.

[Verdauga Greeneyes]

Seems like there's a good case for day-to-day use, and if you really want to do some quick testing with multiple builds of bsnes chances are you can find the option to turn it back on. Add it, default to on

[FitzRoy]

Okay, so is the advanced section going to see a return of boolean options as checkboxes?

[X] Pause emulation when main window does not have focus
[X] Ignore input when main window does not have focus
[ ] Start program in fullscreen mode
[ ] Prompt to confirm program exit
?what else?

[byuu]

New WIP re-adds the multi-part ROM loader. For some reason that took way too long, all I got finished.

A bit different this time, one window for all three modes (bs-x slotted, bs-x and sufami turbo.) It auto adjusts based on what you want. Much more compact now that I can put the labels on the same line as the controls.

It otherwise works the same. In the future, I'll be adding a Date/Time control when loading pure BS-X carts. Makes no sense adding it to the UI before the core supports it.

[X] Pause emulation when main window does not have focus
[X] Ignore input when main window does not have focus

For the hundredth time, that creates four states instead of three. What's the difference between pause on + ignore on and pause on + ignore off?

I'll most likely use a QScrollArea to put a scrollbar on the right if we end up with too many advanced options for one page.

[FitzRoy]

What's the difference between pause on + ignore on and pause on + ignore off?

None from a usage standpoint, but it would save space and look better when all the other options are going to be checkmarks. You could autocheck/gray out the input checkbox when the pause one gets checked.

[blargg]

[X] Pause emulation when main window does not have focus
[X] Ignore input when main window does not have focus

For the hundredth time, that creates four states instead of three.

Heh, my observation exactly. Two alternatives:

Code: Select all

[X] Run emulation even when main window does not have focus
    [X] Ignore input when main window does not have focus (grayed out when first checkbox is unchecked)

When main window is unfocused, [keep emulating/emulate but ignore controller input/pause emulation] (popup menu)

[FitzRoy]

It occurs to me that byuu may have been trying to get away with no checkboxes at all. Which I think is possible, so I withdraw my request.

It's not a big deal if the do not ask selection is irreversible, and I lost the vote to make it off by default. And I can't remember what the point of starting in fullscreen was, it doesn't avoid a toggle or anything... someone remind me.

[Verdauga Greeneyes]

And I can't remember what the point of starting in fullscreen was, it doesn't avoid a toggle or anything... someone remind me.

I think someone wanted it to load games from the command line and have them start in full screen.

[FitzRoy]

And I can't remember what the point of starting in fullscreen was, it doesn't avoid a toggle or anything... someone remind me.

I think someone wanted it to load games from the command line and have them start in full screen.

I see, so the option box isn't really necessary, just the capacity to set the mode from the command line.

[Verdauga Greeneyes]

I see, so the option box isn't really necessary, just the capacity to set the mode from the command line.

I suppose so, if that is what it was. If whoever requested it didn't want to load games from the command line, disabling the menu by default in full screen mode makes the option a bit useless as you noted. I'm stubbornly refusing to look up the topic now

[byuu]

zones spotted to FEoEZ test program regression when porting.

spc7110.cpp:102:
time_t current_time = time(0) - offset;

Missing part is underlined. That's what I get for copying the S-RTC routine (that doesn't use an offset) directly.

Thank you, zones :D

It occurs to me that byuu may have been trying to get away with no checkboxes at all. Which I think is possible, so I withdraw my request.

You were wanting a list of checkboxes? That would be very tough ... a lot of options need numeric values: WRAM init value, CPU/SMP clock speeds, ALU mul/div delays, aspect ratios and axis resistance.

All but the last two really belong in a true advanced panel, whereas the input focus and last two really belong in a "moderately advanced" panel ... I'll think about it.

I'll kill off opacity. Not like anyone used it, and it won't work the way I wanted on GTK+ anyway (where only the background was translucent, not the controls.)

I just didn't want two states that had the same effect just to shave off an extra radio item. We aren't hurting for space.

-----------------------------

Options that don't fit into standard panels:

Generic stuff:
[boolean] Start in fullscreen mode
[boolean] Warn on exit with SRAM-backed game loaded
[boolean] Autodetect filetype
[boolean] Bypass patch CRC32
[integer] NTSC/PAL X/Y aspect ratios [4]
[integer -> slider] Joypad analog axis resistance
[string] Video/audio/input drivers [3]
[tri-state] Focus policy
* this COULD go on the input config list, it just doesn't feel natural there

Generic but probably safe to just remove:
[boolean] Video sepia/grayscale/invert transforms [3]
* will probably allow loading a colortable.bin, which would be similar to an NES palette but covering 32k color range. Let end users make any effect they want, with no need for GUI options.

Fuzzy stuff:
[boolean] Allow invalid up+down, left+right combinations
* leaning toward advanced ... not something casual user wants.

Advanced / system-level / developer stuff:
[integer -> combobox] CPU/PPU1/PPU2 revision [3]
[integer] CPU/SMP NTSC/PAL clock rates [4]
[integer] CPU ALU MUL/DIV delays [2]
[integer] CPU WRAM init value

Any of these can stay config-file only, but I prefer to avoid that as it can be a pain to edit, especially in multi-user mode. No, not defaulting to single-user by default.

I like the idea of command-line "start in fullscreen mode" ... Windows makes it easy to pass parameters to default filetypes ... OS X / Linux, at least Xfce, probably not so much. If we do put that option in the UI, it'll be boolean and under general.

[Jipcy]

byuu, this might be of some utility for improving bsnes' multi-threading capability.

[creaothceann]

Won't help with the context switches.

[blargg]

But multithreading can certainly help with post-emulation filtering: audio resampling and graphics filters.

[_willow_]

Not sure. How the multithreading can help with Audio resampling?

Code: Select all

emulator raw data -> filter -> output api

it's just do not worth it. You will pay more time for micro threads management then win.

I'd go for (to improve the mix audio quality and may be speed too)

Code: Select all

emulator raw channel 1 -> resampler -|
emulator raw channel 2 -> resampler -|
emulator raw channel 3 -> resampler -|-> final mix -> output api
emulator raw channel 4 -> resampler -|
emulator raw channel 5 -> resampler -|
etc..                               -|

then it do make sense for resampler threads, long, barely dependent on each other.

BTW, the last scheme do indeed make sense. As far i do know the emulator doing two resampling operations, internal one up to ~32khz and external one for the final mix scaling. Later final mix and joined resamplers (you just need to compute the proper pitch (scale) for each channel) can greatly improve both speed and quality. The more great consequence you can offload the resampling all the way to hardware.

[FitzRoy]

You were wanting a list of checkboxes? That would be very tough ... a lot of options need numeric values: WRAM init value, CPU/SMP clock speeds, ALU mul/div delays, aspect ratios and axis resistance.

Not necessarily, I didn't know until now what you were intending to bring back.

[boolean] Start in fullscreen mode

Sure you don't want to just save the mode on exit? People should give it a chance.

[boolean] Warn on exit with SRAM-backed game loaded

If you're going to have it, it should probably just be for any game. What's the difference between closing the emulator on the last stage of Space Megaforce and an hour after your last save in FFVI?

[integer] NTSC/PAL X/Y aspect ratios [4]

4:3 is really the only other ratio people might want. Let's contrast the two ways of getting it.

(a) a selection.
(b) looking up the native resolution of NTSC (256x224), deducing the ratio as 8/7 (1.143), dividing 1.333 by 1.143 (1.166), and then going into the advanced section of the configuration to put 116 for X and 100 for Y.

Isn't b overly involved?

[integer -> slider] Joypad analog axis resistance

If it's useful, it probably should go in the input section.

[string] Video/audio/input drivers [3]

This could make sense in its own section or advanced. I'm indifferent.

[tri-state] Focus policy
* this COULD go on the input config list, it just doesn't feel natural there

I can't figure this one out because the whole concept of focus is based on what window is receiving input. If a window is receiving input, it has focus, and vice versa. You can't be out of focus and receiving input, it's an oxymoron.

http://en.wikipedia.org/wiki/Focus_(computing)

Generic but probably safe to just remove:
[boolean] Video sepia/grayscale/invert transforms [3]
* will probably allow loading a colortable.bin, which would be similar to an NES palette but covering 32k color range. Let end users make any effect they want, with no need for GUI options.

Yeah, or hue/saturation sliders.

Fuzzy stuff:
[boolean] Allow invalid up+down, left+right combinations
* leaning toward advanced ... not something casual user wants.

What was this used for again?

Advanced / system-level / developer stuff:
[integer -> combobox] CPU/PPU1/PPU2 revision [3]
[integer] CPU/SMP NTSC/PAL clock rates [4]
[integer] CPU ALU MUL/DIV delays [2]
[integer] CPU WRAM init value

Truly advanced options. Don't forget to add DSP1 revision selection at some point, it would be interesting to see if it can fix those games.

[Verdauga Greeneyes]

If you're going to have it, it should probably just be for any game. What's the difference between closing the emulator on the last stage of Space Megaforce and an hour after your last save in FFVI?

I agree.

4:3 is really the only other ratio people might want ... put 116 for X and 100 for Y.

Easiest way to calculate the ratio is: (4/3)/(256/224) = (4/3)*(224/256) = 896/768 = 7/6 = 1.666...

[integer -> slider] Joypad analog axis resistance

Is there an official term for this? (is this it?) I've only ever seen something like this described as a 'dead zone', but I'm not sure if that counts when anything outside the dead zone means full activation.

I can't figure this one out because the whole concept of focus is based on what window is receiving input. If a window is receiving input, it has focus, and vice versa. You can't be out of focus and receiving input, it's an oxymoron.

'Allow bsnes to operate in the background' and 'capture input when in the background'? I agree that it's a weird concept. It's also presumably only meant to capture input meant for the SNES controller, not other key bindings or hotkeys. It's probably enough to capture input from controllers only in this mode, since I doubt people using the keyboard to control the SNES would want to use it.

Incidentally, you could say the default mode is to 'disconnect the SNES controller' when bsnes loses focus (presumably bsnes could even emulate this ) so you could make the option 'keep controller connected when the emulator loses focus'

will probably allow loading a colortable.bin, which would be similar to an NES palette but covering 32k color range.

This seems really user unfriendly because there's no way to see the effect of this before applying it. Even if you were to write a configuration program the lack of a ROM to test it on in real-time would be frustrating. I'd go with sliders.. I don't think there's any reason to skimp on these if they have their own section, but if they don't it's tough to say what sliders get preference. Incidentally I don't mind writing some more colour conversion functions if you don't want to spend time on it.

Allow invalid up+down, left+right combinations

What was this used for again?

Some games glitch out when you use these invalid combinations, would be useful for TASing except bsnes doesn't have savestates anyway.

[blargg]

How the multithreading can help with Audio resampling?

Code: Select all

emulator raw data -> filter -> output api

it's just do not worth it. You will pay more time for micro threads management then win.

Emulator thread:
- emulate into audio/video buffer 1
- let filter thread know buffer 1 is ready
- emulate into audio/video buffer 2
- let filter thread know buffer 2 is ready
- loop

Filter thread:
- wait until buffer 1 is ready
- filter and play/display it
- wait until buffer 2 is ready
- filter and play/display it
- loop

Seems a pretty clear-cut win to me, and the thread overhead is just the signaling every frame.

I'd go for (to improve the mix audio quality and may be speed too)

Code: Select all

emulator raw channel 1 -> resampler -|
emulator raw channel 2 -> resampler -|
emulator raw channel 3 -> resampler -|-> final mix -> output api
emulator raw channel 4 -> resampler -|
emulator raw channel 5 -> resampler -|
etc..                               -|

then it do make sense for resampler threads, long, barely dependent on each other.

We have to think about cores. There's little sense in using multiple threads on a single core. If we have multiple cores, doing each audio channel would hardly keep them busy. And ignoring that, audio emulation can't reasonably be broken up like that. This idea is a non-starter, but I don't have the patience to debate it, sorry.

BTW, the last scheme do indeed make sense. As far i do know the emulator doing two resampling operations, internal one up to ~32khz and external one for the final mix scaling. Later final mix and joined resamplers (you just need to compute the proper pitch (scale) for each channel) can greatly improve both speed and quality.

Merging the resampling would hardly affect quality at all, unless you mean to do something like SNESAMP does, where it emulates the DSP differently than the SNES in order to enhance sound (where enhance means alter in a way that some listeners find more pleasing).

[tetsuo55]

[boolean] Warn on exit with SRAM-backed game loaded

If you're going to have it, it should probably just be for any game. What's the difference between closing the emulator on the last stage of Space Megaforce and an hour after your last save in FFVI?

Yeah i agree.
But the message could be different for SRAM/NON-SRAM games.
Something like:

No-SRAM
-Are you sure you want to exit? This game does not have save capabilities, all progress will be lost

SRAM
-Are you sure you want to exit? Make sure you have saved your game before quiting otherwise progress since your last save will be lost

Maybe not those exact words but you get the idea

[FitzRoy]

How many documented cases of accidental closure do we have? Include ZSNES. 0. Years on this board and I've never heard someone accidentally clicking the X button while pecking away on their keyboard/joypad. And if it's from clicking the maximize button, why would someone wait until they're well into the game to maximize the window? In fact, why would you even want to maximize the window when bsnes has a fullscreen mode? Should we add the prompt for Reset, too? How about when someone overwrites an SRAM slot? Should it show on SRAM games or all games? What should the window say? Where should the option go? Will people be able to find it?

It's well-intentioned to want to protect people, but not from imaginary risks. There's probably a better chance of power outage or hard drive failure.

[AamirM]

How many documented cases of accidental closure do we have? Include ZSNES. 0.

Nobody is going to come and blame bsnes for his/her own mistake. So I doubt anybody will report something like that.

[byuu]

Later final mix and joined resamplers (you just need to compute the proper pitch (scale) for each channel) can greatly improve both speed and quality

Better quality is subjective, bit-perfect emulation is not. I'm feeding the exact values from the real S-DSP core to the audio driver. From there, any effects can be applied. No sooner.

Sure you don't want to just save the mode on exit? People should give it a chance.

That sounds fine to me, actually. We'll go with that.

4:3 is really the only other ratio people might want.

I suppose people using 1280x1024 on 4:3 CRTs get what they deserve. The built-in values are honestly correct enough. The controls are really only there for people who want to fill widescreen monitors for some odd reason. Eh, it's rare enough. Let's leave these in the config file only.

If it's useful, it probably should go in the input section.

I think the default is good for most people, but some may want to change it.

This could make sense in its own section or advanced. I'm indifferent.

Way too empty in its own section, unless we put back the driver attributes.

I can't figure this one out because the whole concept of focus is based on what window is receiving input.

That's why I use "When main window does not have focus" for the group name.

What was this used for again?

Cheating. You can beat Zelda 3 in under five minutes using it. It can also lock up your game if you hit the combos by accident.

This seems really user unfriendly because there's no way to see the effect of this before applying it.

The alternative is built-in checkboxes for any possible effect. Do we really want an invert colors checkbox in the UI?

I'd still keep the important ones, brightness/contrast/gamma/ramp. Just dropping the uncommon stuff. People writing color tables could make their own test image set to display with the effects. Though I doubt anyone would even use the color table support. Eh I'll leave it out for now.

How many documented cases of accidental closure do we have? Include ZSNES. 0. Years on this board and I've never heard someone accidentally clicking the X button while pecking away on their keyboard/joypad.

I'll agree, I've never seen that. But why would anyone post about that anyway? Especially here ... you'd just get ridiculed to no end for being an idiot :P

[FitzRoy]

I can't figure this one out because the whole concept of focus is based on what window is receiving input.

That's why I use "When main window does not have focus" for the group name.

I'll try to explain this a little better. "Focus" in computing terms is another way of saying "the program receiving input," not "a program receiving input." It is an exclusive ability granted to the program the user is using (commonly determined by clicking), otherwise other currently opened programs would be taking commands that weren't intended for them.

So to paraphrase all three options based on what's selected:

When main window is "ignoring input," "pause emulation."
When main window is "ignoring input," "ignore input."
When main window is "ignoring input," "receive input".

I'd try suggesting something that made the last two make sense, but I gotta leave work now, I hate this place.

I'll agree, I've never seen that. But why would anyone post about that anyway? Especially here ... you'd just get ridiculed to no end for being an idiot

Okay, maybe that part is true. If it was induced by bad design or something, though, I'd fully expect at least a few requests.

[funkyass]

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


Pick one of the first two, having both is silly, as selecting the first and not having a controller effectively gives you the second choice

[odditude]

I can't figure this one out because the whole concept of focus is based on what window is receiving input.

That's why I use "When main window does not have focus" for the group name.

I'll try to explain this a little better. "Focus" in computing terms is another way of saying "the program receiving input," not "a program receiving input." It is an exclusive ability granted to the program the user is using (commonly determined by clicking), otherwise other currently opened programs would be taking commands that weren't intended for them.

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.