Oh ok.


Also, in the docs, the example for zmg.keyMenu() and zmg.keyMenuFast() is zmg.fastKeyMenu().

What does that mean?

That means that I made a copy-and-paste error that I didn't notice. Anyway, I also added a keycode reference to the LuaZM reference page.

Ahh, ok, i thought that keyMenu and keyMenuFast were the same functions and the difference was the input you gave fastKeyMenu.

Ok, thanks for the clarification


EDIT:

Is this a bug, or is it just bad coding on my part? It loops forever without displaying any text:


Code:

You forgot the zmg.fastCopy() call, necessary to copy the VRAM to the LCD after you finish setting up a screen image.

Oh, duh thanks


So fastCopy and LuaFX's refresh sound like the same thing...


EDIT:

hmm... it displays text now but I can not move the text with the arrows. Problem with keyMenu?

Also, why is keyMenu not called getKey?

Did you resolve your keyMenu problems? If not, see if keyMenuFast() works better for you. There's no particular reason it's not called getKey. For the question you asked on IRC, turning an (R,G,B) color into a 16-bit 5-6-5 color:

Code:

This assumes the input is R,G,B={0,255}. This code is untested, but should work.

Usage example please?

Um, ok.

Code:

Oh, thank you, I didn't know it was that simple

Just as an FYI, I should add this function to LuaZM, plus a function to turn color names like "red" into proper color codes. Actually, it will probably be the same function, just assume strings for 1 argument and integers for 3 arguments.

keyMenuFast works. keyMenu doesnt seem to though.

I changed this to make this:

Code:

You could use it to freak people out.

Perhaps adding the makecolor routine you made there to be a native function part of the zmg set of routines would be beneficial to speed and space, also due to its usefulness?

Indeed, it would be much faster to implement in C rather than invoking 5 function calls plus the one wrapper function call.

Some remarks after finally going through the docs:

zmg.copySprite(): The fact it takes all data as 4-character hexadecimal digits is a bit... space killing. It'd be nice if you could add support for loading something like surfaces from rc files or have a feature for SC2.5 that has a Lua output in direct byte values for sprites in RGB565, and have a zmg.copySpriteC (C standing for Compressed) that took the compressed input equivalents (just a rough idea, of course this idea would have to be further thought out to come up with a way to make it work -- RC files sounds like the best path)

zmg.keyDirectPoll(): Perhaps before the execution of LuaZM programs, have this run twice to fill up the buffer with 0-bits, or even better just fill up the buffer with 0-bits directly, before execution?

zmg.keyDirect(): To be honest the current return values work, but it'd be nice if you had constants for them (0 == zmg.key_noEvent, 1 == zmg.key_Release, 2 == zmg.key_Tap, 3 == zmg.key_Held) -- since having magic numbers represent "polling periods" sounds alien to most people who don't get how the polling system works, but events like "just released", "just tapped", "been held down", and "no events" are a lot more explanatory.

Keycodes: Would be nice if you have constants for them (zmg.KEY_PRGM_MENU, zmg.KEY_PRGM_F1, etc.) since magic numbers aren't the most fun thing to work with and while figuring out the keycodes on the fly from their logical organization isn't hard, having constants would make it so much easier and efficient for programmers.


On the inclusion of more useful routines for the zmg library: I'd love to help you convert some of them if you want the help.


On the console: agreed with Gbl08ma, would definitely benefit from having a blinking cursor, perhaps one that also showed the current alpha-case and whether or not shift is held down. Unless of course, this is PrizmIO's fault, in which case Juju should read and consider this.


And, while it's not possible right now, in the future when we have learned how to execute add-ins from other add-ins, it'd be nice to have a feature where you could store some run options for LuaZM (such as no console, run a specific script, exit upon running said script, allow file access to only a certain directory set, etc.) in a standard file that would be read/deleted each time LuaZM ran; LuaZM would execute said options/scripts, and return control to the other add-in. Of course, this is a rough idea, and not even possible at the moment, just some brain candy.

Don't see myself being able to use LuaZM for anything too serious at this point, but I'm sure that'll be a void statement in a month or two at the rate you're working this. Awesome stuff, coolest Prizm Project yet.

For the sprites, again, I have a sprite format that works well.



Why does using a config file require execution of other addins? I must be missing something.

LuaFX just embeds the binary directly in the text file, which I don't think is a good idea. Base-64 encoding would help reduce some of the size.

It already does.

Well, that is of course what it is, but I wanted to use more precise language. You're welcome to edit the Wiki as you see fit.

It would, but it would be quite slow. I'd prefer to leave it as constants for now; if TI-BASIC programmers can deal with it, Prizm LuaZM programmers can deal with it.

Thanks! Which one(s) did you have in mind?

I requested that weeks ago in the PrizmIO topic, but Juju has been busy.

Many thanks; I look forward to see what people create! What do you currently see missing that's stopping you from using it for anything serious?

Yeah, I've been pretty busy last week, I should get stuff fixed this week, hopefully.

Excellent, I looks forward to your progress. As far as my requests go, different modifier behavior and a visible cursor (which shows the current modifier mode) are at the top of my list.

Is there a wait() function yet?

EDIT:

Also, how do I convert Unix Epoch Time to an easier to use format? i.e. "2012-09-10 13:00:00"

EDIT2: seems there are real problems with the keyMenu functions.


Code:


The only key that is respected is [exit].

EDIT3:

I should have done keyMenuFast() = blah.

keyMenuFast works fine.