Omnimaga
Calculator Community => TI Calculators => Lua => Topic started by: The_King on November 20, 2013, 08:34:22 pm
-
i just started this to know about new features of lua in os 3.6
-
We don't know for sure, otherwise we'd already have posted weeks ago ;)
Lua is no substitute for native code anyway.
-
Yeah I am curious about what OS 3.6 really adds in terms of Lua. Of course, I am pretty sure that speed won't be improved, though. >.<
-
Well, in fact, you can see already a few changes if you create a script with the new platform.apilevel (2.3) and dump _G (Lua's environment variable where "everything is").
For example, resources handlers etc.
These changes will be reflected by new features within the SDK (script editor in the computer software), though, so we'll have to wait for its release to actually see what's new...
Changes will be put on http://wiki.inspired-lua.org/Changes_in_OS_3.6 , by the way.
Of course, I am pretty sure that speed won't be improved, though. >.<
Images, in fact, are supposed to have been greatly improved (completely new system). I don't know about the rest. What's slow in Nspire-Lua is some graphing parts, not much else in fact.
-
Really? That's good then, but will it still be possible to set the program version to OS 3.1 or something?
Also, I wonder if image size will be greatly reduced?
-
Really? That's good then, but will it still be possible to set the program version to OS 3.1 or something?
Yep, that's still going to be possible. (and in fact, cross-version handling is now a fully-exposed feature within the SDK)
Also, I wonder if image size will be greatly reduced?
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
-
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)
-
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.
-
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?
-
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.
-
I wonder how are TI-Nspire Lua images compressed?
As of right now (before 3.6, then) : it's not much compressed, in fact : http://wiki.inspired-lua.org/TI.Image
-
That's still better than the HP Prime format DJ was talking about, though. Pixels as raw bitmaps aren't that bad, especially in a sprite-based engine.
-
The actual issue comes from the fact that the really long strings are directly put in the lua source file, and the editor becomes slow if there are several....