I have tried running this on my FXPAKPro. It ran but the SNES sprites flicker like anything. I thought that was supposed to be fixed? I tried updating to the latest firmware (2023) and tried running it again but there was no change. Have I done something wrong or missed something? It flickers like the description of the original design flaw which was supposed to be fixed. Very perplexing. I'm writing a blog post on this and I'll be forced to report that it doesn't work properly on an FXPAKPro unless you can tell me how to fix it. Thanks
Don't be worried, your FXPakPro is working great: the "SNES Sprites" feature of the SGB does flicker, whether you play it on real hardware or emulator. I designed the game with a plain white background to try to mitigate this issue, but the SNES sprites will still appears translucent / ghostly due to the constant flickering.
I'm sorry if the game page description wasn't clear on this topic, but this feature is flawed due to the flickering, and that's likely why Nintendo disabled it. The "fix" performed by this game is to be able to enable this feature back (it's normally locked away), but I don't think anything can be done to prevent the flickering.
I tested my SD2SNES (previous name of FXPakPro) and it does emulate the SGB1 and SGB2 perfectly to my eyes: I didn't notice any difference running my through an actual SGB / SGB 2 and the FXPakPro while testing my game.
So I have to ask, if enabling the flag for the extra sprites disables the VRAM upload command, what stops you from using the command to write to RAM to disable the flag, upload to VRAM and then just re enable the flag to allow for snes sprites?
Hi! You have a good idea, but it's actually a bit more complicated than that. The VRAM upload in the sprites area is permanently disabled in the SGB BIOS, like the "SNES Sprites control" function. According to the SGB documentation, you can set a flag for the VRAM upload to send data to the sprites area, but in reality, the code of this function in the SGB BIOS disregard this flag and always send data to the "background area".
It may be possible to patch the SGB Bios to restore the VRAM sprites upload, or to try to manually send graphics data a few bytes at the time using the general "SEND DATA to SNES RAM" function. Thanks to Nenson Dubois research, this function is used in my game to patch the SGB Bios to enable the "SNES Sprites" function, so there is still hope that it may also be possible to restore the sprites VRAM upload too.
But regarding the sprites flickering, I fear that this issue will never be solved, as I think that's what led Nintendo to disable the "SNES sprites" function in the first place. As the SGB Bios read the Sprites OAM data from the content of the GB Screen sent by the SGB (so from a portion of SNES VRAM actually), I don't think the SNES will have the time to do everything and maintain a 60 fps update.
Mesen-S is just Mesen 2.0 now. The emulator has been integrated into a multi-system emulator that supports NES, SNES, SMS, GBA, WonderSwan, WonderSwan Colour, Game Boy, Game Boy Colour, and of course SGB1 and 2, TurboGrafx-16, and ColecoVision.
Hi, thanks for the heads up! I personally used higan during this project (as it's almost 100% accurate and the one I'm used to), but I guess I should try to include Mesen 2.0 too, sounds neat that they support so much systems!
← Return to game
Comments
Log in with itch.io to leave a comment.
This is really cool! Took me a while to figure out how to emulate but I'm glad I did, it's unique and impressive and actually fun to play!
Thanks a lot for your comment, I'm glad you enjoyed it!
I have tried running this on my FXPAKPro. It ran but the SNES sprites flicker like anything. I thought that was supposed to be fixed? I tried updating to the latest firmware (2023) and tried running it again but there was no change. Have I done something wrong or missed something? It flickers like the description of the original design flaw which was supposed to be fixed. Very perplexing. I'm writing a blog post on this and I'll be forced to report that it doesn't work properly on an FXPAKPro unless you can tell me how to fix it. Thanks
Hi!
Don't be worried, your FXPakPro is working great: the "SNES Sprites" feature of the SGB does flicker, whether you play it on real hardware or emulator. I designed the game with a plain white background to try to mitigate this issue, but the SNES sprites will still appears translucent / ghostly due to the constant flickering.
I'm sorry if the game page description wasn't clear on this topic, but this feature is flawed due to the flickering, and that's likely why Nintendo disabled it. The "fix" performed by this game is to be able to enable this feature back (it's normally locked away), but I don't think anything can be done to prevent the flickering.
I tested my SD2SNES (previous name of FXPakPro) and it does emulate the SGB1 and SGB2 perfectly to my eyes: I didn't notice any difference running my through an actual SGB / SGB 2 and the FXPakPro while testing my game.
So I have to ask, if enabling the flag for the extra sprites disables the VRAM upload command, what stops you from using the command to write to RAM to disable the flag, upload to VRAM and then just re enable the flag to allow for snes sprites?
Hi! You have a good idea, but it's actually a bit more complicated than that. The VRAM upload in the sprites area is permanently disabled in the SGB BIOS, like the "SNES Sprites control" function. According to the SGB documentation, you can set a flag for the VRAM upload to send data to the sprites area, but in reality, the code of this function in the SGB BIOS disregard this flag and always send data to the "background area".
It may be possible to patch the SGB Bios to restore the VRAM sprites upload, or to try to manually send graphics data a few bytes at the time using the general "SEND DATA to SNES RAM" function. Thanks to Nenson Dubois research, this function is used in my game to patch the SGB Bios to enable the "SNES Sprites" function, so there is still hope that it may also be possible to restore the sprites VRAM upload too.
But regarding the sprites flickering, I fear that this issue will never be solved, as I think that's what led Nintendo to disable the "SNES sprites" function in the first place. As the SGB Bios read the Sprites OAM data from the content of the GB Screen sent by the SGB (so from a portion of SNES VRAM actually), I don't think the SNES will have the time to do everything and maintain a 60 fps update.
Cool trick.
Mesen-S is just Mesen 2.0 now. The emulator has been integrated into a multi-system emulator that supports NES, SNES, SMS, GBA, WonderSwan, WonderSwan Colour, Game Boy, Game Boy Colour, and of course SGB1 and 2, TurboGrafx-16, and ColecoVision.
Hi, thanks for the heads up! I personally used higan during this project (as it's almost 100% accurate and the one I'm used to), but I guess I should try to include Mesen 2.0 too, sounds neat that they support so much systems!
Yeah, it has a rather competent debugger that was always the main appeal of Mesen even over Higan/Ares(regardless of which one's more accurate).
Amazing concept! I love pushing the boundaries of these older hardwares.
Hi, thanks for your feedback. I too enjoy trying to push our beloved retro consoles whenever possible :)!
What a wonderful (and super nerdy) idea!
Thanks a lot for your comment, I'm glad you enjoyed it! :)