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?