poke(0x5F2D, 1)
stat(32) -> X coord
stat(33) -> Y coord
stat(34) -> button bitmask (1=primary, 2=secondary, 4=middle)
You should probably limit yourself to using the primary button, not everyone has a middle mouse button and dunno how secondary button would work on a touch device. You should also be using the mouse to enhance a program, not for it to be the only control, or else you make it so anyone lacking a mouse on whatever device they're playing PICO-8 on is unable to use your cart.
EDIT: apparently it doesn't work that well on a touch device, atleast PocketCHIP:
"I tested the mouse support on PocketCHIP. It didn't work well. It seems to cannot detect mouse release (touch up)." ~ oinariman
A cheap way to do mouse press/release is to store the result of stat(34) in some variable at the end of the frame so that during the next one you can see if they differ and then respond on that.
I just tested, and it blown my mind. So much undocumented features ... Thanks for the tips.
Having a mouse input feel good for a retro PC, a bit less for a retro console. The only downside is that some hardware (Rasbery Pi ...) may only have two buttons. But Pocket Chip has a tactile screen so ...
Yeah, I wonder how that would act for say PocketCHIP, from what videos show it seems that the editor is responsive to touch, so that should atleast respond to the primary button.
Sweet, guess my question about Pico8 and touch is more valid than I thought...
And guess who first answered you saying it would do nothing... :D
Looks like the web player can't use the middle mouse or right mouse buttons either because of the default behaviors that it doesn't stop.
I noticed that on the desktop version (regardless of whether or not you have the mouse enabled in your game), clicking in the top right corner will behave as if the editor mode buttons are there.
Well this makes me want to make a Pico-8 rail shooter even more now.
Here I was trying to think up how to do it with limited keys but this will make things much easier, least for one player anyway.
| I noticed that on the desktop version (regardless of whether or not you have the mouse enabled in your game), clicking in the top right corner will behave as if the editor mode buttons are there. |
You mean that hasn't been fixed yet?! Gosh, I forgot that exists!
oh my god this opens the path to so many tools directly on pico8
who wants to make a GUI library?
This is really nice! Now I can make web releases work on tablets!
Because some of the information is rather obscure, I made a wrapper with inline docs:
Here is the module:
mouse = {
init = function()
poke(0x5f2d, 1)
end,
-- return int:x, int:y, onscreen:bool
pos = function()
local x,y = stat(32)-1,stat(33)-1
return stat(32)-1,stat(33)-1
end,
-- return int:button [0..4]
-- 0 .. no button
-- 1 .. left
-- 2 .. right
-- 4 .. middle
button = function()
return stat(34)
end,
}
|
Here is example usage:
function _init()
mouse.init()
end
function _draw()
cls()
local x,y = mouse.pos()
local b = mouse.button()
print("x:"..x.." y:"..y.." b:"..b)
spr(0,x,y)
end
|
Used the drippy demo to make this in a few mins. First time using Pico-8 so any advice would be appreciated.
Left click to draw
That's cool :) Should be trivial to draw a line between each point to create a continuous brush stroke instead of dots.
This is spectacular! I mean, I'm not even a PICO-8 games developer, and still I think this is superb! Think about all the kinds of new games you can create :o
There's something I don't understand, though. How did you "find" this possibility to retrieve mouse X and Y? Nobody from Lexaloffle knew about this? You are in the middle of something huge then, you should be rewarded :)
I'm sure the people who wrote in support for that, I.E Lexaloffle, knew about it :P
Their code didn't just spontaneously mutate and grow mouse support
I wish code could just spontaneously mutate and grow mouse support...
@gamax92: Really though, how did you discover this? The fact you need to poke a byte first to even be able to retrieve the mouse state from stat() makes the fact it was even discovered kinda mindboggling.
You all do now, that it goes against the will of the creator? :) And the Pico-8 "hardware" specification? :)
I wonder is there a way to get individual keyboard presses though :)
Why would he put in this feature if he didn't want it to be used, and no it's not because of the dev tools. The tools aren't written in Lua, they can do plenty of things that aren't exposed to Lua like keyboard input, splore being able to access the internet, etc.
If it's really something that he accidentally left in somehow and doesn't want to be used, he can just pull out support for it. It's his project.
@gamax92 Very nicely done; I thought it would take longer than that to discover!
For what it's worth, I don't think of the mouse as a console feature (hence leaving it undocumented & off-spec), but rather a development kit thing. For anyone using the mouse, keep in mind that not every PICO-8 will have mouse support, so it's better suited to things like tools filed under collab, or at least as an additional, alternative way of controlling a cursor. It's similar to using the P2 keys to get extra buttons -- it means that someone playing PICO-8 on a tv via splore with a controller won't be able to use such a cart, and won't necessarily understand why.
@darkhog Just to clarify why some features are added and not others, or at different times -- I need to balance the aesthetic and practical benefits of having a strong, minimal standard spec against the value of doing non-standard things with PICO-8. Mouse-controlled tools are worth it now at this point, I think, but extended palettes would be too disruptive. They're not out of the question in principle -- they could potentially show up on a gfx chip in the future for example, depending on how cartspace pans out -- but it wouldn't be anytime soon.
I see. Still not agree (because what cartspace has to do with just poking into the ram to change color value of certain palette entry to another, where all possible color values you can choose from are hardcoded, like in the NES or Atari), but somewhat understand.
Update:
Although mouse reading will be supported going forward, just a heads up that in the future reading the mouse will likely trigger a small "devkit mouse enabled" message to show at the bottom of the screen briefly when playing carts via the bbs. This will hopefully avoid confusion from gamepad-only splore users, and also nudge mouse-controlled carts more into the "dev tools" domain (along with carts that read from multiple other cartridges). Sorry I didn't have time to sort this out clearly before the cat was out of the bag! :}
@darkhog
"Cartspace" is ambiguous -- I meant "The World of Carts". For example, there are so many interesting tools popping up that there was more gravity towards supporting mouse control in some way.
zep: Great to hear that mouse support will be continued. Re: the message, I understand the desire to avoid confusing gamepad users, but why not wait on that to see if it becomes an actual problem? After all, it's easy enough for authors to include code that allows the gamepad to drive the mouse cursor (and there's plenty of precedent for that in actual games of the 80s/90s).
I really enjoy the limitations of Pico-8, but I also enjoy how it yields a wild diversity of carts (i.e. not just platformers).
(at the very least, if there is a message, I would vote to remove the word "devkit" from it--which DOES seem potentially confusing and also preemptively limiting.)
I just wanna say that I for one am glad to hear mouse support is only intended for dev tools. Here's my biased, subjective, personal opinion: I hate computer mice. I only use a mouse if I am forced to, never for games. I love the six-button input restriction of PICO-8 and it is one of its most appealing characteristics for me :)
More objectively speaking though, I want to point out that if mouse support became mainstream, it would negatively impact accessibility and limit the range of possible hardware implementations.
Great to read that this support will stay in.
I see it as adding touch screen support to pico8 games. A touch simultaneously moves the pointer and fires a click. Powerful stuff!
I can imagine playing a game with buttons, pausing, switching into editor mode (via the menu item feature coming in 0.1.7) and using the pointer (I refuse to say mouse when it also applies to touch screen) to edit the level, then back to playing with buttons.
Just like Mario Maker!
I agree, just like with modern games with keyboard+mouse or controller, if you're going to support both try to give both a good experience. Please don't make any mouse only carts.
gamax92:
| Please don't make any mouse only carts. |
But it's okay to make cat-only carts, right? =o.o=
I love this. Not only because I wanted mouse support, but because of how it came up - the discovery aspect of things is fun. I like to think of hidden gems in there for people to find to do unexpected things, and by doing it this way, there is no real requirement to support it and worry that it might not work everywhere. It's unsupported!
Zep - was this a case of "I'll leave this here for the intrepid explorers to find", an unfinished feature, or a sheer accident? Just curious.
As for worries about platform fragmentation - unless someone can figure out how to enable non-existent GPIO pins on desktop systems to match the pocket chip, that ship has sailed. And - that's fine. It's not like real retro game systems have a big tradition of being compatible with different versions (he says, staring at a ps3 that can't play ps2 games).
Although - a USB hardware module that had a tiny microcontroller and GPIO pins and responded to the same PICO-8 commands used on the pocket chip would be a total kick in the pants. :-)
And yes - to echo what others have said, it would be really nice to ensure that anything made can work with the stock buttons, and use the mouse (and gpio) as an additional means of control, so nobody is bummed they can't use a cart because they have the wrong version of hardware.
Yeah, the software part, but you'd need a hardware module for themto be actually usable (or do the other part in software, also reasonable)
@Biggles: It was probably sheer coincidence. According to the documentation, 0x5F00 is the memory mapping for the drawing state.
So, it looks like at 0x5F2D where the mouse is located, is where the editor would draw the mouse's position.
I really wish this feature was removed, because for me it kinda ruins the fun of "The harsh limitations of PICO-8 [that] are carefully chosen to be fun to work with, encourage small but expressive designs and hopefully [...] give PICO-8 cartridges their own particular look and feel."
One of the main reasons I switched from developing with LOVE 2D to PICO-8 is because of how limited PICO-8 is, where I'm free to make crappy UIs, use only 6 buttons, and use blips and boops for music and sounds. With mouse support, however, I feel like I'm obligated to use it, which is not only more tokens wasted, but also wouldn't be available for everyone... I'd rather program something that everyone would be able to play/use to its fullest.
EDIT: Although, maybe in the future we could have some APIs only for the executable exporter (once that's added in), such as file selecting, file saving, file loading, keyboard input, and mouse input? Then we could use PICO-8 for all different kinds of external tools...
> inb4 custom configuration tools for steam games
But, of course, file saving and loading would probably have to have confirmation prompts from PICO-8, like what SmileBASIC for the 3DS does. Although, for the executable exporter, since the code would likely not be visible, why not have no token counts for the executables? Sorry for the rant... I tend to do that.
v1tal was here xxx
Um, the post was also edited... I did not say "v1tal was here xxx" on the bottom of my post...
EDIT: That, and I did in fact use the full editor for my post.
v1tal is a friendly neighbourhood hacker, demonstrating how to exploit a (now-fixed) bug in the BBS to edit any post. I've fixed the hole, along with a few other security improvements. (but left the edits there for posterity)
> I would vote to remove the word "devkit" from it--which DOES seem potentially confusing and also preemptively limiting.
The message is there now in 0.1.8, so you can see what it looks like. It is intentionally meant to be limiting! The goal here is to create a separation between dev tools carts (the built-in editor already has mouse so, it's not such a jump in this domain), and release carts -- things that show up in splore. I don't want to straight out tell authors what to do with PICO-8, but instead try to put a little friction in the right places to nudge the ecosystem in what I think to be the right direction. I'm completely on board with the promotion of diverse carts in principle, but I think it should be from thoroughly exploring design within strict boundaries, rather than simply being a sample of a larger possibility space. If that makes sense.
Note that the devkit message doesn't show up in html5 exported carts, so it's still possible to do 'non-standard' things in that space. In the future html5-exported carts will also be able to have multiple carts bundled with them (allowing extra readable data), and custom javascript hacks etc. So it will be an outlet for more unusual uses of PICO-8, while the BBS cart collection will remain more of a sanctuary for purists such as myself :)
Okay, I think I get what you mean. Also, in regards to this feature on HTML5 exports (as well as on BBS), will the mouse be hidden when over a player when the mouse is enabled, to better match PICO-8's behavior on the desktop? Also, in regards to html5-exported carts being able to have multiple carts bundled, why not rework the JavaScript so it uses a JavaScript classes, rather than being forced to only one player per web-page? At one point, I was pondering the idea of having double the screen size, by showing 4 players side-by-side and connecting their displays using GPIO, while only one of them actually processes inputs and really does things. Of course, this wouldn't work with the current HTML5 exports (although maybe it would with the PocketC.H.I.P.), and it'd probably crash Chrome, but oh well! Yolo!
Hey guys, how do i get the cool mouse devkit enabled thing to pop up?
It doesn't seem to be in anyones code?
Also, do I need to use the poke line? Leaving it out still lets me fetch the mouse co-ordinates.
[Please log in to post a comment]
