[SUG] Hi-res only panel and helpers

Started by WillLem, June 18, 2024, 02:12:18 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

WillLem

For 2.8, I'll be taking on the challenge of making the skill panel hi-res only; there will no longer be a low-res version of the panel, and hi-res settings will only apply to the game itself.

That's all for now. I'll update progress here.

WillLem

This is mostly done code-side 8-)

The low-res graphics have been removed, and all window/panel sizing calculations are now based on the hi-res graphics. The icons are loaded from the levelinfo_icons image so no need to draw them from the animations (theme brick colours are still shown). So, it's finally possible to have a lush hi-res panel even when playing in low-res!

Still to do:

*Sort out the position of the level and panel relative to each other when zooming in low res
*Fix the minimap as it's currently appearing too small in both resolutions
*Now might be a good time to look again at dynamic resizing of the panel based on window width!

WillLem

Hi-res-only panel fully implemented in Commit 685eb6adb - everything is the correct size and operates as expected. So, as of 2.8, the panel will always be hi-res, even when the game is low-res!

Still need to look at resizing the panel with the window, but for now at least everything looks good in both resolutions.




Next step is to do the same with the helper images. This will be more difficult, because these are rendered to the play screen and so can't be handled separately like the panel can.

I can think of 3 possible methods:

1) Always zoom low-res to 2x before rendering the helper overlays. Then, they will be the correct size in the final render. The smallest possible zoom factor for low-res would then be 2x, but that probably won't be too much of an issue, especially now that the smallest the panel can be is 1x zoom in hi-res, which is equivalent to 2x zoom in low-res anyway. Pros: minimum impact, relatively straightforward. Cons: we lose 1x zoom in low-res.

2) Implement GR32's layering capability for rendering the helpers to their own layer; this should in theory allow independent zooming of each layer. Then, render the helpers at 1 zoom factor lower than the current low-res zoom factor (it can obviously be the same for hi-res). Pros: retains all current functionality, could potentially improve rendering speed. Cons: Probably the least straightforward method.

3) Double-up on all in-game calculations, effectively making everything hi-res under the hood, then zoom the low-res sprites & styles images to match; physics would appear identical (although they could then be actually made hi-res in future, if we wish). Pros: good future-proofing for if we ever want to simply make the entire game hi-res, relatively straightforward. Cons: may negatively impact rendering speed (which is already slow enough as it is), lots of manual editing work.