It sounds like a return of an old Android bug, it would be appreciated if you could file a new issue for us to investigate.

To go to the current stable just visit https://editor.construct.net, it always points to the latest stable ( not beta ). You can choose a specific release on the releases page it will tell you to update, but you can ignore this.

Projects saved with a newer version won't open in an older version, this is for compatibility safety. In most cases the project can be safely modified to open in an older version.

Go to your application(Android version) on the AdMob website, select "app settings" from the menu. You will see a label "App ID", it will look like "ca-app-pub-0000000000000000~0000000000" that is the ID you want.

igalencar use the debugger and inspect the instances

Ashley

Hmm... maybe GC heuristics work differently in a worker?

I expect the scheduler to behave differently at least, so yeah GC timing is probably different as well. I'm not sure what the threading behaviour of Orinoco is when your in a worker, so that could effect how long GC takes compared to main thread as well. JS execution time definitely seems to be different.

It's hard to keep track of heap size and frame rate in dev tools when using worker mode because it tracks the main thread.

Measuring the performance difference is difficult, the most obvious way is the CPU Profiler in debug mode. But that doesn't really tell the whole story. For instance, the CPU profiler isn't good at showing spikes ( which cause missed frames and jank ), as it shows live performance if you have heavy usage for a frame or 2 you are unlikely to see an accurate representation of that.

While working on the procedural terrain demo I spent quite a while looking at performance to make sure that it ran smoothly. Due to the way the game works it generally has quite a low CPU level, but has VERY high spikes when you cross a loading threshold ( which is quite often ). These spikes would often cause dropped frames, which is unpleasant while moving around. To test what was causing them I mostly used performance recordings from chrome dev tools, as you can see frame times and CPU usage flame graphs for the duration of the recording. I tried testing worker mode to see if it made a difference. However, due to the way OffscreenCanvas works Chromes framerate is technically 0 when your using worker mode... So it's difficult to even tell if your dropping frames! You can however check how much frametime you used, which is fairly close.

Performance with worker mode is... different, before xmas I was seeing a notable performance improvement with the procedural generation demo, but now I'm seeing a fairly large drop. This may partly be due to changes I made since then ( reducing loop iterations mostly ) but it may also be changes by the Chrome team. It's hard to tell. It's biggest win is that if your game is using significant CPU time it won't slow down whatever work the main thread is doing ( DOM elements, mouse movement, scrolling, audio ) and vice versa.

Diepther I can sympathise, the behaviour of the Google Auth API is frustrating to work with. I've tried my best to streamline it, but there is no useful output from it to give to the developer here.

Last time I had to debug an issue with the API I found myself unable to get past this point for most of a day. The issue in the end was that we had changed to a new test account for our devices, I believed I had added the account to the test users for the application but had placed it on the wrong application.

Resolving issues with this basically falls to trail and error, so all I can do is give suggestions. Sometimes the auth API will print kind of useful information to logcat in Android Studio, but you will have to sift through a huge amount of superfluous information from your device and jump through the correct hoops for getting Android Studio to produce a signed debug build.

The Mobile Advert plugin does not have any configuration option for the position of the banner advert, and it's not hidden away somewhere. We create a layout with the banner at the bottom, over the top of the webview. Attaching it to the bottom or the top generally isn't as easy as toggling a flag, and the process is different on Android and iOS. It's probably possible to edit an Android Studio/xCode project export to change how the banner is positioned, I haven't looked at the code responsible for quite awhile so I'm not sure how difficult it is.

We consider this to be an enhancement to the plugin, not a bug. If you think it is important please let us know using the ideas platform, so we know how to prioritise it.

https://construct3.ideas.aha.io/ideas?project=C3

Also as a reminder

https://www.construct.net/en/forum/general/open-topic-33/forum-community-guidelines-141035

There's no time limit on the free version, some features are locked out though. Most of them won't effect you with your first couple of projects. You can see the limits here:

construct.net/en/make-games/buy-construct-3/personal-plans

I recommend giving the beginners tutorial a go, you can do the whole thing in the free version and it walks you through building a game for the first time.

https://www.construct.net/en/tutorials/beginners-guide-to-construct-3-1

Have fun!

Hi pirx

Check out https://www.construct.net/en/make-games/manuals/construct-3/tips-and-guides/performance-tips

I recommend running your code in debug mode and seeing what is using up your CPU time. It can be easy to use up your CPU budget, particularly with a large number of objects on screen. I expect your event sheet is probably using the most time.

Without seeing your project it's hard to diagnose it. There's a large number of skilled users in the community who are probably better at optimising projects than I am, but they will still need to see at least part of your project to help you.