[Freeciv-Dev] Re: New Isometric drawing algorythm

[Jason Short <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

On Wed, 2002-12-18 at 17:33, Daniel L Speyer wrote:
> Hello all,
> 
> I've been following the discussion about isometric drawing speed, and I
> think I've come up with a serious improvement.  Basically, I observed that
> the posted profiling information about masks suggests that it requires
> roughly an equal amount of time to draw a transparent or opaque
> pixel.  Therefore, the most efficient algorythm would draw each pixel on
> the screen exactly once (opaquely).  The present algorythm comes nowhere
> close: to draw a 64x32 *diamond* (1024 pixels) it first draws a 64x32
> rectangle (2048 pixels) then draws another (still 2048 pixels) for a
> special and another for anything else it may have ad nauseum.
> 
> What I've done is to draw the base terrain in 32x16 rectangles for each
> edge, and then make all overlays as small as possible.  The advantages of
> this (apart from speed) include:
>   * hand-drawn boundaries
>   * a sane number of sprites
>   * ability to share units with overhead
>   * smarter eyecandy
> disadvantages include:
>   * hard to add a terrain type
>   * more gui-dependant code (this can probably be improved)  
> 
> My measuring techniques are very crude, but I think this is a significant
> improvement over the old way.  I'd appreciate real profiling data.

Try the attached patch (it may not apply cleanly, but it's easy to
insert to code manually) both with and without your changes.  Try
enabling/disabling certain view options to see what changes.  Try it
with different mapcanvas appearances (no roads/rails, lots of
roads/rails, etc).

> Patch is attatched, corresponding tileset is
> http://dspeyer.student.umd.edu/isotrident_newalgor.tgz
> Screenshot is http://dspeyer.student.umd.edu/new_algor.jpg
> 
> Comments, suggestions and measurements are appreciated.

A change like this is a good idea, but doing it cleanly (without lots of
GUI additions) is a ways off.  In the meantime if you can provide atomic
patches to move toward the goal, that is preferred.

The patch doesn't apply cleanly anymore.  And this will continue to
happen as we move toward the target (my target is a situation where this
change will not require ANY GUI changes).  Be careful that you don't do
a lot of work making excessive changes, only to lose interest later as
the changes are slowly merged into CVS.

-----

Now, for the immediate situation:

On a quick scan of the code, it looks like you "center" the graphics if
they are small.  This isn't perfect.

It is better for the tilespec code to tell the drawing code where to
draw the sprite.  This can be done by providing an offset (0,0) for base
terrain, positive for small tiles, negative for large tiles (including
units and civ3-style hills/mountains).  (As a side benefit, this allows
the special-case for coasts to be removed.)

Better still would be a situation where the client core code calls
functions like mapview_put_sprite(), and all of the logic resides in the
core code.  But this is even further off.

jason