inductible

Members
  • Content Count

    32
  • Joined

  • Last visited

About inductible

  • Rank
    Advanced Member

Contact Methods

  • Twitter
    inductible
  1. How did it work out? I'm intrigued by this question too!
  2. Just studying Flambe/Haxe for professional use (actually it's a requisite of a client brief)... I've looked into Haxe before but dismissed it because I feel the need to be closer to the actual 'runtime' code (not have it authored mostly by a machine). Having gone through the Flambe demos on a range of devices (iPad1, Kindle 1st Gen, Macbook pro, iPad3, Samsung Galaxy Tab 2), checking HTML5 output, I can only say I am very, very impressed at both performance and support for tricky things like audio. I'm concerned that not more people are using this combination of dev tools though - I can only guess it's due to the relative obscurity of Haxe - it's well documented in places, but not at all elsewhere. I shall definitely pay both Haxe and Flambe more attention from now on however! It really is magic - I just want to know HOW it works - is there an intermediate language that Haxe compiles to, with this mapping to other sources e.g. JS (like LLVM)? This 'source of the magic' is seemingly nowhere to be found on the web.
  3. Hullo, I'm talking along the same lines as the following: http://developer.samsung.com/forum/board/thread/view.do?boardName=GeneralB&messageId=235672&frm=7&tagValue=HTML5&curPage=1 Basically, on a range of Samsung devices I have here (Android 4+, stock browser), any touch interaction stops DOM redraw and canvas rendering, until a) the touch is moved by a small distance (at which point rendering continues, even whilst touch is still down) or the touch is ended (finger removed from screen). I have never found a workable solution to this issue, which I've been faced with now on four projects, and sunk countless hours into it. Does anyone on this forum have any experience or anecdotes relating to this issue? There's so little info on the web about it, which is very surprising, because it's such a critical game-breaker of a problem. I know that Chrome is (now finally) the default browser in Android 4.4+, but there's a *lot* of people out there that strangely still swear by the (Samsung bastardised) stock offering...
  4. The old 'recursive function call death loop' - you likely registered 'this' with itself in bad guys array? Update called update called update etc.
  5. Just getting stuck into Phaser now, after having been through the arduous (but very necessary) learning process of rolling my own engine from scratch, for several production titles. I am incredibly impressed with the cleanliness of the Phaser API - and I cannot wait to get up to scratch with the engine and contributing to it's growth, 'on production' as it were. Massive thanks to Richard and Matt (and every other author) for your epic contributions to an embryonic industry - you shall never be forgotten
  6. I've recently run into this, and drawn up a blank - no idea how to resolve it: http://www.bbc.co.uk/cbeebies/tee-and-mo/games/tee-and-mo-face-painting/ http://www.bbc.co.uk/cbeebies/tee-and-mo/games/tee-and-mo-picture-perfect/ I investigated a DOM rendered alternative approach, because I can see in my case that another DOM rendered CSS anim occurring on touch move was still correctly rendering. This turned out to be inconclusive until I had to park things for another day though.
  7. Well... This morning an automatic over the air update obliterated 'default on' webgl in Silk, and, so far as I can see, there's no way to turn it back on. Amazon.... for just one moment, you had an iotum of respect.
  8. Just the HDX: http://media.tojicode.com/q3bsp/ Still got an app store that crashes every 2 mins (about long enough to browse the entire catalogue TBH), and a buggy keyboard though
  9. Just fired up webgl quake on my shiny new Kindle Fire HDX, and lo... webgl. Super fast. In Silk browser. This browser has caused me so much grief on the HD and first gens this year I never thought I'd be impressed by the latest iteration of it - applause to Amazon.
  10. Edit: I clearly need to check the post thread - this answer is relevant to pixi, not Phaser (though phaser can/does render via pixi, so this may be a valid solution still?) You can look at using a RenderTexture to blit to a canvas, or (a solution I deployed recently), simply manage another Pixi display list (another Stage object) with it's own renderer (with a view that you never add to the DOM). So long as any secondary Stage objects don't use interactivity (i.e. no unnecessary overhead), it'll let you do some pretty powerful things with 'pre-composition', etc. You can use the secondary renderer's view as a new baseTexture via Sprite.fromCanvas()
  11. I have the same redraw issue on Galaxy S2 - touchmove seems to suspend repainting. I am preventingDefault on relevant events, etc, but no dice. There's a related listing here: http://stackoverflow.com/questions/7628828/javascript-page-repaint-halted-during-touchmove-event, but I don't think there's a satisfactory solution on the interweb yet. What boilerplate code worked for you Stevenisvader - do you know what fixed it specifically?
  12. I can validate Aymerics suggestion to modify the 'standard' viewport meta tag properties (initial-scale=1.0, maximum-scale=1.0) - I'm using just "user-scalable=no", and my pixi canvas remains acceptable on high DPI devices as a result. However... With iOS7 there's now a flickering black line along the edge or both edges of the canvas when I omit the 'initial-scale, maximum-scale' attributes! Nightmare. I'm looking for a way to balance high DPI crispness without visual artefaction introduced by this important browser.
  13. I ended up tweaking Pixi to open up a new 'updateInteractionMangerOnly' func, then recreated my issue with rendering effectively suspended: conclusion - my audio skippage is not related to Pixi redraw. I think it may be limited to my audio system (a custom sprite based audio tag affair), but HTML 'Audio' tag is so screwed up the spout that that's no surprise. I know there's a ton of unspoken implementation specifics here, so I won't dwell on the issue - it'll be something to do with something elsewhere! Thanks indeed for the notice about plans with interaction manager - that definitely sounds like something to look forward to... +1!
  14. Hullo, from my tentative investigation, it would appear that the InteractionManager's 'update' method (which I presume is where the magic of input event marshalling takes place) occurs within the scope of renderer.render() - certainly for the canvas renderer anyway. What I'm trying to do is get my Pixi based system set up to smartly render *only when necessary*, i.e. when the view state is deemed 'dirty'. This is due some audio performance issues I believe are related to canvas redraw... But, in the greater scheme of things it would be cool to be able to have my cake (Pixi interactivity) and eat it (skip rendering, if I want to). Before I start hacking this in at Pixi's source, I wondered (Matt!) is this something you've thought about? At a very quick glance I don't think it'd be difficult to move the interactionManager update out of the render loop, but it'd be a powerful improvement.
  15. Recently did an internal presentation at work and this app was the "where the tech is headed" headliner. Today, we need frameworks (threejs) and tools (perhaps UDK or a Unity-like editor, with asm.js as part of compilation scheme), plus another browser iteration or so for quality fare such as this to be the defacto standard... When WebGL is stable, and standard across all *mobile* browsers, then Flash hath finally gasped it's last.