Ashley's Recent Forum Activity

  • 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

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • 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?

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,773,960 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
  • x5
    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
  • x42
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs