Log In  

I recently wrote the following routine to scale text:

--scales some text, used for title
function scale_text(text,tlx,tly,sx,sy,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


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...

P#42303 2017-07-09 22:17 ( Edited 2017-07-15 05:58)

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

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.

P#42304 2017-07-09 23:11 ( Edited 2017-07-10 03:13)

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!

P#42311 2017-07-10 08:53 ( Edited 2017-07-10 12:53)
:: Felice

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.

P#42495 2017-07-15 01:58 ( Edited 2017-07-15 06:03)

[Please log in to post a comment]

Follow Lexaloffle:        
Generated 2020-05-28 16:27 | 0.010s | 2097k | Q:15