Need Performance Advice (Android) - Phone getting hot !

Post reply
0 favourites
  • 14 posts
From the Asset Store
Firebase Utilities PRO- Analytics, Dynamic Links, Remote Config, Performance, Crashlytics
$12 USD
Firebase: Analytics, Dynamic Links, Remote Config, Performance, Crashlytics on Android, iOS & Web Browser
Sparsha's avatar
Sparsha

  • My game makes the phone literally heat up.. I've already tested on a few high-end phones too, other users have the same complain. It's a Massive physics-based multiplayer game, been working on it since many years on-and-off, which is why things are not as efficient as they should be. Didn't care about performance back then when I started learning!

    With some experience now, I have short-listed the reasons, but I need to be sure which ones are more critical than the other. I need to know which one(s) are likely to be causing the heating issue the most:

    1. Numerous collision events (20+ Physics objects, only two of them moving)
    2. High-resolution sprites! 40+ of them! (max is the background 1080p)
    3. 600+ Events (not grouped, all of them in 1 layout/event-sheet) and 30+ global variables
    4. Layout size: 15300 x 1480 (however, scroll-to enabled with viewport of 1920x1080/scale outer)
    5. Other possible factors: Layer Scaling (not constantly), Time-scale set to 1.5, Photon plugin?

    Note: I'm not using any Effects.

    Thank you!

  • Here are the screenshots of debug Inspector/CPU/GPU Profiler etc. Again, I want to know what should I focus on most to eliminate the 'heating' issue. The following is taken from Web preview on my HP OMEN Laptop (GeForce GTX 1060, 8GB shared, 120Hz Display).

    Inspector State 1 (this state remains for 70%+ of the game)

    Inspector State 2 (this state appears for 20-30% of the game)

    CPU Profiler:

    GPU Profiler:

    I hope everything is normal in all of them above?

    Ok fine, better question: I hope not everything is abnormal?

  • Numerous collision events (20+ Physics objects, only two of them moving)

    This could be an issue, but the numbers don't look very large to me.

    High-resolution sprites! 40+ of them! (max is the background 1080p)

    This is more a memory issue, probably not related to cpu/gpu heat.

    600+ Events (not grouped, all of them in 1 layout/event-sheet) and 30+ global variables

    The number of events is unlikely to be an issue, but certain events like long running loops can be. Also limit the number of events that run every tick, and turn pretty much everything you can into triggered events. Updating text every tick can be particularly painful.

    Layout size: 15300 x 1480 (however, scroll-to enabled with viewport of 1920x1080/scale outer)

    I don't think this would cause any issues.

    Other possible factors: Layer Scaling (not constantly), Time-scale set to 1.5, Photon plugin?

    Unlikely, but you can test each of these individually pretty easily.

    Also how is your game running at 120 fps? Thought it was capped at 60, unless I missed an update somewhere. Maybe your phone is a high fps device as well. I don't recall if there was a way to limit it, but this popped up in a quick search that might be worth trying. construct.net/en/tutorials/limit-framerate-build-fps-1381

    Otherwise, its probably mostly up to you to isolate certain things you think may be causing high usage and test and test and test again.

  • Many mobile devices warm up when they're working hard. It's normal and affects any kind of software. For example playing Pokemon Go made my Android phone get pretty warm (and that of course was not made in Construct). A lot of CPU/GPU activity dissipates heat; it's a pretty fundamental aspect of computer hardware.

    Generally optimising the entire game, both in CPU and GPU terms, will help, but so long as the device is having to work moderately hard over long periods of time, you can expect the device to get warm. That applies to all software using any technologies on pretty much any hardware (even desktops warm up too, but they tend to have fans to help, and you tend not to be holding it in your hand!)

  • I appreciate your time Ashley, but honestly that was not helpful, nor did it answer my question.

    For example playing Pokemon Go made my Android phone get pretty warm (and that of course was not made in Construct)

    I was never blaming Construct 3 for the device heat up, and yes I do expect some games could warm up a device. But in my case, it's literally extreme heat up within 1 minute of play. I already acknowledged the inefficiencies in my methods that's probably causing the massive heat up. Shouldn't I work towards making it better? maybe end up to heat up half as much?

    If yes, then I would appreciate a more specific response, especially from you, from the list of possibilities above (and profiler/inspector charts) on which of these could be more related to heating up, than the other.

    Unless, it is "None" of them could be related to heating up, and optimizing any of those would not help. But you didn't also mention that statement, so I am still confused if there is or not anything I should do.

    Thanks!

  • I appreciate your time Ashley, but honestly that was not helpful, nor did it answer my question.

    > For example playing Pokemon Go made my Android phone get pretty warm (and that of course was not made in Construct)

    I was never blaming Construct 3 for the device heat up, and yes I do expect some games could warm up a device. But in my case, it's literally extreme heat up within 1 minute of play. I already acknowledged the inefficiencies in my methods that's probably causing the massive heat up. Shouldn't I work towards making it better? maybe end up to heat up half as much?

    If yes, then I would appreciate a more specific response, especially from you, from the list of possibilities above (and profiler/inspector charts) on which of these could be more related to heating up, than the other.

    Unless, it is "None" of them could be related to heating up, and optimizing any of those would not help. But you didn't also mention that statement, so I am still confused if there is or not anything I should do.

    Thanks!

    Make an empty project and check if the phone warms up or it get too hot. I had the same problem years ago making a mobile game with Construct2, but now it seems that the problem is solved.

    If the phone get the same result with the empty project, it might be a "problem" with the devices that you have used for testing.

    Also, why do you use full 1080p background in a mobile phone? I'm just curious.

  • Also, why do you use full 1080p background in a mobile phone? I'm just curious.

    Many flagship phone have higher than 1080 resolution. The OnePlus 7 pro is 1440 x 3120 (the normal OnePlus 7 is 1080), with a 90hz refresh. Games that let me turn on high framerate mode definitely heat up my phone more than those that don't.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • > Also, why do you use full 1080p background in a mobile phone? I'm just curious.

    Many flagship phone have higher than 1080 resolution. The OnePlus 7 pro is 1440 x 3120 (the normal OnePlus 7 is 1080), with a 90hz refresh. Games that let me turn on high framerate mode definitely heat up my phone more than those that don't.

    Thanks oosyrag ! That means it could really be one of the main reasons! I use OnePlus 7 Pro too at 90Hz, Maybe I should first try setting the limit to 60Hz on my phone to give it a test.. Otherwise, your solution of capping it. Although it does heat up on other phones, but I think since mine heat up most, this is definitely one of the reasons.

  • If yes, then I would appreciate a more specific response, especially from you, from the list of possibilities above (and profiler/inspector charts) on which of these could be more related to heating up, than the other.

    My point was: it's all of those things. All CPU and GPU work gives off heat. So optimising everything - all aspects of your game - will help.

  • I agree with ashely and others, not sure if my response will help, but here is a step by step what to optimize if your game has cpu usage issues.

    So here are my tips:

    1. optimize your event sheet, make sure u trigger once the events and not on a loop or multiple loops.

    (you can use loops, but under a trigger once condition, like generate on a loop a certain amount of monsters in a circle for example, or check on start of layout a array database xy etc)

    2. you don't need 1080p on mobile games... max image quality u need is 512px anything above that is pointless(if you are not releasing for tablets which might need a 1080p resolution so your games graphic doesn't look choppy --- you can separate assets loading based on devices. however id just keep 512px and just stretch content a bit + a zoom in to match the screen of tablet device), and will just ruin ur gpu performance, making the gpu of the device work overtime for no reason.(after u export find the spritesheet or the assets u have and run them trough tinypng.com once... it will clear some "ghost" shades from it, and cut out the extra dead weight that u actually don't need, like pixel perfect shading transparency extra layers etc)

    3. turn the webgl effects off if u can replicate them with normal sprites (webgl heats things very fast in Construct, even if u don't use effects, having webgl activated inside ur game will heat things up for no reason -- there might be a reason but i think this list is just going to be to long ... u can guess what the reason is).

    4. don't use 3rd party wrappers, try and wrap ur APK or IOS launcher as native as possible (latest C3 i think does this pretty amazingly good, any outside wrapper is just overcomplicating ur process and dependencies), don't use 3rd parties like the old ones we had ... they are a mess, learn to wrap ur own with android sdk is rather easy, to sign and release a certificate.

    5. make sure u export for latest android and not some old android version, sure older android versions might make ur game compatible with older devices, but then ... lots of glitches will be reported, cause the android version is out of date or soon to be dumped from the service maintenance, plus old devices = more weird problems.

    6. this sort of goes into nr 2... but is related to audio ... make sure u have the small size exact what u need as sound and music, dont add mp3,ogg,vobb,+++ 1000 other formats inside ur game one game will be huge, 2 u only need ogg for cross compatibility or mp3.

    7. if ur running in app purchases or advertisements... make sure u don't over-call them, this sort of goes into 1).

    8. Optimize ur event sheet ... i noticed that more than 30 event lines per event sheet is going to create a issue.

    9. Optimize ur event sheet ... You can have more event lines by just separating ur events into more eventsheets like (Audio calls, button triggers, global variables, end game, score game, etc), just include them and trigger them when needed.

    10. Optimize ur event sheet ... no more than 5 subevents and 10 actions per event line. the more u have the more cpu will consume cause of how many things the computer has to check in that 1 fraction of a second before he moves to the next condition event.

    If you would be reading the blogs on optimizations, you would see that the longest and difficult part of game development is optimization. and this step is the most important when comes to having a "good product". That is why i always recommended when going into a "big product for public" make sure u design and code your game from the beginning "optimize in mind". otherwise once u finish it 1 year later, you have to go back to beginning and redo all the code.

    Hope it helped, but i doubt i said anything helpful in here that you didn't already knew.

    As per device heating up as Ashley said, and i think newton also.... for every action there is a reaction, so cpu/gpu is used (especially on a 80% usage cpu) u will have a reaction out of ur device = heat ... ur mobile game ideally should sit at 0-15% usage idle (CPU+GPU) and ~50% on triggers and rendering. not 70% all the time.

  • Thanks Ashley.

    Thank you so much GeorgeZaharia That really was useful ! Especially Event sheet tips! I think that's the core problem in my case... I do have a huge list of actions for every event and the same for sub-events! I must reduce the repetitive ones and organise them.

    Thanks for sharing your experience... I'll keep the tips in mind. Especially publishing to newer Android versions, that's quite true.

    So hopefully, optimising everything will reduce the heat and usage drastically.

    Cheers!

  • Just gonna chime in again, all the advice above is good, but I wouldn't put too much weight on 8/9/10... You can go try, but in my opinion it shouldn't make a huge difference. I especially wouldn't recommend going out of your way to chop up your event sheets into arbitrary numbers of events with hard limits, more so if readability and organization are sacrificed.

    On the other hand, if it does help readability and organization, refactoring is absolutely a good idea.

    Specifically for performance though, as I mentioned before, keep an eye out for inefficient loops and things that run every frame that don't need to run every frame by using triggers instead (#1 in George's list).

  • Its probably already been said, but when optimising ur events you need to use groups, so you can see in the debugger where cpu is spending the most time.

  • With some experience now, I have short-listed the reasons, but I need to be sure which ones are more critical than the other. I need to know which one(s) are likely to be causing the heating issue the most:

    1. Numerous collision events (20+ Physics objects, only two of them moving)
    2. High-resolution sprites! 40+ of them! (max is the background 1080p)
    3. 600+ Events (not grouped, all of them in 1 layout/event-sheet) and 30+ global variables
    4. Layout size: 15300 x 1480 (however, scroll-to enabled with viewport of 1920x1080/scale outer)
    5. Other possible factors: Layer Scaling (not constantly), Time-scale set to 1.5, Photon plugin?

    i totally skipped ur list lol... but yea when comes to collisions, it sort of needs to be clutter free. like the more objects interact in the same time glitches will pop depending on device performance now.

    but around 20 objects interacting in screen can be around normal shouldn't create to much issues.

    high-resolution sprites, max quality should be 512px unless u need for 4k screens. but if ur target is mobile, id keep it at 480p or 720p .. for background images for characters i think 128x128 is pretty big and should show up on most devices very sharp and crisp.

    on events like i said, organize them make sure ur trigger the loops when needed and not have them trigger all the time.

    layout size.. doesn't matter that much.. it might take some cpu but only if u are rendering it all at once, if u scroll into it like on a platformer, and u dont need gameplay wise to go back once screen past some area... u can destroy the objects outside screen, id just create the objects when screen is in that area, will spike a bit the cpu every time u move to new area but then should balance to lower cpu usage and gpu, once creation event finished.

    glad it helped u :)

Post reply
  • 14 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)