Log In  



Hey, I'm trying to figure out why btnp(x) seems to be true for one frame after stat(31)=="x" is true in devkit mode, or if I'm doing something dumb.

Here's an example cart. Press X, and it will show display the number of the frame that it registered the devkit keypress and the X button press respectively. There seems to be one frame difference.

Cart #zoyifizotu-0 | 2019-02-21 | Code ▽ | Embed ▽ | No License

My actual usecase is this: I have a password input in a game where I want to record numerical input from the devkit keyboard, but I also want it to record the X button, which confirms the password. Unfortunately, the 8 key is mapped to the X button; when they're also recorded on different frames it becomes a little convoluted to separate the two.

Edit: The 8 key is no longer mapped to the X button (in non-Pocket CHIP builds) as of v0.1.12.

Sorry to bump this, but I'm very interested in finding out whether I'm crazy, have done a stupid error, this is intended behavior, or a bug.

Maybe it has something to do with how the devkit keyboard buffers and refreshes input in stat(31)?

Note that this seems to be a problem both with btn() and btnp(), I just chose the latter for the example since it's easier to catch.

You're not crazy. But it might be the way you've written out the code. When I wrapped everything up in the init, update and draw functions it was now sometimes firing at the same time but sometimes it would still exhibit the delay.

Still seeing the same behavior with a gameloop.

 
function _init()
 poke(0x5f2d, 1)
 f=0
 fs={0,0}
end

function _update()
 if stat(30) and stat(31)=="x" then
  fs[1]=f
  c=10
 else
  c=2
 end

 if btnp(❎) then
  fs[2]=f
  c=10
 else
  c=2
 end

 f+=1
end

function _draw()
 cls()
 print("press x",64-(7*4)/2,64,7)

 print("x",0,0,c)
 print(fs[1],16,0,c)

 print("❎",0,8,c)
 print(fs[2],16,8,c)
end


Moving this to Bugs, as I assume it's unintended.

(Note that the 8 key is no longer bound to the X button as of v0.1.12, so my particular use case is solved.)

One frame difference is okay, right ?

Probably Pico can't read both at the same time since one is registered as a joystick press and the other true keyboard.
1

Thanks @tobiasvl, this unearthed a bunch of related issues. Most importantly, btnp, and btn were firing a frame later than they needed to (!!) and also sometimes not on the same frame. In 0.1.12d the state of the input buffer will be locked during each (PICO-8) frame to be consistent with button input.

Glad I could help and thanks for resolving it!



[Please log in to post a comment]