ZDoom

[quote="Xaser"]The pop-up screens appear 'over' the status bar and are too 'tall' to boot on some resolutions. A variant of "fullscreenoffsets" that accounts for the status bar's height (i.e. '-1' is equivalent to '-(height+1)' w/fullscreenoffsets) would be perfect for this, since that would fix the scaling issue too. A flag for CreatePopup that works alongside fullscreenoffsets would work too.[/quote]
There are quite a few differences to how the popups are scaled vs the statusbar that need to be taken into account. They're widescreen compatible and operate independently from hud_scale/st_scale. Probably will add a "popupoffsets" for this.
[quote="Xaser"]Strife's key pop-up isn't emulatable at all. It's a very special case what with the pagination and all.[/quote]
This is probably the hardest part. Will probably have to do something like a popup sequence and allow multiple layers. Not really sure.
[quote="Xaser"]Should I post up my tweaked version? It's still a work in progress given the above issues, but the stuff that's there is pixel-perfect now, as far as I can tell.[/quote]
You can. Be sure to comment out the stuff that can't be properly emulated since at least I can probably use the numbers out of your code. (And add a comment near the monospaced font line noting the log thing.)
[quote="Xaser"]Also, I'll start some threads for the new feature requests if you'd like. Better for organization, that.[/quote]
If it makes you feel better then I guess. :p Like I said, having Strife's bar be defined in SBarInfo is a goal so it's extremely unlikely I'd forget about it.

Welp. Maybe I should act before (double) posting -- I've managed to weed out all the minor inaccuracies. I'll list the remaining points for clarity, since the above post is all sorts of ugly.

[list][*]The health bar can't be properly emulated. With some new images it's possible to do the standard and overlay bars just fine, but there's no way to change the colors based on health/god mode since you can't check for invulnerability and 'health' isn't an acceptable value for InInventory.
[*]Monospacefonts is necessary to make the numbers appear correctly, but using it messes up the log pop-up. Unless there's an undocumented FONTDEFS feature to construct a monospace font. If not, that would fix it too, of course. Maybe even better. ;)
[*]The pop-up screens appear 'over' the status bar and are too 'tall' to boot on some resolutions. A variant of "fullscreenoffsets" that accounts for the status bar's height (i.e. '-1' is equivalent to '-(height+1)' w/fullscreenoffsets) would be perfect for this, since that would fix the scaling issue too. A flag for CreatePopup that works alongside fullscreenoffsets would work too.
[*]Strife's key pop-up isn't emulatable at all. It's a very special case what with the pagination and all.
[*]For some reason, the 'translucent' flag does not seem to be working for the fullscreen version of DrawInventoryBar. Not sure why this is.[/list]

Should I post up my tweaked version? It's still a work in progress given the above issues, but the stuff that's there is pixel-perfect now, as far as I can tell.

Also, I'll start some threads for the new feature requests if you'd like. Better for organization, that.

INDEXFONT_STRIFE
{
   0 INVFONY0
   1 INVFONY1
   2 INVFONY2
   3 INVFONY3
   4 INVFONY4
   5 INVFONY5
   6 INVFONY6
   7 INVFONY7
   8 INVFONY8
   9 INVFONY9
}

HUDFONT_STRIFE
{
   0 INVFONG0
   1 INVFONG1
   2 INVFONG2
   3 INVFONG3
   4 INVFONG4
   5 INVFONG5
   6 INVFONG6
   7 INVFONG7
   8 INVFONG8
   9 INVFONG9
}

Thanks for the code, sir. Helps a bunch! :)

[EDIT] The rest of this post is more or less out of date, because I am a silly human who neglected to fix things himself. :P

There seem to be a couple of inaccuracies, as shown in this before-and-after animation:
[img]http://i.imgur.com/8ths1.gif[/img]

Ignore the fact that the Assault Gun offsets are different. I moved 'em a bit in my mod.

