Will the colors from the 2 options still be different if you paste them into some other program like Paint?
Keep in mind the gray palette is not at all a measure of accuracy, rather they are chosen as they are the easiest to look at and have perfect contrast. As far as the Game Boy was concerned there were no "colors" other than "0, 1, 2, 3", going from light to darker, and not necessarily linear in that path. The original Game Boy had some shades of green, and the Game Boy Pocket had some shades of gray, but they were not the perfect contrasting grays given by default in Gambatte. If you want "accuracy" you could want to switch to the SameBoy core, where you can select between the colors of various models (i.e. original Game Boy, Game Boy Pocket, Game Boy Light) along or the "perfect" shades of gray.
The second image in https://tasvideos.org/Forum/Topics/24580?CurrentPage=1&Highlight=523813#523813 The light gray has 0xBDBDBD and 0xBEBEBE, the dark gray has 0x686868 and 0x696969, which are quite off. Having some differences is actually normal, it's due to the fact that internally the core only stores custom palettes as RGB555 (while the user selects colors in RGB888, so it converts them downwards), when it gets put on the screen it has to be converted to RGB888, that process is a bit lossy but it doesn't really matter much as you couldn't tell without getting some tool to check the exact colors. Even then the differences should be minor, not major like the above example I brought.
I use Windows 10 myself. I assume it'd be due to some configuration or whatever on your end. Something is definitely going completely wrong here, as the colors are just wrong in the first place.
Trying this myself (using the default gray palette, which has all 3 palettes use the same gray palette) and I can't replicate. Furthermore, your screenshots suggest you're using a custom palette anyways, as the grays do not match the default gray palette in Gambatte. I could guess your custom palette actually has different grays between the 3 sets of palettes in it resulting in more colors. That or something else is going wrong anyways (maybe Windows code for sending it to the clipboard is going wrong? which case there is not BizHawk bug, perhaps it's some setting you enabled or whatever, or maybe it's actually the fault of the program you're pasting it into)
I used the eye dropper to get the color values: 1st color: 255, 255, 255 - 2nd color 170, 170, 170 - 3rd color 85, 85, 85 - 4th color 0, 0, 0. BG, SP1 and SP2 all have the same values.
Is that what the default palette is and would that be the most accurate palette to use for making maps of Game Boy games?
I'm guessing if it is a problem with Windows code (I'm using Windows 10), then there is nothing I can do other then using "print screen" to get the accurate colors. It makes one extra step for me for each screen shot I capture, but I can handle that if it is the only way.
So I eliminated the Program I'm pasting into because your image included in your post imports into Photoshop just fine. I eliminated using the default gray palette if you can verify the values I typed in are correct for the image I took of my color palette settings. So all that leaves from your list is Windows is to blame.
Can you, or anyone else if you don't have a computer with Windows, post an image to this topic so I can load that into Photoshop and see if it has the correct colors or not?
Incorrect image with 6 colors taken in the same spot with Ctrl + C:
Edit by feos: Embedded the pics.Can you post example images, with 4 proper colors as it should be, and the same frame with 6 colors?
Ctrl + C messes things up? Are you sure you don't mean Ctrl + Shift + C? Ctrl + C is a raw copy of the emulator's frame buffer, so it should have no issues at all (Ctrl + Shift + C goes through a GPU render pass which could screw things up maybe depending on however you configured the display and driver quality and such)
A better question is, does it work ok in the newest bizhawk release?
If the release history is anything to go by, this is an interim build between 1.4 and 1.4.1, which is... one full decade out of date. I'd be shocked if this is somehow still a problem on 2.9.1, given all of the updates to RAM Search and Gambatte since.
Config - Preferred cores. Current core is at the bottom of the hawk window in the status bar.
Which core?
When using Snes9x (or old BSNES), RAM Search defaults to searching WRAM. When using BSNESv115+, it's the CARTRAM, which might appear to be frozen. You can switch to another domain and the values will update as normal (tested on 2.7).
