Ashley's Forum Posts

  • A quick overview of the WebGL renderer is this: (maybe this deserves a separate blog post)

    1. As far as memory usage goes, the layout-by-layout loading means that on start of layout all textures that are used by the layout are loaded (and any others released). All frames of all animations of any objects initially placed on the layout are loaded. This means for the purposes of rendering a layout, loading/unloading textures can be ignored.

    2. The WebGL renderer is a batched back-to-front renderer. This means it draws the bottom thing on the bottom layer and then moves to the front, drawing things over what's already been rendered.

    3. The "batch primitives" include things like "set texture" and "draw N quads". C2 batches draw calls to eliminate redundant work. For example if the engine tries to set the same texture 3 times in a row, it only adds one "set texture" batch job.

    4. If there are 10 of the same sprite showing the same texture, and they are all drawn in a row (so they must be consecutive in Z order), the batch can be just two items: "set texture" then "draw 10 quads".

    5. If there are 10 of alternating sprite types with different textures, they cannot be batched with a single "draw 10 quads" call, because that can only use the same texture for all of them. So the batch ends up with "set texture A", "draw 1 quad", "set texture B", "draw 1 quad", "set texture A", "draw 1 quad"...

    This is not as bad as it sounds. These are very quick calls and are still much faster than the equivalent canvas2d rendering commands.

    6. After export there are lots of optimisations run like image deduplication and spritesheeting. This makes it more likely that objects share the same texture, so in some cases after exporting the batch can look like step 4 where it would have looked like step 5 in preview, which improves performance slightly.

    So overall you can optimise your game by doing things like making sure objects with the same images appear consecutive in Z order. But this can be difficult, and is probably a "micro-optimisation" - there are likely to be much more important things to worry about for performance.

    It's possible to make giant spritesheets that have all the game's images on it, but it doesn't totally eliminate texture switching if you have lots of images and exceed the maximum texture size with one spritesheet. Also putting all images in one image can make the loading bar useless in web games, and actually can significantly increase the download size (particularly problematic where stores have a file size limit, like Google Play). More info in this in the blog post Under the hood: spritesheets in Construct 2.

  • 1. You probably do not want to sync a whole text box, because that will create and destroy instances to match the host. You should probably just leave it not synced and send messages to update variables. (It's a little unusual to have variables in a text box since they're just for text entry, perhaps you want globals instead?)

    2. It's by design that if you send a message over the network, you don't receive it yourself. See the chat tutorial for an example of handling it locally at the same time as sending off the message.

  • I don't understand: you already have "On peer message". That should work for your purposes right?

    Obviously it would be wasteful if the multiplayer engine sent unchanging data 30 times a second. It doesn't do that. If the data is not changing, it gradually reduces the rate to 2 times per second. (This is still necessary so a newly joining peer gets the game data, or lost packets are eventually corrected.) It can also vary the transmission rate per-instance, so if you have 10 instances and only one is changing, it will send 1 instance 30 times a second and 9 instances 2 times a second. The bandwidth of 2 updates per second is probably negligible for all uses.

  • You do not have permission to view this post

  • Arima - by "compatible" I'm not just talking about the same feature list, I also mean that the features that are supported function identically. If they don't, then ported games will be broken and it will often be extremely difficult to figure out why. For example some part of a platformer might collide differently and break the game, due to a round-down instead of round-to-nearest somewhere deep in the engine. Getting exact compatibility so games actually port with good success rates is months and months of painstaking work by itself. (This would also be complicated by some "interesting" features of Javascript, such as all numbers are doubles - simply choosing an int or single-precision float anywhere in the engine could cause incompatibilities. The list would go on.) Then not having the same supported feature list is the other half of the problem, and if some unsupported feature is critical to your game, tough luck.

    I don't think many people in this thread appreciate the work that goes in to maintaining a large engine which thousands of games depend upon. Maintaining backwards compatibility with updates to the same engine is hard enough. I consider it a pretty significant technical accomplishment that we have so far made well over 100 updates and kept the rate of breaking changes very low. This is an "invisible" success which users quite rightly take for granted and don't think much about, but involves careful planning and good engineering. Lots of other tools out there frequently break things. Many games come to depend on very subtle aspects of the engine - the "quirks" - and they very much have to be left in or re-written compatibly otherwise you break whole categories of games. The idea of rewriting even a compatible subset of the engine in a different technology is a monumental technical challenge far beyond that of even just backwards compatibility with the same engine.

    asm.js only covers the JS logic and would still have lots of dependencies on browser-platform features, such as: the WebGL shader compiler, asynchronous image and audio format decoding and streaming, the Web Audio API, user inputs (touch, mouse, keyboard, orientation, accelerometer, gamepads, user media, etc), WebRTC, AJAX, WebSockets, v-sync, web workers, XML parsing, form controls, platform-specific integrations (Facebook, file I/O, Windows Store, consoles e.g. NWF, etc), other unsupportable features like third party plugins and the Browser object's javascript execution, and probably more I can't think of. All of that needs to be rewritten in native code in a compatible manner, which is still a monumental job. This is why I compare it to writing a new browser engine, and so far nobody does that well apart from the major players in the industry.

    However if we stick with the web platform, we can have it all: a compatible, fully-featured and high-performance engine on all platforms. Mobile needs to catch up a little, but we can already see that happening, such as with the performance results on a Nexus 5 and the fast-improving Crosswalk.

  • QuaziGNRLnose - at some point you can keep improving performance and it doesn't matter, because it's fast enough already (something Fimbul was getting at). CC was fast enough in many cases already, even when it used sub-optimal algorithms. In C2 we've had to work harder to get there since JS does have a performance overhead, but I believe it's fast enough: we still see many games bottlenecked on GPU performance, not CPU, and the number of CPU-bottlenecked games that go from unplayable to playable thanks to the performance improvement of a native engine is probably small. If you have any specific examples of games that cannot get good CPU performance out of Construct 2, please do send them over and I'll profile it and see if we can optimise the engine. Generally though people make vague references to poor performance in C2 but never send me such projects, or if they do, they are GPU-bottlenecked.

    It's a long thread so I'll mention again: writing a compatible native exporter using SDL or whatever amounts to writing a new browser engine, something we are far too small to reasonably tackle in a way competitive with what the likes of Google, Microsoft, Apple and Mozilla can do. Writing an incompatible native exporter is just not very useful (see CocoonJS for an example of how annoying compatibility issues can be, and that's still got a fairly high level of compatibility). A smarter idea would be to rewrite the engine in asm.js, which can come very close to native C performance, and is still improving. But that would mean a complete rewrite of the engine, and possibly for no gain: GPU-bottlenecked games will see no improvement, and in many cases our carefully hand-written JS engine is fast enough anyway.

    As for the security issues, I think you underestimate them. It is a problem with native tech, and the problem simply does not exist on the web. I think there is a huge difference between downloading an unsigned EXE from a website you've never heard of before compared to downloading a digitally-signed installer for Steam from Valve. Some administered systems may forcibly prevent unknown executables from running. Some non-technical users may simply give up if they find out they have to "configure DirectX" (we know this happened in some cases with CC games), or get scared off by a security warning (which is there for a good reason). There are several hurdles here, none of which exist with HTML5 games.

  • iOS export is currently handled by CocoonJS and the compatibility notes are here: https://www.scirra.com/tutorials/303/how-to-export-to-cocoonjs

    Note CocoonJS does support WebGL, even on iOS.

  • Yeah, it's an uppercase "i".

  • Use the Javascript SDK to make a plugin.

  • AllanR is right: our C2 codebase depends so heavily on Microsoft libraries that it would never port. We're aware of demand for the editor on other platforms and are factoring that in to our long-term plans.

  • QuaziGNRLnose - I just want to point out a few disadvantages of Classic and advantages of HTML5 that you didn't mention.

    CC created desktop executables. It's interesting to point out that from a security standpoint, the user is putting a great deal of trust in running an executable they downloaded from the internet. For this reason the latest versions of Windows' default settings use "SmartScreen filter", that basically warns you not to download EXEs if they are not "commonly downloaded", and you have to click through "more info" -> "run anyway". Then CC used optional DirectX components, which often required a separate download and execution of an installer that could take several minutes to run. Both of these serve as pretty big hurdles to getting real players to play your game, especially casual non-technical users (which I think still applies even as a hobbyist). On the other hand HTML5 is secure by design, and can be immediately run in the browser without any security prompts or installers. I think this is a much more significant advantage than most people give it credit for.

    We spent a great deal of time optimising CC, but we still didn't get as fast as Chrome. I don't think the reasoning in the blog post is right any more: I think the main reason is Chrome has a sophisticated multi-threaded/multi-process engine, and can run rendering commands in parallel to the next frame execution on the main thread. We never made CC's renderer multithreaded, partly because parallelism is difficult to get right. So Chrome (and subsequently node-webkit & Crosswalk) have a big performance advantage over CC there.

    We have also done more optimisation work in C2, including collision cells, parallel pathfinding calculations in a Web Worker, and more recently optimisations to skip redundantly evaluating expressions in the event system. I think this means in some cases C2 will provide a better experience when scaling up to large games.

    CC was also at the mercy of the quality of the graphics card driver and in some cases glitched or crashed depending on the state of system updates. Software rendering is slow but can be the difference between working and not working.

    Especially given the security and installer hurdles of node-webkit, I'm surprised by the level of demand that remains for it. Still, it should serve well as a "native app" if that's what you're after.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Firefox does not support gamepads, but the next version (v29) is noted as supporting it. It should work in Nightly already if you have that.

  • Did you try the beta/canary option?

  • We updated to the latest version of BCGControlBar (by BCGSoft). IIRC there have not been any important changes to the save/load code for a long time, so I would expect it's some side-effect of Wine lacking support for various features.

  • This isn't anything specific to multiplayer: changing layout just destroys the list object which shows all the peers, and then when you come back to the layout there's no way to get that information back.

    I'll add a 'Get peer at index' expression for the next build so you can re-fill the list when returning. Or just make the list global and hide it when changing layout.