GLINE can crash SB!?

Recently I've discovered that GLINE can crash SmileBASIC in a running program. Here's the code I used:

ACLS
BGMPLAY 17
?"Press any button to crash"
 REPEAT
 UNTIL BUTTON(2)
GLINE 0,1e+9,1,-1e+9

Interesting bug, it leads to a 3DS system restart, not just SmileBasic closing. And GLINE 0,1e9,0,-1e8 does not trigger it, neither does GLINE 1,1e9,1,-1e8, suggesting it's not the endpoints, it's the slope. And GLINE 1,1e9,0,-1e8 works, suggesting that it's just anticlockwise of vertical, not clockwise of vertical. How bizarre. EDIT: GLINE 1E9,0,-1E9,1 is just, just wierd. I defy anyone to explain the result. I promise it doesn't crash the 3DS (or, I guess I should say, it doesn't crash my SmileBasic 3.3.2 on New 3DS Ver. 11.3.0-36U): it just draws a messed-up line.

Strange... It crashes on my New 3DS, but not on my old one. Both of which are v3.3.2.

Nathaniel: Which one, the very last one I posted? Note that the large range there is over X, not Y.

You flipped X and Y when you tried it. Here's what it's suppost to look like: GLINE 0,1E9,1,-1E8

Yes, GLINE 1E9,0,-1E9,1 is different from what you did. On my system, it draws a small 45-degree line in the top-left corner of the screen (I think 7,0 to 0,7), and a short vertical line dropping from the lowest pixel (I think 0,7 to 0,14). Two straight line segments, from one GLINE. - I don't mean to ignore, or push aside, your GLINE. I'm just exploring how deep the problem is, trying to give it more context and define it further, so I'm writing about other GLINEs too.

I'm reminded of the thread GTRI graphical stripes http://smilebasicsource.com/forum?ftid=1113

I'm reminded of the thread GTRI graphical stripes http://smilebasicsource.com/forum?ftid=1113

Same here. I actually tried it with GTRI, but it just took forever to render a plain white screen.

A clue?: IEEE single-precision floating-point has only about 9 decimal digits of precision. Once that data type can no longer count in '1's, is when this bug appears to manifest.

Maybe it tries to draw on the a subpixel...

I don't know, this still works in V3.5.2 EU.

Ooh! Try- GLINE 1E9,0,-1E9,64 Looks like this:

Since the second y value is 64 why does that go off-screen? Weird.

Interesting bug, it leads to a 3DS system restart, not just SmileBasic closing. -snip-

That's the normal behavior of a crash on the 3DS.

Nathaniel: Maybe it tries to draw on the a subpixel... If it did so, how would it go with this (and many other)

GLINE 8,8,99,230
GLINE 1,1,0,6
'''

the glitch no longer work in 3.6.0 :(

I'm not sure there's any way to crash SmileBASIC in 3.6.0. At least, no way that I've heard of so far. _{Which might be a good thing...}

I'm not sure there's any way to crash SmileBASIC in 3.6.0. At least, no way that I've heard of so far. _{Which might be a good thing...}

I don't think they fixed CONTROLLER, unfortunately.