bsnes v0.036 released

Archived bsnes development news, feature requests and bug reports. Forum is now located at http://board.byuu.org/
Locked
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

Image

This is something I never really got around to posting. The benefits are:

- separate aspect ratio correction settings in advanced and main menus no longer necessary. It is treated as a part of scaling.
- aspect ratio is now apparent to users. For any setting, the status box will change to reflect what the aspect ratio is.
- possible to scale to any non-integer width or height by the hundredth. Coincidentally allows a user to eliminate black bars in full screen mode.
- with video settings in the configuration area, windowed and fullscreen settings are viewable and settable in either mode, not just the one you're in.

The drawbacks are:
- not as quick to change if you (for some reason) change video settings constantly
ShadowFX
Regular
Posts: 265
Joined: Thu Jul 29, 2004 8:55 am
Location: The Netherlands

Post by ShadowFX »

FitzRoy wrote:The drawbacks are:
- not as quick to change if you (for some reason) change video settings constantly
Exactly, that looks way too complicated to the 'average joe'. I understand it, but VG's solution was much easier and can be found in most emulators today, and also the way I'm used to it.
[i]"Change is inevitable; progress is optional"[/i]
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

If it was, I wouldn't have suggested it. You're talking about keeping three sliders nobody needs, hiding mode settings, hiding the aspect ratio, completely separate aspect ratio settings in advanced that uses fractions, and anyone who wants non-integer scaling in widowed mode can't. That's limiting useful options, complicated, and uninformative. So it takes you 1 minute to find a height scale that fills your fullscreen mode, and you're done forever. Big deal.
ShadowFX
Regular
Posts: 265
Joined: Thu Jul 29, 2004 8:55 am
Location: The Netherlands

Post by ShadowFX »

FitzRoy wrote:If it was, I wouldn't have suggested it. You're talking about keeping three sliders nobody needs, hiding mode settings, hiding the aspect ratio, completely separate aspect ratio settings in advanced that uses fractions, and anyone who wants non-integer scaling in widowed mode can't. That's limiting useful options, complicated, and uninformative. So it takes you 1 minute to find a height scale that fills your fullscreen mode, and you're done forever. Big deal.
Really you lost me. Not a problem though, I'll wait until the option is added and come to new conclusions then.
[i]"Change is inevitable; progress is optional"[/i]
Verdauga Greeneyes
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

Alternatively, how about this? One setting for scaling, one setting for aspect ratio correction (either relative to the original resolution, or the original resolution times the fractions in the advanced settings)
Image
With this you could keep the integer scaling factors in the menu for ease of access.
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

I thought about doing that, but it just isn't as simple to understand. With mine, the process is scaling width and scaling height. 2 scales. With that one, you're scaling width/height and then performing an additional scale just to width. 3 scales.

Image

Here's a slightly better example. I was thinking that it would be helpful to display not just the effective output AR, but the effective draw area. Then all you need to know is your monitor's max vertical and match it, there's no guess and check.

I also thought frameskip should stay in the menu because it is eventually going to be wiped. And I think brightness/contrast/gamma settings should move to the advanced section. They're just not that important. Defaulting to 80 gamma and using tv gamma curve are fine. If someone really picky doesn't like the great image that produces, they can go to advanced and change it.

EDIT: scale to thousandths
Last edited by FitzRoy on Mon Oct 20, 2008 2:43 am, edited 3 times in total.
Verdauga Greeneyes
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

FitzRoy wrote:<second example>

Here's a slightly better example. I was thinking that it would be helpful to display not just the effective output AR, but the effective draw area. Then all you need to know is your monitor's max vertical and match it, there's no guess and check.
I like this, but if you have (output) Width and Height anyway, why not make them editable? Then Width/Height scale can change along with them, and you can choose which one you'd prefer to change. (i.e. you'd change the scale if you want a specific aspect ratio/linear scaling, and change the output width and height if you want to fill a certain percentage of your screen)
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

I'm guessing the reason you might not want to do that is because non-integer scales round results to integers. Reversing the process gives funky scale results.

So a height of 224 and 225 is 1.000 and 1.004 respectively when rounded to the nearest thousandth. Rounded to the nearest hundredth, the scale on 225 would display 1.00. Which is wrong. We don't want people thinking 225 is the base draw height. I suppose you could display scale in to the thousandth to avoid that. It wouldn't really affect people entering to the hundredth.

No doubt that if don't, we'll get people saying that they can't match their monitor height exactly when limited to hundredths.
Verdauga Greeneyes
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

FitzRoy wrote:So a height of 224 and 225 is 1.000 and 1.004 respectively when rounded to the nearest thousandth. Rounded to the nearest hundredth, the scale on 225 would display 1.00. Which is wrong. We don't want people thinking 225 is the base draw height. I suppose you could display scale in to the thousandth to avoid that. It wouldn't really affect people entering to the hundredth.

