Ashley's Recent Forum Activity

  • 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...

  • Rotary is now closed! Yes it's fine if we don't approve it till after the deadline. If technical reasons have prevented you submitting we'll allow it in late too.

  • There was a bug a few releases back involving hotspots. One of the release's notes stated you had to open every layout in the project then save the project to fix the issue permanently. Maybe you missed that? Perhaps if you try it it'll fix something?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • OK. Triggers have to trigger in some order, and they check their parent conditions at the moment they run, so it's just an order of events issue. Closing as by design.

  • You do not have permission to view this post

  • We already have our bugs forum which we started using as a temporary replacement for a real bug tracker since we both have far too much to do already, and actually it's working out OK (since it integrates to your forum accounts and can also use the forum's notification system when posts are updated/people are mentioned), so I think we'll stick to that for the time being.

  • I've no idea why this might happen. Are the objects positioned by events? Does minifying the script affect it? If you can reproduce this in a new project that would be great.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,831,080 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x6
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x44
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs