WTF of the day

[metlslime]

I've spent about three nights in a row trying to figure out how i'm corrupting memory in the tempentity list... even when i remove the code i added, it still crashes spectacularly. On the other hand, sometimes it works fine and i figured it must be a compiler bug.

Until just now, when i discovered something peculiar in CL_UpdateTEnts -- there is a for loop inside another for loop, and both loops use the variable "i" as their iterator. Anyway, here's the code (100% pure id software code), see for yourself:

Code: Select all

void CL_UpdateTEnts (void)
{
   int         i;
   beam_t      *b;
   vec3_t      dist, org;
   float      d;
   entity_t   *ent;
   float      yaw, pitch;
   float      forward;

   num_temp_entities = 0;

// update lightning
   for (i=0, b=cl_beams ; i< MAX_BEAMS ; i++, b++)
   {
      if (!b->model || b->endtime < cl.time)
         continue;

   // if coming from the player, update the start position
      if (b->entity == cl.viewentity)
      {
         VectorCopy (cl_entities[cl.viewentity].origin, b->start);
      }

   // calculate pitch and yaw
      VectorSubtract (b->end, b->start, dist);

      if (dist[1] == 0 && dist[0] == 0)
      {
         yaw = 0;
         if (dist[2] > 0)
            pitch = 90;
         else
            pitch = 270;
      }
      else
      {
         yaw = (int) (atan2(dist[1], dist[0]) * 180 / M_PI);
         if (yaw < 0)
            yaw += 360;
   
         forward = sqrt (dist[0]*dist[0] + dist[1]*dist[1]);
         pitch = (int) (atan2(dist[2], forward) * 180 / M_PI);
         if (pitch < 0)
            pitch += 360;
      }

   // add new entities for the lightning
      VectorCopy (b->start, org);
      d = VectorNormalize(dist);
      while (d > 0)
      {
         ent = CL_NewTempEntity ();
         if (!ent)
            return;
         VectorCopy (org, ent->origin);
         ent->model = b->model;
         ent->angles[0] = pitch;
         ent->angles[1] = yaw;
         ent->angles[2] = rand()%360;

         for (i=0 ; i<3 ; i++)
            org[i] += dist[i]*30;
         d -= 30;
      }
   }
}

My guess is that the memory immediately after cl_beams[] is usually full of zeros, and that's why it usually works.

[mh]

Aaaaaaaaahhhhhhhhhhh.

I had the very same last week (made worse by the fact that I no longer had any memory after cl_beams...) and kinda hacked around it by doing a check for "if (cl.time < 0.0001) return;" at the start, as it only seemed to happen at a changelevel. I was never really happy with that solution, so I'm looking forward to trying this out and seeing if it resolves anything.

Thankingyew!

[Spike]

I didn't realise that was in the original code.
That one caught me out too - I thought it was my own bug!

[mh]

Yup, that sorted it.

Nice one and cheers again for sharing the info.

[revelator]

yep had same.

using the same var in two for loops works in old mode c++ where

for could be declared like this for (int i; i<something;i++) {rest of stuff where the int i is conciled}

then another for (int i; i = something; i--) {stuff here doesnt see the above int}

but i discovered later compilers dont like this method at all and prefers seperate descriptors.

for an example try compiling the blood2 client code with msvc 2005 it will bitch like hell and refuse to link