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

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.

@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

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)

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():

Thanks -- fixed for 0.1.12d

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

(Edited out suggesting the timer repro too.)

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

@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: