2019-12-15 21:34 EST


View Issue Details Jump to Notes ] Related Changesets ]
IDProjectCategoryView StatusLast Update
0003057FSSCPgraphicspublic2014-06-12 21:59
ReporterMageKing17 
Assigned ToMageKing17 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
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 Files
  • patch file icon def_files.cpp.patch (1,037 bytes) 2014-06-12 20:44 -
    Index: code/globalincs/def_files.cpp
    ===================================================================
    --- code/globalincs/def_files.cpp	(revision 10795)
    +++ code/globalincs/def_files.cpp	(working copy)
    @@ -1543,12 +1543,12 @@
     " #endif\n"
     " #ifdef FLAG_ANIMATED\n"
     "	if (effect_num == 0) {\n"
    -"		float shinefactor = 1.0/(1.0 + pow((fract(abs(gl_TexCoord[0].x))-anim_timer) * 1000.0, 2.0)) * 1000.0;\n"
    +"		float shinefactor = 1.0/(1.0 + pow(abs((fract(abs(gl_TexCoord[0].x))-anim_timer) * 1000.0), 2.0)) * 1000.0;\n"
     "		gl_FragColor.rgb = fragmentColor.rgb + vec3(shinefactor);\n"
     "		gl_FragColor.a = fragmentColor.a * clamp(shinefactor * (fract(abs(gl_TexCoord[0].x))-anim_timer) * -10000.0,0.0,1.0);\n"
     "	}\n"
     "	if (effect_num == 1) {\n"
    -"		float shinefactor = 1.0/(1.0 + pow((position.y-anim_timer), 2.0));\n"
    +"		float shinefactor = 1.0/(1.0 + pow(abs(position.y-anim_timer), 2.0));\n"
     "		gl_FragColor.rgb = fragmentColor.rgb + vec3(shinefactor);\n"
     "	 #ifdef FLAG_LIGHT\n"
     "		gl_FragColor.a = fragmentColor.a;\n"
    
    patch file icon def_files.cpp.patch (1,037 bytes) 2014-06-12 20:44 +
  • patch file icon missionscreencommon.cpp.patch (540 bytes) 2014-06-12 21:52 -
    Index: code/missionui/missionscreencommon.cpp
    ===================================================================
    --- code/missionui/missionscreencommon.cpp	(revision 10796)
    +++ code/missionui/missionscreencommon.cpp	(working copy)
    @@ -1746,7 +1746,7 @@
     			// render the ships
     			model_clear_instance(model_id);
     			model_set_detail_level(0);
    -			gr_set_color(80,49,160);
    +			model_set_outline_color(80,49,160);
     			opengl_shader_set_animated_effect(ANIMATED_SHADER_LOADOUTSELECT_FS2);
     			opengl_shader_set_animated_timer(-clip);
     
    
    patch file icon missionscreencommon.cpp.patch (540 bytes) 2014-06-12 21:52 +

-Relationships
+Relationships

-Notes

~0015844

MageKing17 (developer)

Patch updated based on how the old shaders work for people not affected by this bug.

~0015845

Zacam (administrator)

Last edited: 2014-06-12 06:52

View 2 revisions

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.

~0015847

MageKing17 (developer)

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.

~0015848

MageKing17 (developer)

Following a discussion in #scp, a secondary patch has been added to restore the original blue wireframes.

~0015849

Zacam (administrator)

Fix committed to trunk@10797.
+Notes

+Related Changesets

-Issue History
Date Modified Username Field Change
2014-06-12 05:34 MageKing17 New Issue
2014-06-12 05:34 MageKing17 Status new => assigned
2014-06-12 05:34 MageKing17 Assigned To => MageKing17
2014-06-12 05:34 MageKing17 File Added: def_files.cpp.patch
2014-06-12 06:17 MageKing17 File Deleted: def_files.cpp.patch
2014-06-12 06:17 MageKing17 File Added: def_files.cpp.patch
2014-06-12 06:17 MageKing17 Note Added: 0015844
2014-06-12 06:18 MageKing17 Status assigned => feedback
2014-06-12 06:18 MageKing17 Status feedback => code review
2014-06-12 06:47 Zacam Note Added: 0015845
2014-06-12 06:52 Zacam Note Edited: 0015845 View Revisions
2014-06-12 20:43 MageKing17 File Deleted: def_files.cpp.patch
2014-06-12 20:44 MageKing17 File Added: def_files.cpp.patch
2014-06-12 20:45 MageKing17 Note Added: 0015847
2014-06-12 21:52 MageKing17 File Added: missionscreencommon.cpp.patch
2014-06-12 21:53 MageKing17 Note Added: 0015848
2014-06-12 21:57 Zacam Product Version => 3.6.16
2014-06-12 21:57 Zacam Fixed in Version => 3.7.2
2014-06-12 21:57 Zacam Target Version => 3.7.2
2014-06-12 21:59 Zacam Changeset attached => fs2open trunk r10797
2014-06-12 21:59 Zacam Note Added: 0015849
2014-06-12 21:59 Zacam Status code review => resolved
2014-06-12 21:59 Zacam Resolution open => fixed
+Issue History