-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Draft] Added nametags, implements #30 #103
base: master
Are you sure you want to change the base?
Conversation
This is cool!
Huh, is this a VGUI1 thing? Would be a shame if we can't vary font size.
I'd keep just I'd like to get some feedback from people who requested / would use the name tags too. |
Thanks, will check it out and see if I can make it work. I had an idea of using a TEMP entity with write_message stuff instead of
I'd assume it's a VGUI1 thing, but I've tried both vgui::Label and the one (tmp64 added?) ScorePanel uses aka CLabelHeader - which should be VGUI2(?), but it unfortunately does the same thing when you update the position like this.
Personally, I prefer the DrawConsoleString appearance (with just the team color of the player/chat color if default/no team, as I am conservative and don't use a colored nickname myself, but at the same time I am liberal in the sense that I think having more options is always better than not having one at all) because of the size mostly (which if we could get VGUI labels to actually update position @ correct FPS would become redundant).
Yep, agreed. :) |
This is sick.
Yeah for sure, I think disabling nametags for enemies altogether (including on-hover) makes the most sense, otherwise it could be too advantageous to spot a nametag when otherwise the enemy visibility is low. We already have a HUD element that displays the playername on hover in the center of the screen. So just have nametags for teammates.
Perhaps make this adjustable, even though there's hud_nametags_team_always which can be used for really long distances. Also make sure to test this in other gamemodes without team deathmatch, such as FFA, Arcade, Arena (and some others). Everyone is an enemy, so no nametags should be displayed here, even if they share the same "model". |
👍 True & agreed, didn't think of the on hover making an "accidental" "reveal" of an enemy. So yeah, let's not show nametags for enemies at all. This however means that it would be non-trivial (for me anyway since AFAIK I can't hook to PlayerId if hud_playerid.cpp already does?) to make health & armor appear for the teammates on hover, so I guess we could just not show health / armor at all in the NameTag even when you hover on a teammate, seeing as it's already showed in the hud_playerid HUD.
Will consider it, at the time always showing seemed more "trivial" for the end-user to change as the code checks if you can actually see the person and AG maps usually don't have many huge "rooms" (can only think of the square in stalkx, really, but I'm not really an avid AG DM player rn).
Yep I already tested this (since the hud_nametags_team_always feature already required this) so this should already be working correctly since the code checks if teamplay is on as well as the teamname being same. Obviously will test again once I remove the nametags for enemies. |
Regarding the sprites:
Dunno if there was ever a leak of HL1 engine src code, but a quick google finds stuff like ValveSoftware/halflife/issues/206 so I'd assume the limitation of temp entities is hit, not the limitation of loaded sprites/models (we're only loading & precaching one .spr). That's a shame, can't combine the sprites on-the-fly into "one big sprite" for each player name in the client library, so I guess we're out of lock with "in-world sprites" in the client... Will check and see if I can do anything using the sprites/TGAs in HUD and also try the VGUI2 again as I've already said before. (Cuz font size would be a very useful feature...) Also: |
cff4f53
to
fd09872
Compare
This looks really cool! VGUI and VGUI2 are pretty much a dead end: you can only scale them by creating a new font handle and you can't remove existing font handles. No transformations are possible either. A better option would be to use TriangleAPI. It allows you to use a sprite as a texture (on a side note, you should probably put all ASCII chars into one sprite frame to reduce the number of texture switches: it's a fairly expensive operation for the GPU). The only downside is that may be inefficient and may reduce the FPS (not much if all chars are in one texture, something like from 500 to 400-450 if there is a lot of text) because it would require many draw calls. The best option, in my opinion, is to buffer all rendered vertices and then draw them in one go. This is used in the engine for text rendering (link). If you want to improve the quality of the text without increasing the resolution, you should look into signed distance field font rendering. I think you shoud start by implementing it using TriAPI and then work from that. Vertex buffering is easy to implement and shouldn't cause any problems. You can find TriAPI docs in Half-Life SDK on Steam (in the "tools" section). |
9ead009
to
3661495
Compare
TODO:
Might TODO eventually(TM) (or in a later PR):
|
42124d1
to
ef93915
Compare
ef93915
to
07abf98
Compare
07abf98
to
ad8442e
Compare
@chinese-soup - hi, this change makes reference to |
bumping this! could you please share the sprites? |
@execut4ble on #30:
So I've implemented this based on a request from egg and only yesterday I've noticed exec posted that issue back in 2017. 😃
I've first tried implementing this using drawn sprites above player heads. This went fine, just making an ASCII table sprite and having each frame correspond to an ASCII letter was a breeze, unfortunately it probably creates too many sprites as it crashes the game whenever there's more than > 5 players. If anyone can tell a dummy how to debug this kind of crashes (the game just exits, no error about edicts or anything), I'd be much appreciated. :) An example of that implemention can be seen here:
Since that didn't work I then moved on to creating the hovering tags using DrawConsoleString and DrawHudString.
Obviously this has its downsides, for starters: you cannot change the font size as its "set in stone" for DrawHudString and depends on what the user has in their resource file for DrawConsoleString. (Uses the same font as the chat etc.)
Therefore I tried to use a VGUI1 label, since you could potentially change the font size depending on how far the player is, but no luck there either, the coordinate updates are way too slow as can be seen in this video:
https://user-images.githubusercontent.com/5108747/114897287-5ef9e480-9e11-11eb-972f-dd3f163aa9ce.mp4
Consider this a draft for now, but here's a list of stuff that is implemented or should be decided:
exec wrote:
Currently the "rules of visiblity" of the implementation are:
I'll implement the mousing over and also health is not yet implemented either as that would require hooking the PlayerId message and therefore merging this code with hud_playerid.cpp.
I was thinking having a switch if you want to have the tags visible only on hover or "always" (as per the "rules of visibility" above).
Something like hud_nametags_hover_only 1 (or whatever):
Current cvars:
Ones I've thought would be good:
Up for discussion cc @execut4ble:
Still TODO:
The current state can be see in action here:
DrawHudString:
DrawConsoleString:
https://youtu.be/rPt24qYXo8s