2018-06-25 14:45 EDT


View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002182FSSCPgraphicspublic2010-04-18 23:39
ReporterThe_E 
Assigned ToThe_E 
PrioritynormalSeveritycrashReproducibilityrandom
StatusresolvedResolutionfixed 
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 Files
  • png file icon Untitled.png (218,565 bytes) 2010-04-14 20:03 -
    png file icon Untitled.png (218,565 bytes) 2010-04-14 20:03 +
  • ? file icon crashtest.fs2 (22,399 bytes) 2010-04-14 20:48
  • patch file icon 2182_fix1.patch (855 bytes) 2010-04-16 01:42 -
    Index: code/playerman/playercontrol.cpp
    ===================================================================
    --- code/playerman/playercontrol.cpp	(revision 6056)
    +++ code/playerman/playercontrol.cpp	(working copy)
    @@ -629,7 +629,11 @@
     				if (!(Objects[Player->objnum].phys_info.flags & PF_GLIDING)) {
     					//pmax_speed = Ship_info[Ships[Player_obj->instance].ship_info_index].max_speed;
     					pmax_speed = Ships[Player_obj->instance].current_max_speed;
    -					ci->forward_cruise_percent = (tspeed / pmax_speed) * 100.0f;
    +					if (pmax_speed > 0.0f) {
    +						ci->forward_cruise_percent = (tspeed / pmax_speed) * 100.0f;
    +					} else {
    +						ci->forward_cruise_percent = 0.0f;
    +					}
     					override_analog_throttle = 1;
     					//if ( ci->forward_cruise_percent > 100.0f )
     						//HUD_printf ("Cannot travel that fast.  Setting throttle to full.");
    
    patch file icon 2182_fix1.patch (855 bytes) 2010-04-16 01:42 +

-Relationships
+Relationships

-Notes

~0011881

The_E (administrator)

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.

~0011882

The_E (administrator)

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.

~0011883

iss_mneur (developer)

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.

~0011889

Goober5000 (administrator)

Mondragon's/The E's fix has been merged in revision 6060.
+Notes

-Issue History
Date Modified Username Field Change
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
+Issue History