I am using AndEngine GLES 2.0. sometime when I resume my activity there is a complete blackout in the game. Although update and touch events of sprites are working but there is a complete blackout on screen. what is the problem?
AndEngine assumes the EGL context was invalidated, and thus must reload all your resources. This typically takes a non-negligible amount of time, causing a black screen.
Efforts are underway to eliminate this problem on Android 3.0+ where possible, but it will likely always affect Android 2.x
My problem is solved now. Blackout is due to the memory management. I was loading engine every time user plays the new Map. One should load engine for only one time and use Layers.
Related
I have created a simple game using a class a which extends SurfaceView and implements Runnable. In the game the drawing is done inside the public void run. Which is targeted by a thread as soon as the activity launches. The game is taking a lot of time(sometimes 10-15 sec) to load. As well as when the game is paused(thread. join()) and resumed(thread = new Thread(this); thread.start()) it takes too much time.
What might be making the game load slow? And what can be the solutions?
The most common cause is resource loading.
I/O operations are very slow, so, if you try and load all your bitmaps before actually drawing, this can cause significant delay before the drawing actually starts.
One strategy to avoid this is to preload your assets before you actually need to start using them. A lot of games do this in the so - called Splash screen. Also, don't be too fast to recycle your assets and free the memory they are using. This means that you will need to reload them the next time you start.
Overall, there is no exact recipe of how to do it - there is a constant trade - off between load times and memory consumption. You just need to experiment and try to see what fits your use case best.
Be sure to profile your app, examine the object creations and memory allocation calls using your IDE. Most of the time you can easily pinpoint the causes of problems there.
I found that the game was loading slow because the thread has been running continuously, without any sleep. So just adding Thread.sleep(15); inside the run, with all exceptions handled, solved this problem. Thank you for supporting.
I am working on a cannon game for Android, which requires procedural generation of levels. As the player flies through the air, new sections get added on to the end of the level to keep it going indefinitely. As those sections are added, sections that the player has already passed are deleted. The problem is that the creation of a section usually leads to a GC_FOR_ALLOC, which pauses the game for around 30ms and causes noticeable lag.
The free memory stays fairly consistent, as objects are deleted while others are added, so there doesn't seem to be a memory leak.
The engine I am using is the cocos2D-android-1 port from iOS.
I saw many solutions along the lines of "don't initialize things while the game is running", but the nature of the level generation requires this, since an indefinite-length level can't be created right at the start of the game.
Thanks for your help!
You are not very specific. If the lag is too big, you must try to reduce it.
One way could be to collect more often - resulting in shorter, but more often occurring pauses.
For example you might create smaller or only partial sections and try to nudge the garbage collector afterwards to run. You would use System.gc() for this. But be aware that System.gc() is not guaranteed to result in it actually starting to run.
An even better solution would be to reuse objects. Objects that were created before the level was started. This way even an endless level would not result in any garbage collection since no garbage accumulates. But be sure to not create any non-pooled objects!
Our Android game has an issue which appears unique to the Galaxy S2.
Occasionally the render will stutter. By this I mean it basically seems to render the last two frames (as though its swapping the last two render buffers without updating either).
What's really odd about this is that the game continues to update, so say the stutter lasts for 2 seconds, the game will have progressed 2 seconds behind the scenes.
This is odd because our code is basically like this:
function Update()
DoGameLogic()
DoRender()
So this means that if our the game has updated, the game has also rendered. The maximum delta time is capped to 1 frame so there must have been more than one Update and thus multiple renders during the stutter.
My current theory is that on most devices the game lags during render, but on the S2 the render calls are executed but they "fall through" without updating the render buffer.
Has anyone run into this problem? I would really appreciate any suggestions about what this could be.
We found out what the problem is.
The Galaxy S 2 was for some reason running out of GL memory. This wasn't apparent on the devices we were testing with, but on other devices it would crash on some Open GL call - not the offending call mind you.
Eventually we tracked it down to using Point sprite VBO's. As the S 2 is a powerful device, we replaced Point sprites with Quad's mimicking point sprites as a workaround.
Incidentally, SoundPool would also run out of memory on this device, requiring another workaround.
I created an app for android. I'm using canvas and making more and more "Sprites" from my Sprite class. when i start the app and there is only one sprite the game runs super fast. I made the class to create more sprites every time the timer i set up gets to 25 (so there would be an even space between each sprite). but when each of the sprites appear and it get to the max that i have made (5) it gets slower. So, my question is, How can set a custom framerate/speed to my app. Is it even possible? and if it does can you please write the easiest way? Thanks!
Here's a good article on how to set up a game loop. That will help you control the framerate of your app (make it consistent). Also, note how you doesn't wait a constant amount after drawing. Instead, you wait a constant amount of time between frames.
Testing my game on a slower device (Orange San Francisco aka ZTE Blade) and I have been getting an appalling frame rate.
I put some debug code into the draw loop and discovered the following line is taking over 100ms:
c = mSurfaceHolder.lockCanvas();
Anyone else seen this behaviour? I temporarily replaced the surfaceview by extending View and implementing onDraw(), and I got a much better framerate.
Although in general surfaceView is much faster on my HTC Desire. I am suspicious this may be a Android 2.1 problem. I'm contemplating rooting the phone and upgrading it to 2.2 if possible, but I did want a device running on 2.1 so that might be counter-productive in the long run.
** update **
I've been working on this some more, and have discovered some more puzzling aspects to it.
I rooted the phone and installed 2.2 and the problem still happens. When the app is first started, the lockCanvas is working as expected (0-1 ms). Then at some point during my initialisation, lockCanvas suddenly starts taking approx 100ms.
It might be worth pointing out that I am loading my assets in an Async task, so that I can display a loading screen.
Despite my best efforts to pin down what the program is actually doing when the slowness occurrs I was not able to do so. In fact when I run it in debug mode and single step, it works fast!
Now I discovered that if I add a delay in the constructor of my SurfaceView (of about 10 seconds), the slowness doesn't occur and all works fine.
However if you press Home, and then switch back, the slowness comes back.
I'm pretty much at the end of my tether on this stupid illogical problem! I've got a mind to put it down to a device specific problem.
I feel it could have something to do with memory usage. Maybe something is being swapped out and it affects the video ram?
I'd be interested in theories at least.
About lockCanvas() from docs:
If you call this repeatedly when the
Surface is not ready (before
Callback.surfaceCreated or after
Callback.surfaceDestroyed), your calls
will be throttled to a slow rate in
order to avoid consuming CPU.
Is it possible that your draw loop is initiated too early for some devices? I think this is the problem, since you wrote:
Now I discovered that if I add a delay
in the constructor of my SurfaceView
(of about 10 seconds), the slowness
doesn't occur and all works fine.
So, maybe we could use holder.isCreating() to check state?
this method will return true if canvas still creating.
Something like
while(holder.isCreating()) {}
can=holder.lockCanvas();
But I'm a bit confuse now. As i know colbeck is called when a surfaceview is creates. We should implement SurfaceHolder.Callback interface. And when surface is created callback method
public void surfaceCreated(SurfaceHolder holder) { } will be called.
From surfaceCreated method I'm starting gameloop thread.
I have recently discovered that if large bitmaps are used to draw on the canvas and these bitmaps are stored in the activity class - the "_surfaceHolder.lockCanvas()" command itself takes very long (about 70ms depending on device). HOWEVER, moving these bitmaps storage to other class (in different file, say MY_DATA), and the activity has just a reference to that new class - solves the problem.
I'm have no explanation to this phenomenon.
I was encountered the same mysterious problem with Canvas drawing, but solved it by changing Canvas drawing to drawing on the SurfaceView. But now I have constantly slow lockCanvas() call.
Here is my observation results.
Problem is only present on some devices:
Galaxy Note 3 n900: has problems
Galaxy Note 3 n9005: has problems
Galaxy S4 i9505: has problems
Galaxy Gio: no problems
LG G2 D802: has problems
Galaxy S2 i9100: no problems
I temporarily replaced the surfaceview by extending View and implementing onDraw(), and I got a much better framerate
I also noticed, that Samsung phones using GLES20Canvas instead of regular Canvas with onDraw() drawing, as a result, better performance.