Ashley's Forum Posts

  • It's exclusive to C3.

  • Look in the browser console for the error message.

  • Real-time collaboration has some extraordinarily difficult problems to the extent I am sceptical it would be as useful as anyone imagines. See our response here.

  • I can't reproduce any such issues. I regularly test on high-DPI devices and haven't noticed any of the issues you describe at all.

  • Please make a bug report following all the guidelines.

  • Try pressing 'Reset dialogs' in settings.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The blog post is pretty out of date now. We had too many issues relating to seams at the edges of those sections, that we just removed that mode and basically render it tile-by-tile now, so it doesn't matter what the tile content is. We're also going to change it again in future. So I wouldn't try to optimise your tiles based on any current algorithm at the moment.

    Empty tiles are simply skipped so don't use any fill rate.

  • We intend to have a desktop build that can save folder-based projects like C2 can, but we have no ETA at this time. I would guess early next year.

  • I've backported the C3 fix to C2 for the next build, so it should be fixed then.

  • If you mute your phone then it blocks all apps making sound. If you're watching a movie you don't want a random app to suddenly start blaring out audio even when you've muted your phone. There is no way for apps to circumvent this. It's just how your phone works.

    Phones have multiple volume sliders for media, ringer, alarms, etc. I presume you've just got them confused which has misled you in to thinking apps can work around this. They cannot. If you completely mute your phone there is no way for an app to make any sound at all. You probably need a screen in your app that plays some music and says "please turn up your volume until you hear the music". There isn't anything else that can be done about this.

  • Ninjadoodle - as the manual notes, the reading is a timer-based estimate. There's a lot of stuff that can throw it off. For example if the CPU throttles down in to a low-power mode to save battery, it will take longer to do the same work. This makes the CPU take longer to process a tick, and since our CPU reading is a timer-based estimate, the timer covers more time, and makes for a higher reading. So you can end up with a high CPU reading even when the device is using say 10% capacity, because it's done something like clocked itself down by 10x to save battery.

    This happens a lot, and I've also noticed it in C3's GPU measurements too. If you run a benchmark the measurements will steadily increase towards close to the 100% mark, then suddenly jump way down as the workload gets more intense. The device didn't suddenly have less work to do - it's always been increasing - it probably just jumped up to a higher performance mode to compensate for the workload. We can't access the CPU/GPU usage directly in a browser, so we have to estimate it from timers, and this is one of the drawbacks of timer-based measurement: we really measure "how long did the work take" rather than the more accurate "what proportion of capacity is being used".

    I made a quick demo and ran it on an iPad Air 2 with iOS 11. It does start at around 83% CPU. However if you touch the screen a bit, the CPU drops down to ~10%. This is probably because it starts in a low-power mode doing work slowly to save battery, but when you interact with it then iOS boosts the priority of the app, powers up the CPU, which does the work faster, so a shorter time is measured, so the engine's CPU measurement drops down.

    So yes, it's normal. It's not really using up all your CPU, it's just saving battery. Since we have to use timer-based measurements, you will only get reliable measurements when driving the device to its highest performance tier.

  • APK files are for Android. We don't build IPA files for iOS yet, but C3 can generate an Xcode project for you.

  • Android or iOS? They handle this differently. On iOS generally it keeps the viewport the same size and shifts the text field in to the visible part of the viewport and everything works OK. On Android though currently the keyboard changes the viewport size, which kicks off a fullscreen scaling resize, which then changes the textbox size. Then you get in to all sorts of awkward situations where you can't see the input, or it scrolls away and therefore hides the field so the keyboard closes, etc. It's made harder by the fact browsers do not provide any way to detect if the keyboard is currently showing, and just to throw another spanner in the works, Android is currently changing the way they handle this, so if we fix it now it could be broken again shortly. All in all, a big headache.

    Generally we don't fix bugs unless there's a report filed for them - can you link me to any relevant bug reports so I can take another look? It's probably going to involve some kind of ugly hack though...

  • If you press Windows+R to open the "Run" dialog, and then type in firefox and press enter, does it start Firefox?

    That's effectively what C2 does. If that doesn't work then there must be something up with your Firefox installation.

  • Closing, please see the bug report guidelines.