Go Kerm, keep the good work!
About nspire lua compatibility, will include physics engine (3.2)?

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.

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.

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:

Code:

The following code prints an "a" on the screen:

Code:

*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

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?).

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.)

Is there a release of this yet?

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.

I don't object to camelCase, I use it in my lua code all the time.

I will be patient.

I was just wondering because I thought I saw someone post a luaZM demo, but now that I can't find it, it seems that it must have been a figment of my imagination. Sorry.

I think camel or Pascal case would be favorable. (My vote is Pascal case. Then camel case.)
I know you had a plan to do this, that's why I said
zmg.nametocolor("red") is taken right from your documentation. My point is that if we have a color class, it can go in there and be all encapsulated and stuff.
Well, everything in programming just boils down to numbers, so, yes, it would just boil down to numbers. Type safety is a good thing, though, and using a class (or table, or whatever Lua uses) is a more idealistic solution than just numbers or defines. That being said, I don't know how Lua is meant to handle these things. I would expect static objects in the class, but I don't even know if Lua has proper classes, in which class static defines in the namespace or something (clearly there's something like a namespace if you can do zmg.*). I'd even be willing to investigate and work on this if you want to work on something else. Is the code available somewhere for me? I promise I won't break it
I think that's a good point--do we want or/and/xor in something like this? Perhaps instead of returning the data, there can just be a function, like, getRect() or something that gets the data in the specified rectangle.

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.

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.

All this sounds great. Out of curiosity, what do you mean by a "string representation"? Shouldn't it be an array of colors? Or at the least an array of shorts.

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.

Oh, like in LuaFX? We pass sprites as string in LuaFX also.

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)

Ah, ok. Then I would expect to be able to pass around colors as strings as well in any function that takes colors (or if we go the color class route, have a constructor or static creator method that takes in a string).

Indeed. How about something like zmg.color.red and zmg.color.blue, though, vebveb? How hard would that be to create?

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.)