One thing I have found which I'm not sure if it's right or not but seems to work much better for me.

Where you have the line that puts the bitmap on the screen, at the end you specify new Paint().

From what I can make out this means that everytime it places a sprite on screen it creates a new paint object.

I tried creating a single paint object at the start of the project mPaint = new Paint(). and then just used this instead of new Paint() for all the lines placing the bitmaps.

This seemed to speed my application up a lot and cured the majority of the force close errors. I do still get some though.

It definately seems as though the application isn't cleaning up after itself.

In reply to the command to close the application isn't there a finish() function that supposed to destroy the application? or does that still not clean up after itself?

Matt.

Danuubz wrote:How do you exit the application?

It sounds like you press 'HOME' button or maybe 'Back'. I would use System.exit(0) for this.

Thats ok but what if you want the user to be to press the home button but then return to your app by pressing the back button.

When people press the home button or recieve a call etc the code should call the pause function and then put the program into a wait loop. Then if people return to your app it should resume from where it left off. Android then has the ability to shut down any applications that are in the background if the space is needed.

So if you set the application to exit when it loses focus you would end up with people being kicked out of games because they recieved a phone call which I doubt they would be very happy about!

I think the problem is something along the lines that when a user launches an application it runs it from the start, recreates all the resources etc even though there is already a copy loaded into memory.

I guess we need some sort of routine that detects if the applicastion is already loaded when you launch it. And it it is it either kills that app or bring that app ot of the background and kills itself?

Am I making any sense or am I speaking c##p?

Matt.

Croccy22 wrote:Thats ok but what if you want the user to be to press the home button but then return to your app by pressing the back button.

When people press the home button or recieve a call etc the code should call the pause function and then put the program into a wait loop. Then if people return to your app it should resume from where it left off. Android then has the ability to shut down any applications that are in the background if the space is needed.

So if you set the application to exit when it loses focus you would end up with people being kicked out of games because they recieved a phone call which I doubt they would be very happy about!

I think the problem is something along the lines that when a user launches an application it runs it from the start, recreates all the resources etc even though there is already a copy loaded into memory.

I guess we need some sort of routine that detects if the applicastion is already loaded when you launch it. And it it is it either kills that app or bring that app ot of the background and kills itself?

Am I making any sense or am I speaking c##p?

Matt.

There is a standard way to handle that, but I've never been able to figure it out. It has something to do with the savedInstanceState Bundle, but despite being a totally necessary function for any program to have I've never found a straightforward tutorial or explanation of how to use it effectively.

If you implement it correctly, then it will give your app the ability to lose focus and then pick up where it left off, as well as the ability to flip the keyboard open and closed without forcing the program to restart from the beginning. I fooled around with it for several hours a couple weeks ago and just couldn't figure out how to make it do anything.

I looked into the savedInstanceState bundle a little more and I'm no longer convinced that it does what I thought it did. It's pretty limited in what it can hold and it appears to be completely manual, requiring handwritten logic to save or rebuild your state from scratch at any moment.

I looked at the original Lunar Lander code from which this template is derived, and it does look like there is quite a bit of manual save state logic involved. Is this really the only way to do things? My game's logic is broken down into multiple levels of objects (representing level maps, tiles, characters, enemies, whatever) some of which are objects containing other objects, or inhereting from other objects, and getting down to the bare ints and booleans is going to be a relatively in-depth process. I'll give it a try if it's the only way, but it seems extremely invasive and I'm hesitant to believe that it is the only possible way to write a game for Android. Does anybody know of a more elegant way to solve this problem?

its the way google does it in all of the examples, and its the way i have been doing it. i dont think there is another way. I didnt see it as a problem as it would be similar to saving a game state to file or something like that if you were developing a game for PC.

esteem wrote:its the way google does it in all of the examples, and its the way i have been doing it. i dont think there is another way. I didnt see it as a problem as it would be similar to saving a game state to file or something like that if you were developing a game for PC.

That's a good point, I've never done a game with a save state so I hadn't thought of it that way. I'll do my best to implement this and I'll report back if it fixes my stability issues.

