So if you have caps lock on or hold shift and start typing in the search bar it uses a 3x4 font! I'm guessing zep tried out other font sizes or tried having 3x5 for uppercase and 3x4 for lowercase or something, and some weird loophole means it accidentally uses the small font for uppercase characters but only in the search bar.
You can print those from your games using escape codes - they're in the ASCII lower case letters slots. There's also some odd symbol in 127 and some double-width dingbats in 128 through 153. Here's a code snippet to print all the graphic characters, with a break between the lower and upper halves
print("\32\33\34\35\36\37\38\39\40\41\42\43\44\45\46\47\48\49\50\51\52\53\54\55\56\57\58\59\60\61\62\63") print("\64\65\66\67\68\69\70\71\72\73\74\75\76\77\78\79\80\81\82\83\84\85\86\87\88\89\90\91\92\93\94\95") print("\96\97\98\99\100\101\102\103\104\105\106\107\108\109\110\111\112\113\114\115\116\117\118\119\120\121\122\123\124\125\126\127") print("") print("\128\129\130\131\132\133\134\135\136\137\138\139\140\141\142\143") print("\144\145\146\147\148\149\150\151\152\153")
Alternatively, I threw this together:
I just found these smallcaps by accident. I wrote some code to allow easier upper/lower encoding, since the capslock editor trick doesn't work anymore and typing '\65' for 'a' is a pain.
function smallcaps(s) local d="" local l,c,t=false,false for i=1,#s do local a=sub(s,i,i) if a=="^" then if(c) d=d..a c=not c elseif a=="~" then if(t) d=d..a t,l=not t,not l else if c==l and a>="a" and a<="z" then for j=1,26 do if a==sub("abcdefghijklmnopqrstuvwxyz",j,j) then a=sub("\65\66\67\68\69\70\71\72\73\74\75\76\77\78\79\80\81\82\83\84\85\86\87\88\89\90\91\92",j,j) break end end end d=d..a c,t=false,false end end return d end
Basically, caret shifts the next character and tilde toggles capslock.
Capslock works windows-style, where shift-alpha gives lowercase when capslock is on.
This does cost 113 tokens. Obviously, if you're low on tokens, then you'd want to go the '\65' way. That, or you could remove a feature or two, maybe take out either the single-letter escape or the toggle, take out the option to escape them, and remove the early-exit from the smallcaser. With just the caret escape, no way to escape the caret itself, and reduced performance, it costs 67 tokens:
function smallcaps(s) local d="" local c for i=1,#s do local a=sub(s,i,i) if a!="^" then if not c then for j=1,26 do if a==sub("abcdefghijklmnopqrstuvwxyz",j,j) then a=sub("\65\66\67\68\69\70\71\72\73\74\75\76\77\78\79\80\81\82\83\84\85\86\87\88\89\90\91\92",j,j) end end end d=d..a c=true end c=not c end return d end
Also this obviously only works for English. Someone with a clue would need to expand the translation strings for the extended charset.
it seems zep only swapped the characters cases when drawing his font.
you can edit your p8 outside of pico (I'm using notepad++ with lua syntax highlighting)
pICO outside -> Pico inside
edit: I was mistaken: the source code is all lowercased as soon as you edit it inside pico, be it code or strings.
so yes, you need escape codes.
lower case as ascii (lua reserved word are lower case), displayed as upper in the editor
well, that's where the real experience is! I always start there but I tend to get claustrophobic after a thousand lines... I've paid the price though, like drawing sprites, forget to save, edit code outside, reload in pico, sprites gone. I know I'm taking a walk on the wild side ^^
I wish labels were also saved in plain text p8 though.
Hey, I just found this "problem" while testing the sublime-PICO-8 plugin for the Sublime Text.
^Look on the last screenshot
i'm with you, I'd rather not have to deal with those character case shenanigans. my comment was more about being coherent.
a few thoughts though:
1.0 is far away, breaking cart compatibility could (should?) happen at some point. cart sources are available, anybody can adapt old carts even if the original author is not around any more. also older html exports will still work on their own.
on topic, facts I'm aware of:
(1) lua is case sensitive + reserved words are lower case (AND is an acceptable variable name)
(2) you're editing code in 128*128
(3) uppercase is 3x5, lowercase is 3x4
(4) pico8's font has lowercase/uppercase reversed
(5) shift+LRUDOX are now glyphs in the editor
(2)+(3) may make code mostly unreadable, so (I think) zep decided everything should be uppercased for readability (or some kind of retro feeling?). but (1) led to (4), which is arguably a bad choice. code could be uppercased in the editor, lowercased at lua compilation, and strings left alone. also (5) is a pita because I'm shifting keys inadvertently from time to time
BUT, I don't know of hardware running pico that hasn't a display capable of at least 256x256. pocketchip is 480x272. what's on your pi ? 800×480 ?! use those pixels on the devkit part of pico8! the worst case (320x200?) would still offer a better experience. 'worstest' case, fallback to current state. once upon a time on my amstrad cpc 464 I would edit code in 640x200, if my memory serves me well (mode 2). even at 320x200, I still had lowercase...
rant mode:off ;)
Or... I dunno... since PICO isn't even "0.2" yet, this might just be an ordinary part of the feature set that isn't fully implemented right now. I mean, you can already use the button glyphs that are part of the expanded set. No reason to believe the same method wouldn't /eventually/ allow you to access the other doublewides.
Plus, defaulting to caps makes sense when you're doing case-sensitive coding. This keeps all of your functions uppercase, which makes them all easier to create.
Give zep some time to make this thing!
I was fiddling around with drawing arrows using the weird character was talking about and it turns out if you copy and paste anything between '\128' and '\153' the symbol is pasted instead of the \ and the number... Handy for saving 3 tokens I guess! Also holding shift and pressing keys in the editor gets these weird symbols text instead of letters, I keep doing it by accident when trying to camel case variable names
I hated that unexpected shift thing enough that I made an autohotkey script to convert all A-Z keypresses to a-z.
Also I think the thing where you paste \128 and up and get the actual character is a bug. It's true you'd save three characters of source code space, though tokens as shown in the editor (x/8192) are compiled code, so either way it's the same.
In fact, I seem to recall an entire string is just one token, since there's just one token that references the entire static string, rather than one token representing each character.
[Please log in to post a comment]