The font inaccuracies probably stem from the fact that I had to define INDEXFONT_STRIFE and HUDFONT_STRIFE myself, which might not be correct. For the record, the code I'm using for that is below:
[code]INDEXFONT_STRIFE
{
0 INVFONY0
1 INVFONY1
2 INVFONY2
3 INVFONY3
4 INVFONY4
5 INVFONY5
6 INVFONY6
7 INVFONY7
8 INVFONY8
9 INVFONY9
}

HUDFONT_STRIFE
{
0 INVFONG0
1 INVFONG1
2 INVFONG2
3 INVFONG3
4 INVFONG4
5 INVFONG5
6 INVFONG6
7 INVFONG7
8 INVFONG8
9 INVFONG9
}[/code]

[EDIT] So I did some tinkering and found that both the health and ammo numbers were offset 2 pixels to the right and the font needed to be monospaced. 'monospacefonts true, "0", center;' would work nicely except that since this is applied globally, it makes the log pop-up look bad. A per-statusbar version of monospacefonts seems like it'd be necessary here, unless there's some way to do it in FONTDEFS.

[DOUBLE-EDIT] Another something: Strife's internal pop-ups come from behind the statusbar, while SBARINFO's SlideInBottom makes it appear above it, originating from the bottom of the screen rather than the top of the status bar. I feel as if I should start a new thread for this. :P

The more pressing issue is that INVCURS appears to be offset a pixel too far to the left, which might be an engine issue.
[TRIPLE-EDIT] ..or I could just move the inventory bar over to the right one pixel. Oy vey. :P

You'll also notice I have an approximation of the health bar, but I had to add a couple of images to do it and use an odd trick to get the overlay bar to show up (double-size, half-transparent bar so only 100% to 200% is shown) since there's no 'minimum limit' for health/armor ATM. That and it doesn't show a different colored bar when at low HP -- we'd need an "IfHealthLower" block or similar for that.

Other than these issues and the key bar, it looks great. I haven't nitpicked the working popups yet but the fullscreen HUD looks fine aside from the ammo1icon placement and the aforementioned font issues.

Here's the incomplete definition from when I last touched it. Obviously there's a lot missing (all of the things you pointed out already), but if there's anything that's possible to accurately emulate at the moment that isn't there, let me know.

Ah, that would be mighty kind of you. :)

From what I can tell, Strife's special health bar behavior isn't present either. It's easy to "fake" to some degree using some new images and DrawBar, but I can't think of a way to get it to change colors when below a certain HP threshold or turn gold when god mode is on. Though I suppose you've thought of this. :P

No need. Obviously the goal is to have Strife's status bar written in SBarInfo at some point.

I have an incomplete definition on my computer at home (unless I accidentally deleted it). I'll post it here once I get home.

Then I guess the real thing to do is suggest an SBARINFO definition for Strife's status bar. I don't mind writing it myself -- I was planning on doing so with the standard status bar anyway, but there's no way to do Strife's special page-based key+tag pop-up just yet. Should I open a new suggestion for that?

I can't really mix a native status bar with an SBarInfo one. So yes, for now you can't do anything with the strife status bar. The others should work as you describe since it just includes the internal definitions.

I'm trying to mess around with Strife a bit, but I just hit a huge stumbling block in SBARINFO. I need to redefine the main status bar to add some things (alt. ammo types, for one), but in trying to use the "base" keyword I found out that "can't modify the result" actually translates to "can't replace or do anything at all" -- using "Base Strife;" results in the rest of SBARINFO being ignored.

This is troublesome, because it means that I'd have to redefine [i]every[/i] status bar when I only need to change the main one and one of the pop-ups. That and I don't think Strife's key display can be emulated in SBARINFO at all at the moment.

Having said that, I'd love to see the "base" keyword be fully implemented so that you can inherit from a game's status bars and only change what you need. I'm fine if defining a certain bar (normal, fullscreen, etc.) replaces the old one outright, thus requiring one to redefine parts. It's just that not being able to use some of the game's defaults is a hindrance.