Gez Posted August 26, 2009 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 unsignedThe 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. 0 Share this post Link to post
Quasar Posted August 27, 2009 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 ;) 0 Share this post Link to post
exp(x) Posted August 27, 2009 What about putting a 0 in front of the minus instead of using unary minus? 0 Share this post Link to post
Gez Posted August 27, 2009 Indeed, no warnings with lines modified as such: x > (y = 0-y) ? 0-tantoangle[SlopeDiv(y,x)] : // octant 7 angle2 = 0-clipangle; 0 Share this post Link to post
Graf Zahl Posted August 27, 2009 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. 0 Share this post Link to post
Quasar Posted August 27, 2009 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 :) 0 Share this post Link to post
exp(x) Posted August 27, 2009 Quasar said:What do you know? Guess I never thought of that ;) Sometimes it's the simple solutions that escape us. 0 Share this post Link to post
Gez Posted August 31, 2009 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 0 Share this post Link to post
Quasar Posted August 31, 2009 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 ^_^ 0 Share this post Link to post
entryway Posted September 8, 2009 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. 0 Share this post Link to post
entryway Posted September 9, 2009 Gez said:Now see what you've done. Did not know zdoom uses that code, because gzdoom uses atan2 in both renderers. 0 Share this post Link to post