Ashley's Forum Posts

  • Good point, will add to next build.

  • —: the reason WebGL is not always supported is browsers blacklist certain drivers for security reasons.

    In our EXE wrapper, we can turn off the blacklist, so WebGL is always on and enabled regardless of the user's computer. That should help ensure the EXE is always fast.

  • Oops, should be fixed in the next build.

  • I'm not sure we can fix this - it's handled by the physics engine entirely, and it only filters collisions at the start of a touch, not during. Maybe you can work around it by applying a little impulse to the object after disabling the collision? That might make it "wake up".

  • In case you didn't see our Facebook/Twitter, we're adding built-in support for this in the next build!

  • Moved to General Game Design.

  • We don't support Firefox 4, because Mozilla have released Firefox 10 and they themselves don't support older versions, and almost nobody still uses the old versions (why haven't you upgraded?). So can you reproduce this on Firefox 10?

  • I've noticed this with the Chrome 18 beta, but it's a browser bug, the browser timer is going haywire. Hopefully they'll have this fixed by the stable release :P

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • A layout represents a level, so just make a new layout and use a 'go to layout' action to go to the next level. There are unlimited layouts in the free edition!

    A layer is like a sheet of objects in a layout, and these are limited to 4 in the free edition.

  • OK, I guess we shouldn't say "nearly as fast", since our own benchmark shows that at best HTML5 comes in at 25% the performance of native. What I think I really meant is that if you render on a GPU then it's always the same speed, since it doesn't matter whether the "draw sprite" command comes from a C++ DirectX app or a HTML5 WebGL app, it renders on the same GPU. The logic in HTML5 apps is indeed slower, but the important thing is to get hardware-accelerated rendering so the CPU is not weighed down with rendering, and can spend its time on the logic instead. When hardware accelerated rendering is in use, benchmarks then just show up the CPU difference between HTML5 and native, since as our blog post notes the GPU can render faster than you can send commands to it, so the benchmark is just measuring how fast the CPU can send draw commands to the GPU, which obviously native does better at.

    For all intents and purposes WebGL and OpenGL are equivalent to DirectX in terms of features and GPU performance. We are planning to add pixel shaders and distortion meshes etc. to Construct 2 with WebGL, the only reason we haven't is we have long todo lists.

    Also I think it's worth keeping benchmarks in perspective:

    • compare Flash to native and you'll see Flash also comes in slower than native for the same reasons. So why did anyone ever use Flash instead of native? Because it's write once, run everywhere (or used to be until mobile came along), and this benefit largely outweighs the performance difference. I think this is an important comparison, since for a long time Flash was software rendered and wasn't even as fast as JS + WebGL - and yet it still conquered web gaming for many years!
    • does your game have over 1000 sprites on-screen at once? If not, you will not see much performance difference between HTML5 and native - they should both manage 60fps just fine. So since many games are simpler and use low object counts, it could actually be said that the performance the user sees is equivalent.

    Also, Javascript and WebGL can probably be sped up even faster than they are now.

    So yeah we could make a bunch of native runtimes, but remember if your game already runs at 60 fps, using a native runtime will not bring you any observable performance increase.

  • This looks like a browser limitation when WebGL is disabled. Have you got WebGL turned off or are your graphics drivers out of date?

  • You shouldn't really pre-load music because it will stream from the server as it plays anyway, saving bandwidth and allowing the pre-load bandwidth to be used for SFX only. It shouldn't matter if music starts a second or two later.

    The Audio object has a global cache for all sounds in all layouts, so I don't know why preloading per-layout would change that at all. Really all you ought to do is set up some pre-loading for the latency-sensitive sounds (explosions, gun fire etc) on the very first layout of your game. Intros or title screens are good for this, e.g. if you flash up your logo for 5 seconds usually the browser can download all your latency sensitive sounds in the background during that, then everything will be ready when the game starts. If you pre-load on start of the game layout itself, and then start trying to play the sounds straight away, they still might not have finished downloading from the preloading, so there's not much point doing that.

    In other words, just preload a few things at the very beginning of the game, then try to have 5-10 seconds before the game itself starts, and everything should be ready.

    Note this only affects the first run - the second play will load from the disk cache so there will be no delays.

  • HTML5 with WebGL support is nearly as fast as native EXE games. Poor performance in HTML5 games is caused almost exclusively by no WebGL support, which is usually due to having old drivers which the browser blocks for security reasons. —, have you tried updating your drivers?

    Have you seen our EXE wrapper alpha as well? It's based on Awesomium, which is basically the Google Chrome browser engine in a standalone EXE. The feedback has been very promising, and it's not even as fast as it could be right now. I'm hoping we can tweak Awesomium to skip the driver blacklists, then we can forget about all the driver updating: you'd have a standalone EXE that runs a WebGL-powered game at near-native performance, using the same HTML5 code, saving our 2-man team from having to take on the 6+ month job of writing a new exporter. It should also be portable to Mac and Linux desktop. Hopefully that will solve some of the platform headaches.

  • krish, it's because the image is on a layer with parallax 30, 30 so it gets offset. If you set the parallax to 100,100 it works fine. It also helps to set the layout's 'unbounded scrolling' property to 'yes'. Does that fix it?

  • ranma, what version of Android does your phone have? The Nexus One might have an out of date browser. I don't think other phones have this limitation so it's not a general limitation of 300 images, it's probably a limitation specifically with the Nexus One. Installing any updates if possible might help fix it.

    We do have sprite-sheeting planned already, but it's a reasonably complex feature and we have tonnes to do already. If other phones have the same problem I'd reprioritise it, but as it is I don't even know for certain that sprite sheets would help fix it - fewer images that are bigger might still make the phone run out of memory...