Ask about ACS, DECORATE, ZScript, or any other scripting questions here!
Moderator:GZDoom Developers
Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. If you still don't understand how to use a feature, then ask here.
Please bear in mind that the people helping you do not automatically know how much you know. You may be asked to upload your project file to look at. Don't be afraid to ask questions about what things mean, but also please be patient with the people trying to help you. (And helpers, please be patient with the person you're trying to help!)
Nash wrote:ZZYZX: I'm aware of the clipping DTA tag, but I wasn't sure if Screen.DrawTexture can be used inside status bars. Right now I'm just using BaseStatusbar.DrawImage, like what gzdoom.pk3 is doing.
Will give your library a try later, I kinda don't understand how to use it yet...
You can use Screen.DrawTexture, but then you have to do all the nasty stuff yourself, like scaling coordinates etc. For specialty applications that is an option, but if you want to write some simple code to draw a status bar you want simple function calls that take reasonable defaults for most parameters and do the dirty stuff internally. Screen.DrawTexture requires you to lay out everything yourself in most verbose detail. Ultimately all those other draw functions call this as well, as it is the one central 2D sprite drawing function.
Graf, will there be support for stacking multiple status bar classes, like AddEventHandlers? I can think of one use case right now: a ZScriptified version of [wiki]Hudmessageonactor[/wiki]. If only one status bar is allowed, the method has to be hardcoded into the mod's only status bar and cannot be modular.
Only if you do it manually by creating a status bar that owns two others and draws them on top of each other.
The status bar is a vital system component and there can only be one.
How do I make the DrawImage'd image automatically adjust its scale according to the uiscale CVar? I looked at the Doom status bar and can't see it doing anything differently than just a plain DrawImage call... but the scaling works automatically on that one.
Patience. I first need to do the features before doing a proper menu screen for them. It's the typical problem of having to preserve legacy features while fixing the design flaws.
All this code comes from a time when 640x480 was the most popular and 1024x768 the largest screen size and nothing ever got properly adjusted to growing monitor sizes until uiscale was introduced last year - unfortunately it was still an incomplete job, because the entire status bar stuff got skipped (presumably because it was far too messy.)
Don't forget, for me this has turned out to be more like a major cleanup job than scriptification of an existing feature.
Nash wrote:Ah! That fixed it. Mine was set to -1 for some reason. Also IMO the various UI and HUD scaling combinations are a little confusing.
I think part of the problem here is that the scale options are scattered throughout the menus. It would probably be better to have a single scaling menu. It would make it more clear that uiscale is the base scale setting, and the other ones are individual overrides.
The defaults should probably also all be changed so that uiscale is affecting everything unless the user explicitly decided it should not apply to some elements. And last I personally think the 'auto' mode for uiscale should scale more to what most people expect (i.e. a 2x scale at 1080p, 4x scale at 4K), not what Doom technically did at 320x200 (which was more like 4x scale at 1080p).
Nash wrote:Ah! That fixed it. Mine was set to -1 for some reason. Also IMO the various UI and HUD scaling combinations are a little confusing.
I think part of the problem here is that the scale options are scattered throughout the menus. It would probably be better to have a single scaling menu. It would make it more clear that uiscale is the base scale setting, and the other ones are individual overrides.
The defaults should probably also all be changed so that uiscale is affecting everything unless the user explicitly decided it should not apply to some elements. And last I personally think the 'auto' mode for uiscale should scale more to what most people expect (i.e. a 2x scale at 1080p, 4x scale at 4K), not what Doom technically did at 320x200 (which was more like 4x scale at 1080p).
That's already planned, but I first want to take care of the last remaining pieces of the status bar.
The auto mode here definitely needs work, too, and even with uiscale the code is still way too obtuse. But don't worry, now that the messed up scaling for the status bar is fixed, it will be a LOT easier to do this right.