? GTRI graphical stripes (Page 1) ● SmileBASIC Source Forums

Sign In

Register
*Usernames are case-sensitive
Forgot my password

GTRI graphical stripes

  • #1 ✎ 86 Simeon Scholar Received for knowing a great deal about programming topics Achievements Amazing Page Hidden Achievements Drawing I like to draw! Hobbies GTRI 0,240,0,900000,400,0 Fills the screen with stripes, modifying the second point will change the stripe pattern The bigger 900000 is, the denser the stripes get. When a Y value in GTRI is anything greater than 33280, this pattern will appear. (The other 2 points can be any position on the screen) Posted Edited by Simeon
  • #2 ✎ 477 SquareFingers So, it seems that these triangles are painted in vertical stripes, something like this: The system iterates through each vertical stripe of pixels, which contains some part of the triangle. It finds the two edges of the triangle which intersect this stripe. It gets the Y-coordinate where each triangle edge intersects the vertical stripe of pixels. It paints all the pixels in the vertical stripe, between those Y coordinates. Now, the problem is when the system calculates the Y-coordinate where the stripe of pixels intersects a triangle edge. If it intersects the triangle edge at Y=33279, everything is fine... if it intersects the triangle edge at Y=33280, it actually uses the Y value of -32256 (which is 65536 below what it should be... giving a hint about the bug to those who know their powers of 2). If the Y value is above 33279, then the Y value actually used is 65536 less, or 65536*2 less, or 65536*3 less, whatever brings it into the range -32256 to 33279. (This is the range of a signed 16-bit integer, -32768 to 32767, shifted positive by 512). If the Y value is below -32256, then 65536 is added to it until it comes into that range. So, the Y coordinate of the steep triangle edge gets greater and greater, going down further, until it gets out of range for some internal calculations - like a speedometer rolling over, except it rolls back to a negative number, it begins counting from the other extreme, very high up above the screen, keeps going down, then passes the visible coordinates again so it's off the bottom of the screen, etc.. The greater the Y coordinate of the extreme triangle vertex, the more times the odometer will 'roll over', the more times the calculated intersection Y value will go from far below the bottom of the screen to far above the top, the more stripes there will be. For the record, I have notified SmileBoom of this bug, giving them the link to this page. Posted
  • #3 ✎ 214 ColeslawProductions Well, maybe this bug can be useful. GTRI 0,0,512,0,0,&HFFFFFF,C This will fill the entire graphics page with vertical lines, 1px wide, 1px apart. Except... using a FOR loop and GLINE to do the same thing is 32x faster. Well, I'm actually kinda surprised it draws in vertical stripes rather than horizontal. I think old computers would do it horizontally because it would align with scanlines. I actually chose to draw the lines horizontally for TRIARAST on PTC But honestly, I expected SmileBASIC to use some polygon rasterization operation provided by the 3DS, that would not have been prone to overflow errors at 16 bits. Posted Edited by ColeslawProductions