ZScript: Status Bar Questions

[Graf Zahl]

So, the status bar is done. I just went through the remaining C code and decided not to export anything more, because nothing would be gained from it.
The RenderOverlay event is now activated, it will fire right after the HUD messages have been drawn, but before the (very rarely seen) system messages.

[DoomRater]

From what I am understanding here is that when I want to design a UI I can give percentages of where something should be on the screen and what size it should be taking up, and that will be automatically scaled for me. I definitely do not want to be giving exact pixel values for HUD elements or exact pixel sizes of elements because that assumes a screen size.

[Graf Zahl]

No, not percentages. What you do is specify a virtual resolution and then position it in that space in virtual pixels. The scaling will be done automatically, depending on engine settings.
Placement in percent is not usable, when you have some graphics you can best measure them in pixels, so that needs to be the base unit here.


BTW, the scaling stuff has just been cleaned up, it still requires a bit of work on the menu but that's quickly done tomorrow.

[Nash]

Thank you for all the work so far Graf. However, is customazible rectangle clipping still missing? I see some commented // SetClip and // Unsetclip still around the scripts.

The reason I ask is, I use DrawImage to draw some moving stuff on the status bar (as in, the position actually changes) and I'd like to explicitly define where my clip rectangles are.

I'd rather stick to using DrawImage because it's simple and does everything else perfectly.

[ZZYZX]

...zzzzz use my library already I need testers.
There's also scaling, clipping and simple Draw function that takes 5 parameters: texture, x, y, alpha and animate yes/no.

[Graf Zahl]

Thank you for all the work so far Graf. However, is customazible rectangle clipping still missing? I see some commented // SetClip and // Unsetclip still around the scripts.

Oops.

I implemented it in the Canvas class but forgot to export it to scripting and to the status bar.
Thanks for reminding me. I'll do it when the menu adjustments are complete.

[Graf Zahl]

...zzzzz use my library already I need testers. .

I recommend against high level clipping. This isn't the same as using a hardware scissor function and can introduce some jitter.

[Nash]

...zzzzz use my library already I need testers.

I promise I will, for my game's in-game character and inventory menu system. I'm too dumb to figure out every little dirty detail about screen drawing so I'll definitely need it. You will get PLENTY of annoying messages and questions from me in the days to come. >8D

@Graf Zahl: Ok, awesome. Will wait for it to be implemented. For actual status bars/HUDs, the native HUD methods are perfect for my needs and I'd rather not try to fight against the engine.

[ZZYZX]

I recommend against high level clipping. This isn't the same as using a hardware scissor function and can introduce some jitter.

I'm using DTA_Clip*. Unless you call this high level.

[Graf Zahl]

No, that goes down to the same thing. The only problem with DTA_Clip* is that it needs to be specified for each draw command, but what was needed here is some means to set a clipping rectangle for more than one draw operation because it's far too clumsy to let this info filter down 3 or 4 function levels, which can happen in the status bar code

In the end, both pieces of info will be merged into a combined clipping rectangle.

[ZZYZX]

I was referring to this viewtopic.php?p=986562#p986562
It exactly works with DTA_, but also eliminates the need to specify DTA_ manually for each call (and also virtualwidth/virtualheight), by calculating it based on element settings and providing it automatically.
It also allows having different relative scale for each of the nested elements.
For example, something of scale 2.0 inside the parent root something of scale 1.5, will receive the resulting scale of 3, VirtualWidth/VirtualHeight of screen/3, and XY coordinates automatically adjusted to that.

But, the user doesn't really need to know all this — he can simply use methods in Drawer — for these, only the 3.0 scale exists, top-left of the element is 0,0, and bottom-right is GetClientRect().Width and GetClientRect().Height (which is essentially mRect.Width/mRect.Height divided by the resulting scale based on all parent elements).
It even scales things that otherwise aren't scaled — Dim, Clear or DTA_Clip*.
Oh and it also provides word wrapping and text align.

The only real downside here is that if you use this, generic sbar functions will be unavailable.
But it should be more or less straightforward to take the required info from BaseStatusBar and setup the position/scale based on user sbar settings.

Technically: https://github.com/jewalky/zgui/blob/ma ... drawer.txt

[Graf Zahl]

I think we better not go there. Especially for status bars the high level functions do a lot of stuff that is essential for creating a working HUD.

[Major Cooke]

What's the difference between BeginHUD and BeginStatusBar?

[Graf Zahl]

These functions set the coordinate system, one for drawing a status bar (stuff gets aligned like on a normal status bar) and one for a HUD (like fullscreenoffsets in SBARINFO with stuff getting aligned to the screen edges.)

[ZZYZX]

I think we better not go there. Especially for status bars the high level functions do a lot of stuff that is essential for creating a working HUD.

For example?..
I think knowing this would be important in order to not accidentally create a broken statusbar, since I most definitely will eventually find myself doing certain things manually. The builtin HUD scaling is so broken...