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?

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!

I use anglediff(angle(B.x, B.y, A.x, A.y), B.Angle), this will always gives me a result between 0 and 360. But angular velocity is either a positive or negative value(for clockwise or anticlockwise). Im probably a little stupid here, but I dont understand how a can apply an angluar velocity in the opposite direction of a number thats always positive (0 -> 360)

anglediff will give you the smallest angle (the difference between the two angles) that should be from 0 to 180 degrees. However, in your case it will probably be within 0 and 90, which is even easier to work with.

That value should help you find the 'impulse' amount (smaller anglediff means larger impulse) and also the amount of angular velocity (smaller anglediff means smaller torque).

However, yes, you cannot find out the direction (plus/minus) angular velocity from that. You need to check if the Physics object 'is clockwise from' the bullet direction or anticlockwise.

So, if [PhysicsObject] "A" is clockwise from [ angle(B.x, B.y, A.x, A.y) ]
Then, angularVel = angularVel
Else: angularVel = - angularVel

An easy solution could be to have an invisible and tiny Physics 'bullet' sprite pinned to the bullet at all times? So it will be a realistic Physics collision.

If not that, then you can do it with a Bullet (non-Physics) and hitbox (Physics) by measuring the perpendicular distance from it's pivot (and/or center of gravity that you define) multiplying with a factor of bullet speed, which will give you the amount of 'Torque' that should be applied to the Physics object combined with (inversely proportional to distance) an impulse. This will require a lot of trials and errors. To save time, you can set up a repeating algorithm where you simply adjust the Torque factor and Impulse and perhaps compare it with an identical clones of two Physics objects to see which values match best to the real impact.

I would personally go with the first option and make life simple.

Yes, that's the problem as the above user explained. And yes, increase the text box size (or reduce font).

Alternatively, if you want Ranktxt exactly where it is, then you can just do this:

This 'Wait 0 seconds' simply skips the following actions and runs them on the 'next tick'. (So by then, it has already completed reading and writing the Array, and comes back to update Ranktxt in nearly 0 seconds)

Are you sure you're using "Touch" and not "Mouse" object ?

You must share your c3p project file for us to look what's wrong. OR if your events are not too many, then share a screenshot of eventsheet where Touch conditions are used.

It's easily possible. Simple maths would do it, by using the % 'Modulo' (remainder) operator.

Go to System --> Compare two values, then write this:

It means, when the remainder of (shots/10) = 0, then do something. So every multiple of 10 (of shots) it will become true.

Your events will then simply be:

..and so on!

(Note: It will also unexpectedly trigger when shots or kills are 0, because 0%10 is also 0. So just have another condition of shots > 0 to solve that). Let me know if it works.