|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002182||FSSCP||graphics||public||2010-04-14 20:03||2010-04-18 23:39|
|Product Version||3.6.12 RC2|
|Target Version||Fixed in Version||3.6.12|
|Summary||0002182: 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.
|Tags||No tags attached.|
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.
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.
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.
|Mondragon's/The E's fix has been merged in revision 6060.|
|2010-04-14 20:03||The_E||New Issue|
|2010-04-14 20:03||The_E||File Added: Untitled.png|
|2010-04-14 20:48||The_E||File Added: crashtest.fs2|
|2010-04-14 20:52||The_E||Note Added: 0011881|
|2010-04-14 20:55||The_E||Note Edited: 0011881|
|2010-04-15 23:26||The_E||Note Added: 0011882|
|2010-04-16 01:16||iss_mneur||File Added: 2182_fix.patch|
|2010-04-16 01:42||iss_mneur||File Added: 2182_fix1.patch|
|2010-04-16 01:42||FUBAR-BDHR||File Deleted: 2182_fix.patch|
|2010-04-16 01:43||iss_mneur||Note Added: 0011883|
|2010-04-16 14:47||iss_mneur||Note Edited: 0011883|
|2010-04-18 23:39||Goober5000||Note Added: 0011889|
|2010-04-18 23:39||Goober5000||Assigned To||=> The_E|
|2010-04-18 23:39||Goober5000||Status||new => resolved|
|2010-04-18 23:39||Goober5000||Resolution||open => fixed|
|2010-04-18 23:39||Goober5000||Fixed in Version||=> 3.6.12|