Ashley's Forum Posts

  • What model device are you running it on and have you tested many other devices? Normally this kind of problem is some ancient device that has buggy graphics drivers and so reverts to software rendering. Virtually all modern devices should be just fine.

  • You must URLEncode URL parameters for them to be sent correctly.

    You can't put a string like {email:example@example.com} in a URL, because it uses special characters which aren't allowed in URLs. If you URL encode it, you get %7Bemail%3Aexample%40example.com%7D (note no braces, colon or at sign, because none of that is allowed in URLs). This is why Construct provides a URLEncode expression. And it's also why it tells you that when you select the "Data" parameter!

  • I'd point out on the upside, we have shipped over 160 ideas so far, including many highly voted ones. Many of these ideas were indeed valuable and the suggestion platform probably did a lot to help bring them to our attention. But to give you an idea of the amount of work involved, that's 160 or so ideas over about 3 years since the suggestion platform was set up. There's over 700 more ideas on there. That's probably another ~5 years to cover, during which time we could easily have another 1000 ideas filed. And the ones we've covered already are probably focused on the small/quick/easy ones, and there are many remaining suggestions that look like at least they need a dedicated 6 month project to get them done, with major implications for on-going maintenance too. So we'd only need to pick 10 or so of those and it's another 5 year's work.

  • As I mentioned, that would potentially be a very large amount of work, and we just can't afford the time to do loads of administration on this.

  • Change the preview mode to 'Browser tab' in settings and you should be able to use the full dev tools, including simulators.

    The presence of the address bar does not mean 'scale outer' is not working - the browser controls that, not Construct.

  • The snapshots feature lets you read the canvas pixel data, modify pixels with events, and then put that pixel data back in to the canvas.

  • Generally the problem is it has been misconfigured somewhere. Double-check everything is set up as described in the manual entry. Also note it advises waiting 24 hours for new accounts since AdMob can take a while before it starts serving ads.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I just tried an iOS build and it worked fine. I haven't seen any other reports of issues either. I'd advise filing an issue following all the guidelines if you have trouble.

  • It's difficult to manage the suggestions platform - I estimate there's already about 10 years of work on there and people are still adding more regularly. As a small team with limited resources, even administrating it could be a huge amount of work. For example even just commenting on every suggestion would be a massive job and probably take a week or two at the expense of everything else we have to do, especially since in many cases even a brief comment covering the feasibility could involve reviewing lots of source code, architecture, and thinking about how it could fit in with existing systems. Similarly adjusting the processes could be tricky, and we also have to work within the confines of what Aha's system supports. I think picking a subset of users to review or curate suggestions could also prove unpopular as it essentially creates an elite few who get more control over the product, which kind of defeats the purpose of the system as trying to identify what most people want. There's also occasional cases of ballot-stuffing too so I'm pretty sure whatever we set up, people will try to game it.

    It would indeed work a lot better if people shift most of their votes to small/quick/easy things, which ideally would get done quickly, and allow the votes to be shifted to the next easiest thing. I have suggested people do that several times, but naturally a lot of votes go for big and potentially exciting projects, which are the very hardest and most time consuming to do.

    I'm not sure there's any good answers here. Periodically we take a look and do anything that looks particularly quick and easy. However given our limited resources and the amount of time that we have to spend on things like support, reviewing bug reports, maintenance, administration and so on, we don't have a huge amount of time to spend on new stuff to begin with. And every new feature, even small ones, tend to require several weeks to go through implementation, adjustments and bug fixes through a few beta releases, and then long-term on-going maintenance as the long tail of bug reports rolls in, and even later down the line when rewriting or upgrading existing code.

  • It's difficult to imagine a useful feature where you manually choose a spritesheet, because all spritesheets are dynamically created on-the-fly and they could be completely rearranged with even a small change. Pinning sprites to a specific sheet could also even result in even less optimal results, since it removes Construct's flexibility to later group the sprite with a better sheet.

    Does this actually have any meaningful impact on the memory use of your game? It's unlikely any automatic spritesheeting algorithm will ever be perfect, and manual intervention could make things worse. So one or two spritesheets that aren't ideal may be an acceptable result.

  • If Construct randomly closes that suggests the browser crashed, not Construct. Normally web pages can't close the browser themselves even if the page's logic crashes, since that just logs an error to the browser console.

    As for why the browser might crash, I can only speculate, but graphics driver problems is a common cause of stability issues.

  • Construct uses the placement of objects on layouts as a way to group objects that are used on layouts together on to the same spritesheet. So which layouts are these objects used on? If none of them are used on the same layout then perhaps there's something could be improved in the way Construct analyses this. However it might be something else, like relying on dynamically creating objects at runtime without them being placed in the layout, in which case Construct can't analyse which objects are used together. As ever it's easier to comment if there's a sample project provided.

  • You can use the 'Set canvas size' action. But it seems an odd thing to do, I assumed most games would always use the same viewport size.

  • If you're writing JavaScript code, why not just use the Instant Games SDK directly? There's no need to go via the built-in plugin.

  • It may never be a problem. Use the profiler to make measurements about what's actually performance intensive in your game, rather than guessing. Otherwise you're likely just wasting your time.