Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2003:
[Freeciv-Dev] (PR#4073) Flow of graphics
Home

[Freeciv-Dev] (PR#4073) Flow of graphics

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients:;
Subject: [Freeciv-Dev] (PR#4073) Flow of graphics
From: "a-l@xxxxxxx" <a-l@xxxxxxx>
Date: Thu, 24 Apr 2003 11:59:22 -0700
Reply-to: rt@xxxxxxxxxxxxxx

I suggest removing all calls to flush_dirty() and simply setting it
up as a timer of 30 milliseconds. Currently, at times when stuff
happens, the client attempts to update the screen at a roaring rate
of more than 500 frames pr second, in short bursts. That's just what
happens when you write a game without relating to the fps concept at
all "because it isn't Quake". This abuse is particularly notable when
watching an autogame. Although this situation may not be the best
target for optimization, it's still reasonable to look precisely at
the times when Stuff Happens, as that's when the bugs creep out and
disconnects may occur.

- When you need a screen update, you never need it so badly that you
  can't wait another 30 ms. The human eye will be happy still.

- If the code makes more changes during that time, you just get a
  bonus optimization, saving superfluous screen drawing.

- Sure gdk drops events every now and then, but it's hardly noticable.

I didn't count the times flush_dirty() was called and 
num_dirty_rects == 0. Counting that just adds some unneccessary
function calls to the pot.

This suggestion can also make animation work in a natural way.
You could have a separate animation timer of 200 ms which does nothing
but adjusting sprite pointers. If gdk drops the flush timer because of
heavy load, some animation frames will simply be skipped gracefully.
This gives really nice animation too, except that I can't draw
something nice.


Arnstein



[Prev in Thread] Current Thread [Next in Thread]
  • [Freeciv-Dev] (PR#4073) Flow of graphics, a-l@xxxxxxx <=