Blit works if you give it things that are correct,
As I was saying before, you can't go passing the blame on that one! :P/>/> Writes to out-of-bounds locations are perfectly valid.
local beforeMaxLen, afterMinLen = internalX - 1, internalX + #text
internalText[ internalY ] = string_sub( internalText[ internalY ], 1, beforeMaxLen ) .. text:sub( 2 - internalX, stitch.getSize() - internalX + 1 ) .. string_sub( internalText[ internalY ], afterMinLen )
It's important to remember that passing a negative argument to string.sub() means "start counting backwards from the right". That goes for both arguments.
Let's say internalX is 5, text length is 20, and screen width is 30:
text:sub( 2 - internalX, stitch.getSize() - internalX + 1 )
text:sub( 2 - 5, 30 - 5 + 1 )
text:sub( -3, 26 )
--# So given #text == 20, you effectively get back:
text:sub( 18, 20 )
Due to the length of the text, your starting point is way higher than it should be, and a three-character string is returned when you should be getting
all of it. This problem is less likely to manifest with shorter strings, and as you move away from the left edge of the display it also becomes less likely to occur, but letting those values go negative isn't a reliable option.
You can probably envision the conditionals you'll need to implement to deal with all this, but you may be thinking "let's use more ternarys inside the sub calls" - that's actually not a good idea here; rather, you should be using your conditionals to avoid making those sub calls in the first place. Your current blit function makes them nine times a pop, even though "worst case" scenarios only
need six, and "best case" requires none. Ignoring this adds up to quite a performance hit, as blit is a function which gets called a
lot. The reason why Dan's window API uses all those if/elseif/etc checks within its blit function has nothing to do with readability and everything to do with execution speed.
Have a think about all the different configurations that can be presented - text going off the left
and / or right of the display, lining up with the edges, or not - and you'll see that you can shift quite a bit of work away from the interpreter with a few more checks.
Edit:
By the way, I assume you've taken on my hatred of term.scroll() by now. Without it, we wouldn't need to buffer stuff within our terminal objects in the first place.
But since you
have a buffer, why not go ahead and implement setVisible() and redraw()? These functions are dead handy to have for the purposes of easily reducing flicker within render-heavy scripts!
