Log In  

As I'm discovering you can use variable names such as 🅾️ and ❎ I ran into this little snag when debugging in immediate mode. Try out this code:

function _init()
end
function _update()
  ⬅️=btn(0)
  ➡️=btn(1)
  ⬆️=btn(2)
  ⬇️=btn(3)
  🅾️=btn(4)
  ❎=btn(5)
  cls()
  ?⬅️
  ?➡️
  ?⬆️
  ?⬇️
  ?🅾️
  ?❎
end

Now while running hold the DOWN ARROW key and press the ESC key.

Now type: print ⬇️ ENTER

Result is TRUE, which is correct.

Now type: print ⬆️ ENTER

Result is 2 which is INCORRECT. It just stated above it was FALSE.

I realize that these variables are initialized when you run your program to make it convenient for btn(⬆️) to see if it's TRUE or FALSE, however as they are not system variables and are free for the taking, this reinstating integer values into them without your say so should not be taking place unless you rerun your code again.

P#106336 2022-02-04 19:57 ( Edited 2022-02-05 00:26)

EDIT: Ignore this, I misunderstood. Read what dw said below and my response to him.


I just ran your test code, held ⬆️, pressed esc, then printed ⬆️, and it worked as you want it to:

Are you using the current version?

P#106343 2022-02-04 22:26 ( Edited 2022-02-04 23:04)
1

Nono @Felice. You want to print out the value of a button you DIDN'T hit, and it should be FALSE, not numeric. Sorry I didn't clarify that earlier. The error appears on a button you didn't hit.

P#106346 2022-02-04 22:30 ( Edited 2022-02-04 22:31)

Oh, I see what you meant now, @dw817. Yeah, agreed, it does do what you say. That's just weird, because it's clearly being set.

Wait, maybe there's a check that always runs to make sure they're set... lemme try something...

function _update()
  ⬅️=nil    -- not truthy
  ➡️=false  -- not truthy
  ⬆️=true   -- literally true
  ⬇️=123    -- number is truthy
  🅾️="str"  -- string is truthy
  ❎=cls    -- func   is truthy
  cls()
  print(⬅️)
  print(➡️)
  print(⬆️)
  print(⬇️)
  print(🅾️)
  print(❎)
end

Produces this:

Notice the non-truthy ones are the ones that get set to their numeric versions.

Actually, I just checked a few other special characters, like ♥ and 😐. They all get reset if they're non-truthy.

I bet when the command line is started, it has code like this in it:

  if(not ⬅️) ⬅️=0
  if(not ➡️) ➡️=1
  if(not ⬆️) ⬆️=2
  if(not ⬇️) ⬇️=3
  if(not 🅾️) 🅾️=4
  if(not ❎) ❎=5
  -- etc.

And that's why only the non-truthy ones get reset.

I'm sure it's meant to be a useful thing that restores defaults, but it feels very much like a misfeature that interferes with debuggability and needs to be fixed.

P#106350 2022-02-04 23:01 ( Edited 2022-02-04 23:07)

Hmm, I hadn't tried testing the glyph values as true or false like this, but I will say that their behavior enables some interesting uses. Specifically, they can be useful for tweetcarts since they can set variables to large values in minimal characters, or they can be used to create a variable with an initial value, while avoiding the need for a separate initialization step.

P#106352 2022-02-04 23:19 ( Edited 2022-02-04 23:21)
1
1

Interesting what you have there, @merwok.

@Felice, yep I think it's an error too.

Well be careful with tweets, @JadeLombax..

I recently found for instance this: ⬇️😐 while it pastes okay to TWITTER, if you copy from the posted message in Twitter to clipboard and paste direct to Pico-8 source-code it comes back as the following:

Downwards arrowNeutral face

Text, no symbols.

I discovered that HERE:

https://twitter.com/von_rostock/status/1488663216410529792

Which unfortunately I believe is an error in TWITTER, Not Pico-8, So until this is fixed I'm just gonna use 6-bit text for my tweets.

All you guys out there using these special characters in your tweets be aware they CANNOT be pasted back to Pico-8 normally. Please stick with 6-bit data until ... something is resolved.

P#106359 2022-02-05 00:04 ( Edited 2022-02-05 00:12)

Yeah, I agree, Twitter is really screwing up emoji copy/paste. I almost wonder if they're doing it on purpose, for some reason. Make it harder to copy "their" content off-site, maybe? I dunno. It sure is annoying. But that's OT I guess.

P#106370 2022-02-05 02:19 ( Edited 2022-02-05 02:19)

@dw817,

Yeah, I know some glyphs do that, it's annoying. I've mainly just been using the birds glyph in my tweets because it doesn't have that issue and it only counts as one character. In general you can use most of Pico-8's character set, though you need to use Puny Font Mode to correctly paste the small caps characters.

P#106397 2022-02-05 20:54 ( Edited 2022-02-05 20:56)

AFAIK Twitter and similar sites convert unicode symbols for performance issues. They want the client to use their font, which means it has to be downloaded. Downloading a font with full unicode support takes a long time, so it's way more efficient to make the client download a font without emoji and download each emoji as a custom image separately.

P#111664 2022-05-11 09:21

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-03-28 22:40:46 | 0.041s | Q:27