Croccy22 wrote:Hi guys,

Can someone give me a piece of sample code that does the following:

I see in the code above where it places your png on the screen. Thats fine.

What I want to do is have a png that is 150 pixels wide and 50 pixels high. This png will acually be three frames of animation each that are 50x50 pixels.

What I want to do is copy a 50x50 part of that image and place it on the screen. So I can then have one image which contains several frames of animation.

If someone could just give me a piece of sample code just to do this, a couple of lines will do.

Thanks, Matt.

I can't see why you wouldn't put them in three separate files? Clipping the image will require extra processing power. But if you're determined, check out the canvas class's drawBitmap(Bitmap bitmap, Rect src, RectF dst, Paint paint).

You can also check out AnimationDrawable, which does frame-by-frame animations that are set up with xml.

Che

ErnestoGuevara wrote:I can't see why you wouldn't put them in three separate files?

It's common practice for animated sprites!

ErnestoGuevara wrote:Clipping the image will require extra processing power. But if you're determined, check out the canvas class's drawBitmap(Bitmap bitmap, Rect src, RectF dst, Paint paint).

For doing the animation within one sprite you should use the src Rect to define each frame: first frame would be ((0,0),(50,0),(50,50),(0,50)), second frame would be ((50,0),(100,0),(100,50),(50,50)) and so on. I don't think defining a source rectangle is a lot slower than having 3 different files for each animation. As when you draw an image, it probably automatically assumes a Rect which contains the whole image, so defining a smaller Rect won't generate extra overhead, except of the passing of 2 Rect parameters, which won't be that much of a time hog.

ErnestoGuevara wrote:You can also check out AnimationDrawable, which does frame-by-frame animations that are set up with xml.

True, but I don't think AnimationDrawable is very well suited for custom, 2D gaming, animation. I think it will use too much resources for that and will be too resticted. Thoug if you want to use some animated image in you normal layout (not a custom 2D game or something like that), then AnimationDrawable is the way to go.

Danuubz wrote:How do you exit the application?

It sounds like you press 'HOME' button or maybe 'Back'. I would use System.exit(0) for this.

Should override this function:

@Override
public void onDestroy()
{
super.onDestroy();
}

Hi Guys

I'm busy learning Android at the minute, and this Game Template's been great for helping me along the way!

I got one thing that's confusing me, though- when I run the code in the emulator, I'd expect to be able to update the position of the snowflake sprite by pressing the keys on the device, since the updateGame() method listens for key presses and updates the x and y values.

But, it doesn't seem to work, unless (in run) I call it again AFTER the doDraw method call, like this:

@Override
public void run() {
while (mRun) {
Canvas c = null;
try {
c = mSurfaceHolder.lockCanvas(null);
synchronized (mSurfaceHolder) {
if (mMode == STATE_RUNNING)
updateGame();
doDraw(c);
//second method call added here
updateGame();
}
} finally {
// do this in a finally so that if an exception is thrown
// during the above, we don't leave the Surface in an
// inconsistent state
if (c != null) {
mSurfaceHolder.unlockCanvasAndPost(c);
}
}
}
}


If I comment out the initial call, so that I'm just calling doDraw() followed by updateGame() it doesn't work either.

It seems weird that I need to call the same method twice to get it to work, so I'm sure I'm missing something, or not understanding something.

If anyone has any ideas or tips I'd love to hear from them!

Cheers and thanks in advance,

Adam

When I wrote it, it worked in the emulator, as I don't have a device. Notice though, some of the flakes only move when you keep pressing and releasing the keys, instead of keeping the key down.

Is this template meant to work without modifications, because I keep trying to get it to work initially and I have a startup force close problem on my emulator and on a device. I've tried messing around with it to try to get it to work, but I've been unsuccessful. I was thinking it may be the change in SDK's, but otherwise I was wondering if this was working for everyone else at the moment.

I'll take a look at it later today!

Thanks, that would be great.

Sorry, I won't make it today, I'll try tomorrow morning. I have a lot of work at the moment... sorry.