[Scummvm-tracker] [ScummVM :: Bugs] #15272: TINYGL: triangle fan produces less triangles than expected?

[ScummVM :: Bugs]

#15272: TINYGL: triangle fan produces less triangles than expected?
------------------------+-----------------------
Reporter:  neuromancer  |       Owner:  (none)
    Type:  defect       |      Status:  new
Priority:  normal       |   Component:  Graphics
 Version:               |  Resolution:
Keywords:  tinygl       |        Game:
------------------------+-----------------------
Comment (by jpres27):

 When compiling in debugx64 mode in MSVC this game crashes as soon as you
 get through the introduction screens and load the game world. The crash is
 an access violation in zbuffer.h in the function setPixelAT on line 168

 {{{
         case 4:
             ((uint32 *) _pbuf)[pixel] = value;
             return;
 }}}

 Pixel at some point (I believe while drawing one of the celestial bodies)
 gains the value of -858980032 and triggers an access violation. This value
 looks suspiciously similar to an uninitialized variable.

 If you compile in ASan setting in MSVC or in debug mode using GCC in
 MinGW, the game will load without crashing, but I got an interesting bug
 about two times out of around 15 compilations where one of the triangles
 in one of the celestial bodies will stretch to the edge of the screen. If
 you continue to walk and look around the game will eventually crash with
 an access violation in the same line of code, and the last time this
 happened it crashed with a value of -2147483008 in pixel.

 If you work your way up the call stack you can follow the garbage value
 which crashes the game. In zdirtyrect.cpp on line 396 there is this

 {{{
     case TGL_TRIANGLE_FAN:
         for(int i = 1; i < cnt; i += 2) {
             c->gl_draw_triangle(&c->vertex[0], &c->vertex[i], &c->vertex[i
 + 1]);
 }}}

 c->vertex[i+1]->zp.x had the value -858993664, which seems like it
 eventually becomes the bad value in pixel.

 When you use comments to disable the drawCelestialBodies function, the
 game runs without crashing. When you go into that function and change the
 value of numTriangles to 19 or 21 (instead of 20) the game will also run
 without crashing, however it continues to not render the proper amount of
 triangles and displays like in the original bug report.

 I looked at the vertices which are generated in drawCelestialBodies and
 they are included below:

 {{{
     x         y              z
 -5000     1200           0
 -5000     1580.42261     154.508499
 -5000     1532.60681*    293.892609
 -5000     1435.11414     404.508514
 -5000     1323.60681     475.528259
 -5000     1200           500
 -5000     1076.39319     475.528229
 -5000     964.885864     404.508453
 -5000     876.393188     293.892578
 -5000     819.577393     154.508514
 -5000     800            -4.37113886e-05
 -5000     819.577393     -154.508606
 -5000     876.393188     -293.892670
 -5000     964.885986     -404.508575
 -5000     1076.39331     -475.528290
 -5000     1200           -500
 -5000     1323.60681     -475.528229
 -5000     1435.11426     -404.508423
 -5000     1523.60681     -293.892639
 -5000     1580.42261     -154.508469
 -5000     1600           8.74227771e-05

 -5000     1600           799.777771
 -5000     1580.42261     954.286255
 -5000     1523.60681     1093.67041
 -5000     1435.11414     1204.28625
 -5000     1323.60681     1275.30603
 -5000     1200           1299.77783
 -5000     1076.39319     1275.30603
 -5000     964.885864     1204.28625
 -5000     876.393188     1093.67041
 -5000     819.577393     954.286255
 -5000     800            799.777710
 -5000     819.577393     645.269165
 -5000     876.393188     505.885101
 -5000     964.885986     395.269196
 -5000     1076.39331     324.249481
 -5000     1200           299.777771
 -5000     1323.60681     324.249542
 -5000     1435.11426     395.269348
 -5000     1523.60681     505.885132
 -5000     1580.42261     645.269287
 -5000     1600           799.777832
 }}}

 The z values seem to be having floating point precision errors but I don't
 know if this alone is enough to cause such problems or if one of these
 more problematic values is being furthered mutated later on in the drawing
 code and this generates the bad value in the gl_context.
-- 
Ticket URL: <https://bugs.scummvm.org/ticket/15272#comment:3>
ScummVM :: Bugs <https://bugs.scummvm.org>
ScummVM