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.
I've also noticed that capital filenames appear as smaller letters when using 'ls' or 'dir'
There's another font in there too, if you enable FPS display in the config file you can see it. I'm not sure if it can be hooked somehow to be usable in games though.
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 noticed that bug in the find feature before, but I didn't know you could use those characters! :P IT'S SO CUTE AND TINY.
Heh, yeah... This is the sort of thing that everyone might've noticed at one point or another, but never really thought to point out or investigate putting to actual use. mmmm...
Here are the extended / wide characters
Sweet, thanks for expanding all those out. There's enough special characters to make a game using just print() and no sprites at all, ha!
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
|
Usage example:
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
For some reason, I have the most fun editing right inside PICO-8. The instant-on, fully-encapsulated environment appeals to my younger self. :)
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.
https://github.com/Neko250/sublime-PICO-8/issues/3
^Look on the last screenshot
@felipebueno: this gets fixed as soon as you enter pico-8's code editor.
zep, you should scan the code for uppercases right at load.
This is really cool, I love all the little contributions that came together to make this possible
@Felice that's a great way of doing it, thanks!
@ultrabrite
or zep could just stop mangling your code when you open it in the built in editor.
Because forcing lowercase on load would break older carts
@gamax92:
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!
@Felice: Thanks for your handy smallcaps() function.
However, I've just seen it has a small bug, where you've accidentally put "\80" instead of "\90".
Was interesting when I tried to eat a slice of "pippa"! :D
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.
With the new chr() and ord() functions the smallcaps function becomes trivial, and quite small. (only 143 chars with all possible whitespace removed)
function smallcaps(s) local t="" for i=1,#s do local g=sub(s,i,i) local c=ord(g) if c>96 and c<123 then t..=chr(c-32) else t..=g end end return t end |
Note that ord() accepts a second argument, avoiding the need for sub():
function smallcaps(s)
local t=""
for i=1,#s do
local c=ord(s,i)
t..=chr(c>96 and c<123 and c-32 or c)
end
return t
end
|
[Please log in to post a comment]
