• Content Count

  • Joined

  • Last visited

About !untrue

  • Rank

Profile Information

  • Gender
    Not Telling
  1. Thanks. I think I'll try to incorporate the flag idea, since I'm probably doing too much per frame anyway.
  2. How I usually use Pixi is that the render loop will just keep going. Which is fine for things that are undergoing constant change and interaction, but I'm considering using Pixi for something more static... something that'll display a certain thing.... be interactive and respond when needed, but really be doing nothing most of the time. What I'm concerned about is the idle CPU usage... it uses a relatively small amount of CPU to leave the whole thing running at 60fps doing nothing, but it feels inefficient and wasteful. (As a user of an older mobile device, it really drives me nuts when I encounter a site that's inexplicably a performance pig.) I'm just curious what other people are doing in these situations, and how you approach this. Does it make sense to exit the render loop when everything is finished updating, then have an event put us back in? Can you stop/pause Pixi itself? Or is this just more trouble than it's worth?
  3. Thanks. I've been looking for this. This has been driving me insane for ages. I've previously resorted to patching pixi.js itself, but I hate doing that. What I find weird is how this isn't more of an issue for people.
  4. It's a problem for me too. Curious to know how people are handling this in cases where you want sharp text. I'm thinking I could overlay html/css elements on top of the canvas? Or failing that, I might design everything around a set of fixed resolutions and forget trying to scale. But yeah, it's a lot of work just to make the fonts a bit nicer looking.
  5. I've encountered this too. What I ended up doing is modifying pixi.js to not "prevent default" if the tap is also a drag (there are some "if" blocks to work with here). But I had to re-minify the dev version and it's not really ideal to be stuck doing that. The most simple way I've found without modifying pixi.js is to set this at the top of your code. PIXI.AUTO_PREVENT_DEFAULT = false;But it won't prevent touch-scrolls or pinch-zooms from pressing buttons if you touch that area to scroll. It might work for your purposes. Unless there's a way to prevent default on your buttons on an individual basis, which I haven't looked at yet.
  6. This may or may not be it, but have you tried accessing the contents of mouseData and pulling out hexId through the event target? That's how I'm doing it anyway. I think in the scope of that function, when it's called later, doesn't have any idea what shape.hexId is, and looks for it in the global scope and craps itself. Try something like this for both event handlers... shape.click = function(mouseData){console.log("MOUSE CLICK " + mouseData.target.hexId);}
  7. So, knowing I want to preventDefault for some things and not others, I've narrowed it down to. Commented out... if(PIXI.AUTO_PREVENT_DEFAULT)event.preventDefault();...from PIXI.InteractionManager.prototype.onTouchStart And added... event.preventDefault();to PIXI.InteractionManager.prototype.onTouchEnd Though I'm not completely certain with my reasoning about the code, what I'm trying to do (and it appears to be working) is to preventDefault on touches that are taps, and not preventDefault on any other kind of touch. It's doing what I want it to do now, without the weird hover & selection side effects, but my question now is, how do I roll this back into the mini-fied pixi.js. Do I just run this modified dev version through a mini-fier? (And can anyone recommend a specific mini-fier to use?) Or is there some better practice way of patching/overwriting these functions from outside pixi.js Never mind, I RTFM and built it with node/grunt. /derp
  8. Ok, I found this looking at the dev build... PIXI.AUTO_PREVENT_DEFAULTSetting it to false in my app has enabled pinch-zoom and pan touches, while still being able to click. Although it's now causing taps/clicks to leave a mouseOver on my buttons, as well as causing momentary selections of other page elements outside the canvas. Which I think a vanilla canvas does too. Hmm.
  9. I have a Pixi.js game/app embedded in a html page, and everything is working fine. The only problem is that I can't use the canvas to zoom or pan the page... this is a problem when I'm testing it on a small iPhone screen, if I position the canvas such that it takes up the whole screen, then I can no longer pan back to the rest of the page because all I can touch is the canvas. I'd also like zoom functionality for a little better usability. At the moment I'm using .tap and .click at the same time, which apart from the zoom/pan problem, is working out fine. A vanilla JS canvas seems to respond well to pan & zoom touches, as well as successfully registering "clicks", so I'm hoping this isn't something impossible. I've tried googling this and reading all the docs, but I'm going nuts trying to figure this out. It's one of those "I don't know what I don't know" problems. I assume there's some event bubbling that isn't finding its way back to the containing page... but I don't really know what to do with that.