This was done mainly to reduce the amount of occurences of the word FTexture but it immediately helped detect two small and mostly harmless bugs that were found due to the stricter type checks.
Note that this is just the bare abstract interface. It is up to content makers to define usable HUD message classes and optionally contribute them to the engine.
This is to ensure that the Class pointer can be set right on creation. ZDoom had always depended on handling this lazily which poses some problems for the VM.
So now there is a variadic Create<classtype> function taking care of that, but to ensure that it gets used, direct access to the new operator has been blocked.
This also neccessitated making DArgs a regular object because they get created before the type system is up. Since the few uses of DArgs are easily controllable this wasn't a big issue.
- did a bit of optimization on the bots' decision making whether to pick up a health item or not.
- all 5 settings affected by uiscale have been changed to have the exact same semantics: -1, if supported means special scaling, this is available for HUD and status bar, 0 means to use uiscale, any larger value is a direct scaling factor.
- scaling is cut off when the factor is larger than screenwidth/320 or screenheight/200 because anything larger will definitely not fit.
- a lot of code has been cleaned up and consolidated. Especially the message code had an incredible amount of redundancy.
- all scaling options have been moved into a submenu. This menu is not complete, though - it still requires a special menu widget to convey the intended information without confusing the user.
- activated the RenderOverlay event, now that it can be called from the correct spot, i.e. right after the top level HUD messages are drawn. The system's status output will still be drawn on top of them.
This allows using the UI scale or its own value, like all other scaling values.
In addition there is a choice between preserving equal pixel size or aspect ratio because the squashed non-corrected versions tend to look odd, but since proper scaling requires ununiform pixel sizes it is an option.
- changed how status bar sizes are being handled.
This has to recalculate all scaling and positioning factors, which can cause problems if the drawer leaves with some temporary values that do not reflect the status bar as a whole.
Changed it so that the status bar stores the base values and restores them after drawing is complete.
This would cut off overlong names and the handling for status bars with protruding elements was far too simplistic and worse, making assumptions based on game mode.
It now uses a virtual function to query the status bar itself for returning this information so it can be overridden and uses V_BreakLines to split the text if it is wider than the display.
This is necessary because the hardware accelerated renderers will hide the problem, but with pure software rendering to a locked hardware surface, like DirectDraw can result in a crash.
Note that ANY mod that gets caught in this did something wrong!
Currently this is only being used for draw operations that are not automap related, i.e. DrawLine, DrawPixel and FillSimplePoly are not subjected to it.
- finished work on the Doom status bar. I also took the opportunity to fix the layout of the inventory bar which is a bit broken in SBARINFO.
- tuned the selection rules for deciding what creates the status bar, so that the most recent definition that can be found is chosen.
- got rid of the image list in the Doom status bar. The cost of the texture lookup is mostly irrelevant here so clearer and shorter code is preferrable.
- moved the box fitting code from DrawTexture into the native function to have all coordinate calculations in one place which is necessary to implement proper alignment default handling. Without higher level functions altering positioning the default can be set to automatic alignment determination, i.e. the value's sign decides where something is placed. Of course for special cases this can be overridden.
- use ANIMDEFS to animate the inventory arrow,
Fullscreen HUD done with the exception of key and inventory bar. I also used the opportunity to make it a bit more resistant against badly designed inventory icons.
- better handling of ForceScale for the fullscreen HUD that doesn't mess around with CVARs.
- moved the mug shot into the status bar, because this is global state that needs to be shared between different pieces of code which want to display a mug shot.
- SBARINFO should work off the current status bar settings instead of the ones stored in its script object
Note that there is no direct access, all this exposes is a single function to get the current face's texture which then can be drawn using the existing functions.
Note that the pop screens are special because they are not subject to scaling - they will always be drawn with the current resolutions clean scale. As a result they cannot use the HUD drawers but instead continue to use the low level draw functions directly.
- replaced Inventory.DrawPowerup with a GetPowerupIcon method so that the calling code can handle the drawing and apply its own rules. This was a major design flaw of allowing the inventory items to handle the drawing themselves, because they were unable to adjust to different HUD frontends. Note that any mod that overrides DrawPowerup will not draw any icon that expects to be handled that way!
- the alternative HUD now has its own, separate drawer that obeys the AltHUD's rules, and not the ones of the normal fullscreen HUD.
- the standard drawer has been scriptified as a virtual function.
- Both drawers now handle positioning of the icon inside its assigned box themselves instead of trusting the powerup item to do it correctly.
- DTA_HUDRules and Screen.DrawHUDTexture are to be considered deprecated because both do not integrate into the redesigned HUD code.
- merged BaseStatusBar and CustomStatusBar back together.
Since the low level draw functions are better done in native code for both performance and debuggability the split has become pointless.
- decided to ditch the widget system I had started to lay out. As it turns out that would make things far more complicated and slower than they need to be.
Note that the Strife status bar does not draw the health bars yet. I tried to replace the hacky custom texture with a single fill operation but had to find out that all the coordinate mangling for the status bar is being done deep in the video code. This needs to be fixed before this can be made to work.
Currently this is not usable in mods because they cannot initialize custom status bars yet.
