bsnes v0.032 released
C
In the only cases where you would arguably need anything between full and nothing (running a second sound program while running bsnes but still wanting to hear what you're doing ingame), even a giant ugly list of subjective presets is not going to be sufficiently flexible.
Inconvenience from not having mute in the menu can only exist if you manage to have all of these characteristics:
a) you need to mute and unmute more than once every hour
b) your muting is needed while gaming (else pause emulation would work)
c) your muting is needed for bsnes specifically, else a systemwide hotkey could be set up externally
In the only cases where you would arguably need anything between full and nothing (running a second sound program while running bsnes but still wanting to hear what you're doing ingame), even a giant ugly list of subjective presets is not going to be sufficiently flexible.
Inconvenience from not having mute in the menu can only exist if you manage to have all of these characteristics:
a) you need to mute and unmute more than once every hour
b) your muting is needed while gaming (else pause emulation would work)
c) your muting is needed for bsnes specifically, else a systemwide hotkey could be set up externally
I'll definitely add hotkeys for volume up and down.
The main thing I was wanting to avoid was having both a mute and volume slider. If one were to set the volume to zero, mute and later unmute, it'd be kind of annoying that there was no sound. Yes, I know televisions tend to do that now, so it's not all bad, but still ... mute is the same as volume 0%, so no need to have two ways to silence audio.
Also, I tend to use mute a lot. I listen to music all the time. This isn't quite as redundant as the power cycle menu option ... I could see myself getting annoyed having to go into the config settings window all the time.
The main thing I was wanting to avoid was having both a mute and volume slider. If one were to set the volume to zero, mute and later unmute, it'd be kind of annoying that there was no sound. Yes, I know televisions tend to do that now, so it's not all bad, but still ... mute is the same as volume 0%, so no need to have two ways to silence audio.
Also, I tend to use mute a lot. I listen to music all the time. This isn't quite as redundant as the power cycle menu option ... I could see myself getting annoyed having to go into the config settings window all the time.
-
- Seen it all
- Posts: 2302
- Joined: Mon Jan 03, 2005 5:04 pm
- Location: Germany
- Contact:
In that case it'd be useful to have visual feedback, e.g. the current volume displayed in the title / status bar if it's not 100%.
EDIT: Fixed.
EDIT: Fixed.
Last edited by creaothceann on Fri May 30, 2008 5:31 pm, edited 1 time in total.
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
bsnes launcher with recent files list
Mute & other stuff
I am totally with you on this, hence me going for poll option C, because it keeps the mute functionality, and optimizes the ui by removing a chunk from the Settings menu list.The main thing I was wanting to avoid was having both a mute and volume slider. If one were to set the volume to zero, mute and later unmute, it'd be kind of annoying that there was no sound.
There is something I have only noticed recently in bsnes that I want to ask you guys about:
If you delete the config file for bsnes so that it creates a new one, you will find it sets the statusbar and menubar to the "escape" key.
If you then untick Show Statusbar in the Misc menu (to get rid of the statusbar) and then press escape, you will see the menubar disappears and the statusbar comes back alternately.
I have to put the statusbar on another key for this functionality to seem correct for my preference of getting rid of the statusbar and pressing escape to see bsnes without the menubar.
I am obviously fine with the way this works because it makes sense why it is happening, but for a new user it might be confusing that they have unticked statusbar and pressing escape makes it alternate like this...
Also I have had another idea which might be good:
We could have a fast forward button that sets the frame skip to 9 and emulation speed to Uncapped, when the button is released it will make the emulator revert back to the original frame skip and emulation speed settings before the fast forward button was pressed.
I will slightly agree that show statusbar should probably come unassigned by default, but I understand why it was done. People who use the statusbar want an easy way to hide both in fullscreen mode. People who don't use the statusbar are having to unassign it.
How about combining the two as a hotkey only, like the fullscreen/windowed action? Are there people who will be pissed that the only way to hide the statusbar is to hide the menubar as well?
How about combining the two as a hotkey only, like the fullscreen/windowed action? Are there people who will be pissed that the only way to hide the statusbar is to hide the menubar as well?
-
- ZSNES Developer
- Posts: 6747
- Joined: Tue Dec 28, 2004 6:47 am
-
- Regular
- Posts: 347
- Joined: Tue Mar 07, 2006 10:32 am
- Location: The Netherlands
-
- ZSNES Developer
- Posts: 6747
- Joined: Tue Dec 28, 2004 6:47 am
FS Hide Status is the best that I can do.
Most emus do this anyways.Verdauga Greeneyes wrote:To be fair, I think most people expect the status bar to be hidden in 'full screen mode'. Little do they know it's not -true- full screenFitzRoy wrote:... the advanced settings, where it is likely to get missed.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
So you don't want it to be possible at all to see the FPS in fullscreen? Remember, bsnes has a statusbar to avoid the complexity of having to draw text in the video display area.To be fair, I think most people expect the status bar to be hidden in 'full screen mode'. Little do they know it's not -true- full screen Wink
I don't think a hotkey is out of place, they're both bars and esc is standard behavior in many programs to hide the menu bar.
-
- Regular
- Posts: 347
- Joined: Tue Mar 07, 2006 10:32 am
- Location: The Netherlands
-
- Veteran
- Posts: 637
- Joined: Sat Apr 21, 2007 8:05 pm
I almost never worry about framerate when fullscreened, myself (if I'm checking framerates in an emulator I almost always have it windowed), but I guess that's not true for everyone. Just seems like it doesn't take that much work to un-fullscreen to see your framerate, and if you've seen your windowed framerate you'll probably be able to tell if it's running noticeably slower in full.
I'm sure that logic isn't air-tight, but it's the way it runs in my head.
I'm sure that logic isn't air-tight, but it's the way it runs in my head.
I bring the trouble.
I don't even know why that's there, to tell you the truth. Internal names are garbage and no one's eccentric enough to care about the order. I guess it can be used for ingame motivation.Verdauga Greeneyes wrote:I didn't mean that, but you're right that it should be accessible. Still, status bar text is currently in the advanced options, so why not this too?FitzRoy wrote:So you don't want it to be possible at all to see the FPS in fullscreen?
misc.status_text = "Enough, you're embarrassing yourself!"
I do think that "%n : %f / %m" should be changed to "%n : %f / %m fps" though.
Last edited by FitzRoy on Sun Jun 01, 2008 6:50 am, edited 1 time in total.
-
- Veteran
- Posts: 637
- Joined: Sat Apr 21, 2007 8:05 pm
By default libao ALSA backend (default at least in Debian/Ubuntu and openSUSE) uses 500ms latency, but it can be changed. Do you mean that lowering it there are problems? (web documentation is wrong in both variable name and units).Nach wrote:This proves ALSA is junk, since compatibility is low when I tried my best to make a driver, spending several hours on it. Contrast this to the fact that I also wrote the OSS, OpenAL, and libAO drivers for bsnes too, and that I didn't spend much time on any of them, and they work great (well, except for libAO with ultra high latency).
If the ALSA driver works fine for you, great, otherwise, try something else. Odds of it working great for you are low. If you know how to fix it, byuu and myself would appreciate a patch.
This untested (edit:now tested, works correctly*) patch should reduce latency from 500ms to 100ms
Code: Select all
--- src/lib/ruby/audio/ao.cpp
+++ src/lib/ruby/audio/ao.cpp
@@ -47,16 +47,20 @@
bool init() {
driver_id = ao_default_driver_id(); //ao_driver_id((const char*)driver)
- if(driver_id < 0) driver_id = ao_default_driver_id(); //fallback on default if driver doesn't exist
driver_format.bits = 16;
driver_format.channels = 2;
driver_format.rate = settings.frequency;
driver_format.byte_format = AO_FMT_LITTLE;
- audio_device = ao_open_live(driver_id, &driver_format, 0);
+ ao_option *options = NULL;
+ ao_info *di = ao_driver_info(driver_id);
+ if (di != NULL && !strcmp(di->short_name, "alsa")) {
+ ao_append_option(&options, "buffer_time", "100000");
+ }
+
+ audio_device = ao_open_live(driver_id, &driver_format, options);
if(!audio_device) return false;
- ao_info *di = ao_driver_info(driver_id);
return true;
}
For ALSA the patch is in the other thread. I would say it is better than the original (does pretty much the same than the ao backend), but since for some people the original worked some more testing would be good.
* But snd_pcm_hw_params_set_buffer_time_near() is exactly the function that openSUSE has patched in his RPM package. If doesn't works in your distro probably that's what the patch fixes.
This worked great, thank you. libao is now tolerable on ALSA. Now I just need to add support for disabling "Audio::Synchronize" (by disabling sound output, since libao is a blocking API.)
---
EDIT: posted a new WIP, with RedDwarf's ALSA and libao fixes. Both work very well for me, your mileage may vary.
No Windows binary, as it would be exactly the same as v032a, anyway. This one's mainly for Linux users who can compile from source.
---
EDIT: posted a new WIP, with RedDwarf's ALSA and libao fixes. Both work very well for me, your mileage may vary.
No Windows binary, as it would be exactly the same as v032a, anyway. This one's mainly for Linux users who can compile from source.
-
- Regular
- Posts: 347
- Joined: Tue Mar 07, 2006 10:32 am
- Location: The Netherlands
-
- -Burninated-
- Posts: 871
- Joined: Mon Sep 10, 2007 11:33 pm
- Location: Unspecified