Ashley's Forum Posts

  • tomsstudio - as I've tried to mention before in the thread, WebGL effects are only the tip of the iceberg. You're going to have a long list of major unsupported features. We would offer more help if we thought it would result in a commercial grade product.

  • Yeah, maybe try the numerical ID instead? I'm not sure why there would be more than one ID per item.

  • WaterlooErik - you can look at the code yourself in <install directory>\exporters\html5\plugins\iap\runtime.js. The Blackberry implementation is implemented with the Blackberry10Store class.

    The product ID is passed as "digitalGoodID" to the purchase() method. 'Request store listing' requests item prices and also calls getExistingPurchases() to identify what products are already owned (since unlike most other stores there's not a method to check if a particular product is owned already). The documentation and samples around the BB10 purchases were not great last time I checked, would be good if you could review the code WaterlooErik and let me know if there's anything amiss. It's difficult for us to test without publishing all the way to the store, where you can't then debug it.

  • hollowthreat - Ludei now maintain the CocoonJS plugin.

  • Low quality mode renders at whichever is the smallest size: the window size in project properties, or the display size. So resizing the window smaller is not slower in low quality mode, it still renders at the smaller size.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Yes, absolutely. That's probably a better example: if you lerp a linear volume from 1 to 0, it will start off hardly getting quieter at all, then will appear to abruptly go silent. (In my previous example see how the last three levels are all under 0.2.) On the other hand if you lerp the dB from say 0 to -60 dB, you will get a smooth fade-out.

  • dB is a much more sensible unit of audio volume than linear scale, because audio volume is perceived with a logarithmic scale. Halving the linear volume of audio results in a drop of 6 dB, and will be perceived as just slightly quieter, not half as loud. "Half as loud" usually corresponds to about -10 dB attenuation. So if you want all your SFX at -5 dB so the music is louder, then you want another sound effect to be "half as loud", you go for -15 dB. To keep dropping the perceived volume by the same amount you'd keep going to -25 dB, -35 dB, etc. Using a linear scale you play all your SFX at about 0.562, then if you want half as loud as that, you drop it down to 0.178. Then stepping down by the same perceived amount you'd go 0.056, 0.018... Not particularly intuitive!

  • We have not made any audio-related changes for some time and as far as we know audio works correctly. The most common problems with audio are incorrect server MIME types.

  • I'm not sure what you're referring to. The debugger lists all object instance variables and every one has a 'watch' icon. Can you describe in more detail exactly what you're doing and where you're looking? Also maybe update to r163, since perhaps it's a bug we already fixed.

  • "Huge" games on mobile are just difficult anyway, since you have much tighter memory and processing capacity. The CocoonJS bug with memory use does make that more difficult, but Crosswalk is not affected and hopefully Ludei can fix CocoonJS soon as well.

  • You do not have permission to view this post

  • Crosswalk has only been around a couple of months, and in that time it's already improved a lot and fixed a bunch of bugs. In the near future I am absolutely confident it will be bulletproof and we're working closely with Intel to support the last features everyone wants (ads, IAP etc). The fact there are bugs in the beta is to be expected and they will be resolved as Intel are actively working on it. Several issues have already been fixed which you can test already with the beta/canary build option. Given how new Crosswalk is and how steady its progress has been I do not understand why anyone would be ready to write it off already. Of course all new engines go through a beta period with a few issues before reaching maturity, that is normal. It will get there soon and the existing progress and even the current state of the canary build option is good evidence of that.

    I also want to point out that we are designing the engine to scale well to large, ambitious scale games. I believe games like Airscape and Penelope prove this is already possible. Optimisations like the recent collision cells go a long way toward making this a reality (collision cells themselves being a relatively new feature). Perhaps a reason there aren't so many "big" games in Construct 2 is people think since there aren't many big games, the tool must only for small games, and then not so many developers attempt big games. I don't think this makes much sense when big games are already being developed and published with Construct 2, but the stereotype persists and probably to some extent is a self-fulfilling prophecy. We also know lots of people develop small and medium sized projects commercially for various clients including for mobile browsers, where it serves as a profitable and efficient tool. Perhaps that's just an easier way to make money than with a single huge make-or-break game; either way, we don't mind, we just make the tool. But we are still thinking about how the engine could better handle large games in case that's what people are after, and any optimisations aimed at large games will probably help smaller games too.

    We also have more optimisations in the works for future builds and we know every browser maker is as conscious of performance as ever and are working on optimisations on their side as well. For example we're aware that one of Google's priorities with Chrome this year is to maximise GPU performance on mobile, and they have some very interesting optimisations in the works towards that (e.g. the ubercompositor, zero-copy rasteriser, etc). All of this will also reach Crosswalk.

    As for iOS, CocoonJS does work for a lot of people for publishing iOS games. We are still trying to work with them to get support for things like memory management. If there are other issues, as ever sending them a clear and detailed bug report with a minimal project to reproduce the problem can mean the difference between getting it fixed and not getting it fixed. However as a lot of you have also mentioned, we're not entirely satisfied with Ludei's rate of progress, so to provide an alternative we will look in to an official Ejecta export option in the near future (we are currently tied up with multiplayer, but hopefully some time in the next stable cycle). However AFAIK it does not have memory management, no Web Audio API support, no WebRTC, no Web Workers (for faster pathfinding), no XML parsing, and no vibrate support. Some of these may be fixable but it remains to be seen if this will be any better than CocoonJS. Still, having a second option could be useful for some games.

    I'd also point out that nobody in this thread so far appears to have tried to argue that native exporters would still be worth it given the likely disadvantages from my previous post. Having a portable engine that can guarantee that even just the logic will work 100% identically is a pretty big advantage and removes a whole layer of porting problems. Remember we are trying to pursue solutions that are both fast and compatible to make porting worry-free. Crosswalk is a perfect example of a perfect solution to that end. We are trying to resist spending months of painstaking work to trade performance problems for some very awkward compatibility problems.

  • Flash is a different technology entirely. You could possibly embed a .swf to the HTML page if you wanted, but there's not much point for mobile, since very few mobile browsers support Flash at all.

  • It sounds like they assumed you are making games using Flash. Tell them you're making HTML5 games instead.

  • You can run any javascript code in the Javascript SDK, so if it is possible in a web page, then you can write a plugin for Construct 2 that can do the same.