2
\$\begingroup\$

SMILEBasic is a 3DS application that lets you run their own flavour of BASIC called SmileBASIC. It's a pretty cool language, and might have some potential for code-golf, but I don't think a lot. The issue in measuring its source-code stems from the fact that we don't know if SmileBASIC saves its programs in UTF-16 or UTF-8 (because they're saved somewhere within the SmileBASIC application's save-data).

This answer has a comment thread discussing SmileBASIC, and how to count the bytes. We see here that SmileBASIC certainly encodes at least displayed strings as UTF-16, but is that enough to say the source code is also in UTF-16?

Here we have a list of every single SmileBASIC instruction. You'll notice all of them are actually ascii, and don't utilise any of the extended symbols presented by the SmileBASIC UTF-16 encoding. Looking closer at the file instructions you'll see that SAVE (2) Saves a string variable to a text file actually saves in a UTF-8 encoding:

Format SAVE "TXT:File name", String variable
Arguments File name Name to save the file under (prefixed with "TXT:")
String variable String variable containing the text data to be saved (UTF-8)
Examples SAVE "TXT:MEMOFILE",TX$

So what should we measure SmileBASIC as? UTF-8 or UTF-16?

\$\endgroup\$
3
  • \$\begingroup\$ Can you not save your program anywhere, and look at the file size that way? \$\endgroup\$
    – Nathan Merrill
    Commented Jan 5, 2017 at 17:20
  • \$\begingroup\$ @NathanMerrill no, you don't have access to the ordinary filesystem. Just a sort of artificial jail. \$\endgroup\$
    – redstarcoder
    Commented Jan 5, 2017 at 17:21
  • \$\begingroup\$ You can view the file size from the menu, what are you talking about? I tried saving a file, and it's definitely 1 byte per ascii character. \$\endgroup\$
    – 12Me21
    Commented Feb 7, 2017 at 1:47

2 Answers 2

Reset to default
7
\$\begingroup\$

SmileBASIC programs should be scored as UTF-8

If SmileBASIC saves its strings as UTF-8, it only makes sense for it to also read in UTF-8 too. Also as its only option for writing strings to a file is UTF-8, I think it's safe to assume source-code is also saved as UTF-8. I believe SmileBASIC either converts any string it reads to UTF-16 before displaying it, or converts it to UTF-16 as the string is built, and back to UTF-8 when writing to a file.

As I don't think we have any way of proving if the files are encoded in UTF-8 or UTF-16 yet, I'll add this: UTF-16 makes SmileBASIC answers (which would already usually be pretty long) ludicrously long (you can see another example here) because SmileBASIC doesn't utilize UTF-16 for anything but displaying strings. If we can't prove either UTF-8 or UTF-16, I think UTF-8 is reasonable as it still probably won't make SmileBASIC super competetive, but at least it won't be completely outside of the realm of most competitions with UTF-16.

\$\endgroup\$
4
  • \$\begingroup\$ We do know that internally, all text characters are 2 bytes (not really UTF-16, a two-byte Unicode-like), but when saved to a text file they're UTF-8. We've done homebrew hax and memory dumping exploits and we're absolutely certain of this. Again, it's ONLY UTF-8 when it's a file. But I guess file size is the point of code golf, and not how much memory they occupy. I do agree with scoring as UTF-8 though, mostly because code becomes twice its size when you score it otherwise. \$\endgroup\$
    – snail_
    Commented Jan 7, 2017 at 20:09
  • \$\begingroup\$ @slackerSnail that's exactly what I thought it did (I'm glad I wasn't way off or something). Do you have a link of people proving it with homebrew so I can include it in my answer? \$\endgroup\$
    – redstarcoder
    Commented Jan 7, 2017 at 21:20
  • \$\begingroup\$ Here's a link to a raw TXT downloaded directly from the cloud servers. sbapi.shadowtech-dev.cf/raw/1DE453HV It has some headers and footers which I don't know the format of off the top of my head, but the rest is all UTF-8 text. Crack it open in a hex editor and it's plain to see. \$\endgroup\$
    – snail_
    Commented Jan 9, 2017 at 13:28
  • \$\begingroup\$ Should also probably be pointed out that the SB editor automatically adds LF when you load/save a file without one IIRC. \$\endgroup\$
    – snail_
    Commented Jan 9, 2017 at 13:46
0
\$\begingroup\$

SB uses UTF-8 for saving files, and UCS-2 for strings. The last line does not need to have a LF after it, so this should not be counted in the answer.

\$\endgroup\$
2
  • \$\begingroup\$ Do you have a source for this information? \$\endgroup\$
    – mbomb007
    Commented Jan 25, 2017 at 22:05
  • \$\begingroup\$ Just personal experience/testing: UTF-8: tested by saving files and checking the filesize UCS-2: tested by finding the highest character allowed in a string (65535) and checking the amount of memory used (2 bytes per character) LF: tested by removing it and checking if the program runs (it does) \$\endgroup\$
    – 12Me21
    Commented Jan 25, 2017 at 22:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .