Before the most recent update, you could print anything below chr(32) and get an actual glyph in the output, aside from the obvious exceptions like \n and \t. For characters below chr(16) this is no longer possible, aside from chr(5), which I suspect is an oversight. In fact, that oversight is the "bug" that brought me here.
The thing is, this is a waste of 16 glyphs in the character set, and potentially up to 32 in the future if you add more control codes.
Can we get some kind of "raw" printing mode, where control character behaviors are completely ignored and their glyphs are simply printed?
Maybe turn the two oem/custom font selector characters into a single oem/custom toggle to free up chr(15), and use that as a raw-mode toggle, as in this pseudocode, where raw mode allows everything to be printed except the toggle itself, unless it is repeated:
fn print(s, ...)
raw = false
just_toggled_raw = false
for each char c in s
if c == raw_toggle then
if just_toggled_raw then
// escape the toggle
draw_glyph( c )
// remember if it was a lone toggle, forget if it was doubled to escape
just_toggled_raw = not just_toggled_raw
raw = not raw
else
just_toggled_raw = false
if raw then
draw_glyph( c )
else
...insert existing print code here... |
Apologies if I've missed some existing way to do this.
\> waste [...] potentially up to 32 [glyphs] in the future if you add more control codes.
Considering 0x18~0x1f are occupied by Japanese punctuation and dakuten/handakuten, there aren't many more printable characters that could still be sacrificed in favor of control codes, barring some wider p8scii redesign involving breaking changes.
It's more probable that new features get tacked on as additional options for \^.
Actually, instead of re-purposing \014 and \015 as Felice suggested above, another possible way to implement the requested "raw" printing mode would be to add it as a rendering mode option, i.e. ?"\^r raw on \^-r raw off"
\> aside from chr(5)
Hypothesis: you were testing by printing each character individually e.g. ?chr(5).
Out of all the control characters, only 0x5 displays as a glyph because it didn't get the two arguments it expected.
With a bit of finagling we can make 0x1~0x6 have insufficient arguments, so (on v0.2.2c) it is possible to kludge in these six as printable glyphs if they are really needed for some particular use case.
It'll still take an officially supported raw-mode to safely make full use of all 255 printable glyphs in a custom font (per the manual, character 0 is never drawn; 0x5f60~0x5f64 are used to encode font atributes)
Full details after the cart.
tl;dr: put a null char \0 immediately after the control character. This reliably prevents control characters from trying to ingest parameters. However, it also terminates the print command and will discard the rest of the string, if any.
Demo/Test Cart
Printing control characters seems to have different behaviors depending on various factors.
Four different contexts are implemented in this cart. Select from the menu to see differences.
Explanation / notes
Invalid params available
Depending on the control character in question, those which expect parameters to be supplied as subsequent character(s) in the string may have unexpected behaviors if those params are substituted by invalid characters.
-
0x0 terminates printing and discards rest of string (as documented)
-
0x8 0x9 0xa 0xd 0xf do not accept params and behave as expected
-
0x6 consumes invalid character and seem to silently ignore it (safe-ish)
-
0xe seems to behave like 0x0 and discards rest of string (unexpected)
-
0x1 0x2 0x3 0x4 0x5 0xb 0xc interpret invalid characters as a number for position/color/etc. Often but not always ==0; does not seem correlated with ord()
- 0x7 also interpret invalid characters somehow and play them as a sound, noticeably different from default beep
At end of string
Behavior is also inconsistent when character is the last in a string. Without null terminator '\0', PICO-8 print commands automatically append a new line and it appears that this new line is getting ingested by control characters as a parameter!
-
0x0 discards the appended new line (expected)
-
0x7 0x8 0x9 0xa 0xd 0xe 0xf leave the new line intact (expected)
-
0x1 0x2 0x6 0xc appear to ingest the new line with no noticeable impact (?)
-
0x3 0x4 seem to treat new line character as p0=0
-
0x5 is unusual as it will output the glyph in this situation, as noted by Felice. Because of insufficient arguments (it expects 2), it does not consume the new line.
- 0xb breaks, because in addition to param p0 for offset, it expects to print one character before restoring cursor position. The the cursor is thus left stuck in the "decoration" offset.
Null terminated
Terminating the print command with '\0' immediately after the control character delivers the most consistent behavior, as it ensures that control characters cannot ingest any subsequent characters as params.
-
15/16 control characters behave predictably "as expected". The one exception is 0xb: like in end of string case above, 0xb breaks and is stuck in the "decoration" offset.
-
Makes glyphs for chr(1) thru chr(6) show up, not just chr(5). Again, this is likely to be a side effect due to insufficient arguments.
- Kind of inconvenient to use but 'safely' gives 6 more usable printable glyphs.
Ah, good observation about how I was indeed printing single-character strings, and also subsequent work on checking out the options. It's nice that some of them can similarly be tricked into being printable.
But yeah, we need something better than a workaround.
As an aside, I think revising the font-select control code to be a toggle is still a good idea, regardless of what the freed code ends up doing. It's simply the case that having an "on" code and and "off" code really isn't necessary and it's quite likely that some oft-used code that's currently relegated to the multibyte \^? format might be more convenient to place there.
Personally, I would like to be able to have glyphs even for characters like '\t'. Visible tabs can be nice to distinguish from multi-space, in certain contexts.
Just so you know, you can edit config.txt and turn on visible tabs in the editor, at least.
Printing them as a visible character elsewhere would need this sort of "raw" print mode though, yes.
@Felice Yes, I do actually mean outside of the built-in editor. Had I known of the config.txt, I would have clarified that to begin with.
[Please log in to post a comment]
