gCircle

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)....

I 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.

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.