Funny "bugfixes"

[mankrip]

Have you ever had your code behaving badly for seemingly no reason, and then you accidentally "fix" it in a way that makes even less sense?

In Makaqu, I've got this little check to make sure that the particle metadata only gets recreated when actually needed:

Code: Select all

   // doubled the minimum size here to make sure the particle will appear,
   // since the width and height calculations reduces its drawing area
   max_size = min (vid.width, vid.height) + 2;

   // don't recalculate when only zooming in
   if (r_particles_init
   &&   r_particles.h_aspect   == h_aspect
   &&   r_particles.max_size   == max_size
      )
      return;

However, in the Windows version it wasn't working properly, so every time the FOV was changed the particle metadata would be recreated, causing lots of unnecessary stuttering in the framerate when zooming.

So, I decided to print out the contents of the aspect variables, since they were the most likely to be malfunctioning:

Code: Select all

   Con_DPrintf ("r_particles.h_aspect %d\n", r_particles.h_aspect);
   Con_DPrintf ("h_aspect %d\n", h_aspect);

And then, when I typed "developer 1" in the console and zoomed in... nothing was printed. And no stuttering happened. The check was definitely working this time.

So, I removed the Con_DPrintf lines, and... the stuttering came back. I put the lines back in, and the stuttering was gone again. Then, I tried removing only the first Con_DPrintf line, and the stuttering was still gone. And finally, I put the first line back in and removed just the second line, and it was still gone. So, adding a Con_DPrintf line after the check made it so the check, which is run before the Con_DPrintf, don't fail. It makes no bloody sense at all .

Things like this can be embarrassing, but it was impossible to not laugh.

[revelator]

I had my share of unexplainable things like that to so your not alone

[taniwha]

Did you leave developer 1 set the whole time? (ie, even when the Con_DPrintf statements were gone). If not, it might actually be a bug somewhere else. If so, I'd suspect a compiler bug.

[szo]

Most possibly a sneaky stack corruption bug, although a compiler bug is not impossible either.

[revelator]

id lean on a compiler bug most of the times i had these kinda weird behaviours switching to another compiler made it go away or revealed a mistake on my part.
it seems to be predominant with later versions of msvc (mostly 2008) better in the latest but still there at times with 2010.
Its like the compiler sometimes thinks it should use minimal rebuild even if told not to and then fails to pickup the change you made untill you force it.

[taniwha]

That sounds like a bug in the dependency generator. Can be tricky to get right, sometimes.

[revelator]

Sounds likely should update ms about this i think.

[mh]

If you've got minimal rebuild enabled that might happen; also if optimizing for size. Another possible cause is that the compiler might somehow have thought that the "if" had no effect and decided to optimize it out; adding the Con_DPrintf convinced it otherwise. Try splitting it out to another function with a #pragma optimize ("", off) on it and see if it reproduces.

[revelator]

Its like the compiler sometimes thinks it should use minimal rebuild even if told not to

Thats the problem it seems to sometimes force minimal rebuild even if that option was newer used it does not happen often but its not the first time i had similar problems.

Disabling optimization on certain code parts might help though

[mankrip]

Well, the compiler I use is the free one from Microsoft Visual C++ Toolkit 2003, which if I recall correctly was said to be more complete than the one used in the Express editions. I may try something else later.

Minimal rebuild bugs aren't a problem, as I always clean the whole build when editing header files, or before compiling release candidates.

Disabling optimizations is a good idea, I've forgot to try that.