Hi everyone!
I picked up PICO-8 again after some months and discovered some very strange thing: The mouse click needs to be very "hard" to be recognised by the editor. I swift and fast one is ignored. When using the macbook track pad it‘s the same. I have set it to "tap to click", that does never work at all (although it works in all other applications).
It feels like the mouse button needs to be down for a small fraction of a second, just a click is not enough. Is the handling of mouse input in PICO-8 handled differently than in the standard OS way? Is there some kind of lag anywhere?
This does not make the editor completely useless, but it's annoying and frustrating. I use macOS Catalina.
Any ideas?
It depends on how you code it. Here, try this:
function _init() x=64 poke(24365,1) end function _draw() cls() circfill(x,64,7) end function _update() if stat(34)==1 then x+=1 elseif stat(34)==2 then x-=1 end end |
You shouldn't have to push down very hard. Just tap the mouse and the player will move. Tap the right button to go to the left.
That's all. Let me know if you're still having problems.
Thanks a lot, dw817!
Unfortunately that does not help at all, because I was talking about mouse clicks in the editors, not at run-time. Sorry if that was not clear.
I didn't even think about using the mouse in the running games. What I meant was the mouse clicking in the sprite, code, sound editors …
Any thoughts about this?
If it's in the editor and not during runtime, hmm ... might be a hardware problem. Do you get bad clicks in other software ? What Operating System are you using ?
Windows
Linux
Macintosh
... ?
I use macOS Catalina, MacBook Pro. And no, nothing like this in any other software...
I guess it’s something very deep down in the PICO-8 Input manager. @zep?
Same problem here. I am using macOS High Sierra on MacBook Pro (2011), and PICO-8 does not register "tap to click" clicks in the editor. I have to push the touchpad hard to click on something in the editor. I have to hook up a mouse if I want to start editing anything before the editor drives me insane.
Is there any solution/options for setting the click sensitivity in PICO-8, if that is a thing?
Same here. I have Tap to click turned on and it works 50% of the time which makes Pico-8 development quite annoying. Only solutions I know of is a full press on the trackpad (annoying) for a click or an external mouse (not always possible). I suspect it's a Mac trackpad mouse-up event that's not always fired and SDL based apps like Pico-8 rely on that event. Same issue on TIC-80. Would be wonderful to have this fixed.
Well guys I guess you can contact @zep in Twitter about this problem. That's where he's at most of the time.
I try to avoid the mouse as much as I can when I'm coding in Pico-8. I know it's required for drawing sprites but I often use my own keyboard tool for that.
One more question about the "hard click." Do you need to click down with physical force or is it you just need to hold the button down longer for Pico-8 to acknowledge it ?
A hard click always registers as a click for me - but this defeats the point of the Tap-to-click feature on a MacBook. Duration of holding down a trackpad click with physical force is irrelevant for me as a hard click always registers. Yeah I may ping zep but feels like this is only affecting a very small number of users. My primary workaround is to use Aseprite (+import) for all art. Still looking at options for sfx/music.
I am also affected by this. I "have to" use the mouse, otherwise the editor is nearly useless for drawing. Thankfully I was able to replicate the wheel-click with the Apple mouse thanks to https://github.com/artginzburg/MiddleClick-Sonoma
but... anything on the trackpad (even Zoom in-out) doesn't work, unless you click it.
I also have this issue, though I run PICO-8 in the Linux environment within Chrome OS (Lenovo IdeaPad Flex 5i w/Intel i3).
Interestingly, in the sprite editor, a tap will work to set flags, select tools and change tabs, but I need to use a solid click to select colors, select sprites or draw.
This would suggest that @zep is polling the hardware each frame, instead of being told by the hardware or the OS when there's a state change.
It's a complex problem, tbh. If you do an instantaneous poll, yes, you get the state at this exact moment, but if your framerate is low, then the user has to have the controller in the "activated" state for at least as long as one frame to make sure you read it as "activated" when you poll.
Ideally the hardware works off of interrupts or event queues that catch every change of state, and when you read the state for this frame, you either go through all of the events since the last frame or you get a summation of them. Technically an input can be both active and inactive, and possibly more than once, during a frame, so the tricky part is deciding how to handle it.
A lot of games written for hardware where your only choice is to read a hardware register with the current state will set up a timer interrupt and read the state maybe 120, or 1000, times a second. You can then keep a record of whether the state changed, not just what it was at the frame transition. If the previous state was off and you see there was a switch to on detected since the last frame, it doesn't matter if the state right now is off again, you still know it happened.
I assume zep's using the SDL input scheme, and I have no idea how it does things. I used SDL a long time ago and... well, let's just say I was very unimpressed with its attention to detail. It's an "It Just Works" thing where "Just" is a qualifier than means it only just barely works. At the time it seemed like it was written by academics rather than people experienced with bare-metal programming.
Thanks for your thoughts on this @Felice, that is valuable to know. However I would say that this happens (for me, and my issue may be different from the mac-specific issues above) so reliably that I would be surprised if I could possibly be missing the frame every time. A tap always, always, always works for setting flags but never, never, never works to choose a color from the palette.
But I think you may be right about this being an SDL input issue, while it does appear to support event-based input (and I would hope that would handle debounce appropriately, but who knows) it looks like Mouse Button events may be handled slightly differently if coming from a "Touch" device, but I'm not certain if that includes touchpads or just touchscreens.
https://wiki.libsdl.org/SDL2/SDL_MouseButtonEvent#remarks
But I also can't be certain that this isn't a quirk of running within Linux within Chrome OS, which certainly creates some hurdles for lucid input.
I have both a Chromebook and a MacBook Air. This bug is definitely within both hardware devices. Feels weird to "tap tap !!CLICK!! .. tap tap".
[Please log in to post a comment]