Just a small wonder concerning RetroArch settings:
There are two instances of “bilinear filtering” under the option menus, one under “video settings,” the other under “shader settings.”
Should those two be left ticked (as it is by default), if one desires to mimic the output of bsnes?
Unticking them does not seem to produce any effect under fullscreen, which brings another question regarding the conditions of its application?
EDIT: edited title for relevance.
Also, concerning the “gamma” of bsnes video settings, is it at 150%, like bsnes default, or at 100%, as unapplied gamma correction?
EDIT: the post of hunterk, right below this one, is right, in that RetroArch does not apply any kind of gamma correction (niceness out of the box!).
The one in the shader settings only applies to the 2-pass FBO shader. If you’re only using a single shader, you’ll never see it either way.
bsnes has bilinear filtering as an option, as well, it’s just called ‘blur’ there (previously known as ‘smooth video’). Whether or not you enable it is entirely up to you.
You may not be seeing any difference with/without it due to utilizing a pixel shader, some of which override that setting to avoid looking like crap.
I am not using the “blur” shader on bsnes, so I will make sure to disable it on RetroArch, too.
Concerning the gamma setting, do you have a clue? I know under bsnes I have to decrease gamma to 100 whenever using the CRT shader, but do I have something similar to perform under RetroArch?
twipley
I don’t think you have to do anything. AFAIK, RetroArch doesn’t do any kind of gamma correction of its own. You might want to compare its output with bsnes with the gamma set to 100 to be sure.
Something is not right. Here are three setting outputs:
(1) bsnes + flat crt shader + disabled (100 gamma): http://i.imgur.com/TGjLc.png (2) bsnes + flat crt shader + default (150 gamma): http://i.imgur.com/nxMSY.png (3) retroarch + flat crt shader + default (unavailable): http://i.imgur.com/LdQfH.png
What on heck is going on there? Both applications are using default settings, as far as I can ascertain. Same shader; same rom. What, then, accounts for the differences between the third one and the other ones?
EDIT: If someone could test to see which application (bsnes or retroarch) produces an incorrect output, it would be very appreciated. I have done screenshot comparisons of “crt shader” vs “ungamma crt shader + ntsc filter,” but cannot publish as of yet because of this particular issue!
In higan or bsnes or whatever, set brightness, contrast, and gamma all to 100% (the value, not the slider position). That should make its output look identical to RetroArch’s.
RetroArch faithfully writes the colors it’s told to write via libretro. It doesn’t do any unexpected post-processing. It’s very likely that what RetroArch is doing is correct here.
Also, by default, RetroArch writes square pixels. If you want, you can change that by editing the aspect ratio setting.
All of the slider values are set to 100% in the first screenshot. I am at a loss here to understand what is going on.
If that’s the case, then byuu changed something major. In the bsnes.exe v087 I have (since higan refuses to work for me), setting all sliders to 100% produces identical output to what RetroArch produces. (edit: incorrect silly statement going on bad memory; read further)
In other words, ask byuu.
By the way, just to be sure we’re on the same page, this is what the settings look like with all sliders set to 100% (at least, in bsnes v087):
Here’s the output:
Oh, wait. Here’s the RetroArch + bnes v083 output:
Byuu must have changed the palette. That’s the best explanation I can imagine without looking at the actual changes. With the old bnes core in RetroArch, the output looked the same. I know because I did that test before, a few months ago. Haha!
Ah, yes, bNES switched to an algorithmically generated palette in v084:
However, this palette doesn’t look quite right, subjectively:
So, the difference wasn’t between higan and RetroArch, but rather between bNES v083 and v084+. I think it comes down to your own decision on which option you prefer. byuu went with Bisquit’s, not because it was more “accurate,” but because it was objective and thus more difficult to argue with.
That’s it then! We have clarity.
I also confirmed that this is true in the bsnes source code. bnes-libretro (which is based on the nes part of bsnes v083) defines a constant palette array, whereas the current bsnes source has
void Video::generate_palette() {
for(unsigned n = 0; n < (1 << 9); n++) palette[n] = generate_color(n, 2.0, 0.0, 1.0, 1.0, 1.8);
}
and, of course, generate_color is a much longer function.
Great! That’s good for clarity to having been achieved.
(1) Is there any reason RetroArch is lagging behind with such cores as bNES v083? i.e. for not using the latest ones?
byuu went with Bisquit’s, not because it was more “accurate,” but because it was objective and thus more difficult to argue with.[/quote]
(2) I am not sure I am following you on this one. Pardon the questioning, but how would you define “accurateness?”
I thought what was accurate in this field was that which followed “correct” mathematical demonstrations – in this case Bisqwit’s palette.
Which quite-well resumes the personal philosophy of mine regarding emulation. I believe yours is the same, unless stated otherwise. 
It’s a lot of trouble to keep up to date on all of byuu’s work for a lot of reasons. For libretro-bsnes, maister has to translate all of the code from C++11 to C++98, which is a big task in and of itself. For bNES, he has to excise the NES-specific code, changes to which aren’t very well documented, and incorporate it with the libretro wrapper code. It ends up being a lot of work for little return (like palette changes), especially when there are other cores for the same system that are faster and more complete (i.e., fceu). Plus, maister has just been really busy with other things (life, etc.).
I may take a look at things with bNES and see if I can bring down any of the changes, though it’s likely out of my league.
As for palette accuracy, NES palettes are a hotly debated topic in some circles. The way we actually perceive(d) the colors is affected by a lot of analog (re: impossible to capture perfectly in digital form) factors, from the CRT displays to the individual NES units themselves. Since they all look slightly different, there’s no “one true palette,” and people will argue about it endlessly.
A lot of NES emulators have a palette file (a LUT? I may be using that word wrong) with a grid of available colors that have been hand-picked to reflect the colors the author remembers/sees. Instead of going this route, which invites comments like “your Mega Man blue is too warm,” byuu went with an algorithm that determines the colors and if someone doesn’t like it, they can take it up with the algo.
Personally, I had a lot of different TVs growing up and they all looked different, so the palettes don’t really matter much to me, as long as they get pretty close (I don’t want Mario in a purple hat; that’s distracting).
Your posts are so informative dude, keep it going! 
[…] This is the same reason I went with Bisqwit’s NES palette. I like yours more, I like the webpage one I took more. But Bisqwit’s has mathematical correctness.[/quote]
If I am getting it correctly, no bsnes build at all has ever made use of the Firebrandx palette? Screenshot comparisons between bNES v083, bNES084+, and Firebrandx palettes at some point in the future would sure be nice to have.
I was also wondering: so, there being NES-palettes arguing, is there any too, not related to NES/FDS, but to GB, GBC, GBA, and SNES?
I don’t understand this question. “Is there any too to GB, GBC, etc.?”?
Which I mean is, given there are discrepancies between different NES palettes to be used, is there variance too concerning SNES palettes?
EDIT: forgive my gibberish technobabble.
No. SNES games’ palettes’ colors are chosen from the 15-bit RGB color space and specified in the game’s code. All emulator cores should report the same output colors for any particular SNES game scene.
Yeah, I think most other systems have either too many or too few colors to really dispute. Perhaps the Sega Master System or Atari Lynx, etc. has a similar debate, though…
If you want to read about the origin of Bisquit’s NES palette, here’s the NESdev thread: http://forums.nesdev.com/viewtopic.php?f=3&t=8209
It looks like it’s already color-corrected for the NTSC color gamut, which may explain some of the differences.