Source Code Project Mantis - FSSCP
View Issue Details
0003057FSSCPgraphicspublic2014-06-12 05:342014-06-12 21:59
Assigned ToMageKing17 
PlatformOSOS Version
Product Version3.6.16 
Target Version3.7.2Fixed in Version3.7.2 
Summary0003057: Ships/weapons render as solid black in loadout previews with FS2-style animation.
DescriptionWith newer AMD video cards, there's a known bug whereby the loadout renders are solid black for some reason. Additionally, if the FS1-style loadout animation is used, the model fails to appear at all. After diving into the shader code, it looks like the shaders were relying on undefined behavior for the pow() function (specifically, the OpenGL specification says pow() is undefined if the first argument is negative). With this knowledge in hand, I altered the default fragment shader to avoid calling pow() with a negative first argument and tweaked the values until I got a more familiar FS1-esque effect, and got the FS2 effect working again. Patch file attached.

I would be very interested to know if this patch works even for people unaffected by the bug.

Note that this bug makes it impossible for me to compare this behavior with the old behavior. If my behavior is drastically different, the values can (hopefully) be tweaked to produce more consistent results.
Steps To ReproduceImpossible to miss by simply going to ship or weapon select with 3D models, if you're affected at all.
Additional InformationFS1-style animation under old shaders results in the model never showing up at all.
TagsNo tags attached.
Attached Filespatch def_files.cpp.patch (1,037) 2014-06-12 20:44
patch missionscreencommon.cpp.patch (540) 2014-06-12 21:52

2014-06-12 06:17   
Patch updated based on how the old shaders work for people not affected by this bug.
2014-06-12 06:47   
(Last edited: 2014-06-12 06:52)
I never experienced this issue, but with the patch, I don't have anything breaking.

I do notice that (compared to Valathil's videos) that my FS2 effect wireframe lines are black instead of blue, regardless of patched or un-patched, but that is outside of the scope of this fix.

2014-06-12 20:45   
Clearly, I was sleep-deprived when I wrote the earlier patch, because an hour and a half of sleep pointed out a much, much, much simpler solution.

New patch uploaded.
2014-06-12 21:53   
Following a discussion in #scp, a secondary patch has been added to restore the original blue wireframes.
2014-06-12 21:59   
Fix committed to trunk@10797.

Issue History
2014-06-12 05:34MageKing17New Issue
2014-06-12 05:34MageKing17Statusnew => assigned
2014-06-12 05:34MageKing17Assigned To => MageKing17
2014-06-12 05:34MageKing17File Added: def_files.cpp.patch
2014-06-12 06:17MageKing17File Deleted: def_files.cpp.patch
2014-06-12 06:17MageKing17File Added: def_files.cpp.patch
2014-06-12 06:17MageKing17Note Added: 0015844
2014-06-12 06:18MageKing17Statusassigned => feedback
2014-06-12 06:18MageKing17Statusfeedback => code review
2014-06-12 06:47ZacamNote Added: 0015845
2014-06-12 06:52ZacamNote Edited: 0015845bug_revision_view_page.php?bugnote_id=15845#r814
2014-06-12 20:43MageKing17File Deleted: def_files.cpp.patch
2014-06-12 20:44MageKing17File Added: def_files.cpp.patch
2014-06-12 20:45MageKing17Note Added: 0015847
2014-06-12 21:52MageKing17File Added: missionscreencommon.cpp.patch
2014-06-12 21:53MageKing17Note Added: 0015848
2014-06-12 21:57ZacamProduct Version => 3.6.16
2014-06-12 21:57ZacamFixed in Version => 3.7.2
2014-06-12 21:57ZacamTarget Version => 3.7.2
2014-06-12 21:59ZacamChangeset attached => fs2open trunk r10797
2014-06-12 21:59ZacamNote Added: 0015849
2014-06-12 21:59ZacamStatuscode review => resolved
2014-06-12 21:59ZacamResolutionopen => fixed