Unusual screen tearing in GBC emulators


Arkay Firestar

Very Active Member
Joined
Apr 28, 2010
Messages
245
i have the whole suite of .emu emulators on my pandora and they all work fantastically EXCEPT GBC.emu, which has a weird screen tearing issue. I've tweaked every setting but it still does it. The tear is vertical and in the right half of the screen consistently.

I tried gambatte as well and it did the same thing which I found REALLY weird.

Gngb (I think it's called) is the most recently updated GBC emulator and it DIDN'T do it, but it's also nowhere near as polished to use (I really prefer the .emu ones). It's so weird that this doesn't happen on SNES or GBA, which are significantly more demanding.

Help? :(
 
GBC.emu is based on Gambatte, so it makes sense there are bugs they share.
It's so weird that this doesn't happen on SNES or GBA, which are significantly more demanding.
Emulators are a lot more complicated than "this hardware is more powerful, therefore it's harder to emulate". Some systems like the Sega Saturn can almost not be emulated at all despite the hardware being relatively slow, while others like the PSP of Nintendo DS are relatively easy to emulate (whatever easy means with software as complicated as emulators). Also, not all emulators have the funds, demand from the community or good developers with enough time to get their sofware to work perfectly. Even two emulators for the same system can work VERY differently, like you see in your example of Gambatte/GBC.emu and GnGB.

If one emulator doesn't work as it should, tell the developer and/or use another one.
Maybe it's just the port that has problems, in this case you could ask @ptitSeb, but with both ports sharing this bug, I don't believe that to be the problem.
 
GBC.emu is based on Gambatte, so it makes sense there are bugs they share.

Emulators are a lot more complicated than "this hardware is more powerful, therefore it's harder to emulate". Some systems like the Sega Saturn can almost not be emulated at all despite the hardware being relatively slow, while others like the PSP of Nintendo DS are relatively easy to emulate (whatever easy means with software as complicated as emulators). Also, not all emulators have the funds, demand from the community or good developers with enough time to get their sofware to work perfectly. Even two emulators for the same system can work VERY differently, like you see in your example of Gambatte/GBC.emu and GnGB.

If one emulator doesn't work as it should, tell the developer and/or use another one.
Maybe it's just the port that has problems, in this case you could ask @ptitSeb, but with both ports sharing this bug, I don't believe that to be the problem.

Right, understood. I guess I was more surprised that I wasn't seeing anyone else reporting these issues, and so I thought it might be a system unique issue.

Is there a vsync option I could explore in a config file? It seems the config file is in the PND for the .emu release?

As a reference, I've tried to upload a gif off my iPhone (let's see if this works!)
[doublepost=1473015527,1473014930][/doublepost]
I've been using 8Blitter for Gameboy. Works well and no screen tearing issues.

Dude, great reco. I hadn't seen this one before and can confirm it doesn't exhibit that issue. I do wish I could control where its save files go, but with the OpenGL renderer, it seems pretty flawless.

Thanks!
 

Attachments

  • image.gif
    image.gif
    4.4 MB · Views: 450
Right, understood. I guess I was more surprised that I wasn't seeing anyone else reporting these issues, and so I thought it might be a system unique issue.

Is there a vsync option I could explore in a config file? It seems the config file is in the PND for the .emu release?

As a reference, I've tried to upload a gif off my iPhone (let's see if this works!)
[doublepost=1473015527,1473014930][/doublepost]

Dude, great reco. I hadn't seen this one before and can confirm it doesn't exhibit that issue. I do wish I could control where its save files go, but with the OpenGL renderer, it seems pretty flawless.

Thanks!
Happy to help! :) I use a lot of .emu emulators too. Most are fine, but the GBC one does have a very prominent tear in it. I went through all the options like you did and couldn't solve it either! 8Blitter has been working well for me though.
 
Well, the GameBoy runs at an especially weird refresh rate (59,7Hz) which no LCD does support... so it's not easy getting it tearing free (Well, running at 60Hz would be an easy way, but then it would run a tiny bit too fast)
 
Ah. Thanks ED, I didn't know that. I'm even more impressed how anyone can get it working tear-free! :)
 
Us PAL gamers are well used to running games 6% too slowly on our weird TVs, and I guess we're now getting used to playing our childhood games 6% faster than we remember them. So playing our handheld games 0.5% faster should be a no brainer, I'd have thought!
 
I've been using 8Blitter for Gameboy. Works well and no screen tearing issues.
8Blitter is fantastic - it runs my Metroid II Colour hack rom much better than most emulators. I just wish someone with enough know-how could get some better sound code in there...
 
