bbMilliSecs on Mac broken!
Archives Forums/BlitzMax Bug Reports/bbMilliSecs on Mac broken!
| ||
| Just when you thought it was safe to go back into the IDE.... My Mac is on all the time, so there often comes a time when Millisecs() starts reporting negative numbers because it has been on for so long. This is immediately noticeable because Graphics-based apps' frame rates very quickly grind to a halt. It happened to me last month, and I dug around the Graphics code thinking there was a timing issue with negative numbers, but couldn't find anything. After a reboot all was well. Anyway, it happened again today, so on further investigation, it seems that the negative value returned by Millisecs() doesn't actually change! Instead the value is always this : -2147483648 It appears to be something to do with casting this : return t/(1000.0/512.0) into an int. I have patched mine like this : return (int)(long long)(t/(1000.0/512.0)); which seems to get around the "bug", and returns negative numbers correctly. Now when I run a graphics-based app, it runs smoothly as before, so there is definitely a connection between the result from bbMilliSecs and the graphics updates. OS X 10.6.x Intel. Anyhoo... :-) |
| ||
I usually ignore Mac bug reports but just noticed this one. A double precision value is used to calculate milliseconds, but must be cast to an integer. This can fail as demonstrated here. Out of range values are cast to -2147483648. I suppose the rationale is it's the most extreme possible integer value. It also provides a hint to what went wrong. That's how I recognized it!' Signed integers are in the range -2*(2^31) to +2*(2^31)-1 ' Floating point values out of this range are considered infinite. pInf:Double = +1.0 / 0.0 nInf:Double = -1.0 / 0.0 huge:Double = 5e9 Print Print "Double values: " + pInf + " " + nInf + " " + huge Print Print "Cast to integer: " + Int( pInf ) + " " + Int( nInf ) + " " + Int( huge ) Print ' That's what happens in blitz_app.c when the double t, which holds the ' millisecs value to be returned in a signed integer, overflows the ' 2^31 boundary. Here's another fix, manually wrapping t back into ' the appropriate integer range. Print Print "Test first four instances of proposed fix." Print Const TWO31:Double = 2^31 Const TWO32:Double = 2^32 For n = 0 To 3 For tt:Double = n*TWO32 + TWO31 - 2 To n*TWO32 + TWO31 + 2 t:Double = tt ' simulated whopping millisecs t:Double = t Mod TWO32 ' first wrap to 0 to 2^32 - 1 If t > TWO31 Then t :- TWO32 ' and then to signed integer range Print tt + " " + Int( t ) ' Int( t ) should now be correct Next Print Next |
| ||
| Bumpity bump, and pretty please! Since this is a recurring "if I leave my Mac on for too long, my BlitzMax graphics apps stop working" bug. I'd rather not have to reboot my computer more-so-often because of BlitzMax... :-( |
| ||
| Hi, Ok, thought I'd fixed this but it looks like I left some brackets off. Will have another go... |
   |