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>

>

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

console

I think it is likely that the Xbox One update to Windows 10 will make it possible to publish HTML5 games to Xbox One, but we are holding off on making official announcements about that until we know for sure.

it could also be described as a top-down FZERO, which the SNES could handle

Obligitory "my SNES could run this", obligitory reminder that as far as I can find the highest resolution mode of the SNES was 512x239 8bpp which is 122kb per layer vs. a modern 32-bit 1080p game which is 8mb per layer or about 68x more bandwidth. Assuming you have the background and four own-texture layers, that's 340x as much bandwidth, not including higher-resolution textures, plus rotation and scaling, plus no sprites-per-line restrictions, plus transparency and alpha blending, etc.

Construct 2 games fail hard on Mac OSX and Linux with games over 500MB, and most of that size is soundtracks.

Maybe that's a NW.js issue, but it's surely solvable. I know that recently there were bugs that combined with the slow NW.js release cycle has made for a lot of waiting, but I think it is pretty clear that NW.js should soon be back to working effectively, and that's a far more sensible option than burdening ourselves with a multi-year fork of our engine.

it's roughly a 2.4GHz dual-core Intel CPU with Intel HD Graphics 4000 GPU. Do you use a device with these specs when you test the examples people send?

Yes! And the bottleneck on that kind of device is the fillrate on the weak Intel GPU. Which is a hardware limit. Which means making a native engine will be no faster at all. So that's actually a pretty good example of why making a native exporter is completely futile for improving performance on that kind of device: WebGL is basically already performing identically to a native app in that case. Intel CPUs are pretty strong even on low-end models, meaning the overhead of Javascript is really not an issue. The GPU fillrate is the real issue. Intel GPUs really suck. That's not our fault, or HTML5's fault, or Chrome's fault. It's just crappy hardware.

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

The "temporary sprite list" is pretty much exactly how it works already, and it moves those instances to the main list at the end of the top-level event. However if every condition also checked the temporary list as well as the existing list, that would add a performance impact to every event again, since now every condition has to check two lists instead of one.

It's defined by the browser. I think its every couple of seconds generally but it could depend on the download speed.

The reason objects aren't pickable until the next top level event is an architectural detail. It actually used to make them pickable immediately, but it led to crash bugs, so the existing system is a workaround to those bugs. The problem is that to make an object pickable it needs to be added to the set of instances in the object type, but conditions iterate this set when evaluating conditions. For example think about this event:

+ For each Sprite

-> Create "Sprite"

"For each Sprite" will iterate every Sprite instance, but the event itself modifies the set of Sprite instances. It's difficult to handle this case correctly without introducing a global performance impact to the event system, because every condition has to constantly check if the set of instances it is iterating has changed. (It's also interesting to think about how this event would turn in to an infinite loop if it also iterated the instances it just created!)

The actual bugs IIRC were even more complicated, involving sub-events and function calls, which ultimately led to an instance being created half-way through the evaluation of a condition that was testing the set of instances in that object. In order to handle this case, created objects are picked (so you can access them in the event immediately), but they are not added to the set of instances until the end of the top-level event, which guarantees no conditions are iterating them. I thought about only doing this when this mid-iteration case was specifically identified as happening, but I thought it would be better to be always consistent rather than doing something subtly different depending on the parent events/function call context which would make for some pretty maddening debugging. So created instances don't "really" exist until the next top-level event, although they are picked.

It's hard to see how this could really be different. We could make it only do the workaround when it needs to, but being slightly inconsistent depending on the context is generally a terrible idea, because in practice it means unpredictable consequences. We could add them to the instance lists immediately, and then a bunch of games start crashing. Or we could add a check to every condition to verify if the instances change while it is iterating them, which adds a performance overhead to every event. Given these options, leaving it until the next top level event is the best option IMO.

BTW the stated goal of C3 is to rebuild the editor and keep the same runtime, so this is not really the kind of thing we intend to change anyway in the scope of that project.