Us PAL gamers are well used to running games 6% too slowly on our weird TVs, and I guess we're now getting used to playing our childhood games 6% faster than we remember them. So playing our handheld games 0.5% faster should be a no brainer, I'd have thought!
Eh? Didn't we play them 16,67% slower than the rest of the world and 20% faster now if we don't use PAL roms?
This makes your argument even better, I just wanted your math to be correct ;)
[doublepost=1473097422,1473096746][/doublepost]By the way: The Super Gameboy was known to run games 2,4% faster, and barely anyone even noticed. So having an unofficial emulator run them 0,5% faster should really be no problem for anyone but speedrunners or extreme purists, but both of these groups don't use emulators anyway.
 
Well, the GameBoy runs at an especially weird refresh rate (59,7Hz) which no LCD does support...

Actually, I think 60Hz NTSC is 29.97 frames per second, aka 59.94 fields per second, so I expect 60Hz LCDs are actually that rate.

Edit: Though I misread your 59.7 rate as 59.97 so there's still a fair difference if you're right.

Edit2: Wikipedia confirms your number, but reckons a SuperGameboy displays games at over 61Hz field rate. No idea how it does that on an NTSC analogue TV. I guess it was always possible to overclock a TV to a certain degree. On the original PAL TV I used with my Dreamcast, the display would simply get shorter in '60Hz' mode, i.e. there'd be a black border at the bottom, and all circles would be slightly fat.
 
Last edited:
@Arkay Firestar : Unzip this file inside your GBC roms, maybe it will help.

Thank you for the suggestion! I gave it a shot (uploaded the .ini to the same folder the ROMs are in) and it didn't seem to have an effect on the tearing. My ROMs are zipped btw; not sure if that would affect anything.

Appreciate the attempt to help (and thanks for everything you've done for Pandora btw)
 
Here you go (posting with the Pandora... I really can't wait for Pyra's speed improvements for web browsing):

=======================================================================================
PND : /media/SD2/pandora/menu/GBCemu.pnd
PND_FSTYPE : Squashfs
APPDATADIR : /media/SD2/pandora/appdata/GBCemu
APPDD_FSTYPE : vfat
PND_CPUSPEED : <unset>
EXENAME : runscript.sh
ARGUMENTS : <unset>
=======================================================================================
[ START ]--- Mount the PND ----------
Mounting : mount -t squashfs -o ro "/dev/loop1" "/mnt/utmp/GBCemu"
Mounting the Union FS : mount -t aufs -o exec,noplink,dirs="/media/SD2/pandora/appdata/GBCemu=rw+nolwh":"/mnt/pnd/GBCemu=rr" none "/mnt/utmp/GBCemu"
[SUCCESS]--- Mount the PND ----------
[ START ]--- Starting the application ( runscript.sh ) ----------
--------------------------------------------------------------
Setting PATH to /mnt/utmp/GBCemu:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
--------------------------------------------------------------
Setting LD_LIBRARY_PATH to /mnt/utmp/GBCemu/lib:/lib:/usr/lib
[SUCCESS]--- Starting the application ( runscript.sh ) ----------
[ START ]--- Restoring the frame buffer status ----------
[SUCCESS]--- Restoring the frame buffer status ----------
[ START ]--- uMount the PND ----------
[ START ]--- Waiting the Union to be available ----------
[SUCCESS]--- Waiting the Union to be available ----------
rmdir: failed to remove `/mnt/utmp/GBCemu': Device or resource busy
[ START ]--- Waiting the PND mount dir to be free ----------
[SUCCESS]--- Waiting the PND mount dir to be free ----------
cleanup done
[SUCCESS]--- uMount the PND ----------
=======================================================================================
Return code is : 1
 
Nothing wrong here.
I need to update the packages. I have a new build (with latest sources), unfortunatly, the C64 emu doesn't work anymore (many changes on the this one). I already spent some time trying to make it work, but still no go (well, it start, but it still fail to find any C64 module).
It seems I have some crash with shader selection too, but I haven't investigated at all that point.
I'll try GBCemu and see if I see some tearing in my build...
 
Nothing wrong here.
I need to update the packages. I have a new build (with latest sources), unfortunatly, the C64 emu doesn't work anymore (many changes on the this one). I already spent some time trying to make it work, but still no go (well, it start, but it still fail to find any C64 module).
It seems I have some crash with shader selection too, but I haven't investigated at all that point.
I'll try GBCemu and see if I see some tearing in my build...

Ok, so, I'm a bit embarrassed to admit this, but during my pre-sleep web browsing ritual, I just saw that 72 is NOT the newest Pandora firmware; that we're up to 75, and that more importantly, that 74 introduced some major vsync stuff. Will update tomorrow and figure out if maybe this was user stupidity all along. If so, in my sheepish defense, it's beyond belief that this system is still seeing so much support years after its launch. I'm honored to have one of these.
 
Back
Top