Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
Gez

VC++ compile warnings

Recommended Posts

These three warnings have been there for a while, so I suppose that maybe GCC doesn't catch them. They're all instances of purposefully exploiting 32-bit math overflow on angle_t values.

1>.\source\r_main.c(248) : warning C4146: unary minus operator applied to unsigned type, result still unsigned
1>.\source\r_main.c(264) : warning C4146: unary minus operator applied to unsigned type, result still unsigned
1>.\source\r_bsp.c(1742) : warning C4146: unary minus operator applied to unsigned type, result still unsigned
The line numbers correspond to r830. The first two are the "octant 7" lines in R_PointToAngle and R_PointToAngle2, the third is in R_CheckBBox, the "angle2 = -clipangle" operation that happens after the check for whether it is "Totally off the left edge" or not.

Share this post


Link to post

It is impossible to eliminate these warnings AFAIK. There is no valid portable idiom in C that will replace what these statements are trying to do to the best of my knowledge.

If you know of one, do share ;)

Share this post


Link to post

Indeed, no warnings with lines modified as such:

        x > (y = 0-y) ? 0-tantoangle[SlopeDiv(y,x)] :              // octant 7


      angle2 = 0-clipangle;

Share this post


Link to post

That reminds me, is Eternity still using the Killoughized version of R_PointToAngle? Interestingly it's both far less readable and creates less efficient code than the original in Doom.exe...

That guy really had a problem with coding style. ;) What he did to these functions was just plain idiotic.

Share this post


Link to post

What do you know? Guess I never thought of that ;)

And yes it's still the Killoughized code simply because I never thought to revert it (a number of other such single-expression functions have been unwound through the years, though). Maybe now would be a good time to look into it :)

Share this post


Link to post
Quasar said:

What do you know? Guess I never thought of that ;)

Sometimes it's the simple solutions that escape us.

Share this post


Link to post

Two new warnings in r839:

1>.\source\p_cmd.c(350) : warning C4013: 'P_InitLightning' undefined; assuming extern returning int
1>.\source\p_cmd.c(355) : warning C4013: 'P_ForceLightning' undefined; assuming extern returning int

Share this post


Link to post

Guys you gotta give me more than 5 minutes after a commit to catch stuff like that ;) I appreciate the thought and effort, just don't go overboard ^_^

Share this post


Link to post
Graf Zahl said:

That reminds me, is Eternity still using the Killoughized version of R_PointToAngle? Interestingly it's both far less readable and creates less efficient code than the original in Doom.exe...


not so much though :)

unsigned int i, k, tic;
tic = SDL_GetTicks();
for(i = 0; i < 1e8; i++)
{
  k += R_PointToAngle(k, i);
}
I_Error("%d %d", SDL_GetTicks() - tic, k);
~1412 msec for Boom
~1374 msec for Carmack

So you can save ~0.04 sec with 100 billions of PointToAngle

btw, zdoom version (which is not used, but code is there) is 1710 msec - much slower. Used (precise) version of course is super slow - 8140 msec.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×