Ashley's Forum Posts

  • Theme addons are now supported in Construct 3 r38+. These are essentially custom stylesheets you apply to the document Construct 3 is running in. This allows complete control over the appearance of the Construct 3 editor.

    The SDK documentation has been updated to cover theme addons:

    https://www.scirra.com/doc/c3sdk/

    Most of the new content is in the themes section.

  • The server just looks like it's really slow. I loaded the page watching Chrome's network tab and one request took over 30 seconds.

  • -would be great to multi select containers > shift-click only selects parts

    Alt does that. I just tried it and it's a bit confusing because it doesn't refresh the view when you release alt, I'll fix that for the next build.

  • Good idea, added for r38!

  • Is android 5.0 the default minimum target for C3?.

    Yes. Android 4.x is not supported I'm afraid, because the system webview on those versions is too limited to run games.

  • Performance aside, I think C2 and C3's biggest problem is third party wrappers. I haven't found a wrapper that I haven't experienced some trouble with. If C3 was native, you wouldn't need to rely on HTML5 wrappers.

    The downsides of writing native engines would be far worse than any issues people have with wrappers.

  • There's no good way to automatically decide the SVG raster size, so it's up to you. Using an automatic size would either degrade the quality in some cases, or waste memory in others.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • If you import a file from the animations editor via choosing the "Open" button, then pick an SVG, you can set the raster size and import it as a bitmap.

  • I don't think it matters if some platforms fall out of use and others rise to prominence. It could change several times in the coming years, but we already support almost every major platform, so we've got it covered really.

    The web has legendary backwards compatibility for widely-deployed features - you can still correctly view the original Space Jam website from 1996! That's a website over 20 years old. Newer features tend to chop and change more, but mainly as the spec is refined to make sure it's robust for the future, and we update regularly to keep up anyway.

    I recently saw a benchmark where the C2 engine in Chrome outperformed a competitor's native engine on desktop Windows, and approximately equalled another which compiled to C++. This pretty much confirms to me that the performance argument for native, or this idea that "HTML5 is slow", is totally dead now. Having a native engine does not guarantee good performance, and modern JavaScript JITs are incredibly potent. For years I've already noticed that almost every performance complaint comes down to hardware limitations (e.g. GPU fillrate), and people simply knee-jerk blame HTML5 without understanding what the real problem is. So as far as I'm concerned, we're there: HTML5 has native-grade performance now. There's nothing significant to gain by a native port.

  • Install any software updates that are available, and update to the latest macOS Sierra if you can.

    If that doesn't help, as a last-ditch effort you can go to chrome://flags and enable "Override software rendering list", but if the graphics driver is really poor quality it may crash or glitch when using C3. WebGL is usually blacklisted for a reason after all.

    • Post link icon

    The point of this thread is that you should submit ideas to https://construct3.ideas.aha.io/, but people keep adding ideas in replies, so locking this thread now.

  • And I've just shown that C3 sheets waste memory in a small test case. In larger games, the amount of VRAM used will just balloon.

    That does not necessarily follow. So far I've not seen any reports of someone porting their game from C2 to C3 and the memory use increasing significantly. Almost all spritesheeting approaches will inevitably involve a few extra sprites being bundled in to a sheet, but it's not necessarily a major problem. Actual cases of real-world games using more memory is what would persuade me this needs addressing. Further, it gives me something to actually benchmark, so I can measure there's a real improvement rather than just shooting in the dark.

  • I'm sorry I didn't make it clear in this post. In a previous topic, I explained that these are all separate objects. Death, Death2 and Swim are not included in the main player sprite object. At the start of levels that have water in them, I load the Swim sprite that contains SwimIdle, SwimForward, SwimStop, etc so there is no jank. This is good memory management for large games.

    What measurements did you make that demonstrated this was necessary? If you didn't make any, how do you know this isn't just a waste of time?

  • The Scirra Arcade effectively already does that. We do have plans to make it even easier (e.g. one-click build), but we can't give an ETA on that right now.

  • Oh wow! Does this mean that with IOS 11 we may be able to develop on our iPad? I apologize for my ignorance.

    No, that is Remote Preview only, but it's still useful for testing on iOS.