ValveSoftware
all games: Add support for animated avatars
Description
This PR implements support for displaying Steam animated avatars on scoreboard, friendslist, etc.
Players can disable animated avatars using cl_animated_avatars ConVar.
The CGIFHelper class can be used to easily map GIF frames to textures and display them in-game.
Demonstration video:
Closes https://github.com/ValveSoftware/Source-1-Games/issues/5566
GIFLIB v5.2.2 dependency is added for decoding GIFs pulled from Steam. It has been sourced from here and is released under a permissive MIT/X Consortium-like license:
https://github.com/ValveSoftware/source-sdk-2013/blob/3068fd6518f1e6a83937aad7d3fde98735d16c8e/game/thirdpartylegalnotices.txt#L914-L936
There were only few modifications made to the original library:
- Added CMake support for more streamlined building
- Fixed linking errors on MSVC related to file I/O
- Replaced OpenBSD array realloc with custom implementation
For convenience, I have included precompiled amd64 binaries of GIFLIB for Windows and Linux. You can verify their integrity using respective SHA-256 checksums:
`giflib.lib` (Windows)
aa1e88697244f88fd51769214a4d32fed8317f0a673955934807484b6b2b366b giflib.lib
`libgiflib.a` (Linux)
238eef38fb63152d8df3857ebf798e1c485d1bc2676db7b02fb6e42cab65adb6 libgiflib.a
The modified GIFLIB source is available in src/thirdparty/giflib-5.2.2. You can find build instructions in BUILD.MD file where the source is located.
Would probably be better to have pre-compiled binaries for windows/linux to make it easier to implement in mod projects
Would probably be better to have pre-compiled binaries for windows/linux to make it easier to implement in mod projects
When this PR will be ready to merge I'll include them with a way of verifying their integrity
I don't think this PR is stable yet. (although i might be wrong as i'll describe later)
I implemented it into my mod and it works perfectly initially. However, if I change a static avatar to a animated avatar (or another animated avatar if I already have one equipped), it produces a this was 0xFFFFFFFFFFFFFFEF. crash.
The call stack leads to the delete pAvatar; portion of CAvatarImage::OnHTTPRequestCompleted. This DOES work if the delete pAvatar; line is commented, but it corrupts some animated avatars as shown below, and I originally thought this was why delete pAvatar; was added to begin with.
I didn't know if this is the fault of the PR however. My mod disables the TF2 main menu in favor of the GameUI source menu, so that change could have been a factor here. Since the normal menu was just a preprocessor definition away in my mod base, I re-enabled it, recompiled it, and it didn't crash, although it had the same corruption issue in the scoreboard as before.
I worry that this PR (in its current state) could crash in HL2MP due to the above issue, as that doesn't contain any animated avatar code anywhere but the scoreboard.
I'm not sure what's causing the corruption problem too, some avatars work fine while others break. It seems to be scoreboard related but i'm not sure. The effected avatars DO work when launching the mod, but corrupt when switching to them from Steam.
I have tested this again using stock SDK2013 on two vastly different setups and although I couldn't replicate your crash when destroying pAvatar, I did notice some artifacts on GIFs when GameUI isn't overriden (on TF tested by commenting out line 330 in tf_hud_mainmenuoverride.cpp), which right now doesn't make any sense to me and I'll need to do further investigation on it.
I'm gonna clone your fork later and see why is the crash happening exactly, however my blind guess is that a change made in Valve's STL makes this specific scenario segfault.
I'll update this thread when I find anything.
The artifacting should be fixed now, caused by the previous framebuffer not being initialized correctly sometimes making disposal not work properly.
Fix just ensures that it is set with the background color.
I have also tested your mod however I never managed to get the delete pAvatar crash you described, both with legacy mainmenu disabled and enabled. Maybe I didn't have some preprocessor definitions you had turned on?
I have also tested your mod however I never managed to get the delete pAvatar crash you described, both with legacy mainmenu disabled and enabled. Maybe I didn't have some preprocessor definitions you had turned on?
After I sent the bug report i put an ifndef for BDSBASE_LEGACY_MAINMENU around the "delete pAvatar" line, which suppresses the crash so it works without crashing in each instance
Just tested the bug fix and the artifacting still seems to be a problem. I'll try rebuilding the solution to see if that fixes the issue and update this
EDIT: this seems to be fixed with the Space Core avatar, but it appears to still not be fixed with others (like the aperture desk job avatar)
The purple Cat Face avatar was one of the affected avatars from before the fix. Although now it got a black background rather than the light bluish-yellow background it had before
Replying to https://github.com/ValveSoftware/source-sdk-2013/pull/1380#issuecomment-3042199798
I did comment out the ifndef when testing, should've specified that, sorry.
Replying to https://github.com/ValveSoftware/source-sdk-2013/pull/1380#issuecomment-3042208547
I'm still debugging this however the broken background in GIFs seems to only occur in TF without the GameUI override. Both normal TF and HL2MP display them fine. (EDIT: The only difference I noticed between non-GameUI override TF and HL2MP is that TF calls CGIFHelper::OpenImage during the loading screen, so I'm guessing it has to do something with that)
Went over and improved some things that I have initially missed:
- Reset animation speed for very fast GIFs to match web browsers (technically old behavior was more correct, but it's probably preferred for avatars to act the same way as on Steam)
- Optimizations in
CGIFHelper::GetRGBA, also made it a bit easier to look at - Overhauled animated avatar handling in
CAvatarImage, e.g. reference counting is performed automatically, faster cache lookup
Reduced memory usage by around 80% by storing GIF textures in DXT1 format instead of using raw RGBA8888 ~~(drawback being more processing needs to be done, but I think the trade off is worth it)~~. GIFs are processed on a separate worker thread now.
~~CGIFHelper also now supports exporting to other 8-bit channel texture formats.~~