Re: [pygame] update() or tick()

[DR0ID <dr0id@xxxxxxxxxx>]

Tom Wardill schrieb:
> DR0ID wrote:
> > In many examples and tutorials of pygame a update() method is used. 
> > This means that in the main loop in one place one has to go through 
> > the objects list and call the update() method. This is done every 
> > frame of the game.
> This is the 'normal' method of dealing with animation, with the 
> addition of a timer to ensure smooth movement across the screen. 
> Relatively easy to program, develop and work with.
> > A similar but eventbased approach is using a special event, lets call 
> > it E_tick(). But then a event dispatching mechanisme is needed and 
> > for updating the objects a special event E_tick() would be used to 
> > update the objects. E_tick() has the actual time or the time elapsed 
> > in the last frame, so the object can update accordingly (I think the 
> > elapsed time is more usefull as the absolute time but perhaps one 
> > should pass both so the object can use what it need).
> This works in places but I can see two main flaws in it (off the top 
> of my head, I've never worked this way before). The first is that the 
> overhead is going to be relatively large in dealing with the events, 
> so it may be slower than the other method (no numbers on this, as I 
> said, not done this). The other is that if you use an event to cause 
> something to happen, you have to wait for an event for it to happen, 
> if this makes sense. Your program will not run until an event is 
> triggered.
> You could cause a trigger based on the time or something equivalent, 
> but then you've just recreated the above method.
> It will also be more work to implement.
>
> Hope this helps, if I've misunderstood the problem, I apologise, post 
> again and I'll see if I can help.
> --
> TomW
Hi

You didnt misunderstand the problem. Your right, with timer triggerd 
events it becomes the same as the update() approach. Only one thing: 
with the update() approach it is more or less synchronous and with the 
events aproach its more asynchronous. Many games are eventdriven, so 
only something happens if an event is posted (it a sort of action and 
reaction, or not?).

The overhad to implement such a system: I dont know how big it is and 
how much it would slow things down. But I think it will not be much 
slower as the update() aproach, because things are only done if an event 
was posted. And its perhaps a bit more complicated to implement, thats 
right, but Im not sure if it is more flexible or not. An obejct first 
has to register to get the events it wants. Once done that it only 
becomes the events it can handle. And now you can implement in the 
eventhandling method what the object has to do and how to react. But I'm 
a little affraid of the number of event it could exist in a single program.

If you want to add a new, lets say,  control the only thing it has to do 
is post events. Or network connection. Or any other object that triggers 
an event.

I also have never implement such a system so I also only can guess how 
it will be.

Perhaps a mixture of both aproaches could be used?

~DR0ID