Ashley's Forum Posts

    • Post link icon

    You cannot use the desktop exporter in the free edition. Closing since discussion about ways to circumvent licensing are not allowed.

  • The reason why I personally want native desktop is because I know that Scirra can and has done an AMAZING native DirectX 9 runtime before with Construct Classic: http://www.scirra.com/construct-classic

    Literally the C2 editor exporting to CC would be all I'd ever need

    The CC runtime had annoying third-party-inherited issues too, just different problems. The "optional DirectX components" (D3DX) installer was a pain. We had to use it since there didn't seem to be any other way to render text in DirectX, and it provided a bunch of other must-have utility functions. However end users didn't really seem to understand it even though we tried to make the error message clear. If an ordinary user sees a "sorry, you need a DirectX update, go here..." type error message before running the game, I think a lot of users just gave up at that point, or came to our forum asking what to do (which kind of mystified me, it had instructions in the error message - I think people just freak out when they see a message box with anything technical in it). We recommended making an installer for games, but loads of people wanted their games to run without an installer for easier distribution (an under-appreciated feature of browser games IMO). D3DX had some weird bugs as well that were difficult enough to work around that CC had some unsolved bugs. So it was always a thorn in our side, and we're talking about an official Microsoft DirectX component here. Then there were driver bugs, making the game look totally glitched up unless you updated your graphics drivers direct from the video card manufacturer (try getting a non-technical user to figure that out).

    After all that trouble with DirectX, we decided to switch to OpenGL for the C2 editor itself, and especially in the early days driver bugs were horribly frustrating. We had a bug like "the editor crashes on startup on any AMD Radeon graphics card in this range of models". It was fixed after about 9 months, because I got a random drive-by reply on a StackOverflow question that gave the (obscure) answer. Luck fixed that one, we had no chance of fixing it ourselves. While dealing with that kind of problem I was thinking "phew, I'm glad the runtime doesn't get screwed by issues like this".

    So with CC - and the native C2 editor - we just depended on different third parties, and we had a different bunch of problems. I don't see changing technology or writing a new native exporter changing that. Even if we did the whole native tech stuff, I just imagine threads like this one, but complaining about why we rely on some different set of technologies and have to deal with inheriting their problems. Also I know "bug 422000" is now infamous, but the fact there's a long comment thread there with Google engineers commenting on it is pretty outstanding - on that previous AMD driver bug, I failed to even find any reasonable way to report a bug at all - I was sent in circles by the standard customer support staff and certainly never got as far as an engineer.

    I do sympathise with the complaints in this thread; I'm frustrated too, and I can see this comes at a bad time after all the nonsense with CocoonJS and the other non-browser engines, and the OpenSSL vulnerability ruling out CW7 makes it a perfect storm with not many other options right now. This sucks. But lots of people are working on this, and all platforms have their issues. For those of you talking about native exporters, our difficulties with native tech was one of the factors in pushing us towards HTML5. Don't imagine native being perfect - from my own experience it can definitely have problems of a similar level too. And I know I always say this, but it will be worked out. Crosswalk was working smoothly as of pretty recently and I don't think there's any reason to believe it will stay this way forever.

  • Since it's based on Chromium it's not really that interesting to test IMO - it's probably going to produce the same results as Chrome. Browsers like this are basically just a new UI over the Chromium browser engine (as Opera now is).

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You can add a gain effect and ramp its gain parameter.

  • Ludei list 22 people on their team, and yet our experience with Canvas+ is it is missing so many features that customers get angry about all the stuff it doesn't do and ask us for refunds. From our point of view, those of you asking for this are far outnumbered by those who were upset by the shortcomings of non-browser engines. Our aim is to support all the features in C2, and to do this it is necessary to develop for real browser engines.

    Also, a non-browser engine is definitely not just graphics+audio+a few cherry picked features. If your game happens to run well with such a small set of features, you are in a lucky minority and I don't think you should assume therefore it will work for everyone. A commercially viable solution needs to implement a wide array of features which modern browser engines provide, and bringing that to a non-browser engine is tantamount to reinventing a modern browser engine. And how can we hope to keep up with companies like Google which have hundreds of engineers working on their browser engine?

    Most criticisms people raise of platforms like Crosswalk are simply temporary bugs. They'll get fixed. Native platforms have bugs too, and they usually end up fixed as well. Everyone was crying for us to develop a new desktop exporter when NW.js had a v-sync bug. As far as I can tell, it's now fixed, and I haven't seen any other demands for a native desktop exporter since. I knew it would be fixed and I tried to explain this, but people demanded native exporters anyway. It would be crazy if we started this massive engineering project just because of a temporary bug. In the space of a year or however long it would take, any temporary issues would almost certainly be fixed. And given how fast HTML5 has developed - from no mobile support at all just a few years ago - it seems unwise to bet against this.

  • IE still uses the <audio> tag for playback. Right now all other platforms support the Web Audio API, which is specifically designed for low-latency polyphonic audio playback. <audio> is a more heavyweight music player with advanced playback controls. It's not too surprising IE struggles with audio playback in some cases when it has to use <audio> and I'm not sure there's much we can do to fix it in C2.

    The good news is the new IE engine on Windows 10 already supports the Web Audio API, and I've already tested it and it seems to work great, with effects and all. So I'd guess this is just a matter of needing Web Audio API support, which is on the way.

  • There was a bug report for this which I couldn't reproduce on any of my own machines. Are you sure your graphics drivers are up to date?

  • imaffett - have you tried testing ignoring the GPU blacklist to establish whether this is caused by Chromium blacklisting more devices which fall back to software rendering?

  • My opinion hasn't changed: CocoonJS had such severe problems that users would demand refunds from us, and Ludei were not able to resolve them. I don't see this particular technology working out any differently. There have been recurring problems with every non-browser engine we've tried, which is several now: things like lack of memory management mean bigger games crash, and it can be an uphill struggle to even get the developers to understand the problem; meanwhile it's never been a problem in real browser engines. Then the lack of DOM, Web Audio, WebRTC, XML parsing and so on mean major C2 features get crossed off the list. This also causes other complaints like "it's not properly supported" or "why do you advertise features that don't work on mobile". So even if we followed up on this again we will just resurrect older problems and a different set of users will be unhappy.

    These days it's almost impossible to write software without depending on some third parties - whether it's a compiler developer, operating system, device drivers, components (like that annoying D3DX installer requirement for Construct Classic games), library authors (e.g. for graphics/audio/input so you don't have to reinvent the wheel), installer engines, or even other software that conflicts with or breaks your own (like overzealous antivirus or conflicting software that breaks features, like some firewalls blocking C2's preview server). If you're tired of "ask someone then wait for a better future", then this does not go away by depending on other third parties. Think of running in to a problem caused by Microsoft (think of how they dropped XNA support - oops! we'd be hosed if we went with that), AMD (abjectly ignore driver bug reports and even if they fixed it most devices wouldn't be updated anyway), library authors or whoever else who may not have our own priorities as their focus. Yes, it sucks when Chromium goes through a rough patch and bugs end up in NW.js and Crosswalk which are on slower release cycles. But no, I don't believe radical technology shifts are going to make this any better, and they have a huge work overhead; what a terrible shame it would be to set ourselves 2 years behind working with some other technology, only to find it's not any better. Meanwhile I am confident whatever current HTML5 issues there are on any platform will get worked out.

  • Crosswalk is based on Chromium, so in theory should be as good as the browser. I think they're working through a bug in CW10 at the moment though but it sounds like things are better in CW12.

    CocoonJS had far more issues than Crosswalk, like lack of memory management crashing the game and a bunch of unsupported features.

  • saiyadjin's suggestion of using Process Explorer is a good idea for a far more detailed breakdown of memory usage. I found it can actually display GPU usage and GPU memory too (one of the only tools I've ever found which can!). But it can also break down RAM usage in to things like "WS Private Bytes" (the private working set) which from what I've read is the most accurate measurement for how much that single process is actually using.

    I think Windows' task manager may have changed the measurement it reports at some point. I remember a bug report where someone said Windows task manager indicated it was using something like 600mb of memory, but on my Windows 8.1 it said something like 50mb. I think Windows 8+ reports the private working set size (realistic per-process memory usage) whereas older versions report the full working set size (including memory shared with other processes).

    I found an interesting article explaining more about memory measurements here: http://cybernetnews.com/cybernotes-windows-memory-usage-explained/

    Here's an interesting analogy:

    [quote:3buk3t8g]Lets pretend that there are two kids who are coloring, and both of the kids have 5 of their own crayons. They decide to share some of their crayons so that they have more colors to choose from. When each child is asked how many crayons they used, both of them said they used 7 crayons, because they each shared 2 of their crayons.

    The point of that metaphor is that one might assume that there were a total of 14 crayons if they didn’t know that the two kids were sharing, but in reality there were only 10 crayons available.

  • If it's at all possible rest assured we will support it as soon as humanly possible, but note how it depends on Xbox One getting the Windows 10 update, and we don't know when that will be (it could easily be months or longer after the desktop Win10 update). We're keeping the C2 exporters up-to-date so there will be an update in future to support Win10 store apps too.

  • If you use PhoneGap without Crosswalk then you are stuck with the Android system web view, which is really only good from Android 5.0+. (Android 4.4 has a Chromium webview but it lacks WebGL support so performance will be poorer. I can't remember but it may not even support GPU rendering for canvas2d, since as that bug report shows it's still really slow in 4.4.)

    Crosswalk supports full GPU-accelerated WebGL on Android 4.0+ (if the graphics driver is not blacklisted) so is likely far faster. This is why we recommend using Crosswalk for Android publishing. Once Android 5.0+ is as prevalent as Android 4.0+ is you'll be able to simply PhoneGap it, but until then Crosswalk is essential.

  • This isn't anything to do with Construct 2. It just uses the browser-provided Gamepad API, which is generic and should work with any kind of controller though. However your controller needs to:

    • be recognised by the OS
    • have drivers installed so the OS knows how to communicate with the gamepad
    • report the gamepad to other apps like browsers
    • and the browser may possibly only recognise certain models of controllers, since it has to know in advance how to map its buttons and axes on to the standardised Gamepad API.

    We have no control over any of those steps, so there's not much we can do if a specific gamepad doesn't work. Also IIRC even the official PS gamepads don't have official Windows drivers, so they don't want to officially support Windows gaming. You can get third party drivers, but then there's not much guarantee it will actually work correctly. And then if you're using an unofficial controller just pretending to be a PS gamepad... well, no surprises if it doesn't work.

    The wired Xbox 360 controller is the one we recommend because it's a common controller that is known to just work on most platforms - even Android! I think the Xbox One controller is gaining support too, but I haven't tested one lately.