Log In  
  Page
1
2

42

Cart [#22286#] | Copy | Code | 2016-06-04 | Link
42

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.

P#22278 2016-06-04 16:17

::

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 ...

P#22283 2016-06-04 17:13

::

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.

P#22284 2016-06-04 17:20

::

Wow, that's awesome!

P#22287 2016-06-04 18:15

::

So now we can make "lightgun" games ;)

P#22288 2016-06-04 18:48

::

Sweet, guess my question about Pico8 and touch is more valid than I thought...

https://www.lexaloffle.com/bbs/?tid=3475

P#22290 2016-06-04 19:19

::

And guess who first answered you saying it would do nothing... :D

P#22299 2016-06-04 20:06

::

Super!

P#22300 2016-06-04 20:19

::

This will be great. Thanks for finding!

P#22304 2016-06-04 21:32

::

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.

P#22327 2016-06-05 03:20

::

awesome find! ^_^

P#22329 2016-06-05 03:50

::

This is AWESOME! Thanks!

P#22332 2016-06-05 05:37

::

that's amazeballs

How did you find it?

P#22334 2016-06-05 05:41

::

This opens the door to so much stuff.
So much.

P#22335 2016-06-05 05:42

::

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.

P#22339 2016-06-05 08:33

::

Because someone has to...

Cart [#22384#] | Copy | Code | 2016-06-06 | Link
2

P#22385 2016-06-06 01:50

::

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.

P#22391 2016-06-06 04:14

::

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!

P#22393 2016-06-06 04:56

::

oh my god this opens the path to so many tools directly on pico8

who wants to make a GUI library?

P#22470 2016-06-07 20:05

::

This is really nice! Now I can make web releases work on tablets!

P#22472 2016-06-07 21:42

::

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
P#22474 2016-06-07 22:25

::

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

Cart [#22496#] | Copy | Code | 2016-06-08 | Link
2

P#22497 2016-06-08 05:08

::

That's cool :) Should be trivial to draw a line between each point to create a continuous brush stroke instead of dots.

P#22498 2016-06-08 07:09

::

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

P#22526 2016-06-08 14:56

::

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

P#22528 2016-06-08 16:37

::

I wish code could just spontaneously mutate and grow mouse support...

P#22529 2016-06-08 16:45

::

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

P#22531 2016-06-08 17:19

::

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

P#22548 2016-06-09 10:33

::

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.

P#22558 2016-06-09 15:09

::

This will end like the extended palettes.

P#22562 2016-06-09 16:39

::

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

@Ivoah @JTE: fixed for 0.1.7!

P#22563 2016-06-09 17:10

::

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

P#22570 2016-06-09 17:44

::

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.

P#22571 2016-06-09 17:54

::

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.

P#22619 2016-06-10 15:20

::

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.)

P#22623 2016-06-10 16:31

::

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.

P#22628 2016-06-10 18:03

::

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!

P#22631 2016-06-10 18:18

::

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.

P#22632 2016-06-10 18:19

::

gamax92:
Please don't make any mouse only carts.

But it's okay to make cat-only carts, right? =o.o=

P#22749 2016-06-12 08:53

::

I see your theme JTE :)

P#22959 2016-06-15 20:16

::

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.

P#23170 2016-06-19 00:34

::

GPIO pins are coming in 0.1.7 to web player and desktop AFAIK

P#23192 2016-06-19 06:34

::

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)

P#23266 2016-06-19 22:49

::

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

P#23267 2016-06-19 23:14

:: v1tal was here <3

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

P#23536 2016-06-24 04:07

::

Who is v1tal?

Has the board been hacked?

P#23549 2016-06-24 11:30

::

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.

P#23587 2016-06-25 00:52

::

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

P#23670 2016-06-26 11:29

::

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!

P#23687 2016-06-26 16:02

::

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.

P#25787 2016-07-23 17:19
  Page
1
2

Log in to post a comment

user:
password:

New User | Account Help
:: New User
X
About | Contact | Updates | Terms of Use
Follow Lexaloffle:        
Generated 2017-04-25 06:29 | 0.230s | 1835k | Q:76