Mirrors/sf2000
2
0
Fork 0
mirror of https://github.com/vonmillhausen/sf2000.git synced 2024-11-03 08:35:12 +01:00
Code Issues Packages Projects Releases Wiki Activity

Added some workaround suggestions for the system logo/"Games Exist" UI issue

Browse Source
This commit is contained in:
vonmillhausen 2023-05-30 23:52:08 +01:00
parent e975a303af
commit 11474f6df6
1 changed files with 2 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@ -419,6 +419,8 @@ This section isn't really about the `Resources` files per-se, but it's tangental
- If you're including background music in your theme, note that when the SF2000 starts up it fails to output about the first 1 second of audio; therefore, if you'd like the person using your theme to hear your background music from the start, cut one second off the end of your background music loop, and move it to the start of the loop instead.
- If you're creating custom system logos (`sfcdr.cpl`), make sure the logos don't overlap the "Games Exist" image's screen area (`exaxz.hsp`, top-left coordinate `456, 88`, width and height `152, 72`); the main menu compositor clips an area of the section's _background_ image behind where the "Games Exist" artwork will be drawn, renders the "Games Exist" artwork into that clipped section, and then draws the result _on top_ of the system logo. As a result, any pixels of the system logo that should be visible in that area will be replaced by the background image, even if you make the "Games Exist" image fully transparent. Removing the `exaxz.hsp` file entirely doesn't work either, as you get garbage drawn on the screen in the same area instead. The only section not impacted by this is the "User ROMs and Settings" section, as on that screen the "Games Exist" artwork is not drawn.
- There's a workaround, but it's not perfect: you can bake a system's logo directly into the background for its main-menu section, and make it's portion of `sfcdr.cpl` fully transparent (so that you don't see the logo physically moving). As the code for drawing the "Games Exist" image pulls from the section's background, it'll pull the portion that overlaps with the system logo and render that too. The _downside_ is that the poor draw code of the stock OS only updates the horizontal portion of the screen that contains the rotating logos during section transitions, and only draws the lower portion of the screen (the bit under the rotating logos) afterwards. So baking your logo into background for the section will create some artificial "latency" for the theme user - they'll see the new logo appear instantly, then have to wait the quarter second for the invisible "rotation" animation to complete, before the lower portion of the screen with the new shortcuts for the new section appears.
- One _other_ workaround (that's even worse than the first workaround): bake just the portion of the system logo that overlaps with `exaxz.hsp` into the background. Doing it this way, you can still have your custom system logo in `sfcdr.cpl`, and still have it in the rotation animation (which gives the user something to look at, and reduces that fake "latency" feeling from the workaround above)... but you'll see the bit of logo baked into the background appear instantly, and then the rotating logo will slide up/down to meet it, so it'll still look a bit janky. So really it comes down to picking your particular flavour of jank: scaling your logos to avoid the `exaxz.hsp` screen area (which might leave you with a lot of empty space), baking your logo into the section background (adding fake "latency" to the experience), or only partially baking your logo into the section background (which will make things look jank during the rotation animation, but perfect otherwise)... the decision is yours!
- When designing your theme, think carefully about the use case in which you want your theme to look best. Although the SF2000 uses many different UI images at many different scales, internally the screen area it draws to is `640 x 480` pixels in size. However, the actual physical display is only `320 x 240`; as the SF2000's OS does not do any image resampling when downscaling its UI output to the screen, what essentially happens is every second row and column of pixels is thrown away - and as a result, a theme designed for the internal `640 x 480` resolution can look a bit aliased or "jagged" on the internal display. If you want your theme to look pixel-perfect on the internal display, design it for `320 x 240` instead (i.e., for any image asset you create, design and create it at half of the original resolution of the same file in the stock SF2000 theme), and perform a nearest-neighbour upscale of the image back to the original resolution when converting it to an SF2000 data format. The resulting images will be pixel perfect on the internal display. _HOWEVER... there is one major downside to do thing this_: AV output. When using the AV output of the SF2000, it does so at 576i - higher than the resolution of the internal display. If you're using a theme that was scaled up from a `320 x 240` design base, you can clearly see pixelisation of the UI assets on the external display; a `640 x 480` based theme displays smooth assets. So what if you want to design a theme that looks decently sharp (not aliased) on the internal display, _and_ looks decently smooth on an external display, then design your theme for three-quarters resolution (`480 x 360` design base), and do a bilinear upscale to `640 x 480` based resolutions during final data conversion. To summarise:
- If you only care about how your theme looks on the internal display, and don't care about how it looks on AV output, design for a `320 x 240` base resolution and do a **nearest-neighbour** 2x upscale when converting to SF2000 formats
- If you only care about how your theme looks via AV out, and don't care about it looking alised/jagged on the internal display, design for the regular `640 x 480` base