Hy Community,
Should this code not produce the same ?
gcircle 0,0,100,-7.5,0,1 ' ? °
gcircle 0,0,100,360-7.5,0,1 ' 360-7.5= 352.5 °
rotating a line step by step gives me the second result.
(x1= x1*cos(rad(angle))- y1*sin(rad(angle)....
gCircle
Replying to:
MZ952
MZ952I think what's happening is the angle is being truncated to an integer rather than staying a float. The decimal value gets chopped off.
-7.5 -> -7
360-7.5 -> 352.5 -> 352
Now there's a difference of 1 degree, and you end up with a different result.
Yes, i tought the same, but if you enter both lines in the same programm the output differs.
So if i enter -7.5 its not the same as 360-7.5, that means internally
the gcirlce does not calculate the angle to mod 360, or i am wrong ?
i bet the start of the function definition of GCIRCLE in the source code of SmileBASIC looks something like this:
void sb_gcircle_sector(vec2 center, float radius, float startAngle, float endAngle) {
int startAngleInt = (float)startAngle % 360;
int endAngleInt = (float)endAngle % 360;
// ... and then interact with graphics pages
}
there's a float-to-integer conversion, but because they've done it with this specific type casting syntax in C, it acts the same as FLOOR in SmileBASIC -- it won't do any rounding of the value at all, and it will remove the fractional part. only after that did they use % 360 to do MOD 360. plus, the strange parenthesizing that comes with C language syntax could confuse readers of the code about what order the MOD and FLOOR functions are applied in.
there's a perfectly-fine and standardized fmodf function in the C standard library, so i'm mystified as to why this bug exists. maybe fmodf calls are CPU-intensive on the 3DS in some way? that, or maybe they just forgot it existed -- SmileBASIC doesn't seem to have an FMOD function for us to program with.