Update Handlers - Using their Power!

  ... tutorials on how to use AndEngine.

Update Handlers - Using their Power!

Postby Mimminito » Mon Aug 30, 2010 11:31 am

Hey guys. After looking at a post on the forum, it inspired me to quickly create this tutorial on Update Handlers.

So, what is an Update Handler? It is something which you can create, and register within your Engine or Scene so that it is run on every update that AndEngine does! These can be quite powerful, allowing you to run certain tasks every update without having to override the onManagedUpdate() function within a custom class.

So, how do we create these Update Handlers? Check out the code below:

Syntax: [ Download ] [ Hide ]
Using java Syntax Highlighting
  1. this.scene.registerUpdateHandler(new IUpdateHandler() {
  2. @Override
  3. public void onUpdate(float pSecondsElapsed) {
  4.         // TODO Auto-generated method stub
  5.         //Your code to run here!
  6. }
Parsed in 0.030 seconds, using GeSHi 1.0.8.4


So, as you can see you can create and register a new Update Handler within your Scene very easily, only using a few lines of code. Within the onUpdate() method, you will place your code that you want to run on every update.

There are endless uses for this sort of functionality. You can really start to customize your applications and games here!

Well, that's the end of this short tutorial. I hope it helps some people out.
---------------------------------------
Adam Goodchild
Your AndEngine Forum Moderator!
My Tutorials List
http://www.adam-goodchild.co.uk
---------------------------------------
Mimminito
 
Posts: 360
Joined: Wed Jul 21, 2010 3:08 pm
Location: Chelsmford, UK

Re: Update Handlers - Using their Power!

Postby Wiese82 » Mon Aug 30, 2010 2:33 pm

Hi!

I agree that UpdateHandlers can be quite powerful, but it is more intelligent to use them as few as possible,as much as is necessary!

The problem is that the code will run EVERY f***ing frame. Also when there is no need to run your code. This can(!) make your game very slow.

In my opinion Listeners are the smarter tool, to make a performant game. I think that is the reason why Nicolas uses many listeners and no ("classic") main loop in AndEngine.

By the way, I am using also an UpdateHandler in my actual AndEngine project :-).

Greets,
Wiese82
Last edited by Wiese82 on Mon Aug 30, 2010 2:39 pm, edited 2 times in total.
Download my new game: Safari! / Safari! HD
Wiese82
 
Posts: 45
Joined: Sun Jul 18, 2010 7:00 pm
Location: Germany

Re: Update Handlers - Using their Power!

Postby Mimminito » Mon Aug 30, 2010 2:35 pm

Yeah thats a very good point, and should be taken into consideration when using them. I shall update the tutorial with that information later.
---------------------------------------
Adam Goodchild
Your AndEngine Forum Moderator!
My Tutorials List
http://www.adam-goodchild.co.uk
---------------------------------------
Mimminito
 
Posts: 360
Joined: Wed Jul 21, 2010 3:08 pm
Location: Chelsmford, UK

Re: Update Handlers - Using their Power!

Postby darklord » Mon Sep 06, 2010 1:16 pm

Also, important to note, is that it is very much recommended to UNREGISTER the handler when you're done with it. Wiese82 stated why.
darklord
 
Posts: 121
Joined: Thu Aug 12, 2010 2:48 pm

Re: Update Handlers - Using their Power!

Postby k3vlar » Sun Sep 12, 2010 12:23 am

Hi,
I see this thread is quite old but I have a question. I've just started using andengine and going through these tutorials to see how I can retro fit it onto a game I've already started. The game has a main update loop and an object graph. On each update loop the object graph is updated.

Wiese82
The problem is that the code will run EVERY f***ing frame. Also when there is no need to run your code. This can(!) make your game very slow.

I would have thought a main update loop is a fairly standard way of doing things. Wiese82 seems concerned this update handler will run on every frame, but surely this is how standard game loops execute. Each frame game objects are updated based on the time passed so that there positioning, animations, sound events etc can be updated based on the game state and the time passed since the last frame.

What I'm wondering is will I see bad results if I slot my main game loop into an update handler? Is it not designed to handle this kind of architecture? Or will I have to re-architect my engine to use listeners in the way that Nicolas has designed andengine games to be?

Thanks in advance for any advice
k3vlar
 
Posts: 10
Joined: Sun Sep 12, 2010 12:10 am

Re: Update Handlers - Using their Power!

Postby mr_deimos » Sun Sep 12, 2010 1:23 am

Well, main loop might be a good idea when you actually want to do all animations, object positioning and other things all by yourself, and stashing your main loop code in an update handler should work as long as you don't do some really complex and time-consuming operations there. But why do that if the engine can handle most of the stuff for you?
For example, you can have a main loop and check if the screen has been touched, and if the touched came in a valid area. If so you set a correct flag and start animating some sprites moving them from frame to frame and keep checking each frame how far you still have to move them, and update the objects graph when animation is finished.
On the other hand you can just set attach a onTouch listener to some sprite and have its callback fire precisely when it is needed - when the screen has been touched in a certain place. You'll not only know that a screen touch occurred but you'll also know if it actually hit the sprite as the callback won't fire otherwise. No need to check it yourself. When you need to take some action based on received touch, for example move some sprites around you just attach a shape modifier to them and andengine moves them where they need to go, it even can do cool stuff like accelerating, decelerating, bouncing and others (ease functions). Again, no need to do anything but passing movement parameters to the engine. Instead of updating the object graph every frame you can add listeners to shape modifiers so that their callback will be launched whenever the movement is finished and update the graph then.
I guess you should get the idea by now so i won't go on ;)
For me using listeners and scrapping the main loop took some time to get used to, as i usually coded in C and assembler so far and relied on such loops heavily. Also you have to put some thought into it and take into account that unlike the main loop the callbacks work asynchronously and one callback can be launched while you're handling other, potentially leading to a game-crashing situation. But you can always have some flags indicating what is happening and either service or ignore launched callbacks based on them - for example in a puzzle game you wouldn't want to start a new sprite move before the previous one has finished so you'd have to ignore or buffer incoming screen tap for later use.

But in the end, after getting used to, building your game on listeners and callbacks really makes your life easier and your code more efficient, simpler and it's totally worth the effort even if you need to redesign the game.
mr_deimos
 
Posts: 42
Joined: Wed Sep 08, 2010 11:03 pm

Re: Update Handlers - Using their Power!

Postby k3vlar » Sun Sep 12, 2010 12:44 pm

Thanks for the reply mr_deimos.

I see what you mean; as long as I don't have anything too complex in that main loop it should be okay, and in my case the thing going in there will be my highly optimised ( ;) ) main game loop so it shouldn't be a problem.

I can see how the listener approach has its advantages in the architecture ... I was about to say that there wouldn't be an advantage in operations, but I see now that the advantage is in there not being any checks for touch events when the user is not touching the screen (which is what you have to do in a traditional update loop - check on every single frame).

The fact that the listeners get called asynchronously makes me feel a little nauseous. That's one advantage of an update loop - for each run of the frame you know exactly the state of everything in this frame and are essentially dealing in an encapsulated unit of state. The idea that something can just jump in there and update something (possibly halfway through another gamestate-modifying operation) could certainly lead to some undesirable states. I would be interested to hear a little more about the caveats that these asynchronous calls can cause.

I will probably try and integrate my main game loop into an update handler as my first stage of integration and then go from there. I'm pretty far into the implementation of my engine so hacking apart all the architecture of my update loop will be pretty painful, but over time I may get over this and go for listeners!
k3vlar
 
Posts: 10
Joined: Sun Sep 12, 2010 12:10 am

Re: Update Handlers - Using their Power!

Postby Tom@Jerry » Fri Oct 01, 2010 9:25 am

thanks for the information guys.

this will help me a lots.
Tom@Jerry
 
Posts: 1
Joined: Fri Oct 01, 2010 9:20 am

Re: Update Handlers - Using their Power!

Postby VBCoder68 » Sun Oct 17, 2010 9:32 pm

I have a question. I'm new to AndEngine and I'm working on a side scrolling shooter. What would be the best method for updating missile sprites? Should I use update handlers? What about detecting collisions?

Thanks,

Mike
VBCoder68
 
Posts: 9
Joined: Sun Oct 17, 2010 9:27 pm

Re: Update Handlers - Using their Power!

Postby anindo » Fri Feb 04, 2011 4:25 pm

I am trying to rethink my code to follow the "Listener" approach, instead of loops and update handlers... and I need some help:

Is there a way to fire a listener on a sprite when an associated ShapeModifier, e.g. a RotationModifier, finishes? Maybe not for a LoopModifier, though that might be useful too, in some situations.

Related question: Is there a way to make a ShapeModifier get disposed for GC (better yet, the owning sprite AND all its ShapeModifiers in one go) at the end of the modifier's duration?


Thanks!
anindo
 
Posts: 3
Joined: Tue Jan 25, 2011 10:07 am

Next

Return to Tutorials

Who is online

Users browsing this forum: Google Feedfetcher, RonScript and 21 guests