No doubt that if don't, we'll get people saying that they can't match their monitor height exactly when limited to hundredths.
I guess it would be best to display the unrounded value in as few digits as possible, while maintaining a reasonable minimum and maximum number of digits. (i.e. 1.00 for 1 and 1.33333 for 1.333333...) The value will be stored either as a fraction or in floating point anyway.
Dullaron
Lurker
Posts: 199
Joined: Mon Mar 10, 2008 11:36 pm

Post by Dullaron »

FitzRoy that is what I'm looking for. I wish every programs have that. Set it up the way we want it.
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

Verdauga Greeneyes wrote: I guess it would be best to display the unrounded value in as few digits as possible, while maintaining a reasonable minimum and maximum number of digits. (i.e. 1.00 for 1 and 1.33333 for 1.333333...) The value will be stored either as a fraction or in floating point anyway.
We basically just need to ask ourselves how many decimal places are required to give access to every integer result from 224 to 1920. And the answer is thousandths. Unless someone is using a monitor with a 12000 pixel height, there's no need for floating point precision.
Dullaron wrote:FitzRoy that is what I'm looking for. I wish every programs have that. Set it up the way we want it.
Well, it's certainly better than stuff like CPS3 Emulator, where you're given the ability to stretch to anything, but are relegated to eyeballing it. So you've no idea if you've hit a perfect scale, what AR you've stretched to, or even what the base resolution is.
Verdauga Greeneyes
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

This all still leaves the issue of what should happen if you set the scale factor to something that's bigger than the maximum window size or the screen resolution. The problem here is that the necessary upscaling is handled by the filters and the drivers, so unless we clamp the output rect to the max window size / screen resolution every driver would need to be modified to only send the centre portion of the output rect to the primary buffer that would actually fit. I know Direct3D can do this, but I don't have any experience with the other drivers.
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

My understanding was that if someone did that, bsnes would operate exactly the way it operates now. The scale settings would then become reflective only of themselves, not changing to reflect the restraints applied to the image.

Because the way bsnes operates now, if you set scale to 5x and that result exceeds your display's res, it scales it back to something like 4.**x to prevent the screen from going blank. But the scale still says "5x". Nothing I've suggested would change this. Although you would want to block values below 1.000.
byuu

Post by byuu »

New WIP. Couple of changes here.

Ran into that damn char *argv[] crushing Unicode on Windows thing again with the MOTHER 3 patcher. Before I had to #ifdef the main() entry point and add all kinds of magic to rebuild the command-line string as UTF-8. So I moved all of that inside of hiro. Linux users can now use GTK+ command-line arguments as a result, too. And ui/main.cpp loses a bunch of platform-specific wrappers.

Moved realpath(), userpath() and mkdir() wrappers inside hiro; as they all need UTF-8 <> UTF-16 stuff anyway. That cuts bbase.h to ~1.5kb. Very close to killing it off now.

And probably most importantly, added VG's scaling changes. But I redid the code to support the same effect in windowed mode. I also made sure it works on portrait monitors, too (eg width is too big; scale height instead). That was a messy section before. Please test it out and let me know if it doesn't work as you guys were wanting.

I want to get a new release out shortly. Release-stoppers right now are:
- axis sensitivity sucks; mouse maps too fast, joypad axes don't map at all on Windows.
- need to swap mouse.button01 with mouse.button02 so Linux and Windows use the same IDs; then I need to set defaults for the mouse / SS / Justifiers.
- need to hide expansion port / region in simple UI mode.
- still need to add that skew help message to the audio settings panel.

If I'm missing anything serious in the above, eg you know of some critical bug or something, please let me know now.

I'm going to put off the video panel discussion and ROM PCB mapping stuff until the next release or so. Too much to cover, and they'd take too long at this point.
That saddens me a little, not because I don't think you'd do a great job, but because there are far more people rom hacking than there are writing emulators or improving emulation.
And what have we been improving for the last two years? :/
It's been 95% GUI polishing and minor bug fixes. The only major change I can think of off-hand was the HDMA timing improvements.

I'm really starting to doubt that it's possible to simultaneously allow both the scanline and cycle-based PPUs. I try and come up with something every other week, and nothing I think of will avoid a major speed hit to the scanline renderer.

And I really don't personally care about the SuperFX / SA-1. Yes, I know a lot of you do, and I'll hopefully get around to adding them. But if I'm going to start a months-long RE task, it's going to be the PPU first, sorry. And I'm at a major impasse there.
ShadowFX
Regular
Posts: 265
Joined: Thu Jul 29, 2004 8:55 am
Location: The Netherlands

Post by ShadowFX »

