My game is slow in phone

neverjoy

hi sirs,

With the help of sirs here, i was able to complete my second game. now the thing is in my phone and other phone tested, it shows drop in fps and i noticed somewhat the phone heats, but my game is just a simple jumper, obstacles come, you just dodge by jumping over it, that's all. It's very simple in mechanics and i really suspect that my programming to blame -causing memory leaks etc.

As a newbie, I need to know sirs what is your golden-rule-to-effecient-coding or at least what you keep in mind when making your games.

I noticed myself: (i need to know sirs if these causes it)
-i usually use a lot of enter frame events..
-i like to put mathematical operations as arguments to functions like..

avatar:run(movSpeed*movAdd*t)

-i use just change the texture when using animations.. and using enter frame to control it..
that is one enter frame event per animation in one object.

thanks.

Tom2012

Hi NeverJoy!

Here's what I find... When I'm working on a game, I forget to test memory leaks and FPS - the main things that need to work for my game to run smoothly. So, every now and then during development, it's a good idea to run the FPS and memory leak checks.

It's highly likely that you will have memory leaks and FPS problems and there's always something causing them.

Incidentally here's the code for memory leak checks

-- Memory leak checker   memNum = 0 floor = math.floor monitorMem = function()   memNum = memNum + 1 if(memNum==20) then collectgarbage() collectgarbage() collectgarbage() memNum = 0 print("MemUsage: ", floor(collectgarbage("count"))) end end   stage:addEventListener(Event.ENTER_FRAME, monitorMem)

And here's the code for FPS checking

local frame = 0 local timer = os.timer() local qFloor = math.floor   local function displayFps()   frame = frame + 1 if frame == 60 then local currentTimer = os.timer() local fps = qFloor(60 / (currentTimer - timer)).." test" print(fps) frame = 0 timer = currentTimer end end     stage:addEventListener(Event.ENTER_FRAME, displayFps)

The best way to find what's causing slowdown is to disable everything you can and then 'turn it on' one at a time, checking FPS / memory leak after each one. Disabling elements in your game can be as simple as commenting out each class, or turning off all graphics (you have to code that into the game, it's not a feature).

That's a bit of a vague answer but each game is different. The code you mentioned doesn't seem problematic and Gideros is a very FAST framework. It only usually slows down if there's a problem with one of your classes.

In my experience, the main cause for memory leaks is not removing something from the stage properly OR having a table reference to a sprite that prevents it from being garbage collected.

One last thing, you didn't mention what your testing device was. It could be that it's an older model that is safe to disregard (but it might not be!) Or it could be a problematic class, too many sprites (unlikely on modern devices...) or something different. Code in a way to turn parts of your game off and then go from there. You'll soon find it.

neverjoy

Dear sir @Tom2012. Thanks for the reply. Thanks for these handy little codes. My game when tested on pc shows no decline in fps but in device after some time being run it shows decline in fps. So how woud i find the suspect of fps drop if this drop shows only on devices and not in pc? I mean the codes for fps drop check in gideros might not return accurate reading since there is no fps drop in pc.

tkhnoman

Any visible object ( setVisible(true) ) in the game would be rendered, and that means it consume CPU, so make sure you only turn visible of an object on when the object is in the screen bound.

The main problem that slow down your game usually is that, or any renderTarget/shader object. Don't worry about calculation to much.

[Also of course, memory leak like Tom2012 explained]

neverjoy

sir how would i check all objects at stage to know if there are objects that aren't remove properly?

amin13a

Don't use onEnterFrame for change the texture. Changing texture is not a cheap work.
Use Movieclip class to change texture for animation. Its very fast. One of my game runs in 60 fps on low end device with 100 sprites ( 14 textures 60*60 size for each of them. ) and a lot of calculation in lua.
Another point: Never use large textures. Never!

amin13a

Here is a simple structure for classes in Gideros.
I like it very much.



Person = gideros.class(Sprite)

function Person:init()
--members
self.myName = "Amin"

self:addEventListener(Event.ADDED_TO_STAGE, self.onAddedToStage, self)
self:addEventListener(Event.REMOVED_FROM_STAGE, self.onRemovedFromStage, self)
end

function Person:onAddedToStage()
self:addEventListener(Event.ENTER_FRAME, self.onEnterFrame, self)
end

function Person:onRemovedFromStage()
self:removeEventListener(Event.ENTER_FRAME, self.onEnterFrame, self)
end

function Person:onEnterFrame()
-- every frame this code is run.
end

function Person:myMethod()
return self.myName
end


Now somewhere in the code:

local me = Person.new()
local name = me:myMethod()

NatWobble

A few other things to think about off the top of my head:

1) RAM use. All images are decompressed at power of 2. So a 513 X 513 image will take the space of a 1024x1024 image. So in RAM terms that would be 1024x1024 pixels X 32 bits divided by 8 bits per byte =4MB, whatever it's compressed PNG size. So think about how many images you are loading and are they really necessary? It's best to keep in mind power of 2s to be efficient. Don't go slightly over a power of 2 threshold unless you really need to. Using too much RAM is a big performance killer.

2) Draw calls. I remember a few years back reading that most mobiles couldn't draw more than 3 layers at 60FPS. It might have improved a bit since then, but we try our best to stick to no more than 3 or 4 max. Don't layer sprites over other sprites where you don't need to. You say your game is a runner - have you got large backgrounds covered by large foregrounds etc? If so, think about your design a bit to reduce overdraw.

3) Overuse of transparencies. Some transparency is essential in games, but it's also very GPU intensive. It still counts as a draw call, and is actually worse than an opaque image. A border created as a one sprite window, for example, is terrible for the GPU - It is much better to create the horizontal and vertical parts as 4 separate sprites.

Generally the main drags on performance are to do with what, how and how much you are rendering, rather than maths logic and, as mentioned above, whether you are clearing your memory.

mertocan

Hello,

Even if I am using scenemanager, when I change page to empty one, collectgarbage("count") doesnt decrease.

Is it normal?
If not ,What can be the reason?

I think, It should be something like 10-20.