-
-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
parse SGB movie files to use the GB label #1125
Conversation
I personally don't particularly care with the policy here, other staff can discuss that. My only concern to it would be if someone decided to TAS that Space Invaders game that uploads SNES code and has that executed or some ACE playaround (e.g. Pokemon Plays Twitch) doing that. Someone should figure out how to resolve that. That aside, there is a slight issue with this. Namely, framerates. This is a bit of a complicated issue, namely due to the multiple ways "framerate" can be defined. The internal GameBoy speed on the SGB1 is derived from the SNES master clock. This is lazily divided by 5 to get the clock rate, which after that dividing by 70224 will give the internal nominal framerate, ~61.167 FPS on NTSC (21.477Mhz / 5 / 70224), and ~60.61 FPS on PAL (21.28137Mhz / 5 / 70224). On the SGB2, a separate clock is used for the internal GameBoy speed, making the internal speed and nominal framerate identical as the GameBoy regardless of region (~59.7275 FPS) However, these internal nominal framerates do not mean so much in LLE cores (i.e. lsnes, both old and new BizHawk BSNES) and on the actual system, which would have actual frames displayed and inputs sent at the SNES' framerate (~60.099 FPS for NTSC, ~50.007 FPS for PAL), dropping/duping GB frames to maintain that framerate. As inputs are sent at this rate, these framerates would used for LLE cores (which depending on region, with SGB 1 vs 2 playing no choice here). For HLE cores however (Gambatte in BizHawk), the SNES framerate would not be used, rather the internal nominal GB framerate, as the actual SNES is not emulated as the commands sent to the SNES are HLE'd. VBA is also an HLE core, although that's 60 FPS and even then you still have problems with its timing and then you have the detail that SGB is banned for VBA (although GB/C VBA is likely going to be put on that ban list soon, so eh). And then even so, Gambatte still gives a variable framerate due to the fact the GB framerate is a nominal framerate rather than an absolute framerate, so cycle count would need to be used. As Gambatte only supports the SGB2 and as established the SGB2 internal timing is identical to the GB ends up working out (so as is it just works). The old SGB SameBoy core in BizHawk (removed in 2.7) (see #332) should be noted to run at the nominal SGB1 NTSC framerate instead, and it is forced to run with Equal Length Frames, so cycle count isn't needed there but just that framerate. So tl;dr framerate is wrong here for LLE SGB emus. |
Added frame rate override settings for bSNES based SGB movie files. |
This was discussed briefly in discord. But I the idea was that we do default parsing to GB. Then in the rare instances where SGB makes sense (such as a TAS that actually utilizes SGB/SNES hardware, or a game that utilizes its capabilities) we can just manually change it to SGB. These would be rare enough that the manual work is fine |
Is SGB just a mode or are there games that actively utilize its features? Are there SGB-only games? I agree that if someone makes an SGB only movie, removing SGB entirely solves zero problems but adds new ones like having to classify it wrong. |
Please be more specific. Which ones of these features do you think would be worth of using the SGB system name? |
Quoting Wikipedia: "The Super Game Boy is a peripheral that allows Game Boy cartridges to be played on a Super Nintendo Entertainment System console. The Super Game Boy is compatible with the same cartridges as the original Game Boy: original Game Boy cartridges, the Game Boy Camera, and dual-mode Game Boy Color cartridges (in Game Boy-mode)."
The latest commit in this branch keeps SGB as a platform on the site and only makes SGB submissions parsed as GB by default.
Yeah, it is important to draw an actual line for "SNES features", because if we take it in the literal sense, even simple display of colors beyond monochrome can be considered "SNES/GBC/GBA/GBP feature".
This is often used as an example on this topic, but it seems the SNES mode from that game is identical to the SNES version of the game (https://tcrf.net/Space_Invaders_(SNES)) so I doubt there is much practical reason for someone to make a submission of the SNES mode of that game unless it's about ACE demonstration, just saying. |
There should be some rewording of what this PR ends up doing, because people read it, see that it removes SGB as a platform, and get confused. |
This reverts commit 69d3bb1.
…1125)" (TASVideos#1162)" This reverts commit 06d0050.
…SVideos#1125)" (TASVideos#1162)"" This reverts commit 624e3b7.
Related to #1030.
It doesn't make much sense to use SGB as a separate system on the site when GB movies done on GBC mode are still labeled as GB (the same applies to GBC movies on GBA, GBA movies on GBP, etc).
The use of SGB as a separate system is even causing issues like this movie being unintentionally un-obsoleted.
This commit aims to make the parsing system label future SGB submissions as GB. SGB is still kept as a platform on the site and in edge cases, a movie can be manually changed to be under that as a system.