byuu wrote:And probably most importantly, added VG's scaling changes. But I redid the code to support the same effect in windowed mode. I also made sure it works on portrait monitors, too (eg width is too big; scale height instead). That was a messy section before. Please test it out and let me know if it doesn't work as you guys were wanting.
This is exactly what I've been looking for in bsnes for quite some time. Thank you very much as it works like a charm on my widescreen monitor now :)
[i]"Change is inevitable; progress is optional"[/i]
Verdauga Greeneyes
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

byuu wrote:And probably most importantly, added VG's scaling changes. But I redid the code to support the same effect in windowed mode. I also made sure it works on portrait monitors, too (eg width is too big; scale height instead). That was a messy section before. Please test it out and let me know if it doesn't work as you guys were wanting.
Hmm, I'm fairly certain my code worked regardless of the screen's aspect ratio..

The code gets triggered if either width or height is too big, so we know at least one of 'width / view_width' and 'height / view_height' will return a value of > 1, we just have to find the biggest one (or if you turn it around, the smallest one). Then we scale both values by that scale factor, so one of them will be divided by itself and be the same size as the screen/window, and the other will be less than or equal to it (relative to the screen/window).

As a minor note, I also rounded the values, rather than flooring them.

I like what you did with the function as a whole though, the code looks a lot cleaner now.

In the same vein as the new code:

Code: Select all

  if(height > viewheight || width > viewwidth) {
    double scalar = min((double)viewheight / (double)height,
                        (double)viewwidth  / (double)width);
    width  = (unsigned)((double)width  * scalar + 0.5);
    height = (unsigned)((double)height * scalar + 0.5);
  }
If there is a problem with it, please let me know as I just spent a while thinking about it :P
Verdauga Greeneyes
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

