Ashley's Forum Posts

  • Ashley

    [quote:2fet3nbx]If HTML5 will be perfect - literally native-grade - within say 2 years, why bother taking a detour now?

    It's nice that Scirra is earning money on technology that might be reliable after next 2 years, but you should also ask yourself one question: Would you risk to sell C2 made game, i.e. exported to desktop or Crosswalk, knowing that you can't do anything IF your customers will have problems with your game? And that they will i.e. laugh at you and give 1-star reviews hearing excuses like "We can't fix this problem now, please wait a few months for Chromium team..."?

    Imagine we made a native Android exporter, then your game crashes on a bunch of devices due to an obscure bug in the Qualcomm Android graphics driver. (This should not surprise anyone, it happens.) This is exactly the same situation: some third party is screwing up the game and there's not much either us or you as the game developer can do about it. In fact, it's worse, because even if Qualcomm are receptive to bug reports (which I doubt given my past experiences with other vendors), when was the last time you updated the graphics driver on your phone? It effectively never happens. So there is basically no hope of it being fixed, short of waiting for everyone to throw away their old phones and buy newer ones. Then people would probably be on the forum with posts exactly like yours, but just talking about Android compatibility instead of Crosswalk, and instead of "please wait a few months", it's "hopefully next year's devices will work".

    Moving to native doesn't solve the problem of third parties screwing up the game. In comparison, having a company the size of Google handling device compatibility and pushing updates out every 6 weeks is pretty great compared to what happens with drivers, which is what a native engine would be directly interfacing with. Also drivers are not the only third party involved; a native engine would probably need a few third party libraries to cover some features which a browser has built-in (e.g. graphics, audio, networking...) and these libraries could have their own list of issues, and so on.

    No platform is perfect, and I think it's easy to think the grass is greener on the other side. Remember we do have native tech experience with Construct Classic's runtime, and the C2 editor itself. Graphics driver bugs in the C2 editor have been a major ongoing pain with many extremely difficult problems and is still one of the top causes of crashes in C2, and that's on Windows which is more mature and less fragmented than Android.

  • I think it's premature to design 4K games. Some systems shipping with 4K displays today don't have a powerful enough GPU to run a game at full resolution - a single force-own-texture layer could use all the fillrate you have left. I'd stick to designing assets for 1080p. Low-quality fullscreen mode is the easiest way to save fillrate, and adding an in-game option to enable it should allow your 4K gamers with underpowered GPUs to get by.

  • paradine - you're right, it makes more sense to file a bug directly with NW.js. Have you done that?

    The biggest bottleneck of C2 is most assuredly non-native exporters.

    Everything is a tradeoff. Making native exporters does not make everything in to a magical perfect world - it will trade performance characteristics for far slower development time, longer bug fixes, more difficult maintenance, slower rate of new features being added, and even new kinds of bugs (for example, browser engines implement a long list of graphics driver bug workarounds, which we will have to reimplement if writing our own engine). All of this would probably also make the product more expensive. My point is I'm asking is that all really worth it? Is HTML5 performance really that bad? If HTML5 will be perfect - literally native-grade - within say 2 years, why bother taking a detour now? (If that sounds ridiculous, consider that in 2011 when we first launched, no mobile browsers ran HTML5 at all, then for a couple of years they ran it incredibly slowly, now they run it reasonably fast but with the odd frameskip. It's really come on so ridiculously far in the past few years I think it's perfectly reasonable to imagine it being native grade within 2 years.)

  • I don't think Flash will ever go away - there's over a decade's worth of existing content on the web using Flash, such as from all those Flash game arcades all the way through 2000-2010, and some websites still use it. But I think it will definitely encourage adoption of HTML5. Firefox just (temporarily I think) disabled Flash due to the latest security vulnerabilities. I'm glad we don't have a Flash engine, otherwise I can imagine our forums flooded with upset users!

    Shumway is an interesting project - it's an SWF player implemented in HTML5... that could allow browsers to drop the Flash player but keep support for running SWFs!

  • Closing as by design.

  • You can export to a HTML5 website in the free edition, then try it on a mobile device.

  • That video says it compares game development tools, but it only actually compares their physics engines. At the time it was posted we only supported box2dweb physics. Since then we added support for asm.js physics, which is based on the compiled C++ codebase for the physics engine, and should run close to native performance. In that type of test it should make a radical improvement. Unfortunately they never updated their video, which is a shame, since it has been way faster for some time now.

  • I know how to fix it - installing Visual C++ redistributable solves the problem

    I've not heard of this before, and it's a bug if it's the case. Have you filed a bug report? Ideally the NW.js exporter can work at best performance without having to install anything extra (other than the DirectX web setup thing, which is a pain, but we had to have that for Construct Classic as well, which used... a native exporter).

    I don't think we'd make more money with a native exporter: it is an enormously expensive project, requiring more staff, more development and testing time, and other far-reaching implications (like third party plugins essentially become unportable unless the developer feels like doing 5x as much work for free). We'd probably have to put up the price of C2, or charge per-exporter like some other companies do, running up a high cost for the customer if they want all the export options. Given that it has all export options built in, C2 is one of the cheapest tools on the market.

    Independence from third parties never goes away unless we write our own operating system and device drivers. We could for example choose XNA, Haxe, Flash, or something else, and equally be hosed by problems in those frameworks.

    It's true we don't have control over the performance of browsers. It already works great on most browsers though. The performance of modern browsers is improving at an impressive rate. I haven't heard any complaints about the performance on desktop for as long as I can remember now, and I think that's enough to prove HTML5 is not fundamentally slow. The only reason mobile is sometimes slow is due to a Crosswalk bug that hung around for a while (and should be fixed in due course so it performs identically to Chrome - it uses the same codebase), and possibly the fact Cordova still doesn't use JIT on iOS by default (which should be fixed in iOS 9, and despite this I have very rarely heard of performance issues on iOS, so it seems to be OK already!) As I've said before... anything which has a fix on the horizon isn't much of a reason to give up on the technology entirely.

  • I guess you've read the blog post on spritesheets, although some details have changed (it now goes up to 2048x2048 instead of 512x512 for example).

    I agree the progress bar argument isn't really that relevant, but there are other significant considerations. It is a surprisingly difficult area with some interesting tradeoffs. One of the tradeoffs is compatibility with existing plugins, which is why currently only Sprite animations are spritesheeted. It's difficult to make changes to C2 at this stage, but I think we will make some improvements in this area for Construct 3.

    Here are some other factors that impact how spritesheets work:

    • Construct 2 automatically optimises images to PNG-8 when there are under 256 unique colors. The more images on a sprite sheet, the more likely it is to go over 256 colors. Therefore increasing the size of spritesheets can increase the download size.
    • The canvas2d renderer does not support rotated source images, which it looks like Texture Packer uses. WebGL can support this, but right now for compatibility with canvas2d images cannot be rotated to improve packing. I want to ultimately drop the canvas2d renderer, but now is too soon.
    • When downscaling images a long way, it is necessary to pad images out to power-of-two offsets in the sprite sheet to prevent mipmap bleed (which appears as thin lines appearing along the edges of downscaled images). This reduces the packing efficiency and increases memory use, but is mandatory to completely rule out this type of glitch and is why the "high quality" downscaling option exists. (I don't know if Texture Packer supports power-of-two alignment)
    • The performance test I use (an automated version of Space Blaster) is a pretty realistic test I think, and the framerate is the most important performance indicator. It does include GPU throughput, it is not a CPU-only measurement. When experimenting with the different spritesheeting strategies, I literally measured zero performance difference, even on an older mobile device (an iPad 2). I think modern drivers and GPUs are pretty good at swapping textures, and the main optimisation is actually a CPU optimisation so it doesn't have to issue "set texture" instructions, but that is pretty much a micro-optimisation and probably the least of all the concerns here. I do not believe there is any important GPU performance difference using individual images, one gigantic spritesheet, or anything else in-between.

    I also have no idea why you would ever want to manually intervene in the layout of the spritesheet. It seems to me almost completely pointless: they will have to be re-layout every time you add, remove or change an image, or even just changing some project properties causes a global spritesheet re-layout (such as changing the downscaling quality to/from "high quality"). If you manually put an image in some position on a spritesheet and then you change something else, the editor has two options:

    1) absolutely rigidly for all time insist that the image appears on the sheet where you put it. This is ridiculous, because it will reduce packing efficiency, since after a few edits it may save a lot of space to pack it somewhere else.

    2) do the automatic re-layout again and revert your changes. This makes it pointless to have a feature where you can change the layout of the spritesheet.

    Neither seems sensible, so I don't think it's worth having as a feature. C2's sprite sheet packer may not be perfect, but I think it's at least OK, it does the job of saving memory, and it does it automatically so you don't need to worry about it.

  • I'm not sure what to do about this, the physics engine is a big block of someone else's code and I've no idea how it ends up with those forces. Maybe apply less force depending on the timescale?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Were these games really running at say 20 FPS? Are they still playable like that?

  • You can try all past releases here: https://www.scirra.com/construct2/releases

  • It depends on your network configuration, particularly the NAT setup. It's not really anything to do with the .capx.

  • The thread you linked to contains a .capx with a number of events. Could you attach a minimal example made from scratch as per the bug report guidelines?

  • Can't reproduce here, it runs fine in all of Chrome, Firefox 39 and Firefox Beta (v40) here on a 2nd gen Moto X running Android 5.1. Perhaps the issue is specific to the device, Firefox version or Android OS version you are testing, but you did not include any of that information. Perhaps you are testing an older version of Firefox for Android which is buggy?