if i use the export command to generate html/js, the cart will run, but its _update60 will be completely ignored, so only _draw will be called unless _update is also defined.

HTML export is one of the cases mentioned in the documentation that doesn't support _update60(). If both _update and _update60 are present in the cart, _update60 will be used on platforms that support it, and _update will be used on those that don't. You can add this to the cart to get both:

function _update() _update60() _update60() end

(Feature request: add this automatically.)

@dddaaannn: what do you mean by 'documentation' ?

from pico-8.txt and https://www.lexaloffle.com/pico-8.php?page=manual :
'On machines that do not support it, _update60() will instead be called twice per frame and _draw() at 30fps.' so, yes, it's automatic.

unless 'will' also means 'not yet', of course.

the bug is that it's not automatic, when the manual implies it is

pico8.txt is the official documentation. I did a quick test like so:

t = 0
r = 0
function _update60()
  t += 1
end

function _update()
  r += 1
end

function _draw()
  cls()
  print(t, 0, 0, 7)
  print(r, 0, 8, 7)
end

In Pico-8 desktop, the top counter runs and the bottom counter doesn't. In HTML export, the bottom counter runs (half as fast) and the top counter doesn't.

function _update()
  _update60()
  _update60()
  r += 1
end

... runs both counters at the expected speeds on both platforms with the lower fps in HTML export.

yes, it works, but it's just a workaround.

_update60() HAS to be called twice from above, if only for button polling in between. otherwise btnp() stays true 2 frames in a row. also stat(1) gets halved inside _update60(), and there may be some other caveat I can't think of right now.

but if you stay away from btnp and don't rely on stat(1), it's a good workaround: if your game is working properly then it'll still work if/when the html player is fixed.

> (Feature request: add this automatically.)

Yes, it was supposed to be automatic! Fixed for 0.1.9. Adding your own _update() function that calls _update60 twice is a correct work-around and should work in all cases.

so, until 0.1.9 it seems there's an even more correct work-around:
function _update() _update60() _update_buttons() _update60() end

@ultrabrite

I can't get buttons to register using that setup

function _update()
  _update60()
  update_buttons()
  _update60()
end

@matt
that's _update_buttons() (with an underscore) but you should get an error, unless you also happen to have an update_buttons() defined somewhere ?

yes i have one called update_buttons()
i also tried it called _update_buttons()

i put my button code inside that function.

no luck.

am I misunderstanding something?

@matt:

Did you literally do this?

function _update()
   _update60()
   _update_buttons()
   _update60()
 end

While making sure there is no _update_buttons() function in your own code? The call should be syntax-colored as a system call, like flip() is. It's the system call that literally updates the internal variables used to supply btn() and btnp(). Don't override it, just call it.

OK, that worked :)

Thanks for clearing up my confusion! I wasn't aware of the system function _update_buttons()

I'm sure it's considered an unofficial/undocumented syscall. But considering this is meant to be a temporary bodge anyway, I'm sure it's okay in the short term. I'm assuming zep will address the problem under the hood in 0.1.9.