(1) There is no wait function. You could put ticks() in a loop if you want a timed wait, or use keyMenu() to pause until any key is pressed.
(2) There are formulae for that out on the internet. I don't know any of those off the top of my head.
(3) Are you using v0.1 or v0.1.1? If just 0.1, upgrade ASAP. It fixes keyMenu() and adds the makeColor() function directly in ZMG.
KermMartian wrote:
(1) There is no wait function. You could put ticks() in a loop if you want a timed wait, or use keyMenu() to pause until any key is pressed.

OK, thanks Smile

Quote:

(2) There are formulae for that out on the internet. I don't know any of those off the top of my head.

I checked, nothing in lua.

Quote:

(3) Are you using v0.1 or v0.1.1? If just 0.1, upgrade ASAP. It fixes keyMenu() and adds the makeColor() function directly in ZMG.


Ah, OK, will do right now Smile
flyingfisch wrote:
Quote:

(2) There are formulae for that out on the internet. I don't know any of those off the top of my head.

I checked, nothing in lua.
Well no, I wouldn't expect so, but I'm sure there are general algorithms or Java or C or Python code that you could easily port. Smile
KermMartian wrote:
flyingfisch wrote:
Quote:

(2) There are formulae for that out on the internet. I don't know any of those off the top of my head.

I checked, nothing in lua.
Well no, I wouldn't expect so, but I'm sure there are general algorithms or Java or C or Python code that you could easily port. Smile


Oh, ok will check Smile
The first answer in this StackOverflow thread seems like a decent solution to me:
http://stackoverflow.com/questions/1692184/converting-epoch-time-to-real-date-time
Would this be a good port?

C++ code:

Code:

void DateTime::splitTicks(time_t time) {
    seconds = time % 60;
    time /= 60;
    minutes = time % 60;
    time /= 60;
    hours = time % 24;
    time /= 24;

    year = DateTime::reduceDaysToYear(time);
    month = DateTime::reduceDaysToMonths(time,year);
    day = int(time);
}

int DateTime::reduceDaysToYear(time_t &days) {
    int year;
    for (year=1970;days>daysInYear(year);year++) {
        days -= daysInYear(year);
    }
    return year;
}

int DateTime::reduceDaysToMonths(time_t &days,int year) {
    int month;
    for (month=0;days>daysInMonth(month,year);month++)
        days -= daysInMonth(month,year);
    return month;
}





Lua Code:

Code:

function splitTicks( time_t, time )
   seconds = time % 60
   time = time / 60
   minutes = time % 60
   time = time / 60
   hours = time % 24
   time = time / 24
   
   year = reduceDaysToYear( time )
   month = reduceDaysToMonths( time, year )
   day = math.floor( time )
end

function reduceDaysToYear( time_t, days )
   math.floor( year )
   for year=1970, daysInYear( year ), 1 do
      days = days-daysInYear( year )
   end
   return year
end

function reduceDaysToMonths( time_t, days, math.floor( year ))
   math.floor( month )
   for month=0, daysInMonth( month, year ), 1 do
      days = days-daysInMonth( month, year )
   end
   return month
end



Please tell me if any of that is wrong. Smile

I have no C++ knowledge and only a small amount of lua knowledge.
Unfortunately that's not quite right. time_t is a type (like string, int, float, etc), not an argument. I'll see if I can bang out a bit of code tomorrow to help you; feel free to ping me about it if I forget.
OK, this seems to me like a garbage collecting problem. If I try to run a large-ish program two times in a row, this happens:


Code:

not enough memory
stack traceback:
    [C]: in function 'run'
    stdin:1: in main chunk
    [C]: in ?
flyingfisch wrote:
OK, this seems to me like a garbage collecting problem. If I try to run a large-ish program two times in a row, this happens:


Code:

not enough memory
stack traceback:
    [C]: in function 'run'
    sdtin:1: in main chunk
    [C]: in ?
It could also be insufficiently-aggressive garbage collecting, but the problem could be fixed if your global variables were tagged with local, as far as I understand Lua scoping.
KermMartian wrote:
flyingfisch wrote:
OK, this seems to me like a garbage collecting problem. If I try to run a large-ish program two times in a row, this happens:


Code:

not enough memory
stack traceback:
    [C]: in function 'run'
    sdtin:1: in main chunk
    [C]: in ?
It could also be insufficiently-aggressive garbage collecting, but the problem could be fixed if your global variables were tagged with local, as far as I understand Lua scoping.

The same thing happens with bloxorz.
Yeah I know, but spence's program does not use local vars, and for some reason it does not seem standard in non-luaFX circles not to use global vars...
When you run it twice in a row, or when you run a very large program once? If the former, then yes, something needs to be adjusted (not the least of which is the Prizm's baffling malloc() behavior.
KermMartian wrote:
When you run it twice in a row, or when you run a very large program once? If the former, then yes, something needs to be adjusted (not the least of which is the Prizm's baffling malloc() behavior.

for me it has only happened when I try to run it twice in a row. Or when I exit with AC/on.
OK, also don't know if this is a bug or not.

If you do not use a getkey function then you cannot break from loops with ac/on.

For instance:


Code:

while 1
print("hello moon")
end


Will loop forever until you press the reset button or pop a battery.
That's a glitch; it should be possible to break out of that. When I get back to LuaZM and work on the IO library, I'll see if I can track that down.
BUG REPORT

Version: 0.1.1beta

Subject: zmg.drawText sometimes freezes when drawing off screen

Reproducible: Yes

Steps to reproduce:
Run this code:


Code:

drawText(1, 20, "by TakeFlight Productions (flyingfisch)", color.fg, color.bg)


Notes:
It has happened with other strings of text as well, but some work when drawing off screen fine. Don't know what the problem is...
Can you please try with a shorter string closer to the edge of the screen, and see if you can replicate it that way?
This code freezes my calc... maybe someone else would like to test it too?


Code:

local keyDirectPoll = zmg.keyDirectPoll
local keyDirect = zmg.keyDirect
local drawText = zmg.drawText
local fastCopy = zmg.fastCopy

local key = {F1=79, F2=69, F3=59, F4=49, F5=39, F6=29, Alpha=77, Exit=47,
Optn=68, Up=28, Down=37, Left=38, Right=27, EXE=31}
local text = {x=300, y=1, string="test"}

while exit ~= 1 do
   if keyDirect(key.Exit) > 0 then exit = 1
      elseif keyDirect(key.Left) > 0 then text.x = text.x - 1
      elseif keyDirect(key.Right) > 0 then text.x = text.x + 1
   end
   
   drawText(text.x, text.y, text.string, 0x0000, 0xFFFF)
   fastCopy()
end
I tested it out and it did the same thing for me.
Whenever I try to use a masked sprite, it appears all weird looking. Can someone test this too and see if it is a bug?
  
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
» Goto page Previous  1, 2, 3, 4, 5, 6  Next
» View previous topic :: View next topic  
Page 3 of 6
» All times are UTC - 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