Ashley's Forum Posts

  • We are full steam ahead on C3 development and it's not ideal to divert resources away from that to work on someone else's plugins. We'd rather third party developers can keep maintaining their plugins, and did offer to pay for the maintenance of the AdMob plugin in this case, but it did not seem to be a well-received idea. So I feel a little caught out by this. I think the best way forward is to suggest any specific features you need and have them integrated in to official features. For example adding the consume feature to the official IAP plugin, instead of dealing with some of the difficult copyright and maintenance implications of trying to ship third party code in a commercial product.

  • No, it's not supported through any built-in features. This sounds like an unusual case so it seems reasonable to use a third party plugin for it.

    Two complications with this feature are the fact you need two URLs to support both AAC and Ogg formats to cover all platforms, and potentially the memory usage if you really do go through 10k sounds.

  • Forum regular and long-time user zenox98 has kindly offered to help clean up the spam and maintain law and order on the forums as a moderator. Welcome to the moderator team zenox98!

  • paradine - can you provide .capx files? It's difficult to test the performance of the engine, or try different publishing options, when all I have is an APK.

    The same goes for anyone who has a game they think is slow: please send me the .capx source and I will profile it and look for any performance deficiencies in our engine.

    Also that video is from way back before we even introduced asm.js physics, which brings native-like performance to the physics engine. I've seen benchmarks on the web that show asm.js comes in about 1.5x the performance of native, so it should be far better now.

  • No idea, your best bet would be to run the profiler in Chrome's dev tools and see where JS time is being spent.

  • paradine - please, link me to every example of CPU-bottlenecked games you can find. I want to investigate them but am so far unaware of most of them. I assure you I do not intend to ignore them, but with hundreds of posts made to the forum every day it's very easy to miss posts.

    I am also skeptical of polls for features in general. We did feature polls that showed the vast majority of users out of hundreds of voters said they wanted multiplayer. I was concerned that even with C2 doing much of the heavily lifting and hard work, networking is still a difficult subject to work with in general, so it would probably still be hard to use. Even when I specifically described how it would likely be difficult to use, still people voted for it in huge numbers. Then when we released it, very few people actually used it. As far as I can tell it's because... it's a difficult subject to work with in general!

    To me this proves large numbers of users will vote for features based purely on hype. They imagine that everything will be perfect and brilliant and there will be no shortcomings or tradeoffs and it will be super effective and easy to use. Of course reality rarely ever lives up to that.

    So I don't really care if a million people vote for native exporters. I regularly see that people blame HTML5 for performance issues when really it's a hardware bottleneck. I can see that people think "just make a native exporter, it's not that hard right?", whereas I can see it's a colossal project with severe ongoing impact on the product development. So even if everyone voted for it, I am not persuaded they have a proper understanding of what they are voting for, as happened with the multiplayer polls.

  • mrneko - did you build with Crosswalk or just the plain Cordova? Crosswalk should work on Android 4+, whereas Cordova will only work well on Android 5+.

  • Also Ashley Could you please add keyboard, joypad and mouse action : Cancel Input, so all keys that are currently pressed would stop working and require player to press them again?

    Again, this seems easily doable with events. I don't want to get in to the habit of adding built-in features that just replicate what a few simple events could do.

  • I'm a little confused if you mean designing a HD game, as in for 1080p, in which case you just set your viewport to 1920x1080 and off you go. So I'm guessing you really mean high-DPI graphics so designing for different display DPIs (aka the device pixel ratio, or number of physical pixels to CSS pixels, e.g. 2 for 2x retina devices).

    The intent in C2 is just to design it all at the highest resolution, and let letterbox scale shrink it down where appropriate. There are so many device pixel ratios out there (including 1.325, 1.33, 1.5, 1.7, 1.8, 2.37, 2.4...) that designing artwork for each level is insane, and even if you do 1x, 2x and 3x, there's always going to be a bunch of devices scaling that anyway, so it seems you may as well go with the highest and let the GPU scale it down.

    Mipmapping improves the downscaling quality and performance. It uses a slower, high-quality downscaling filter at initialisation time to take in to account all the image's pixels. It basically turns the image in to an array of images at sizes 1, 1/2, 1/4, 1/8... down to 1px big. Then if the image is half as big it renders from the 1/2 size image. If mipmapping is not used it just linear samples down the full-size image, which requires more GPU bandwidth since it's sampling a larger area of pixels, and the quality is inferior because linear sampling only ever considers a 4x4 patch of pixels at the sampling point, which is insufficient for more than 50% downscaled images. Beyond that it skips areas of the image which causes aliasing artefacts that make it look "crisp". Some people subjectively seem to prefer that look, but it really is actually technically worse quality.

    It is a bit of a problem that WebGL currently does not support mipmaps on non-power-of-two images. This means in preview mode often you won't see the effect of mipmaps, regardless of your "downscaling quality" setting. However after export, most images are assembled on to power-of-two spritesheets and then mipmapping can take effect. I can see this inconsistency is frustrating, but it is fixed in WebGL 2 (which can mipmap any size image), and in-editor spritesheeting is a goal of C3 which would help preview work identically to export.

    So anyway if we can assume for a moment that mipmapping is enabled, then with all artwork at full resolution, the GPU is basically rendering from high-quality automatically downscaled source textures by using the appropriate mip levels. This should resolve any question about performance. It does use more memory on devices which don't need the extra detail. On the up side if you zoom in or upscale images then you get the extra detail back. Perhaps there could be a feature to save memory in this case. However with good game design and C2's existing layout-by-layout memory management, this already seems largely mitigated (I don't hear much about it). Also you probably need to optimise the full-resolution version of your game anyway, since corner-cutting device vendors will happily stick an insanely high-resolution display on a weak device with not much memory, so the memory use of the full-res version is still a concern.

    I do think there are some features we could add to make this easier though - in particular I think if the image editor had a way for you to tell it what the device pixel ratio of the source image is, it could get the default size in the layout view correct, and improve the detail of tiled backgrounds, etc.

  • I thought the issue was 3rd party reliance

    The only remotely practical way to write a set of cross-platform native exporters would be to rely on some kind of existing framework or library, which... relies on third parties. I struggle to see why this is an argument for native exporters.

    80% games are CPU bottlenecked and only 20% are GPU bottlenecked.

    This contradicts what I've seen, and I've done profiling for some of the largest C2 games like Airscape. As ever, I am absolutely keen for anyone with poorly performing .capx files to send them to me (preferably in minimal form like a bug report) so I can optimise anything that needs to be. I repeat this with every thread that ever crops up like this, so I've said it a lot, and I am either sent nothing, sent games which are incredibly inefficiently designed, or games which are GPU-bottlenecked. So even if what you say is true, I'd be very interested to see any examples of that, because I almost never see them myself.

  • There's nothing you can do: you can't make a sound on iOS 9 until a touchend event. It's Apple who impose this restriction, not us. The only solution is to adapt your game design to take this in to account.

  • hardware is not so limit as you think !

    You are still missing my point. If a game is slow because it is drawing more to the screen than the GPU has bandwidth to handle, then it doesn't matter what technology you use. You could write it in carefully optimised C++, or even hand-tuned assembly instructions, and it would not be any faster at all, because the bottleneck is in the GPU hardware. The only way to optimise in that case is to draw fewer objects, which you can already do in C2.

    This thread highlights exactly my resistance to making native exporters. People identify that the game is slow on weak hardware, specifically call out a case where GPU hardware limitations are the bottleneck, and then ask for native exporters as a solution. In the described situation, the suggested solution will not help. Developing native runtimes to try and fix that case is pure folly.

    As I've always said before, WebGL uses the GPU pretty much identically to a native app. Javascript has some performance overhead, but it's generally not the bottleneck except perhaps in a minority of exceptionally complex games. And with modern devices like the iPhone 6S benchmarking close to laptop CPU performance and continuing improvements to Javascript JIT compilers, this overhead is becoming even less significant. Were it a significant problem, something like WebAssembly would solve it in a far more practical and portable manner.

    Anyway few people seem to understand the hardware issues involved here, so I guess we will face continuing calls for native exporters to fix hardware limitations :-\</p>

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • >

    > I really think some people have the impression that if we write a native exporter, hardware specs will magically increase.

    >

    Ashley please just make one game with unity and then you see native performance is really different and so much better !

    I won't see any performance benefit if the game is fillrate limited on a weak Intel GPU! Again, as I said before, hardware limits don't change even if you change the technology you use. It seems that most people don't understand this?

    But you can play games like grimrock and even gta4 on Intel HD Graphics 4000 GPU.

    3D games use a radically different rendering model which is actually lighter on overdraw than multi-layered 2D games. Also because most top commercial hits are 3D games, some hardware and drivers are probably better optimised for 3D than 2D!

    Maybe all we need is an option to force desktop resolution in fullscreen to something lower to cope with weaker fillrates

    That's effectively what "low quality" fullscreen mode does, and it should be a big help on fillrate-constrained devices like Intel GPUs. A fillrate-heavy game is going to have trouble on an Intel GPU regardless of the technology you used to build it.

  • As it stands, the only real performance overhead applies at the end of a top-level event that created new instances, when it transfers the temporary list. If every condition checked both lists, all conditions would have a performance overhead, regardless of if the event created new instances or not.

  • It's slower simply because it's more work to iterate two lists than one, and that overhead would apply to every single condition in the project. Currently the engine uses a simple flag to indicate that there are instances on the temporary list that need to be transferred, and checking a flag between every top level event has negligable overhead.