[Freeciv-Dev] Re: (PR#2941) RFC: canvas_put_sprite

["Vasco Alexandre Da Silva Costa via RT" <rt@xxxxxxxxxxxxxx>]

On Sat, 1 Feb 2003, esr@xxxxxxxxxxx via RT wrote:
> Jason Short via RT <rt@xxxxxxxxxxxxxx>:

> Let's step back a moment and look at the systems engineering.
>
> Freeciv is not a real-time game, updates are relatively sparse in both
> time and space.  Latency due to network turnaround will often dominate
> draw time by an order of magnitude.  We have the luxury of engineering
> for long-term maintainability rather than having to scqueeze every
> cycle out of the hardware; I say we should use that.

Actually you are wrong. Freeciv is a twitch game. Try playing a
multiplayer game on Pubserver and you will see what I mean when you get
to combat.
Players do not play in order; all players execute their turns at the same
time and player actions are reflected immediatly.

Also we have several problems due to the client not responding fast enough
to AI events. The AI can severely flood any client, especially when running
in localhost. The AI sends for e.g. unit move requests at such a rate that
the client cannot process them before filling up the network buffer under
certain conditions. I had to tweak the network map, city update, unit
sends by inserting wait states so they wouldn't flood users as much.

There are limits to reason of course. But do not think graphics
performance is irrelevant. Try scrolling the map and see how long that
takes. It should be real-time like scrolling a web browser page but it is
not by far.

> Under these conditions, unifying the drawing code down as far as
> BitBlt level would make sense (no that anyone's proposing going that
> far).  The fancy optimizations you can get with toolkits like SDL
> simply won't gain us any performance in real-world cases, so there is
> no loss in keeping the code simple and well-factored.
>
> I didn't have an opinion about this three days ago, but I've read all the
> client code since in order to do the mods I needed to crop_sprite().  I
> don't know what other people are thinking, but I sense a natural
> plane of cleavage at about the level of pixmap_put_overlay_tile() in
> the gdk client.
>
> In this model, the basic primitive of the gui-independent code would
> look like "draw this stack of sprites at (x, y)".  The client's job would
> basically be to translate that into BitBlts with clipping.

---
Vasco Alexandre da Silva Costa @ Instituto Superior Tecnico, Lisboa