Regarding the SameBoy core

First of all, a big thank you to all of you and the hard work you are doing!

Now on topic, I’ve seen a ton of commits being made on the SameBoy core and have started to notice heavy work is being made on it which is really nice.

This have lead to thoughts on how SameBoy might be the next replacement for my Game Boy and Game Boy Color needs. Where does SameBoy stand compared to Gambatte, bgb, mGBA etc.

Is it more accurate in terms of emulation and sound or is it not quite there yet?

http://tasvideos.org/EmulatorResources/GBAccuracyTests.html doesn’t seem to have been updated for quite a while and does not have SameBoy even mentioned.

Accuracy and authenticity is all I care about and it looks like SameBoy is about to surpass the competition.

SameBoy is extremely accurate. For example, it is the first (and only, AFAIK, though that may have changed since the announcement a few weeks ago) emulator to accurately emulate Pinball: Deluxe (some older, inaccurate emus ran it, basically by accident).

Gambatte is still very good and runs on actual potatoes, but if you’re shooting for pure accuracy, I think there are a number of test ROMs that SameBoy passes (along with a few other hyper-accurate emus) that Gambatte does not.

2 Likes

Well my initial tests and experiments with the core were very promising and positive, I definitely liked what I saw and heard.

One concern though, on Game Boy Color there was a core option called “sameboy_color_correction_mode” and I chose “emulate hardware”, OK fair enough but how does it play along with shaders like “gbc-color.glsl”

Is there no longer any need for using the “gbc-color-glsl” shader or is the option “sameboy_color_correction_mode” for something else?

1 Like

Dunno for sure, as I haven’t actually played around with those options, but it does seem to do something similar, just glancing at the code. I think it would be an either/or situation rather than a both situation. Which one you decide to go with is up to you.

1 Like

Thanks for clearing that up, I’ll have to test more with both the option and the shader on Game Boy Color games to see the difference properly.

It’s easier with DMG games because then I’ll just use the “gb-shader.glslp” which provides me with accurate DMG colors from the get go.

Another question if you mind, could you explain in layman terms what the “sameboy_high_pass_filter_mode” core option does? There is off, accurate and remove dc offset to choose from and by instinct i choose accurate even though I have no idea what this option does.

1 Like

from the source:

GB_HIGHPASS_OFF, // Do not apply any filter, keep DC offset
GB_HIGHPASS_ACCURATE, // Apply a highpass filter similar to the one used on hardware
GB_HIGHPASS_REMOVE_DC_OFFSET, // Remove DC Offset without affecting the waveform

Sort of similar to the low-pass filter stuff that’s been going on with GenPlusGX, there’s some stuff that goes on with the Game Boy’s audio hardware that filters out some unwanted noises. The ‘accurate’ one reproduces the hardware behavior while the other options give you the exact signal created by the software sans any hardware filtering that my have occurred afterward.

1 Like

Thanks man, I really appreciate your comments and when you referred to GenesisPlusGX then I understood better because I have followed the progress on it for some time now.

I’m all in for accuracy options that makes it as close to the hardware as possible.

SameBoy seems like an excellent core so far, although I’ve had quite some audio pops in some games, Link’s Awakening comes to mind immediately but from what I can tell by the commits sound is being worked on so I think it’s only gonna get better from here!

Once the remaining sound pops are worked out it’ll probably be the go-to accuracy GB/GBC emulator. The author mentioned a major speed up for an upcoming version too. If you want more info about the core options and recent developments, there’s a discussion here: https://github.com/LIJI32/SameBoy/pull/14

Does anyone know if Sameboy has any interest in adding super game boy borders/colors like BGB? It’s nice to have real super game boy emulation with higan but it’s also very demanding.

High-Pass filters explained: When the Game Boy APU is playing sound, silence is not always represented by the PCM value of 0 (i.e. it has DC-offset). Since this DC-offset can be controlled by software running on the Game Boy, it must be retained for accurate emulation (This is what causes the infamous pop sound when you turn a Game Boy on, and it’s also cleverly used by some games). Regardless of high-pass mode, SameBoy always emulates the DC-offset.

Now, if you plug in an AUX cable to a Game Boy and record its audio output, you’ll notice there isn’t any DC-offset, although its effects can be heard! This is because the Game Boy itself has a capacitor used as an analog high-pass filter, which effectively removes the DC offset.

So the 3 modes work as follows:

  • GB_HIGHPASS_OFF outputs the audio exactly as the APU would, skipping the capacitor and retaining the DC-offset as digitally output by the APU. Because in this mode silence is no longer represented by PCM 0, you will hear a popping sound whenever you pause or resume the emulator.
  • GB_HIGHPASS_ACCURATE digitally emulates the analog high-pass filter to remove the DC-offset. However, like on real hardware, it also lowers the volume of lower frequencies.
  • GB_HIGHPASS_REMOVE_DC_OFFSET is a tradeoff between both previous modes. It separates the DC-offset from the rest of the wave form, and applies the high-pass filter to the DC-offset alone. This way the DC-offset is removed while preserving the waveforms.

GB_HIGHPASS_ACCURATE is the default in all SameBoy ports (Cocoa, SDL and libretro)

As for SGB support – I’ve considered this for a while, but it’s currently not a goal for SameBoy 1.0. My main reasons against it is that SameBoy is accuracy focused, and accurately emulating SGB/2 requires emulation of an SNES/SFC, and high-level emulation of SGB is often inaccurate (Borders on some tricky games), difficult to implement (additional sound effects) or simply impossible (Code execution, like in Space Invaders). So currently, I’d rather avoid investing in half-working SGB emulation when higan already emulates SGB exceptionally well.

3 Likes

Just curious, which one of those modes would gambattes audio be closest to?

Probably GB_HIGHPASS_ACCURATE.

1 Like

SInce there is a thread about the sameboy core, got one question: Is it me, or is the picture output of sameboy broken, if the vulkan driver is selected? The picture is just white, regardless what i do…

Anybody else got this issue? Or is the core simply not working on vulkan?

It’s software-rendered, so it shouldn’t matter, but I’ll try to verify tomorrow if no one beats me to it.

I recently opened a issue regarding sound pops and clicks here, when this issue is solved SameBoy will likely be the No.1 GB/GBC emulator of choice if accuracy is what you want.

Thanks for looking into it, tried different graphic drivers, oder ones and new ones. And tried it without and with slang shaders, doesn’t make any difference at all, the output is 98% is just white, sometimes there are black vertical stripes in the picture, but that’s all i can see. If it’s any important, i use a nvidia gpu…

I’m getting the same behavior with my AMD card at work, so yeah, something seems to be afoot. Dunno what would cause such a thing, though…

@hunterk @Kurozumi

There have been a commit made to address this issue here

Do you still have problems with Vulkan?

Looks like the buildbot is still on an older build from before the fix went in. It seems this commit is breaking the Travis builds (and probably the buildbot, as well):

1 Like

I had this happen whenever I used threaded video on my laptop. I used to have this problem with Vulkan when it first came out. You do see the first scanline from the top pulled to the entire screen. Recent updates has big speed improvements.