messages in sbarinfo

[kgsws-CZ]

Requested here: http://skulltag.net/tracker/view.php?id=358
Simple to make.

Code: Select all

DrawMessages <x>, <y> [, <scale> [, center]]

Scale defaults to 0. Using this will ignore con_centernotify and con_scaletext.
It might be even more enhanced to support different font, show time, number of lines ... etc.

[Jimmy]

Heck yes!

[NeuralStunner]

Sharp! This would be great for HUD readouts.

[Nash]

OMG about time!!! :D

[Jimmy]

Other thoughts:

- A flag for allowing the user to customize whether messages appear on the left or center (as they do now).
- Number of pixels before the lines wrap (as opposed to them only wrapping when reaching the edge of the screen).
- Number of pixels between lines.
- Number of pixels between messages (in case the lines wrap).
- Option for messages to use the same scale/resolution as the status bar, as well as allowing them to be 2x or 4x scaled.
- Fade time.

[wildweasel]

I'd appreciate support for different fonts, so that I can use a BMF font to display messages. Also, this might be kind of hard, but perhaps a flag to make it type-on in a similar manner to HUDMSG_TYPEON?

[Blzut3]

While I still don't like the idea since it promotes tangling of the SBarInfo code with other parts of the engine (the lack of which is one of the main reasons we even have SBARINFO in the first place). Here are some things I noticed with the patch:

• This code makes no attempt to work with hud_scale, st_scale, or even resolutions. Start the example in 320x200 and notice the complete lack of a console read out.
• Get rid of the magic numbers: hudMessagesFlags should have an enum somewhere I think.
• Change the name of the command to something along the lines of SetConsoleLocation. The command doesn't draw anything and as such acts completely differently from any of the other drawing functions (you can only effectively use it once per tic and it is always on top).

Otherwise I'm leaving it up to Graf or Randy to decide if this feature gets accepted.

[kgsws-CZ]

This code makes no attempt to work with hud_scale, st_scale, or even resolutions. Start the example in 320x200 and notice the complete lack of a console read out.

Isn't this because of 'FullScreenOffsets'?

[Blzut3]

If fullscreenoffsets is used then hud_scale must be taken into account. All of the scaling and coordinate adjustments are done in DSBarInfo::DrawGraphic() or DSBarInfo::DrawString() so all you're doing is feeding the absolute coordinates to the console system.