Extra Data in Sprite Rotation
Root / SmileBASIC Bug Reports / [.]
randoCreated:
This is due to a rounding error related to sprite rotation. The transform they use can cause 1 or 2 pixels to bleed in from adjacent sprites. They use OpenGL 3D tech to render the sprites because it's just easier; sprites are UV-mapped textured quads, the GRP sheets are textures loaded in VRAM. But for some reason the rendering of the textures creates lots of artifacting when scaling or rotating. It's a known and stated problem and the recommendation is to just leave spaces between your sprites on the sheet.
Cool
I actually have the whole line of pixels next to the sprite, because the sprite next to it is just a box. Anyway...
To replicate this, just fill the entire area next to your sprite so that all pixels adjacent to the sprite are colerful. Then create that sprite and rotate it 45 (I think) degrees.
You also might get bleed just by moving the sprite. That might be a side effect of either using SPLINK or setting the X and Y coordinates to decimal values.
This is due to a rounding error related to sprite rotation. The transform they use can cause 1 or 2 pixels to bleed in from adjacent sprites. They use OpenGL 3D tech to render the sprites because it's just easier; sprites are UV-mapped textured quads, the GRP sheets are textures loaded in VRAM. But for some reason, the rendering of the textures creates lots of artifacts when scaling or rotating. It's a known and stated problem and the recommendation is to just leave spaces between your sprites on the sheet.Why don't they give US access to OpenGL in a limited fashion? SB4 better have built-in 3D acceleration in a future update. Even a native PERSPECTIVE function would be great... They have access to 3D acceleration. Why not use it on both SB3 and SB4?