Source Code Project Mantis - FSSCP
View Issue Details
0002182FSSCPgraphicspublic2010-04-14 20:032010-04-18 23:39
Assigned ToThe_E 
PlatformOSOS Version
Product Version3.6.12 RC2 
Target VersionFixed in Version3.6.12 
Summary0002182: Rendering cuts out seemingly randomly
Description(This is The E, in case this isn't clear)

This is quite possibly the strangest bug I've seen so far.

During BP:WiH development, we have encountered a strange issue where sometimes, for no apparent reason, rendering would just cut out. Check the attached screenshot for the result; while suns are apparently still working, everything else 3D is just gone, the 3D radar is rendered where the head.anis are supposed to go, and the reticle has disappeared.

This issue crept up a few times; in each case, it was not clear just why and how this happened.
However, now we finally have a combination of assets and missions to reproduce this reliably.
Based on my own investigation so far, it seems that at some point, the View_position global (declared in 3dinternal.h, line 24) gets itself into an invalid state, causing all sorts of issues.
Running the mission through debug and with an attached debugger reports an Assert in vecmat.cpp line 543, the callstack at that point goes to snd_get_3d_vol_and_pan() (sound.cpp, line 726), but this does not seem to be the cause, but merely a symptom.

If other developers need access to the data that allows this issue to be replicated, drop me or Fury a line so we can arrange access to our modpack.
TagsNo tags attached.
Attached Filespng Untitled.png (218,565) 2010-04-14 20:03

? crashtest.fs2 (22,399) 2010-04-14 20:48
patch 2182_fix1.patch (855) 2010-04-16 01:42

2010-04-14 20:52   
(Last edited: 2010-04-14 20:55)
Attached is the mission that displays the issue, adapted to run on the released BP:AoA DC pack.

Beware spoilers, though.

2010-04-15 23:26   
This thing is doing my head in.

After god knows how much grinding at the stone that is the Visual Studio debugger, I have arrived at the conclusion that, at some point after the event "eerie flash 1" in the attached mission, the player ships' phys_info.forward_thrust variable gets itself into an invalid state (to be more precise, the state that VS2010 represents with "-1.#IND00", which is Not A Number, and therefore bad).

This seems to cause a cascading failure, where first the ships' phys_info.desired_velocity gets invalid, which then contaminates the real world object position, which then proceeds to mess with the eyepoint, culminating in a corruption of the renderer, as it tries to render the frame from a viewpoint that is clearly not from this Earth.
2010-04-16 01:43   
(Last edited: 2010-04-16 14:47)
Attached proposed fix after consulting with The_E (Mondragon).

The cause of the bug was the speed match function. It would allow a divide by zero if the the players max speed was 0, resulting in NaN.

2010-04-18 23:39   
Mondragon's/The E's fix has been merged in revision 6060.

Issue History
2010-04-14 20:03The_ENew Issue
2010-04-14 20:03The_EFile Added: Untitled.png
2010-04-14 20:48The_EFile Added: crashtest.fs2
2010-04-14 20:52The_ENote Added: 0011881
2010-04-14 20:55The_ENote Edited: 0011881
2010-04-15 23:26The_ENote Added: 0011882
2010-04-16 01:16iss_mneurFile Added: 2182_fix.patch
2010-04-16 01:42iss_mneurFile Added: 2182_fix1.patch
2010-04-16 01:42FUBAR-BDHRFile Deleted: 2182_fix.patch
2010-04-16 01:43iss_mneurNote Added: 0011883
2010-04-16 14:47iss_mneurNote Edited: 0011883
2010-04-18 23:39Goober5000Note Added: 0011889
2010-04-18 23:39Goober5000Assigned To => The_E
2010-04-18 23:39Goober5000Statusnew => resolved
2010-04-18 23:39Goober5000Resolutionopen => fixed
2010-04-18 23:39Goober5000Fixed in Version => 3.6.12