Ashley's Forum Posts

  • When we first released Construct 2 no browsers had hardware acceleration and the games only worked on Chrome and Firefox. We had threads just like this one, but saying that HTML5 sucked for desktop browsers, go make a native engine or use Flash instead, etc. etc. I think by now it is obvious - as mentioned in this thread - that desktop browsers generally work excellently. I am totally convinced we cannot beat node-webkit for quality of desktop exporters. So I would like to assert that there is no need for a native engine on desktop (barring dumb decisions over hardware acceleration on XP and Vista which I hope they reverse). In fact I would go so far as to say that having written a native or Flash engine for desktops in the first place would have done a great deal to hold us back. Here are some of the technical problems raised by writing a native/different tech port:

    • exact compatibility with a browser is probably impossible, without actually writing what amounts to a new browser engine. So inevitably there will be a list of features that are incomplete or simply not supported.
    • exact compatibility with the features that are supported is very difficult. There are likely to be subtle bugs or variations in behavior that trip up games in obscure ways and make ports more difficult. All third party addons can probably be assumed to never be supported.
    • the rate of improvements to the engine and editor would have been significantly slowed while we were bogged down by the technical debt of having to maintain multiple codebases in parallel. We probably could not have got to where we are today if we had taken on that extra work.
    • the whole point of the exercise is to improve performance, but on GPU-bottlenecked games, the GPU is still the same, so making a native engine would still not actually improve performance at all in that case.
    • eventually the work is redundant, because HTML5 on desktop is good enough, but we would be obliged to keep supporting the native ports since some users would by then depend on them.

    In short we'd just trade one set of complaints for another: difficult to know which features work on which platforms, annoying random bugs when porting, things aren't progressing fast enough, etc. If you look at some other tools you can see they are definitely affected by those problems. I do think it's actually a good thing for users that we made this decision on desktop. And this may be a tough pill to swallow right now, but we're making the same decision on mobile, and I'm convinced it will pan out just as it did with desktop.

    Mobile performance is already excellent on many devices: my Nexus 5 can get 20,000 sprites on-screen at 30 FPS - faster than many desktop systems. Crosswalk is effectively the node-webkit for Android, and matches that performance. Crosswalk will support IAP, ads and screen orientation lock within a few months - we're working with Intel on that, and it only first released recently as beta, so it was always going to take some extra time to sort out all the features everyone wants.

    We often get complaints about mobile performance which are clearly limited by the GPU hardware, such as the fillrate. For example if 'Low quality' fullscreen mode improves your game's performance, the engine is doing identical work, except the GPU hardware has less work to do, so it's clearly hardware-limited and nothing would be gained with a native engine. In this case we usually have a tough time explaining that it's not a problem with Construct 2, you just designed your game in such a way as to exceed the hardware capabilities of the device. In these cases, a native engine would not be faster, because it uses the same GPU. For low end devices you have to be extremely careful, and a native engine won't stop you throwing more sprites at the GPU than it can handle.

    So we could make a native engine, but it would have incomplete feature support, probably introduce obscure bugs when porting, slow down overall development at Scirra, not actually improve performance on GPU-bottlenecked games, and have ongoing technical debt even after HTML5 becomes excellent on mobile. There is no magic bullet that makes everything perfect, and a native port would just trade one set of problems for another, and I don't think they'd even be a "nicer" set of problems.

    There are some cases where performance is a problem, particularly the Android stock browser and iOS native apps. These are often solvable with software updates. Just as with desktops being slow due to no hardware acceleration, subsequent software updates fixed that and now in many cases it's super fast. Chrome for Android is replacing the stock browser steadily, and future iOS updates could introduce features like WebGL and JIT for apps. There is a lot more going on in the tech world, all moving in that direction. So working on native ports could even become redundant fairly quickly. That's why we think it's best, even with our plans to expand the team this year, to stick to the HTML5 engine and work on other compelling and highly-demanded features like multiplayer. I know some of you won't like this choice, and we'll likely keep seeing threads like this for some time. But I would encourage you to spend more time thinking about where things are likely to be in the near future. Things are not standing still; they are literally changing month by month. If we didn't think HTML5 was an absolutely solid choice for the long-term prospects of our engine, we'd already be working on native ports.

  • From a cursory look, Playmaker is very different to Construct 2. It looks like it's based on 2D flowcharts, whereas Construct 2 uses a list of events and sub-events that work by filtering instances (see how events work).

  • I don't think modern mobile networks are as bad as you think. Admittedly I've only done one or two tests, but connecting over HSPA cell data in the UK only added 20ms to my ping time to a US server (70ms from cell data, 50ms from wifi), and was otherwise responsive and smooth. The main problem with testing this is none of the tests we've made support touch input properly yet. Maybe I should make one specifically for testing in Chrome for Android...

    Anyways the multiplayer engine can cope well with high packet loss due to the buffering techniques it uses, and usually only complete packet loss (e.g. temporary reception drop, such as going through a tunnel on the train) will trip up the game. The biggest problem from the tests that I've seen is that a high PDV makes the synchronisation unstable, but I haven't done enough testing or research to know if PDV is worse over cell data. It might not be.

  • Yep, hopefully we'll get a solution soon, but the way asm.js works is kind of tricky. Meanwhile the workaround is of course just to skip minifying.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Are you using asm.js physics? I think there's a known bug where it gets broken by minify on export, but I'm not aware of anything else other than badly written third party addons that are also broken by minify.

  • Right now we're focusing on completing the engineering work. We will be considering custom-hosted infrastructure later down the line but don't have any clear plans right now.

  • True Valhalla - as of r163 they're well-optimised, stable and complete in the sense that we don't have any immediate plans to add further improvements. That doesn't mean we never will though.

  • It's not on the roadmap at this time.

  • Do not attempt to translate Construct 2. The feature to load strings from the .xml file was never finished. You cannot translate all of Construct 2, and sometimes if you translate something, it will break that feature.

  • We have no ETA, but it's taking longer than usual due to the sheer scope and complexity of the new multiplayer feature. Hopefully the next beta will be out within 1-2 weeks.

  • The 'Window size' project property is poorly named. It should be called the 'Viewport size'. (I don't think we will change it because other expressions and a lot of documentation refer to the same name.) It just sets how much of the layout you can see.

    When the game is actually displayed at runtime, the size it ends up on your screen is the display size. For example you could have a 'window size' of 854x480 and use letterbox scale mode to display it at 1920x1080. In that case the viewport to the layout is 854x480 and the display size is 1920x1080.

    In 'High quality' fullscreen mode, in practice only the display size affects performance. Note if you run a game in a browser window, you can resize the browser smaller and notice it's running faster. This is because the display size is smaller, so there's less GPU work. The project viewport is still the same (i.e., the project 'Window size' property has not changed, even though you resized the browser window. I do regret choosing that name for the project property!)

    In 'Low quality' fullscreen mode, the game is rendered at the 'Window size' in project properties, and the result simply stretched up to fit the screen. Usually the stretch is fast and the performance impact can be ignored, so the display size is effectively the same as the viewport size. Since the viewport size is usually smaller than the display size, this improves performance.

    In no case has the memory use changed. The viewport and display size do not affect the textures that are loaded to memory, which are always fully decompressed images at their original size they appear in the image editor.

  • Juryiel - in my experience, 90% of users don't even read the message, and click the first button. Then when it crashes they will email you complaining!

  • Perhaps contrary to 'test mode' it still fires the 'success' handler in the real store, but with 'Has product' returning false. This is at best confusing design on the part of Microsoft, and I'd consider it a bug... but we might be able to work around it.

    I presume it works fine if you add the 'Has product' condition under 'On successful purchase'? And if 'Has product' is false in that trigger, treat it also as a failed purchase.

    If that workaround works we can build it in to the plugin itself.

  • Scirra can't really take responsibility for the accuracy of information posted on third party sites. There's just no way we could logistically manage that. Also like the OP says I would strongly recommend not covering anything any official documentation covers; that is written as accurately as possible and is kept up to date with every stable release, whereas user-submitted documentation might not be.

  • Andre Krug - note that Construct 2 games stream audio after loading, so if you are concerned about loading times, don't count audio files in the 3mb limit.