[Prizm] Introducing LuaZM

[helder7]

Go Kerm, keep the good work!
About nspire lua compatibility, will include physics engine (3.2)?
_________________
SiO2 + CaCO3 ----------> CaSiO3 + CO2

[KermMartian]

To back up your vsnprintf example, in trying to pull in libc's code, I needed about 10 different files, and about 20 other dependencies that I pulled select pieces of code from to avoid having to pull in even more dependencies. There were general set/long jmp headers, SH-specific ones, SH4-specific ones, sysdep, the SH sysdep, and much more. The same thing happened when I tried to pull in a tiny piece of the locale system, only to throw up my hands five hours later and hard-code the locale.
_________________

[vebveb]

Yes, but we could just take some parts of the code to use specific features. For example we'll need an implementation of the %f %g %e options for printf, and as I said in an other topic, we can find it in glibc sources.

[KermMartian]

True. Thanks to vebveb's help and AHelper's careful reading, we tracked down a bug in libfxcg slash the Prizm's memcmp() implementation, wherein it returns 1 instead of 0 for matching strings. Now the following code works perfectly:

[KermMartian]

*bump* To keep you all updated, the zmg library continues, and I continue to debug running lua scripts from disk. Currently, something with fopen/fread is going wonky. Also, documentation:

http://prizm.cemetech.net/index.php?title=LuaZM_Reference
_________________

[merthsoft]

I have a couple things to talk about. One is naming. I think all-lowercase-naming is a pretty bad idea. I think Pascal case is the way to go: zmg.DrawLine(), zmg.CopySpriteMask(), etc. This will make it easier to read. I'd also be OK with camel case or even underscores, just so long as there's something to separate the words and make reading it faster.

I notice that for colors it's a number. Is it possible to have a color class instead? I think that would make the most sense, especially since we have the color constants right now (shamelessly dumped from the C# color definitions). And then people can do zmg.Color.Red (or however it would look). If we want to take a cue from C# we can even do a Color.FromName(string) in place of something like zmg.nametocolor("red"). There could be a couple constructors, one that just takes in an int16, and one that takes in the RGB values individually.

As I mentioned in IRC, whether the function clips or not should be an optional parameter at the end of all the graphics calls. It should probably default to True.

The sprites should just be a DrawSprite, and then pass in logic (I assume there are enums): copy, xor, and, or, whatever. This could also be optional with the default as probably copy. And possibly include an optional mask param so that function is also wrapped into this one (though I'm not 100% on that--is masking distinct enough to be its own thing?).
_________________
Shaun

[Deep Thought]

In case you're wondering (on the topic of case in function names), on the Nspire there are two forms. The standard Lua functions are all-lowercase (according to the Lua spec), but TI's official functions are all in camelCase (for example, in the extended Lua library).

So if you move away from the usual all-lowercase function names, you could use camelCase to add readability while making it still feel close to the Nspire Lua interpreter.

(All class names on the Nspire are in PascalCase, by the way.)
_________________

[flyingfisch]

Is there a release of this yet?
_________________

[KermMartian]

Shaun and Deep Thought: I had made my function names (or are they methods?) all lowercase as per the Lua convention, but I personally prefer camelCase or some other distinctive casing. I would be happy to switch to camelCase, as long as no one objects.

Shaun:
:: As you may note in the zmg.drawcolor() documentation, I did indeed plan to have at least a function to take a color name like "red" and turn it into the requisite number. A zmg.color.* (table? I really need to get the nomenclature down) would be even better, I think, but those would still just boil down to numbers.
:: Actually, I'm not even convinced that there's value in having routines to or/and/xor on a color screen; it might be better to just offer overwriting or masking as the two options. I wonder if there's value in returning a string of the old contents of the area for easy restoration, at least in one version.

Edit: Flyingfisch: No. Be patient.
_________________

[flyingfisch]

[merthsoft]

[vebveb]

Well, you can put many names to call the same function: a name in lowercase, a name in camelCase and a name in Pascal case.

[KermMartian]

That's true, but we should think of a primary casing for consistency and documentation. I went with camelCase, and updated both the code and the reference page accordingly.

Shaun: I removed the xor routine and made copySprite do clipping. I think I will keep copySpriteMask a separate routine for now, but also add clipping for that. And I agree that two VRAM-reading functions are needed: one to read the color of a single pixel (a la pxlTest() ) and one to read out a string representing a rectangular area that could by copySprite'd back to the LCD.

Regarding troubles opening Lua files on-calc: fgetc was broken. A fix is pending in libfxcg/libc from AHelper.
_________________

[merthsoft]

[KermMartian]

Well, sprites are going to be passed in as ASCII-encoded hex, like "F5008704..." etc. It makes sense to spit out strings like that, too, so that they can easily be passed back in.
_________________

[flyingfisch]

[vebveb]

It is because it's the type that uses the less memory and because it is easy to read a lua string in C (tables are difficult to read for example)

[merthsoft]

[KermMartian]

[AHelper]

KermM, I have a serialized sprite format that can contains multiple variable-sized sprites (with meta-data), compressed using LZ77. I can send you the specs to the format, the file parser, and PC build tools for it If you are going to have large sprites, then you would have very large character strings (Not saying to replace, just another option.)
_________________
°ᴥ° Get Lucky

<BrandonW> "You don't even want to know what TI Connect does when it's just detecting your calculator...It ACTUALLY ERASES THE SWAP SECTOR on every communication attempt...EVERY SINGLE ATTEMPT...Yes, TI Connect will kill your calculator..What do I have to do to get your attention?!....Such a bloated protocol."