Log In  

When running the time() function, suspending a cart using esc and then resuming it using resume causes the time to increment faster. I am able to reproduce this on both machines I have access to by printing the value in a draw loop:

function _draw()
  cls()
  print(time(),1,1,7)
end

I am using version 0.1.12c

P#67508 2019-09-10 22:17

Dang ! You found something alright. I hope that's not affecting seconds: stat(95).

I can't use RESUME myself because of the way I code so fortunately I will not run into this bug you found:

repeat
  cls()
  print(time(),1,1,7)
  flip()
until forever

I see the error encompasses _update() and _update60() as well.

You should also be aware that TIME only flows forward when your program is running.

Try this, in immediate mode:

CLS
?TIME()

wait a moment, do it again:

?TIME()

Now wait longer, 2-seconds, type it again:

?TIME()

Notice that it always only increases by a 3rd of a second each time you request to see the value. This could be an indicator that this is not a good variable to gauge time with.

P#67510 2019-09-10 22:26 ( Edited 2019-09-10 22:47)

@dw817, I'm reasonably sure you mean "by a 30th of a second" (0.0333) rather than a 3rd (0.333) - unless your machine/pico8 runs differently than mine.

"time / t

Returns the number of seconds elasped since the cartridge was run.

This is not the real-world time, but is calculated by counting the number of times _update or _update60 is called. Multiple calls of time() from the same frame return the same result." -source pico-8.txt

Because the frame rate (normally) is 30 per sec, time() returns a result a 30th of a second advanced from its previous state.

A short command line instruction seems to be interpreted as one frame, so a 30th of a "second" for time().


@Nord

The following snippet uses stat(85) to get seconds and calculates a difference. The two numbers will be a little out of sync anyway, but when you do your esc, resume it shows quite clearly. You seem to be getting extra frames per second; interesting find. [Edit: seem - I don't believe them to be real, just that the count for time is going twice as often.]

function _init()
 counter=0
 last=-1 --an invalid value to start things off
 pause=30
end

function _draw()
  if not(last==stat(85)) then
   if pause<=0 then
    counter+=1
    pause=30 --framerate
   else
    pause-=1
   end
  end
  cls()
  local a=flr(time())
  print(a,1,1,7)
  print(counter,1,8,7)
  print("difference: "..(a-counter),1,15,7)
end
P#67533 2019-09-11 07:35 ( Edited 2019-09-11 13:51)

Just for fun, in hopefully perfect sync, and no way to resume:

counter=0
last=-1 --an invalid value to start things off
pause=0

repeat
 cls()
 local a=time()-(1/30) --the first call advances it one thirtieth, so we can make it to 0 decimal places by deducting that amount
 print("time: "..a,1,1,7)
 print("stat(85) counter: "..counter,1,8,7)
 print("difference: "..(a-counter),1,15,7)

 for i=1,30,1 do
  if not(last==stat(85)) then
   if pause<=0 then
    counter+=1
    pause=30 --framerate
   else
    pause-=1
   end
  end
  flip()
 end
until (forever)
P#67534 2019-09-11 07:50 ( Edited 2019-09-11 13:52)

Bumping this because if 0.1.12d is coming soon, it would be nice to have the bug investigated. We know time() will increment twice as fast after a resume() but there may be other affected features that only @zep can know about.

Another simple repro:

cls()
a=0
function _update()
    pset(a,127-t()*30,7)
    a+=1
end

Run the program, stop it, call resume, you’ll see the line slope will change after resume():

P#74471 2020-04-04 20:32 ( Edited 2020-04-04 20:33)

Thanks -- fixed for 0.1.12d

P#74484 2020-04-05 11:43

Hey, just to let you know, this bug persists when resuming after a debugging command:

(Edited out suggesting the timer repro too.)

P#76459 2020-05-12 22:12 ( Edited 2020-05-13 09:06)

@noppa are you running the latest version (0.2.0i)? it appears to be fixed when I try the script remcode wrote:

P#76469 2020-05-13 00:16

@kittenm4ster I'm on the newest version, but sorry, seems I may have been wrong about reproducing with the timer. I didn't properly read what the timer did before testing.

In addition to the pset()-repro by @samhocevar, this affects my games animation, which is using time(). It also affects btnp()-input, which is a bit harder to demonstrate. Here you can see the animations speed up after resume:

P#76486 2020-05-13 09:05 ( Edited 2020-05-13 09:34)

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-03-28 12:27:44 | 0.029s | Q:30