UI polish

[Hop311]

• Added GFXButtonStateTexture which modifies the base/normal image in the same way as Vic2 does:
  • hover - +0.1f to each colour component (clamped)
  • pressed - -0.1f to each colour component (clamped)
  • disabled - make greyscale using standard luminance coefficients
• Added support for block colour font/back segments for progress bars, used when the corresponding texture isn't defined/fails to load (all vanilla ProgressBars have both colours defined, but not all of them have the textures defined).

[Spartan322]

Tested on Linux, personally I prefer how the UI states are handled here, it feels more consistent and obvious imo compared to how Victoria 2 does it, but keeping this could be considered to be distinct from Victoria 2.

[Hop311]

Tested on Linux, personally I prefer how the UI states are handled here, it feels more consistent and obvious imo compared to how Victoria 2 does it, but keeping this could be considered to be distinct from Victoria 2.

Hover and pressed look fine, fairly similar to Vic2 anyway, but disabled look much worse IMO. I'm going to implement a custom class extending ImageTexture which generates a monochrome and 10% whiter version of the normal texture (always either GFXIconTexture or GFXMaskedFlagTexture) and is connect by a signal so it updates itself whenever the base texture changes.

[Spartan322]

Why can't you just make such a modification a disabled style? Why would you need to update it like that?

[Hop311]

Why can't you just make such a modification a disabled style? Why would you need to update it like that?

It would be using a separate disabled stylebox, when I said update on the normal texture changing I meant stuff like a flag changing to a different country, so regenerate the modified image when the normal image changes completely.

[Spartan322]

That's fine, you can modify the look of textures with a stylebox, like you can just make a new derived stylebox that modify the draw however you want, there is no need to manually manage it. (and its automatically handled by Godot anyway)

[Hop311]

That's fine, you can modify the look of textures with a stylebox, like you can just make a new derived stylebox that modify the draw however you want, there is no need to manually manage it. (and its automatically handled by Godot anyway)

Oh yeah that sounds better, same texture referenced everywhere just changed by the stylebox. My only concern is will the stylebox have to calculate the modified version pixel by pixel every frame, as opposed to only when the base texture changes and caching after that? Unless there's a way to grey-ify and lerp images with a colour other than pixel by pixel calculations.

[Spartan322]

My only concern is will the stylebox have to calculate the modified version pixel by pixel every frame,

What you could do is have a texture exist in a control, have a stylebox for that control that can get the texture and draws it modified, then what you do is whenever you change that control's texture, you call queue_redraw, and now whenever that texture changes or the stylebox is swapped out or changed, it'll draw it as you want. (you can't store any values of the control in the stylebox, you can retrieve them from control in the stylebox though)

[Hop311]

My only concern is will the stylebox have to calculate the modified version pixel by pixel every frame,

What you could do is have a texture exist in a control, have a stylebox for that control that can get the texture and draws it modified, then what you do is whenever you change that control's texture, you call queue_redraw, and now whenever that texture changes or the stylebox is swapped out or changed, it'll draw it as you want. (you can't store any values of the control in the stylebox, you can retrieve them from control in the stylebox though)

Looking through RenderingServer, I can't see any way to achieve what I need for disabled with draw methods - that is, convert RGB to greyscale by calculating each pixel's luminance. I think I'm going to have to generate a modifier Image, and it'll be faster to only generate when the normal image changes rather than on every redraw.

[Spartan322]

Might need to consider RenderingDevice as well, also draw functions in Godot don't generally run every frame, CanvasItem.queue_redraw() is necessary when you modify the values of a node that changes the node's draw behavior, Resource.emit_change() is necessary for resources whose value changes (specifically styleboxes) if you don't run either of these functions on change, the common draw functions never update the draw behavior. I was thinking maybe you could use something like Texture2DRD but I'm not actually sure how to deal with that.

[Hop311]

godot-cpp doesn't provide access to RenderingDevice, and I can't see a way to use it to draw an image as luma greyscale (so each pixel is 0.2126f * r + 0.7152f * g + 0.0722f * b), except maybe generating a byte array containing the modified image and using it to create a texture, which is basically what I'm already doing.

[Spartan322]

Just to point out godot-cpp does provide access to the RenderingDevice: RenderingServer.get_rendering_device(). To get the RenderingServer you do RenderingServer::get_singleton() so in total you do RenderingServer::get_singleton()->get_rendering_device() which returns a pointer of the RenderingDevice.

[Spartan322]

Works on Linux

[Hop311]

Just to point out godot-cpp does provide access to the RenderingDevice: RenderingServer.get_rendering_device(). To get the RenderingServer you do RenderingServer::get_singleton() so in total you do RenderingServer::get_singleton()->get_rendering_device() which returns a pointer of the RenderingDevice.

Oh so it does, thanks for pointing that out, my VSCode search was bugged, fixed now with a restart.