I've made a almost-100%-smooth scrolling engine for a game I wanted to make... it worked pretty well but the game I wanted to make (jumping arcade game, with buildings scrolling, and the character had not to fall between the randomly generated buildings) didn't get really far, so....

Maybe I can find some scrolling functions I have in my backups ... %)

It's probably a meta method, and is probably not ment to be used in normal scripts

Well, my guess is that the variable doesn't do error checking, and triggers a reset/crash when invalid parameters are passed.

Does TI utilize LuaJIT (not sure if the ARM port is compatible with this processor) ?

Okay, I can't find my Nspire, and I've yet to update it to 3.0, so if any one can run the following code for me, that would be wonderful.

local function test(...)
    if arg then
         print("Lua") -- might have to replace print() with a graphics API call, I haven't use it yet
    else
         print("LuaJIT");
    end
end

test(1, true, 'cool');

LuaJIT handles variable argument functions differently than normal Lua, which is why the above would discern the two.
Sorry, but I don't know the graphics API, as I said, I've yet to start messing around 

Also, did TI keep the loadstring() function, or did they clear that out for security reasons ?
If they kept it, it opens the doors for at least one potential exploit, and the possibility of optimized Lua assembly (though TI-Basic is still probably faster)

Good, TI finally made a smart decision.  
LuaJIT is insanely fast compared to normal Lua.

Can you explain a little bit more (as you're there )

Having "..." as a function parameter will cause that function to accept any number of inputs.
Lua 5.0.* (I think) was the last version to official support converting of variable arguments into a table which is automatically localized (the 'arg' variable).
Lua 5.1.4 has compatibility with this feature, LuaJIT does not by default (I think you can enable it).

While this is good news for speed, it's bad news for the one exploit I mentioned, as LuaJIT uses a different bytecode format, and the exploit probably isn't viable.
Not to mention I've been working on a complex Lua assembler for other things and when I saw NSpire 3 uses Lua I got excited, but I guess that won't be of much use here  :'(

TI does not use LuaJIT:
* the first optimized ARM release occurred months after TI started working on Lua in the Nspire OS 3.x;
* LuaJIT is likely to have fixes for the Lua 5.1.4 bugs, while TI's implementation in OS 3.0.1.1753 remained unfixed, see http://ourl.ca/10472 .
Even with a JIT, Lua would remain very far from being a substitute to native code, in terms of both power (expressiveness) and speed.

Some people have expressed worries that if we get native code access (which is perfectly in our right to use the hardware we bought the way we see fit) through Lua, the anti-programmation subset of the management at TI would shut the door on Lua.
But more than four months into Lua programming on the Nspire, and after the making of many programs that dramatically improve the functionality of the Nspire for both educational and gaming uses, it's probably way too late to do that, though... unless they're crazy enough to go the Sony way, and motivate reverse-engineering with a goal of revenge and ghastly attacks on the business model...