Calculator Community > Lua

new in 3.6

<< < (2/3) > >>

Adriweb:

--- Quote from: DJ Omnimaga on November 21, 2013, 02:19:16 am ---Really? That's good then, but will it still be possible to set the program version to OS 3.1 or something?
--- End quote ---
Yep, that's still going to be possible. (and in fact, cross-version handling is now a fully-exposed feature within the SDK)


--- Quote from: DJ Omnimaga on November 21, 2013, 02:19:16 am ---Also, I wonder if image size will be greatly reduced?
--- End quote ---
I haven't tried yet, but that's highly possible though, with the new thing :) (Could it be worse anyway ? :P)

We'll see :P

DJ Omnimaga:
It can't be worse than HP Prime image data for sure... (one pixel is made of four hex characters and programs use UTF-16. Add to that the fact that the string of hexadecimal characters is broken into 64-bit chunks separated by commas, and this pretty much gives you an idea of how massive just a 16x16 sprite can be)

willrandship:
That gives a nice convenience tradeoff, though. The only reasonable change I can think of for that without making some kind of converter would be to switch to UTF-8 or plain ASCII.

DJ Omnimaga:
I think the UTF-16 was so that we can use as many special chars as possible in our HP PPL programs, ranging from Chinese chars to even shapes and small images (smileys, spades, etc), so many that you could basically design a game off those chars and people would think you used sprites. However, literally every bit of code grows to ridiculous file sizes as a result (such as my 4 KB Tunnel game)

I wonder how are TI-Nspire Lua images compressed?

willrandship:
UTF-8 has the full range of characters that UTF-16 provides. Special characters are larger, but normal Latin characters are only 1 byte each. UTF-16 is almost always 2 bytes per character, with only the most obscure character sets taking more. UTF-32 is ALWAYS 4 bytes.

All 3 have the same base character range, 4 bytes worth of individual characters. However, the worst case sizes are:

UTF-8: 4 or 6, depending on the standard used. (6 if using the pre-2003 standard, but 4 reduces the theoretical size)
UTF-16: 4 bytes, but the implementation makes this 4 have more chars available
UTF-32: 4 bytes (exact)

The best case, on the other hand, is much more telling:

UTF-8: 1 byte
UTF-16: 2 bytes
UTF-32: 4 bytes

Keep in mind, the unicode character set is far from full. The set is laid out sparsely, with several large gaps. The slight lackings in UTF-8 fall in these areas, giving it full access to all characters.

UTF-8 is used when dealing with memory constraints, and also when using common sense. It's also the newest standard. The primary disadvantages lie in problems with measuring length.
UTF-16 is the "old" way, having been around the longest of any Unicode standard, in many forms.
UTF-32 is nice for slow 32 bit systems, since it is straightforward to interpret. However, usually memory constraints outweigh this.

Navigation

[0] Message Index

[#] Next page

[*] Previous page