Hi!
p5 mouse events seem to work quite well on mobile / tablets (i.e. touchEnded falls back to mouseReleased if not defined). However p5.play does not seem to handle touch events.
Am I right? Is this planned in a near future? (Would be a great addition to p5.play).

It would be really nice if we could remove the built docs from the repository, so that we don't need to spam the commit history with rebuilds of the documentation whenever we change it.

(This issue was split off from #41.)

I'd like to add a simple unit test suite in the style of p5's test suite (mocha, phantomJS, Travis CI integration, nyan cat test formatter, etc). This way future bugs can have regression tests easily written for them.

To start I'd like to just add the test infrastructure along with a regression test for #13.

@molleindustria does this sound okay?

p5.play.js refers to GPL: "This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.", but licence.txt contains LGPL.

I'm not sure what the release process is for p5.play, but we should document it so folks can continue to maintain it. In #24 a bug that was fixed over two months ago was re-reported, presumably because a new version of p5 with the bugfix hadn't been released yet.

For reference, here's a release process I instituted for a previous project I worked on.

We should also probably make the official project page at p5play.molleindustria.org something that other maintainers can deploy to as part of the release process--perhaps either through a Travis CI hook or a gh-pages branch.

var screenit = 0;

function setup() {
    createCanvas(windowWidth,windowHeight); 
    enemy = createSprite(300,300); //create a new enemy
    enemy.addImage(loadImage("assets/cloud.png"));

    player = createSprite(-100,-100);
    player.addImage(loadImage("assets/sun1.png"));
}


function draw() {  

  background(255);

  fill (0);
  rect (600,0,100,height);

  if (mouseX > 599 && mouseX < 701){
    screenit = 1;
  }

  else{
      screenit = 2;
  }

  if (screenit == 1){
      save('export.png');       //sprites are not shown when screenshots are here?
      print('screenshot!');
  }

  player.position.x = mouseX;
  player.position.y = mouseY;

  drawSprites();
} 


function keyPressed(){
  if (key == '1'){
    save("export.png")     //however, screenshots display as expected here?
  }
}

I have been trying to make a screenshot trigger upon hit detection. It works as it should with keyPressed, however when using the hit detection, p5.play sprites disappear from the screenshot.

Hello im trying to build a game and im getting stuck ad the part where i need groups. so i decided to google "p5 play groups"but the only useful thing i could find was the examples but i think those aren't working anymore because i tried them. so can someone PLEASE explain how the groups work and what i haev to do.

The API lists two clear methods. The code has @method clear on the removeSprites method.

In #91 @cpirich made p5.play check the p5 angleMode before doing conversions, so that internally we call p5 methods with the correct angle measurements. However, p5.play methods still expect angles in degrees, regardless of what the p5 angleMode is. It would be nice for p5.play's API to fully respect the angleMode, so that p5.play's methods take radians if angleMode(RADIANS), and degrees if angleMode(DEGREES).

This will be a breaking change, since p5's default angleMode is RADIANS but p5.play's API currently expects degrees.

I believe the complete set of public p5.play methods and properties that would require an API change are:

• Sprite.rotation
• Sprite.rotationSpeed
• Sprite.setSpeed(speed, angle)
• Sprite.addSpeed(speed, angle)
• Sprite.getDirection()
• AABB.rotate(r)
• Animation.draw(x, y, r)

Mouse events on sprites such as Sprite.mouseIsOver and the related events (overridable methods) don't work if the camera is moved.

To test it you can add a camera.position.x = 500; somewhere in this example

The problem is here
https://github.com/molleindustria/p5.play/blob/master/lib/p5.play.js#L1390-L1393

The idea was: some sprites (eg GUI) may have to be drawn in the screen space ignoring the camera position and have to be triggered by the normal mouse position, however at that point in the update the camera will always be active so the sprite doesn't know if its being drawn with the camera on or off.

A fix would be to check a new property in the condition above instead of camera.active:
if(this._drawnOnCamera)

The property would be somewhat unelegantly set in the display cycle here
https://github.com/molleindustria/p5.play/blob/master/lib/p5.play.js#L1556

by adding something like this:
this._drawnOnCamera = camera.active;

I don't know if that covers all the cases though.
Here's an example that illustrates the problem and that would be fixed by this change

var s1;
var s2;

function setup() {
createCanvas(windowWidth,windowHeight);
s1 = createSprite(width/2, height/2, 200, 200);

s1.onMouseOver = function() {
this.rotation+=10;
}

s2 = createSprite(30, 30, 20, 20);

s2.onMouseOver = function() {
this.rotation+=10;
}
}

function draw() {
background("#FFFFFF");

camera.position.x++;

if(s1.mouseIsOver)
s1.shapeColor=color("#ff0000");
else
s1.shapeColor=color("#224477");

drawSprite(s1);

camera.off();

//camera is off - this sprite is drawn in the screen space like a UI

if(s2.mouseIsOver)
s2.shapeColor=color("#ff0000");
else
s2.shapeColor=color("#224477");

drawSprite(s2);

}

Our documentation claims that Sprite.depth defaults to 0, and while we do set it to that in the constructor, the createSprite() function immediately changes it to allSprites.maxDepth()+1.

So for practical purposes, our documentation is incorrect, since users are expected to use createSprite rather than the Sprite constructor directly.

The debug drawing code found in Spirte.display() at p5.play.js:1485 does not properly push/pop p5 render state, so it can affect rendering operations that take place after it runs.

Example

An easy example of this is that text rendering breaks when it follows sprite rendering with debug=true, including on subsequent frames. Here's a small repro case where debug=true when the mouse is down.

You can run this example at http://p5play.molleindustria.org/examples/ by pasting the following code:

var circle;

function setup() {
  createCanvas(800,400);  

  //create 4 sprites
  circle = createSprite(400, 200);
  //compact way to add an image
  circle.addImage(loadImage("assets/plain_circle.png"));

}

function draw() {
  background(255,255,255);  


  //if debug is set to true bounding boxes, centers and depths are visualized
  circle.debug = mouseIsPressed;

  drawSprites();

  textAlign(CENTER, CENTER);
  text('Here is some example text', 0, 0, 800, 200);
}

Related issue

There's a related problem, equally easy to fix, where debug also doesn't draw if the user calls strokeWeight(0).

@joshlory has volunteered to fix these two issues; assigning to him right away.

I noticed that calling Group#removeSprites wasn't actually calling Sprite#remove for all sprites. I think this is because of your implementation of remove.

array.removeSprites = function() {
for(var i = 0; i<array.length; i++)
array[i].remove();

array.length = 0;
}

This loops over the length of the array and calls remove on sprites. However, because Sprite#remove also removes the sprite from all groups, when the next iteration of the loop happens, the group is now one shorter.

e.g. The group has two items in it, Sprite1 and Sprite2. Group#removeSprites is called. The loop has i=0, grabs the first element, and calls Sprite1.remove(). Sprite#remove removes the sprite from the group. The group now has one item in it. The loop completes and increments, so i=1, and group.length=1, so the loop terminates, even though it has one item in it.

While the last line, array.length=0 does make the group empty, it means that not all of the sprites are removed from other groups (particularly allSprites). Over a long period of time this begins to add up and results in the game slowing down.

Alternatives would be using a while loop to remove them or iterating from the back to the front.

Extending the Sprite class seems like something users of p5.play are very likely to want to do, especially since certain methods, like draw(), are documented as being override-able. So it seems like it might be useful to document a recommended way of doing this.

However, there doesn't actually seem to be a particularly easy way to make a proper subclass, as the only documented way to create a sprite is via the createSprite() function.

On top of that, while the Sprite class is accessible from code, due to the weird hacks I put in place to support instance mode in #22, accessing it actually always returns a constructor that is bound either to a specific p5 instance or window, which complicates subclassing even more. 😓

That said, some alternatives:

• Advise users to just make a factory function, e.g.:

  function createFunkyEnemy(x, y, pInst) {
    pInst = pInst || window;
    var sprite = pInst.createSprite(x, y, 50, 50);
    sprite.draw = function() { /* do stuff here */ };
    return sprite;
  }

• For more complex use cases, advise users to prefer composition over inheritance, e.g.:

  function FunkyEnemy(x, y, pInst) {
    pInst = pInst || window;
    this.pInst = pInst;
    this.sprite = pInst.createSprite(x, y, 50, 50);
    this.sprite.draw = this.draw.bind(this);
  }
  
  FunkyEnemy.prototype = {
    draw: function() {
      /* do stuff here */
    }
  };

Any other ideas?

In the point and pixel overlap example it looks like overlapPixel is not working - the poor triangle falls straight through the platform.

animation() call fails to animate. Even the "Animation - sprite sheet" demo example fails to actually animate the spritesheet.

Prints message: Warning undefined frame 0 p5.js:12477

Hey @molleindustria!
I've got a question for you. I ran into a problem with sprite sheets because when an Animation is added to a Sprite, .clone() is called on the animation. This doesn't work for sprite sheet Animations because it doesn't deep clone the state. What I need is a way to deep clone the object. There is a popular JavaScript library https://lodash.com/ that has a really nice cloneDeep() method, that would make this operation so easy, efficient, and browser compatible. It totally works because I tested it and it makes sprite sheets work with Sprites. This example is with lodash: http://scripta.co/p5.play/examples/index.html?fileName=sprites_with_sheet.js

So on to my question. Is it ok with you if I add require.js and grunt to build lodash.js into a single p5.play.js lib?

This would also add all the other benifits of having grunt i.e. magnification, and doc generation.

This is the last problem I have to solve before I'm ready to make a Pull Request for sprite sheets.

Thanks!

@islemaster mentioned this in https://github.com/molleindustria/p5.play/issues/57#issuecomment-203142789 so I thought it might be useful to start a discussion about it here.

JSDoc 3 pros:

• Better tooling? (@islemaster can you be more specific about this?)

JSDoc 3 cons:

• Since we're not currently using it, there may be some work involved in getting our current docs to work with it. @islemaster mentioned that the syntax is really similar though, so it probably won't be much work.
• Default theme doesn't look like p5.js branding at all. This is ultimately @molleindustria's call I think, but I personally feel this is pretty important. If there are lots of compelling reasons to switch to JSDoc 3, I'm interested in writing a custom theme that conforms to the style of p5.js core.

YUIDoc pros:

• It's what we're currently using, so there's no extra effort involved in sticking with it, really.
• It's what p5.js core uses, so it lowers the barrier for p5.js contributors. I don't think there is specific code or theme-ing we can necessarily lift directly from its repository, though.

YUIDoc cons:

• Inability to treat specific methods/properties as private, and therefore hidden. This is actually a problem with our particular YUIDoc theme, I think, but I could be wrong. But basically, we can only treat entire classes or modules as private--and therefore remove them from default docs view--but not individual methods/properties.
• Broken cross-links to other parts of the documentation. Again, this seems to be a problem with our theme rather than YUIDoc itself, but I could be wrong. Filed as kevinlacotaco/yuidoc-bootstrap-theme#24.
• In general I feel like YUIDoc has a lot of "paper cuts"--minor bugs or lack of helpful features that make writing docs a bit harder than I think it could ideally be. For example, in #72 I fixed a problem with a duplicate parameter name and another one with an empty method name, but it would've been nice if YUIDoc had actually reported these problems, rather than requiring me to manually find them myself.

Does your framework support spritesheets? which is more or less a common occurrence e.g. http://getsetgames.com/wp-content/uploads/2010/04/grossini_dance_atlas.png

The issue:

Repro:

var s, g, ball;

function setup() {
  createCanvas(400, 400);
  g = new Group();

  s = createSprite(200, 75, 200, 0);
  s.immovable = true;
  s.debug = true;
  s.setCollider('square');
  g.add(s);

  s = createSprite(200, 325, 200, 0);
  s.immovable = true;
  s.debug = true;
  s.setCollider('square');
  g.add(s);

  s = createSprite(251, 275, 0, 0);
  s.setCollider('circle', 0, 0, 50);
  s.immovable = true;
  s.debug = true;
  g.add(s);

  s = createSprite(149, 125, 0, 0);
  s.setCollider('circle', 0, 0, 50);
  s.immovable = true;
  s.debug = true;
  g.add(s);

  ball = createSprite(200, 200, 0, 0);
  ball.setCollider('circle', 0, 0, 10);
  ball.debug = true;
  ball.velocity.y = 5;
}

function draw() {
  background('#fff');
  ball.bounce(g);
  drawSprites();
}

This code will paint a red dot in the middle of a square canvas with simple P5.js - when resize the red dot stays in the middle of the screen. If you include the p5.play.js library in the head of index.html, change nothing in 'sketch.js' the red dot will 'drift'.

In short P5 is messing with the resizeEvent :(

sketch.js

function setup() {
  createCanvas(windowWidth, windowWidth);
}

function draw() {
    background(0);
    noStroke();
    fill(255, 0, 0)
    ellipse(windowWidth/2, windowWidth/2, 10, 10);
}

function windowResized() {
  resizeCanvas(windowWidth, windowWidth);
}

index.html

<html>
<head>
  <meta charset="utf-8">

  <!-- Libraries -->
  <script src="js/libraries/p5.js"></script>
  <!-- <script src="js/libraries/p5.play.js"></script>  -->

  <!-- Javascript functionality -->
  <script src="js/sketch.js"></script>
</head>

<body>
</body>
</html>

Currently it seems our private methods and properties are documented by our YUIDocs. As far as I can tell, it seems this is because YUIDocs templates only remove entire classes and modules marked @private from their documentation output--not individual methods and properties. This is a bit of a bummer.

Some ways to get around this:

• Hack our copy of the theme. (Not a huge fan of this.)
• Somehow make it possible for the theme to not publish the private methods/properties, and push this functionality upstream. (This could take a while.)
• Make a yuidoc filter that removes the private methods and properties from the output data.json file. This is pretty straightforward and I've done something similar in processing/p5.js#1295; it basically just consists of writing a node module that exports a function that takes the data.json blob and modifies it in whatever way it wants, after which YUIDoc will write it to disk.

I thought it might be neat to either add a new method or overload Sprite.setSpeed() like so:

setSpeed(speed, targetSprite)

This would just make the sprite move towards the targetSprite at the given angle.

This is just an idea, not sure how useful it'd be to our users.

I was just reading through the docs and noticed that our Sprite constructor is documented as a public function.

However, another method we have to create sprites is the createSprite function, which actually seems preferable, because it adds the newly-created spite to allSprites. Should we actually deprecate using the Sprite constructor directly, or mention in its documentation that the reader will probably want to use createSprite instead?

Love p5.play! I use it in a class. I found a problem looking at a student project. If a sprite moves off screen and isn't removed, any subsequent collisions using a sprite group its in will break when quadTree is true. The following code shows the behavior. To see the error, let the first spawned block go off the screen. I've found subsequent collisions to break.

var player;
var pickups;
var count;

function setup() {
  createCanvas(200, 400);

  player = createSprite(100, 360, 20, 20);
  pickups = new Group();
  count = 0;
  //useQuadTree(false);
}

function draw() {
  background(240);

  player.overlap(pickups, playerPickupCollision);

  if (count >= 80) {
    var pickup = createSprite(random(10, 190), -10, 20, 20);
    pickup.velocity.y = 2;
    pickups.add(pickup);
    count = 0;
  }

  if (keyIsDown(LEFT_ARROW)) {
    player.setSpeed(-4, 0)
  } else
  if (keyIsDown(RIGHT_ARROW)) {
    player.setSpeed(4, 0)
  } else {
    player.setSpeed(0, 0)
  }

  drawSprites();
  count++;
}

function playerPickupCollision(p1, e1) {
  e1.remove();
}

I tried sorting through the quadTree code and got a bit lost.

I think it's just npm docs right? Would be nice to document it in the README.

If p5.js angleMode(DEGREES) is called, p5play doesn't work properly anymore.

See code-dot-org/code-dot-org#8243

Would be nice to have a moveTo method built in for easy basic directional movements

e.g.

setSpeed(1); // set the speed of movement
changeAnimation('run'); // set the animation 
moveTo(x,y[, rotation]); // moves the sprite to x,y values, rotation optional

Created a simple map using an array to generate blocks. When running on a long string of blocks, touching.right worked fine but touching.left would trigger from corner collisions. Thus making collide() trigger and stop movement.

example with touching.left being logged to console

I have no idea how to regenerate the reference documentation for this project.

It would be great if we had an npm docs command or something that rebuilt them.

It would be really cool if npm start also rebuilt the docs whenever changes were made to lib/p5.play.js, but I suspect this would require adopting grunt or gulp (I prefer gulp, but we can use grunt if we want to maintain parity with p5.js development).

We might also want to consider removing the built docs from the repository, so that we don't need to spam the commit history with rebuilds of the documentation whenever we change it.

There's a number of problems with the documentation for these methods:

• They claim that a Group must be passed in as the first argument; however, as far as I can tell, these methods are all analogous to the eponymous methods in Sprite, which actually accept a Group or a Sprite as their first argument.

• Similar to #23, Group has two overlap methods documented, and no collide method documented.

• The examples for these methods seem to be copy-pasted from their eponymous methods in Sprite, which is confusing. For example, the Group.displace() example says:

  sprite.displace(otherSprite, explosion)

  but it would make more sense to have e.g.

  group.displace(otherSprite, explosion)

p.setup = function () {
            canvas = p.createCanvas(1000, 1000);
            pg = p.createGraphics(1000, 1000);
}

Uncaught TypeError: pInst.createVector is not a function
Camera @ p5.play.js:2387
(anonymous function) @ p5.play.js:2359
get @ p5.play.js:58
p5.Graphics @ p5.js:11555
p5.createGraphics @ p5.js:13288
p.setup @ RTChess.js:58
(anonymous function) @ p5.js:8900
_runIfPreloadsAreDone @ p5.js:8853
_decrementPreload @ p5.js:8862i
mg.onload @ p5.js:17669

It works in non instance mode, but seems not be working for instance mode. Am I doing something wrong?

Alternatively, we could just have the linter detect for undeclared globals, but I'm not sure if that's possible with jshint... My main intent here is to prevent regressions like #59.

This is a bit more of a "wouldn't it be cool if..." sort of enhancement, but I thought that it would be great if some of the more complex methods in the reference docs actually linked to relevant examples, to provide a better context for their use.

For example, it would be cool if the reference docs for Sprite.displace linked to the collisions example.

I suppose an even better alternative might be to do what p5's documentation does, and actually provide an environment for running and tinkering with full example sketches in the documentation itself (here's an example).

I'm using P5JS 0.5.6 with your library and I have a in the

setup() {
var sprite = createSprite(0+400 * x + 200 , 0+400 * y + 200, 400,400 );
    sprite.addAnimation('singing'
      ,loadAnimation('assets/images/reject'.concat(i+1,'b.png')
      ,'assets/images/reject'.concat(i+1,'a.png'))
    );

    sprite.shapeColor = color(random(255), random(255), random(255));

....

however when running the sketch I get in the console

Warning undefined frame 0

The images are loaded via the preload() but they do not appear on the canvas despite having drawSprites in the draw()

any suggestions as to what this might be?

Not sure if this is a big deal, but I noticed it when I accidentally wrote the following code in a test:

var mySprite = createSprite(1, 1);
allSprites.add(mySprite);

console.log(allSprites.length);

The number 2 will be logged to the console.

This is because createSprite() actually adds mySprite to allSprites on its own, so the call to allSprites.add() actually adds it again.

This could lead to weird behavior. For instance, since our current implementation of Group#remove() only removes the first reference to a sprite, this could result in unexpected behavior if someone's code calls it but it doesn't seem to "work" because another reference to the sprite still exists in the Group.

Not sure what we should do about this. Two options I can think of:

• Use the ES6 Set class instead of Array for Groups, and use a Set polyfill when it's unavailable.
• Alternatively, if we want to keep as much backwards compatibility as possible, we could just add a check to Group#add() that first checks to see if the given sprite already exists in the group... The user could still shoot themselves in the foot in a number of ways since Group is also an Array, but at least we'd prevent the most common ways of doing so.

with reference to https://github.com/molleindustria/p5.play/issues/129

the sprite.width and sprite.height gets the image width and height. Could it not also set the image's with and height?

if you create a sprite with the dimensions less or greater than the an image's and then add the image to the sprite ...shouldn't the image be resized to fit the dimensions of the sprite?

If not shouldn't there be some way to do it from the sprite?

Some complexity in supporting instance mode was introduced because there wasn't a way for extension libraries to do initialization when a sketch is first created. This resulted in us having to create a function called defineLazyReadOnlyP5Property(), among other things. Some discussion about the complexity is at https://github.com/molleindustria/p5.play/pull/22#discussion_r53211269.

Anyways, since then, I've contributed a new 'init' registerMethod() type to core p5 in processing/p5.js#1291, so going forward, we could potentially use that instead of defineLazyReadOnlyP5Property(), which could simplify p5.play's internals a bit.

Not sure if it's an issue or on purpose, but sprite.height returns its position.y, not its actual height.

As @islemaster noted in https://github.com/molleindustria/p5.play/pull/66#discussion_r57763538, a number of return types in the docs are just {Object}, when in fact they could be more specific, e.g. {Sprite|Group}.

It would be nice to go through the docs and fix these.

We dropped support for ESLint >= 2.10.0 in #92 due to a regression causing a false positive when linting our code. The fix for the regression has been merged to master so it should probably go out with 2.10.3. Once that happens, we should update our dependency to allow the newer versions with the fix.

I get errors when using the key methods.

I tried one of your examples:

if (keyWentDown("x") || mouseWentDown(LEFT)) {
  asterisk.velocity.y = -JUMP;
}

but it gives me this error message in the console: Uncaught ReferenceError: keyIsDown is not defined

Hi,

I've been using your addon lately and love it! Thanks, awesome work!

Couple things, maybe we should change the names of the events from things like onMousePressed() to simply mousePressed() in order to stay in line with the p5/processing style. Same thing for mouseOver() instead of onMouseOver() etc... Generally we try to keep methods names up to 2 words.

And maybe this should be it's own issue, but when creating a class I can't seem to set something like onMousePressed() onto the prototype, though it works in normal context

here is an example of what doesn't work

var myChar;

function Character(){
  this.sprite = createSprite(400, 200, 50, 100);
  this.sprite.addAnimation ("standing", "./assets/myChar01.png", "./assets/myChar04.png");
  this.sprite.mouseActive = true;
  this.sprite.onMousePressed = function() {
  console.log('pressed on character!')
  }
}

function setup(){
  myChar = new Character();
}

function draw(){
 ...
}

any idea?

A bit similarly to processing/p5.js#1134, it'd be nice to run all the examples in the examples directory during npm test just to make sure that they don't throw anything during setup or after rendering the first frame.

Issue: In latest release of p5.play sprite and collider box are drawn off center.

Here's an image of a sprite with debug turned on. The center is drawn correctly but the sprite itself is drawn as if rectMode is set to "CORNER" rather than "CENTER":

Here's the same sketch using the same version of p5.play that's used in the examples on the your website:

You can download the sketch used to create these images here:
colliderTest.zip

You can recreate for yourself by downloading the latest p5.play release from the website.

Hi, there.

I tried p5.js and p5.play in instance mode, like this.

However, it stay loading...

Please tell me, is p5.play running in Instance mode?

<body>
    <div id = "p5Canvas"></div>
    <script src="http://cdnjs.cloudflare.com/ajax/libs/p5.js/0.4.7/p5.min.js"></script>
    <script src="/js/p5.play.js"></script>
    <script>
    var img
    var s = function(sketch) {
        var x = 100; 
        var y = 100;
        sketch.setup = function() {
            sketch.createCanvas(800,400);
            sketch.background(200);
            sketch.fill(255);
            img = sketch.createSprite(400, 200, 50, 50);
        };

        sketch.draw = function() {
            sketch.drawSprites(img);
        };
    };

    var myp5 = new p5(s, "p5Canvas");
    </script>
 </body>

The following codes remains two sprites.
Am I missing something?

// Group
var pumpkins;

function setup() {
  createCanvas(300, 300);
  pumpkins = new Group();
  for(var i = 0 ; i < 5 ; i++){
    var sprite = createSprite(random(0, width), random(0, height / 2)); 
    sprite.velocity.y = 1; 
    pumpkins.add(sprite);
  }
}

function draw() {
  background(255);
  drawSprites();
}

function mouseClicked() {
   pumpkins.removeSprites();
}

The following "removeSprites" code in p5.play.js looks fine.
("@method clear" should be "@method removeSprites")

  /**
  * Removes all the sprites in the group
  * from the scene.
  *
  * @method clear
  */
  array.removeSprites = function() {

    for(var i = 0; i<array.length; i++)
      array[i].remove();

    array.length = 0;
  }

@karneaud just reported on PR #8 that they:

"Tried to install bower p5.play --save and got

ENOTFOUND Package p5.play not found

The folowing was originally noted in #42.

The documentation for keyDown states:

Like p5 keyIsDown but accepts strings and codes

However, the implementation is checking to see if the internal key state is specifically equal to KEY_IS_DOWN. The problem is that the internal keystate might actually be KEY_WENT_DOWN, in which case the method will retrun false but keyIsDown() will be true!

It's understandable that no one has noticed this, because it just means that the result of keyDown will be inconsistent with keyIsDown for only the frame in which the key went from up to down.

A parallel problem exists with mouseDown/mouseIsDown, as well as mouseUp.

@islemaster has some thoughts on it:

I knew about this. I definitely want to fix it so keyDown and keyWentDown
are not mutually exclusive states. I figured it wouldn't happen soon
though, since it's technically a breaking change. I also want to check
whether @molleindustria did this on purpose, to circumvent a certain set of
beginner mistakes.

If we had a release process and semver I would bundle this with other
breaking changes in a major version. Since things are still pretty fast and
loose (and I don't think anyone auto-updates this library?) maybe we can
just fix it.