Ashley's Forum Posts

  • That's right, we're keen to expand it soon but we're extremely busy right now with the C3 launch.

  • As always a minimal project if you can provide one is far more useful, otherwise you can email it to

  • If you can provide a minimal .capx that shows high draw call usage, I'd be happy to investigate optimising the engine. Without that the most I can do is speculate.

  • Draw calls is another matter really, and happens on the CPU side. It's probably best to split that topic off to a new thread. We have OpenGL ES 3 equivalent capabilities with WebGL 2 though, so if at any point draw calls prove to be a bottleneck, it's something we can potentially optimise in exactly the same way a native app would adjust their draw calls to be more efficient. Most 3D APIs, WebGL included, are specifically designed to allow as much drawing as possible with the fewest draw calls, to as far as possible eliminate the CPU overhead.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I think all modern OSs double buffer everything on-screen. Certainly all modern graphics applications do.

  • Also if it is fillrate-bound, how is that combated? I assume that's what it is since if I minimize to the standard resolution (640 x 360) I get a constant 60 fps, but that's a bit unrealistic to play at, and even using low settings it doesn't change anything.

    If using a lower display resolution makes it run faster, you've basically proven it's GPU fillrate, exactly as I suspected. I can take a look at the .capx if you email it to me (), but I am sure it's that just based on what you've said.

    Force-own-texture layers (which includes any with an effect, blend mode or opacity other than 100%) add a lot to fill rate, as do any large sprites or tiled backgrounds. You have to reduce the number of those you use.

    I always laugh at this argument. "Graphics card drivers are bad!"

    Ask any low-level graphics programmer how they would characterise drivers. Watch them bang their head against the nearest desk/wall while wailing. This is an industry recognised issue, and I backed it up with references in my earlier post. What makes you think this is not actually the case? Do you think those references I provided are wrong? If so, why?

    [quote:1rffrqe3]so you decided to use possibly the most unsupported and experimental platform

    This is ridiculous. WebGL is a robust, reliable and widely-deployed technology, which actually to a large extent sanitises OpenGL support by closing off some gotchas, defining previously undefined behavior, and working around driver bugs where feasible. To illustrate the point, on my high-end dev machine if I go to chrome://gpu, Chrome tells me all the driver workarounds it's applied, which are the following:

    [quote:1rffrqe3]Some drivers are unable to reset the D3D device in the GPU process sandbox

    Applied Workarounds: exit_on_context_lost

    TexSubImage is faster for full uploads on ANGLE

    Applied Workarounds: texsubimage_faster_than_teximage

    Clear uniforms before first program use on all platforms: 124764, 349137

    Applied Workarounds: clear_uniforms_before_first_program_use

    Always rewrite vec/mat constructors to be consistent: 398694

    Applied Workarounds: scalarize_vec_and_mat_constructor_args

    ANGLE crash on glReadPixels from incomplete cube map texture: 518889

    Applied Workarounds: force_cube_complete

    Framebuffer discarding can hurt performance on non-tilers: 570897

    Applied Workarounds: disable_discard_framebuffer

    Limited enabling of Chromium GL_INTEL_framebuffer_CMAA: 535198

    Applied Workarounds: disable_framebuffer_cmaa

    Zero-copy NV12 video displays incorrect colors on NVIDIA drivers.: 635319

    Applied Workarounds: disable_dxgi_zero_copy_video

    Disable KHR_blend_equation_advanced until cc shaders are updated: 661715

    Decode and Encode before generateMipmap for srgb format textures on Windows: 634519

    Applied Workarounds: decode_encode_srgb_for_generatemipmap

    Native GpuMemoryBuffers have been disabled, either via about:flags or command line.

    Disabled Features: native_gpu_memory_buffers

    That's a list of bugs - and performance issues! - you will run in to and need to work around yourself if you don't use WebGL, for just one modern and up-to-date system. Think about extending that across the entire ecosystem of different OSs and hardware. So actually WebGL is a more robust graphics technology. Browser vendors have done a huge amount of workarounds already to maximise reliability and performance.

    Given that, on what basis do you believe this is an experimental technology?

    [quote:1rffrqe3]That still runs on graphics card drivers!

    I'm not sure what your point is, because literally every other GPU-accelerated technology also depends on drivers.

    [quote:1rffrqe3]Personally, I'd rather pay $100/year for Scirra to make a commercially sold large 2D pixel-perfect retro platformer in their own engine and then release and troubleshoot it on Steam

    We have effectively already done this with the Construct 2 editor itself, which has in the past faced severe graphics drivers (e.g. crash on startup). To this day there is still the odd crash-on-startup issue due to graphics drivers. It is incredibly frustrating and difficult and costs us sales. This is literally one of our motivations to use web technology. We've done the native side and seen how excruciating that can be. WebGL is better! I'm not sure what you expect us to do about it, either - do you think I can just phone up AMD and tell them to fix a wide range of bugs and then retroactively install that to millions of PCs worldwide? We could change technologies, but that could easily make it worse, as I've shown above. What are you expecting us to do in response to these issues?

  • Ashley - Yes, mine is hardware accelerated. I think that's kind of our point - for the game I'm working on, my CPU never goes above 50%, my RAM is always less than 40mbs, and I'm not using any effects, yet somehow I'm unable to get a constant 60 fps (sometimes I sit in the 30s). If not HTML5, CPU, or GPU, what else could be causing something like that?

    If the CPU isn't maxed out, the most likely thing is... the GPU is maxed out. So the hardware is the bottleneck. The most common reasons I've seen in practice is it's fillrate-bound (maxing out memory bandwidth), which is exactly the kind of thing which people blame on HTML5/browsers/us without realising it'd be identical in any other engine. I'd take a look at your .capx if you're willing to share it.

  • I can't give any ETA right now. We have been insanely busy for months with the broad scale launch of C3. It's on the list.

    • Post link icon

    Right, except most users can side load apks.

    AFAIK most Android devices by default only allow APK installation from the Play store unless you modify the settings, which makes side-loading unsuitable for mass market distribution (probably another intentional side-effect).

  • Just go to chrome://gpu and see what it says. WebGL 1 or 2 should say "hardware accelerated" in green. Construct will pick whichever one is hardware accelerated.

    • Post link icon

    You mean Google, right? Yeah, it's pretty standard that they ban you from circumventing their payment system, so they can collect their 30%.

    • Post link icon

    The standalone versions are intended as a supplement to the browser-based version, to cover a few features that can't be done in the browser like direct disk access. We'd prefer to unify our offering across all the products, because it's simpler for us and easier for customers to understand. Having mixed patterns depending on where you use the product is pretty confusing for a new user IMO.

    In addition to that, we can't produce standalone versions for every platform. Standalone on Android - which already has surprisingly large usage, comparable to Mac - would mean sacrificing 30% of our revenue via the Play Store, which we really want to avoid, and may in fact be infeasible to integrate with our own payment system (Google has an entirely separate payment system and rules about how it can be used). "Add to homescreen" is also very much app-like and does not involve any revenue cut at all, so providing a standalone version would be difficult, provide little functional benefit, and cost us a significant amount of revenue. Chrome OS - where we have no other major competitors and a great opportunity, particularly in education - cannot provide any standalone version at all. We can't tell Chrome OS users to switch to a different OS to use a standalone product. We'd rather come up with one system focused on browser usage that covers everything. The standalone versions are basically a bonus for Windows, Mac and Linux users only.

    When I make posts like this, some people seem to accuse me of "shutting down the conversation" - that's not what I'm setting out to do, I'm pointing out the difficulties with all of these alternatives. It's easy to sit back in your armchair and claim all the solutions are obvious. It's really not: every approach we could take has tradeoffs like this, and there are a lot of different angles to consider.

  • Touch.Alpha gives the compass bearing, so you're using the wrong value here.

  • (Moved to C3 forum)

    "QuotaExceededError" most likely means your system has run out of storage space. Chrome uses a quota system which limits web page's access to disk so you may still get this with some free space available. If you increase the free space it should start working again, so try freeing up some space on your hard drive.

    At the moment running out of storage causes C3 to crash; it shouldn't, but it's hard to develop the feature.

    This issue tracks making Construct 3 more robust in the face of storage failures.