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.
KermMartian wrote:
That means that I made a copy-and-paste error that I didn't notice.


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 Smile


EDIT:

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


Code:

--setup

--functions
local drawText = zmg.drawText
local keyMenu = zmg.keyMenu

--numbers
local x = 1
local y = 1
local key = 0
local keyUp = 28
local keyDown = 37
local keyRight = 27
local keyLeft = 38
local keyExit = 47

--Main loop

while key ~= keyExit do
drawText(x,y,"Move me with the arrows!", 0xFFFF, 0x0000)

key = keyMenu()

if key == keyUp then y = y-1
elseif key == keyDown then y = y+1
elseif key == keyLeft then x = x-1
elseif key == keyRight then x = x+1
end

end


You forgot the zmg.fastCopy() call, necessary to copy the VRAM to the LCD after you finish setting up a screen image.
KermMartian wrote:
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 Smile


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. Smile For the question you asked on IRC, turning an (R,G,B) color into a 16-bit 5-6-5 color:

Code:
bit32.lshift(bit32.rshift(R,3),11)+bit32.lshift(bit32.rshift(G,2),5)+bit32.rshift(B,3)

This assumes the input is R,G,B={0,255}. This code is untested, but should work.
KermMartian wrote:
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. Smile For the question you asked on IRC, turning an (R,G,B) color into a 16-bit 5-6-5 color:

Code:
bit32.lshift(bit32.rshift(R,3),11)+bit32.lshift(bit32.rshift(G,2),5)+bit32.rshift(B,3)

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


Usage example please?
Um, ok.

Code:
function makecolor(r,g,b)
    return bit32.lshift(bit32.rshift(r,3),11)+bit32.lshift(bit32.rshift(g,2),5)+bit32.rshift(b,3)
end

local white = makecolor(255,255,255)
local black = makecolor(0,0,0)
local orange = makecolor(255,200,10)

repeat
   zmg.drawText(math.random(0,200),math.random(0,200),"Hello World",orange,black)
   zmg.fastCopy()
until zmg.keyMenuFast() == 47
Oh, thank you, I didn't know it was that simple Smile
flyingfisch wrote:
Oh, thank you, I didn't know it was that simple Smile
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.
KermMartian wrote:

Code:
function makecolor(r,g,b)
    return bit32.lshift(bit32.rshift(r,3),11)+bit32.lshift(bit32.rshift(g,2),5)+bit32.rshift(b,3)
end

local white = makecolor(255,255,255)
local black = makecolor(0,0,0)
local orange = makecolor(255,200,10)

repeat
   zmg.drawText(math.random(0,200),math.random(0,200),"Hello World",orange,black)
   zmg.fastCopy()
until zmg.keyMenuFast() == 47


I changed this to make this:

Code:
function makecolor(r,g,b)
    return bit32.lshift(bit32.rshift(r,3),11)+bit32.lshift(bit32.rshift(g,2),5)+bit32.rshift(b,3)
end

local white = makecolor(255,255,255)
local black = makecolor(0,0,0)


repeat
local orange = makecolor(math.random(1,255),math.random(1,255),math.random(1,255))
   zmg.drawText(math.random(0,312),math.random(0,312),"VIRUS!",orange,black)
   zmg.fastCopy()
until zmg.keyMenuFast() == 47

You could use it to freak people out. Razz
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?
Ashbad wrote:
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?


KermMartian wrote:
flyingfisch wrote:
Oh, thank you, I didn't know it was that simple Smile
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.


Indeed, it would be much faster to implement in C rather than invoking 5 function calls plus the one wrapper function call. Smile
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.

Quote:
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.


Why does using a config file require execution of other addins? I must be missing something.
Ashbad wrote:
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)
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.

Quote:
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?
It already does.

Quote:
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.
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. Smile

Quote:
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.
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. Smile

Quote:
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.
Thanks! Which one(s) did you have in mind?

Quote:
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.
I requested that weeks ago in the PrizmIO topic, but Juju has been busy.

Quote:
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.
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.
juju2143 wrote:
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:

local drawRectFill = zmg.drawRectFill
local fastCopy = zmg.fastCopy
local keyMenuFast = zmg.keyMenuFast

local keyExit = 47
local keyUp = 28
local keyDown = 37
local keyLeft = 38
local keyRight = 27

function makecolor(r,g,b)
    return bit32.lshift(bit32.rshift(r,3),11)+bit32.lshift(bit32.rshift(g,2),5)+bit32.rshift(b,3)
end

local color = makecolor(0,0,0)
local angle = 0
local i = 1
local width = 100
local height = 100

--main loop
while keyMenuFast() ~= keyExit do

   local red = 20 * math.sin(angle) + 20
   local green = 10 * math.cos(angle) + 20
   local blue = 50 + 30 * math.cos(angle)


   color = makecolor(red,green,blue)
   drawRectFill(0,0,width,height,color)
   
   if keyMenuFast == keyUp and height > 0 then height = height-1
      elseif keyMenuFast == keyDown then height = height+1
      elseif keyMenuFast == keyLeft and width > 0 then width = width-1
      elseif keyMenuFast == keyRight then width = width+1
   end


   angle = angle + i
   if angle == 150 then i = -1
      elseif angle == 0 then i = 1
   end
   fastCopy()
end



The only key that is respected is [exit].

EDIT3:

I should have done keyMenuFast() = blah.

keyMenuFast works fine.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 6
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement