SBARINFO

[Blzut3]

I thought everyone here would like to see this: custom Strife popups in action. Currently there are no transition effects though.
http://blzut3.maniacsvault.net/popup.png

In addition to all popups working the next update will contain:

• Aspect ratio detection
• Inventory item checks
• Ability to turn off the lower health cap
• Printing of global ACS variables (currently untested)

[Kate]

Looks like the doom press release beta =p

[Project Shadowcat]

Looks like the doom press release beta =p

Knowing us, however, the graphics would be spruced up a great deal, even for that. Perhaps an "enhanced beta", with its treasure gobbling and everything back. Would be neat if anything.

Sir, you have been making leaps and bounds with this. Keep up the great work.

[Nash]

Nice work, Blzut!

[Jimmy]

custom Strife popups

YES

Inventory item checks

YES

Printing of global ACS variables (currently untested)

YES

THANK YOU VERY MUCHLY. Looking forward to seeing if this feature can possibly get any more powerful.

[Blzut3]

And here is the update:

Code: Select all

- Fixed: Monospacing fonts wasn't quite correct.
- Fixed: The new mug shot code forgot to use the first arg of drawmugshot (the
  one that picks the default sprite prefix).
- Added: lowerHealthCap variable to SBarInfo, which is set to true by default.
- Added: ininventory event to SBarInfo to detect if one or two items are in (or
  not in) the player's inventory.
- Added: The ability to print global vars using drawnumber.  I need someone to 
  test it though.
- Added: aspectratio command to detect what the user's aspect ratio is.
- Added: missing spacing argument to drawstring.
- Changed the sbarinfo display routine for drawnumber to not use cmd.value to 
  store what it is about to display.  Now it uses a new variable.
- More conversions from DrawImage to screen->DrawTexture.  I think only the
  inventory bar drawing functions have to be changed now.

All of the following need to be [Added]'d.
http://forum.zdoom.org/viewtopic.php?f=15&t=16691
http://forum.zdoom.org/viewtopic.php?f=15&t=16690
http://forum.zdoom.org/viewtopic.php?f=15&t=16689
http://forum.zdoom.org/viewtopic.php?f=15&t=16684

[Graf Zahl]

patch added

[Enjay]

Hmmm, with r845 at 640x480 I'm getting a 1 pixel line under my status bar that wasn't there before. It's not too obvious until you bring up the menu then cancel it again but then the yellow fade of the menu screen gets left below the status bar.

[Blzut3]

Apparently screen->VirtualToRealCoordsInt() returns values with a 1px difference for the height than DrawImage's method. Something for Randy or Graf to fix?

[StasBFG[iddqd]]

Hmmm, with r845 at 640x480 I'm getting a 1 pixel line under my status bar that wasn't there before. It's not too obvious until you bring up the menu then cancel it again but then the yellow fade of the menu screen gets left below the status bar.

I always had this problem and also with standard hud. It's most likely OpenGL related, works fine in software.

[Remmirath]

Looks like the doom press release beta =p

Agree. It'd be nice to add as a feature...

[Enjay]

I always had this problem and also with standard hud. It's most likely OpenGL related, works fine in software.

I've had it in the past too. The point this time though is that something in a recent revision made this happen because it was fine until recently. Oh, and it's not just an OpenGl thing. It happens in software too.

[Gez]

Apparently screen->VirtualToRealCoordsInt() returns values with a 1px difference for the height than DrawImage's method. Something for Randy or Graf to fix?

I suspect a rounding inconsistency.

[MartinHowe]

I am having trouble with custom statusbars that draw faces - if a regular SKIN that includes a face replacement is in use, the game crashes. This is with my current experimental build, but I suspect that there is some overall discrepancy between the global consoleplayers variable and the statusbar CPlayer variable. Not saying this is purely an SBARINFO problem, but if anybody here knows what the difference between consoleplayers and CPlayer is it'd be agreat help.

[wildweasel]

I always had this problem and also with standard hud. It's most likely OpenGL related, works fine in software.

I've had it in the past too. The point this time though is that something in a recent revision made this happen because it was fine until recently. Oh, and it's not just an OpenGl thing. It happens in software too.

Is it perhaps possible to draw a row of black pixels at the 201st horizontal line on screen? Normally this line would be invisible (i.e. exactly one pixel off screen), but it may help against the "gap" that Enjay et al are experiencing.

Note: I'm no programmer, so I don't know if this is even technically feasible.