[DISC] Improvements to Skill Panel

[jkapp76]

I like the different colors for the buttons. But now the grey looks out of place. Maybe swap the grey for green or something?

[WillLem]

Maybe swap the grey for green or something?

I went for a dark, leafy green (007F0E) so that the Lemmings' hair would stand out. Could probably go even darker tbh, the above is a quick fix to see what it could look like.

Thoughts? I'd be happy sticking with the grey, personally, but if people prefer green we can go this way with it, for sure.



I could also do with some help with the rewind button if anyone has any programming experience and doesn't mind giving me half an hour or so to help debug.

[jkapp76]

I definitely prefer the green.

I color my own too, I think I posted them here somewhere, I prefer purple on mine. I think it pops like no other and the green hair looks great over it. I just wasn't sure if it was too bold to actually suggest.

P.S. Also notice my improved nuke icon.

[WillLem]

Tried this shade* of purple today. Looks good, I probably prefer it to the green:





*Hue adjustment: 50, 110, -8 from Ocean Blue

[jkapp76]

I use Hue to get my colors too.

I prefer the purple. I like adding colors instead of reusing colors already present.

I miss the (framestepping) button on NeoLemmix. The black DOS background color could easily be a graphics setting.

[WillLem]

Update on the progress of the new skill panel.

I haven't figured out how to make the panel dynamically resizable yet, still looking into this.

In the meantime, I have managed to implement a "Show Minimap" option in the Config menu. Unchecking this removes the squiggle/minimap from the panel and centers the remaining buttons/text. It also unchecks HQ Minimap, so there is no rendering lag*. This idea was inspired by reading through some old posts from when namida was culling features in NeoLemmix; I happened upon this reply from minim which sparked the idea to make the minimap optional.

This should be a good enough workaround for those who need a smaller window in the meantime (it could even be considered that shrinking the screen beyond its ability to display the minimap automatically triggers this behaviour, but I'd honestly rather spend my time looking at dynamic resizing than attempting to do this).

So, here's how to two options currently look:






*I went through all the minimap code I could find to try and disable any rendering at all when Show Minimap is unchecked. I kept finding that whenever HQ Minimap is checked, there is lag. Then I discovered some areas that HQ Minimap seems to play with independently of the actual drawing/rendering code, so this is likely what needs to be updated. If people like this feature, then I'll go ahead with a proper implementation. For now, hacking it via the checkboxes does the trick for testing purposes.

EDIT: Implemented proper checks for HQ Minimap in Commit 2d656f9

[WillLem]

Dynamic resizing of the skill panel is currently in progress! This feature will hopefully eradicate the need for awkward panel zooming and allow users to size their window as they wish.

So far, I've been able to get the panel itself (plus all buttons and text) to resize quite nicely and remain fully operational, but the one thing holding this feature back is the minimap. Ironic, really, because getting rid of the minimap altogether would solve this and a few other problems!

But anyway, the minimap is to be kept, so I'm going to need to figure this one out. Here's what I have so far:



The minimap temporarily changes red for testing purposes: this shows where the actual minimap bitmap itself is. I tested a few levels, and it always gets resized to the width of the minimap base image. So, chances are it's a simple fix once the relevant part of the code is located. However, minimap code stretches far and wide throughout the codebase and so far I haven't been able to find the relevant lines...

[WillLem]

The blue area is the total minimap image, the red area is the actual minimap bitmap. This is for testing purposes only to show whereabouts they actually are.

So far so good! Next step is to remove any reliance on panel zoom and replace it instead with the resize percentage value; much of this is already done, but there are still one or two things that rely on knowing exactly how big the panel is.

For instance, the noticeable 'jump' of the panel position relative to the level (seen halfway through resizing in the screenshot above) happens when the panel gets to 150% of its size and is due to rounding logic; the relative zoom factor moves from 1 to 2 at this point so its position suddenly gets recalculated. The bottom edge of the window resizing *past* the bottom of the panel before the panel gets nudged upwards is also due to this same reliance on an integer value.

Investigating solutions...

[WillLem]

Panel resize is now much smoother. Also, when in "resize" mode (as opposed to "zoom" mode, which is still an option), the panel is magnetized to the bottom of the screen (rather than the bottom of the level), but does not push past the bottom of the level when resizing:



This is to make sure that the full height of the level is always displayed after resizing, without having to micro-adjust the window. This only applies for levels that are 160px or less in height, and/or for zoom factors that allow the full height of the level to be displayed.

To get a smaller screen, then, it's necessary to zoom out:



This balances control over the window size with ease of adjustment after resizing.

So, that's dynamic panel resizing sorted! My only qualm with it is that the preview and postview screens will necessarily have blank space either side of the bitmap if the window is anything other than the default size:





This may require either complete refactoring of the menu bitmap sizing so that it always adjusts to window height/width (difficult, but not totally out of the question) or automatic resizing of the window whenever the menu screens are being displayed (easier, but far more potential for problems user-side; for example if using SLX to record an LP). I'll probably go for the refactoring.