ZDoom

DrawImage [translatable] <image>, <x>, <y> [, {lefttop|center|centerbottom}, [ width, height, [ flags]]];
DrawImage [translatable] <image>, <x>, <y> [, {lefttop|center|centerbottom}, [ width, height, [ flags|alternateonfail]]]
{
	//Block executed if nothing is drawn
}
[Else
{
	//Block executed if drawing succeeded
}]

{skipicon|skipalticon|skipspawn|skipready|alticonfirst|forcescale|alternateonfail}

• *icon searching*
  
  weaponicon, armoricon and ammoicons goes through so-called icon-searching process.
  Best and most logical one is
  
  AltIcon (defined in ALTHUDCF) -> Actor Icon property -> sprite from Spawn state [for weapons: -> sprite from Ready state]
  
  That's how AltHud works, however, to maintain compatibility with current SBarInfo code, the default order is:
  
  Icon -> AltIcon -> Spawn [->Ready]
  
  Note that the searching process has been expanded for armor/ammo. No compatibility problems are expected there, but if they'd arise, it's easy fix.
  
  You can affect this process with these flags:
• alticonfirst - AltHud (better) order of checking
• skip* - skips one phase of checks
  
  *rest*
• forcescale - sprite is upscaled to fit the box if too small
• altternateonfail - similiar to syntax of DrawSelectedInventory

Blue Shadow wrote:

Tesseract wrote:probably only thing I can do about it is renaming it to more fitting "DrawImage enhancements", which could attract more people. I'm not sure how to do that myself, though.

Simply, use the Edit button on the opening post and change the title.

Tesseract wrote:probably only thing I can do about it is renaming it to more fitting "DrawImage enhancements", which could attract more people. I'm not sure how to do that myself, though.

Tesseract wrote:Well, unlike original submission, in proposed solution flags would affect any use of DrawImage that goes through icon searching process - armoricon,weaponicon,ammoicons at least. Still not entirely universal, but worth mentioning this wouldn't indeed be one-use feature. You probably knew that, but I think it's better to state it for the sake of completeness.

Tesseract wrote:Actually, I tried to address this very issue by asking for public opinion. Something like poll with "Would you use these flags in your hud? Yes/No" question should give definitive answer if this is obscure choice or wanted standard. As you haven't mentioned this in your posts, I assumed you turned down this idea entirely, therefore addition wouldn't depend on suggestion popularity and would be declined only because it would be better in ZS. But if your ZS speculation is right, everything would be better in ZS and SBARINFO would be effectively deprecated. That led me to previous conclusion that Sbarinfo additions are not much welcomed.

Blzut3 wrote:As I stated my primary objection comes from the fact that these flags apply only to the case of DrawImage where weaponicon is used.

Blzut3 wrote:There's nothing technically wrong with that, but from that standpoint of "ZDoom doesn't actually support modifier mods," unless you can show that the flags would be widely used, I would rather not have the bloat there.

Blzut3 wrote:I would rather not have the bloat there. Especially since I know trying to cater for modifiers will just lead down a road of requesting many similar small things that ZScript should, in theory, be able to solve in one go.

Blzut3 wrote:I would have no objection to the maxwidth/maxheight or sub-block on failure suggestions mentioned for example.

Spoiler: ZScript speculation

---

On the topic of DS/ZScript. I have asked Randy about it at one point, ZScript is not an ACS replacement. ACS has built in timing mechanisms which make it really good at level scripting. ZScript is supposed to solve the abuse of ACS has a behavior scripting language. From what I gather it will basically give you access into the DObject hierarchy and some fundamental APIs within ZDoom. So it will be possible to program things like new thinkers. The status bar is also a DObject.

If this is indeed correct, SBarInfo will be more or less deprecated once ZScript is a thing. It will of course remain around since the SBarInfo code is just a scripted version of the old built in status bars. Randy has been mostly working on the scripting branch these days so hopefully we'll know before 2025.

• I don't know DS specifications, not even sure anyone besides Randy do - so if you know more, please correct me on this one. I think that DS will be primarily C-like thing that substitutes/extends/unites Decorate and ACS. Full addition into special lumps wouldn't have much use, would be SBARINFO exception? It was designed to be simple, lightweight scripting lump that can't affect game state in any way, ensured by finite amount of own functions and lack of variables. These properties allows for example easy hud switching when loading games, and such advantages can't be seen in potential full, non SBARINFO based DoomScript huds, which are just evolution of ACS huds. So it's possible that it won't be changed much for sake of simplicity.
  
  Even if SBARINFO would get DS additions that only offer passive information retrieval, question is how difficult would be to replicate these flags there. Code would be certainly longer and with multiple conditionals. That's not a problem if such flags would be used in one or two huds, but if they would be in like 75% of them, flags are more optimal.
  
  Lastly, WFDS over the years started to look like "When it's done" from 3d Realms, leaving similiar aftertaste. As common Zdoom player, I see it as distant as it was decade ago. To say it pragmatically, I'd like to get my hud working in official releases before 2025. Indeed, it won't be added for one modder, so I think real question is how many hud creators would use these flags.

Spoiler: Slightly offtopic babble

---

Blzut3 wrote: I'm still not entirely sold on the idea of the flags since ZDoom lacks a whole lot of "cross modding" features. I'm sure with little effort you could come up with a dozen examples of little paper cuts that prevent mods from working seamlessly with others (not limited to status bars).

It's true that ZDoom lacks a lot of cross-mod features compared to say Unreal Engine, but on a same time it's not bad enough. I'm still suprised I've got Brutal Doom working with KDIZD with no major issues, and got very enjoyable afternoon with it. Sure, little "paper cuts" may appear, but if mods are well written and if no serious actor name or script number collision occurs, many mods are perfectly playable together. And HUDs, due to their passive nature and being part of interface, are especially susceptible for (mis)use in another mod.

Blzut3 wrote: Actually it wouldn't be entirely unprecedented. DrawSelectedInventory has flag to execute a sub block if nothing is drawn. If you choose to implement something like this be careful though, drawswitchableimage hangs off of the drawimage code.

Thanks! I must have read about this one, but I completely forgot about it. Very useful indeed!

Tesseract wrote:Blzut, thanks for your feedback, I'm only puzzled by your remarks about skipspawn being useful just for vanilla. In fact, I think the opposite, as all these flags are designed to increase cross-mod compatibility. Maybe it was just little misunderstanding and it's cleared now, if not, please explain it in more detail.

Tesseract wrote:NOTE: I didn't even dare to suggest it,but even better than automatic "draw nothing on failure" would be if DrawImage could work as flow control element,in this fashion: