Ashley's Forum Posts

  • You do not have permission to view this post

  • Gamepads are supported wherever the browser has Gamepad API support, which you can check for browser support here. Unfortunately since Safari doesn't support it yet, HTML5 games can't access the gamepad. Hopefully Apple will add support in future.

  • You do not have permission to view this post

  • Thanks, closing.

  • You do not have permission to view this post

  • Siberian - I removed your link - please provide evidence that you have permission to distribute the work you've described.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • OK, so that sounds like what I assumed, but you realise that doesn't work with 'Is button down' for the reasons I described, right? So you'd still need to do those conditions over. But then I guess you can also check that in a loop, which you can't do with triggers.

  • You do not have permission to view this post

  • The .capx you have provided is working correctly; the sprite artwork does indeed have a white outline as if it were rendered with alpha on to a white background, then only the exactly white sections removed around it. That's a possible mistake that's sometimes easy to make with certain tools if viewing on a light background.

    Closing as no evidence of a C2 bug here. If you think at some point C2 is adding these white outlines itself during the import process, please file a new bug demonstrating the steps to reproduce, going from external images with a correct alpha channel to the images in C2 with a white outline. I suspect however this happened before importing to C2.

  • Firstly I think you are asking for a "LastGamepadIndex" expression? The gamepad ID is a string describing it, which doesn't sound especially useful to this case.

    Secondly I don't see how it helps by itself: currently you have to always specify a gamepad index when using a trigger like 'On button pressed', so the expression would be redundant, it would always be the same as the number you already provided in the trigger. So are you in addition to that asking for new triggers which don't specify a gamepad index and provide it by an expression instead? That did not appear to be specifically outlined.

    Thirdly the way conditions work, that could not really be extended to the non-trigger 'Is button down'. If you have 'Is button A down' that is true for any gamepad, then if two gamepads press A simultaneously, then the condition still runs its actions once with a LastGamepadIndex for just one of the gamepads, since that's just how the event system works. So we could extend new gamepad-neutral triggers, but not non-trigger conditions, which then makes a sort of weird inconsistency between what you can do without a gamepad index and what you can do with one.

    This is why you should always describe feature requests in as much detail as possible, a bit like the approach with bug reports. The suggestion just raises more questions and has implications you probably didn't foresee.

  • It's by design that when the browser is minimised or goes in to the background, the game suspends entirely. This is to prevent unnecessary resource/battery drain. Generally you should not attempt to work around it, because you will cause unnecessary resource/battery drain on the user's system.

  • The main problem with older Android devices is they have buggy graphics drivers that crash the system, so browsers have to turn off GPU accelerated rendering to avoid crashing. Then you end up with a slower software renderer. It's more of an Android problem than with C2 or Crosswalk, because the drivers need to be fixed... you can force it to use GPU rendering, but then you risk crashing the system (to the extent you have to pull the battery out and reinsert it for it to work - then think about people with phones with a sealed-in battery...!)

    Newer devices should be fine.

  • You do not have permission to view this post

    • Post link icon

    McKack - I'm a bit dubious about solutions involving tweaking Chromium command line parameters. Since I don't think they're defaults, sometimes they are unmaintained codepaths, and if you run in to bugs in them Google may refuse to fix them since they're not intended to be used in production. They might also just rip out all the code and remove the option at some point, to keep their codebase simpler. Notice how chrome://flags warns you "These experimental features may change, break or disappear at any time. We make absolutely no guarantees about what may happen if you turn one of these experiments on".

    The best solution would be to contact Steam and to figure out how to get their overlay to display correctly with the default settings.

  • Turning off alpha is a performance optimisation, which apparently can make a difference to fillrate-limited devices. It means the backing canvas doesn't have an alpha channel so the alpha components don't need to be filled or processed or composited to the screen. On platforms where there is typically nothing that can appear behind the canvas then the runtime sets this mode to allow the browser to optimise it if possible. This isn't limited to node-webkit - it's also used on Windows Store, Crosswalk and PhoneGap apps for the same reason.

    I guess your plugin needs to force alpha enabled on all platforms, but I don't want to just turn it off completely since that could de-optimise it even when unnecessary. So for the next build (in r188) I added a flag in the runtime you can use to force alpha mode enabled: set runtime.forceCanvasAlpha to true. You have to set that in the plugin or type constructor, since by the time you get to an instance's constructor/onCreate it's already read the value to initialise the renderer.