GLINE can crash SB!?
Root / SmileBASIC Bug Reports / [.]
NathanielCreated:
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.
Nathaniel: Which one, the very last one I posted? Note that the large range there is over X, not Y.
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=1113Same 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.
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.
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 :(