Ashley's Forum Posts

  • This is the kind of thing which is a lot easier to do if we drop canvas2d support, but right now I think that would upset a larger number of people.

  • Closing, please see the bug report requirements, and note this is most likely to do with supported codecs in the browser you test, rather than a bug or anything mobile-specific.

  • It's not really that easy, audio can sometimes take a long time to encode anyway so you can't reliably detect a hang situation, it transcodes multiple files in parallel, the UI is blocking, etc. It's one of those "sounds easy but is hard" things.

  • > The only issue is objects store their position in single-precision floating point numbers

    >

    Read the bold sentence above that Ashley said from 2010 .

    Actually, that post is about Construct Classic, which has a different engine. C2 uses double-precision floats for numbers, but for performance reasons uses single-precision floats for rendering. This means you have an enormous range of high-precision positions, far beyond even billions of pixels (1px accuracy up to 9,007,199,254,740,992). However they can only render to within 1px accuracy in a range of about 8 million pixels from the origin (my previous statement of 100,000 was pretty much a guess, I can't remember, it was like 6 years ago ). Beyond that there is not enough precision in the rendering engine to draw everything to at least 1px accuracy, but you might get further before you notice anything wrong.

  • Closing as won't fix: the problem is with the AAC encoder we use (which doesn't report an error, it just hangs), which is the one built in to Windows, so really it's a Windows bug. We can't easily change the encoder because AAC is a patent-encumbered format. The workaround is to use your own AAC encoder or extend the audio clip. Sorry, not much else we can do.

  • There is no technical reason for the limit you set there, it's just a sanity check to avoid most likely accidental use of absurd values. If you enable "unbounded scrolling" you have an effectively unlimited size, but you'll probably run in to floating point precision issues if you go to extreme distances.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • There's a built-in video plugin.

  • I don't think Intel actually said they will drop Cordova, they are just shifting their focus.

    Performance with PhoneGap should be identical, since it's the browser engine that determines the performance, the build system just assembles the files. Personally I find it easier than the Intel XDK, since once it's configured with your certificates, you just upload a zip and it gives you back an .ipa and .apk.

  • On Android you can use the 'Request fullscreen' action. On Safari it's not allowed by Apple's browser I'm afraid.

  • In the canvas2d renderer, yes, it's difficult. I'm hoping we can drop support for that at some point and go 100% WebGL only, which would make things like this easier.

  • It's a good idea, but we would only do this for C3 at this point.

    • Post link icon

    we'd still have more options if we'd roll with native engines.

    No, I think in many ways it would be likely fewer. For every feature you'd have to find libraries that are compatible and work across all platforms (from iOS to Xbox One). For example, can you find a native WebSocket library that runs over all those platforms? Even if you can, should we depend on the possibly buggy third-party code and face the same criticism when something doesn't work? Or do you expect us to do the laborious work of writing cross-platform libraries which we maintain ourselves, when we get this for free with a browser? The key point is as a small company, we don't have the resources to maintain all those libraries ourselves - and I believe we got to where we are today specifically because we didn't get dragged down in to all that extra work. I'd point out there are several similar-sized, or even larger and better-funded, competitors who appeared over the years and maintained multiple codebases, who are more or less irrelevant now because they couldn't keep up. That could've been us.

    No. Otherwise Unity and UE4 devs would think native export is overrated then....?

    Well, I could change the comparison: most Unity devs write in C#, a garbage collected managed language. C++ may well be faster, closer to the metal, and smoother since there is no GC. Generally though, the difference doesn't matter, the higher-level managed language is good enough and the increased productivity is more important.

  • Scirra may be unable to fix it themselves at all, but to be concerned and using its large(r) industry standing/PR power and fanbase as leverage to apply pressure to the NW.JS staff to apply pressure to Chromium developers (officially as a company, not just "C2 users individually requesting"), is what Scirra's paying customers would expect from the developer of the product they purchased.

    The screen recording issue is nothing to do with NW.js or Chromium either. It's a problem with the screen recorder.

    I don't understand what you even expect me to do about this? I can't fix the screen recorder apps, it's not our software and many of them are closed source. All I can do is ask them to fix it. You can do that yourself, and the more people who do it, the more likely they are to take it seriously as an issue. Don't overestimate our influence, even browser makers shrug us off unless there is a tide of users behind us.

    What more can we do? What is your best-case scenario here? Do you expect me to disassemble a screen recorder and fix it from the assembly code or something?

    • Post link icon

    Html5 wrapped export will never run as efficiently as a 'native' export, in the same way that a windows / virtual machine OSX will never run as quickly or smoothly on an i5 laptop as an installed version would.

    You could probably say the same about hand-writing assembly vs. compiling code. Beyond a certain point, the difference doesn't matter any more.

    I like to go with examples, so I'd like to get back to this quite old report also known as the "30fps cap"

    No platform has all features. If we went with native engines, you'd probably lose support for browser-provided features like WebRTC, probably anything based on Web Workers (since they make multithreading so much easier to use), some service-backed features like speech recognition, probably user media features since they require a lot of cross-platform media support, you'd open the graphics driver bugs can of worms (browsers do a lot to sanitise WebGL), and so on.

    Judging by the fact the 30 FPS cap feature only has ~30 stars despite the fact I always link to it, I think it's fair to say it's a niche feature. Everyone will always have their favourite feature they want which is difficult to do, regardless of the platform. For example users of native engines still want things like networking, including things like loading web-hosted images, which browsers do really well.

    I'm sure someone will now say "but you could use libraries/frameworks to help", without realising the paradox that creates given others criticise us for depending on third-party code!

  • You do not have permission to view this post