[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



On, Wed May 24, 2006, DR0ID wrote:

> Hello
> 
> 
> I asked in the past about what animation kind you use: event, time or 
> frame based. But the more important question is how are the objects 
> updated? One thing is shure, every object has to be updated once a 
> frame, or even not?

No it must not. Dependant on the application/game you create, you might
need to update only the changed objects and areas instead of
redrawing/updating all objects each frame.

Most arcade games with a lot of floating objects and a moving background
for example will usually update all objects each frame, while a static
interface, in which only a few objects change their appearance might be
better with updating only their areas.
 
> First one need to know what has to be done in the main loop:
> 
> 1. eventhandling
> 2. updating 
> 3. drawing

Updating and drawing is optional in a main loop, if you work with an
event based approach. Updates then will be only necessary, if a certain
event occurs. And no, timer-based events are not a good thing for that :-).

> I hope I did not forget something important or doing something wrong. 
> Perhaps the order can change. So basically it goes two times trough the 
> objects list: once for the update and once for the drawing (more or less).

This depends on your object implementation scenario. Personally I
prefer, that my objects update themselves (their surfaces) as soon as
they are changed and will be blit on the screen instantly (or at least
blit within the next frame).
This however might not be the best approach for any type of application
or game, especially not for those, which have to do a lot of updates as
the example above.

[...] 
> 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).

Consuming a timer-based event and reacting upon it (with a fixed time to
be elapsed each occurance) is pretty bad in my opinion. It is just a
more complex (and time consuming) approach for what you can achieve with
the different pygame.time.* methods more easiliy.

> 
> What avantages or disadvantages has each of these approaches?


> I think the eventbased approach is more flexible so any kind of events 
> can be passed around. So my next question will be how to build a event 
> dipatching mechanisme, but I will ask this in a further email.

If you use timer-based events, which occur each X ms (X being a
constant), I would say, that you made some typical 'broken-by-design'
mistake. You then should use the pygame.time.*() methods instead to
synchronize the updates and operations.
If you use a fully event-driven system, which usually only should update
objects, if they changed, get rid of those timer-based events and raise
a special 'update' event as necessary.

Regards
Marcus

Attachment: pgpAQW1wvIh4c.pgp
Description: PGP signature