By the way, is it just me or has the NTSC filter's intentional glitchyness gotten erratic and unpleasant? It's like it randomly gets a seizure :( Very noticeable in Chrono Trigger on the world map.
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

byuu wrote:And I really don't personally care about the SuperFX / SA-1. Yes, I know a lot of you do, and I'll hopefully get around to adding them. But if I'm going to start a months-long RE task, it's going to be the PPU first, sorry. And I'm at a major impasse there.
Oh, I wasn't bugging you about those again, they're years away from feasible. I'll just focus on the next two versions before I ask you if you're interested in contributing to something on the game management end of things. I'm guessing it would take you less than a month.

Couple of things:
1. I noticed that you may have forgotten to remove video sync from the advanced section after it was added as a functional menu option.
2. What happens when someone uses multiple mice? You currently don't list the mapping as mouse00, just mouse. Will this ever pose a problem?
byuu

Post by byuu »

Got the EP / Region stuff hidden in standard UI mode, and added the text label to the audio panel. Didn't post the WIP, not much point in testing that.

I think I'll just take it slow, wait another week or so, make sure no bugs pop up; rather than rush a release this weekend.
If there is a problem with it, please let me know as I just spent a while thinking about it
Yeah, I wasn't sure about the math. That's why I put the height scale first. I think your code should be fine, too. If someone can definitively show them to be the same, we can use that just because it's smaller, which is nice.
By the way, is it just me or has the NTSC filter's intentional glitchyness gotten erratic and unpleasant? It's like it randomly gets a seizure
I believe I turned off the NTSC filter's merge fields setting, now that we have vsync. It needs to have its own panel just for that filter, I'm just really lazy and don't want to add the hooks to libfilter to allow modifying NTSC filter settings :/

The merge fields thing looks good when not running at perfect 60hz, but it's less faithful. I figured more people would be using that filter with the idea of faithfulness, and thus vsync, enabled.
Oh, I wasn't bugging you about those again, they're years away from feasible.
Just stemming off the inevitable. I do wish it was quick and easy to add those, like with the other chips. So far the Cx4 has been the worst (thanks to Andreas Naive and neviksti's awesome S-DD1, SPC7110 and DSP-1 libraries, and Overload's DSP page for the rest.) And I even had at least half of the Cx4 done by Nach.
I'll just focus on the next two versions before I ask you if you're interested in contributing to something on the game management end of things.
I hear game-specific settings are in high-demand. But that's a difficult thing to get working right. But yeah, thanks; we'll cover that in a future release.
1. I noticed that you may have forgotten to remove video sync from the advanced section after it was added as a functional menu option.
Kay, we'll add that to the list.
2. What happens when someone uses multiple mice? You currently don't list the mapping as mouse00, just mouse. Will this ever pose a problem?
Both DirectInput and Xlib only support one mouse. If you plug in two, they both return input to the same device. You'd need something like ManyMouse to support multiple mice. I didn't bother as I didn't want to add another library dependency, and really -- how many people really have multiple mice on one PC?

It's definitely a really neat feature in ZSNES, and the library itself is definitely awesome. But I think the analog joystick mapping should cover people who really want to use dual justifiers / mice for bsnes.

If not, we can always add it in a future release. The guy's license is really permissive (zlib), which is awesome.

EDIT: this may pose some problems, too ...
On Windows, ManyMouse requires Windows XP or later to function, since it
relies on APIs that are new to XP...it uses LoadLibrary() on User32.dll and
GetProcAddress() to get all the Windows entry points it uses, so on pre-XP
systems, it will run, but fail to find any mice in ManyMouse_Init().

...

Please note that using DirectInput at the same time
as ManyMouse can cause problems; ManyMouse does not use DirectInput, due
to DI8's limitations, but its parallel use seems to prevent ManyMouse from
getting mouse input anyhow.

...

(XInput code isn't finished yet, but in the future this note will be true.)
Mmm ... those are what I use now. But I think ZSNES uses DirectInput, too; so who knows.
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

byuu wrote: Just stemming off the inevitable. I do wish it was quick and easy to add those, like with the other chips. So far the Cx4 has been the worst (thanks to Andreas Naive and neviksti's awesome S-DD1, SPC7110 and DSP-1 libraries, and Overload's DSP page for the rest.) And I even had at least half of the Cx4 done by Nach.
You should think about posting something like a DSP3 specific topic in the nesdev forum for kicks. I think seeing an active emulator author show interest in old mysteries can reinvigorate efforts to solve them. There aren't any glamorous ones left, but Gundam GX still buys the farm despite most of the registers being bit perfect.
I hear game-specific settings are in high-demand. But that's a difficult thing to get working right. But yeah, thanks; we'll cover that in a future release.
Well, what I'm talking about isn't bsnes related. I'll... PM you sometime.
Verdauga Greeneyes
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

byuu wrote:Yeah, I wasn't sure about the math. That's why I put the height scale first. I think your code should be fine, too. If someone can definitively show them to be the same, we can use that just because it's smaller, which is nice.
Proofs are my worst nightmare :P I'll see if I can categorically show it works for all cases.
byuu wrote:I believe I turned off the NTSC filter's merge fields setting, now that we have vsync. It needs to have its own panel just for that filter, I'm just really lazy and don't want to add the hooks to libfilter to allow modifying NTSC filter settings :/

The merge fields thing looks good when not running at perfect 60hz, but it's less faithful. I figured more people would be using that filter with the idea of faithfulness, and thus vsync, enabled.
Aah, I figured it would have something to do with the vsync stuff. I recently got an LCD, which probably makes it more noticeable. Unfortunately I have to run the audio at 31950Hz to avoid crackle, so all the frame duplication is probably throwing it off. How hard is this to enable manually?
byuu

Post by byuu »

You should think about posting something like a DSP3 specific topic in the nesdev forum for kicks. I think seeing an active emulator author show interest in old mysteries can reinvigorate efforts to solve them. There aren't any glamorous ones left, but Gundam GX still buys the farm despite most of the registers being bit perfect.
Well, one; I felt bad that I was of zero help with the SPC7110. I don't want to bug them again about the DSP-3. And two, SD Gundam GX sucks. Hard. :P
Not worth the trouble. Same for those Japanese Chess games. Though I am generally interested in the ST-018's RISC instruction set / clock speed info, just for the sake of homebrew. Might be worth emulating if demo games can use it. And to help MAME out with any game(s) that use it.
How hard is this to enable manually?
src/lib/libfilter/ntsc.cpp:line 68:

Code: Select all

  adjust(0, 0, 0, 0, 0, false);
->

Code: Select all

  adjust(0, 0, 0, 0, 0, true);
A config panel for adjusting all of its neat settings is on the perpetual to-do list :/
Verdauga Greeneyes
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

Talk about simple! Adjusted it and the twitching has vanished, as expected. Also decided to apply my scanline shader, and the result is perfect 8)
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

byuu wrote:Well, one; I felt bad that I was of zero help with the SPC7110.
But that was the point of my suggesting it, it's actually something other people can do and might be willing to do.
And two, SD Gundam GX sucks. Hard. :P
I know it sucks, but these guys don't do it for that. Any completist would be bothered by the fact that licensed games were still screwing up and nobody knew why. That anybody ever worked on them at all proves it. I know a concerted effort around the DSP3, DSP4, or ST010 could perfect their remaining registers and get them playing without issues. Tell them your ultimate goal, how far you've come, that you'd appreciate any help you can get. Worst they can do is say no.
Dullaron
Lurker
Posts: 199
Joined: Mon Mar 10, 2008 11:36 pm

Post by Dullaron »

byuu wrote:And to help MAME out with any game(s) that use it.
Is this a joke? When did you care about MAME? You don't even work with them.
Window Vista Home Premium 32-bit / Intel Core 2 Quad Q6600 2.40Ghz / 3.00 GB RAM / Nvidia GeForce 8500 GT
Locked