CSQC minimalistic hud

[gnounc]

http://dl.dropbox.com/u/1776436/hud.zip



Health and armor are on the crosshair and show briefly when hit

weapon icons show previous, current and next weapon briefly while switching weapons

ammo type and ammo count show constantly

and runes/keys show only when you hold the +showscores button.

quad damage, pentagram of protection and bio suit all show up in the middle of your cursor
and scale to 0 as their timer runs out

the icons are all placeholders, ill make another release in a while with updated art.
feel free to icon replacements here

http://www.youtube.com/watch?v=EvTq0PPeG2o

the version in the video is about a week old, there has been some improvements.
ill make a new video when i have nonplaceholder assets.

[ceriux]

i like works on dp right?

[Nahuel]

looks nice, i made some csqc HUD´s for dp, and smith update the code

[gnounc]

thanks nahuel.
also thanks for the link, looking into it now.

and yes it works on dp. its got a bug in the armor ive yet to sort out, im certain its dead simple but i havent found it yet.
yellow armor doesnt show on the crosshair.

sizing for dp and fte arent consistant, i think its down to me using conwidth when spike told me not to.

i sized everything in fte, so things are a bit big in dp, thats just a matter of resizing whatever images you use
to replace the ones provided.

[ceriux]

you could just scale them with the csqc.

[Spike]

Querying an image for its size is non portable, not just between engines but also between image replacement packages (an engine might have a few different behaviours, it might retrieve the size of the original lmp instead of the replacement, it might use the scale features of a jpeg, or it might return the exact pixel size of the replacement - fte does the first and never the second, I don't know what dp's behaviour is).
also certain shaders may not even have an image and thus cannot have any predetermined size.
So the getimagesize builtin should generally not be used.
getimagesize will generally return the expected size of the image in virtual-screen-space which mirrors expected engine internals, which is why vid_conwidth resizes everything as it changes the virtual screen width but not the results of getimagesize.
vid_conwidth/height can be used, but its inefficient to query a cvar instead of just using the arguments to your render function... fte will emulate any incompatibilities with that cvar, but like I say, you shouldn't depend upon that behaviour, especially if someone runs your hud in a (possiby software rendered) engine with no vid_conwidth cvar. What I'm trying to say is that if you have the same effective value set in both engines, you should get the same result.