I recently wrote the following routine to scale text:
--scales some text, used for title
function scale_text(text,tlx,tly,sx,sy,col)
print(text,0,0,col)
for y=0,7 do
for x=0,#text*8-1 do
local col=pget(x,y)
if col!=0 then
local nx=x*sx+tlx
local ny=y*sy+tly
rectfill(nx,ny,nx+sx,ny+sy,col)
end
end
end
print(text,0,0,0)
end
|
However it depends on first printing the text to the screen.
I was trying to think of ways I could enable scaled text printing while other things are going on. Right now I just keep a black strip at the top of the screen of my current game so that I can scale text whenever I would like.
One idea I had was to create a table outside of Pico-8 that matches the Pico-8 font, and each row would be a single byte where every bit is a pixel, 8 bytes each for all characters in the font, then look up the correct bit when scaling each character, instead. Problem with that is the space it could use up, I guess.
I was kinda hoping the font would be in some kind of pseudo "system ROM" readable using PEEK, but I didn't see this listed in the memory map.
Another idea I had was to print every character, read the pixels and keep the data in a table. It'd be a sort of ugly "blip" of text right as the game starts up, though, but it might be so fast nobody would notice...
You can just do a cls() at the start of _draw, then print your text, pget it all, then cls() again and do what you normally want to do. It'll work fine. Try this in a blank cart. You'll see what I mean:
function _draw()
cls(12) --clear:blue
print("a",0,0,7) --text
c1=pget(0,0) --should be 7
c2=pget(1,1) --should be 12
cls() --clear again
print("c1="..c1,10,10,7)
print("c2="..c2,10,16,7)
end
|
I had it clear to blue, instead of just cls(), so you could see it doesn't do anything like cause a flicker or something like that.
Oh yeah! Dur. I should have realized this was possible...it's all drawn to a backbuffer first right? Nothing you drew shows up til _draw exits, correct? Thanks!
Also, if you're writing code that doesn't re-draw the screen every frame, for whatever reason, then you could first do a memcpy of the first five or six rows of vram to an offscreen ram location, write out your text to the top of the screen, make use of it, and then memcpy the saved bit back before the end of frame.
It's too bad there isn't a function, DRAWBUF(addr) or somesuch, that says where the drawing primitives write to, rather than hardcoding it to 0x6000. That would allow the sort of thing above without having to save/reload visible screen memory.
[Please log in to post a comment]



