[Freeciv-Dev] (PR#11433) Fog of War rendering improvement

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

<URL: http://bugs.freeciv.org/Ticket/Display.html?id=11433 >

> [andrearo - Thu Dec 09 16:21:58 2004]:
> 
> Following the discussion on how to do fog of war with alpha blending, I
> did a little test to implement an improvement to the fog of war rendering.
> 
> It doesn't use alpha-blending, since you would need to use pixbufs.
> Instead the brightness of every pixel is reduced by 50%, by iterating over
> each pixel in the pixmap.
> 
> There is little or no performance hit that I can notice, but it would be a
> good idea to do some benchmarking. Is is possible to get a frames/s
> output?
> 
> Patch against CVS head, for the Gtk 2.x client.
> 
> Screenshot: http://www.stud.ntnu.no/~andrearo/scr.png

This does make things a *lot* prettier, but it also makes them a *lot*
slower.  It really cannot be stressed enough how much prettier and
slower it is.

Without the patch I get 15-30 FPS.  With it I get 2-10 FPS.  This is on
a random late-game savegame I happen to have lying about.

However this problem is solvable.  But there are so many ways we could
solve it it is difficult to choose one.

--- 1 --- The easy way ---

For each sprite we have a mask and a pixmap.  We could create a second
pixmap, which is the same sprite fogged.  This can be created on demand
but it need only be created once per sprite.  After that drawing is fast.

The only drawback is it'll take almost twice as much memory.  This may
not be a huge problem now, but once we have animation graphics it will
be (the animation sprites for warriors took 30 Mb of memory...already
unacceptably much; we need this to be less not more...but then maybe
animations will never be fogged, I dunno).  So I guess I'm not sure if
this drawback is a fatal problem or not.

I can say that this is the only solution that's workable for 2.0 - and
if it were a client option then people could have their choice.

Note also that you'll have to hack some stuff to get this to work with
non-isometric tilesets - which you should do.  Non-iso tilesets don't
currently use canvas_put_sprite_fogged; instead they use a fog graphic
in the tileset and draw that on top of everything else.  This would be
ideal if that fog graphic could use alpha, but since it can't it really
doesn't help.  The solution is to just disable this option and use the
same method as is used by iso-view.  If this same client option is
enabled, skip drawing the fog sprite and instead use
canvas_put_sprite_fogged for fog sprites.

--- 2 --- The right way

First of all, I think civ2-style fog must go.  It makes alpha-blending
for fog much slower (since it must be done many times per tile) unless
you use the above method that takes lots of memory.  In civ3 the fog
graphics in the tileset used a grayscale gradient that the game would
interpret at runtime (I assume) into a sprite with alpha level.

Note we don't have to use pixbufs to draw all graphics (although that
would be nice since alpha-layers for all graphics would be nice).  We
just need a special case to use pixbufs for fog.  Oh, and it has to be
able to work in other clients too.  So we use tileset graphics similar
to what civ3 has, and have the GUI clients render these into alpha
sprites at runtime.  We might want to introduce a new type struct
alpha_sprite.  Then we just draw this fog on top to fog areas.  Doing it
the way civ3 does it (with, IIRC, 16 different fog sprites to give a
smooth gradient everywhere) will take even more work.  It's all possible
though and shouldn't be too much slower.  Old tilesets that don't
support alpha levels will have to return stippled sprites that can still
just be drawn on top to get alpha fog.

Note this way will be slower than the current system because you
actually do use alpha levels at draw time.  So maybe "the easy way" is
the only reasonable way to do it for the moment.  Without doing work to
implement it, it is hard to say.

--- 3 --- Making all this easier

Currently fog drawing algorithms are hard-coded based on is_isometric. 
Instead we should have a variety of different algorithms, and let the
tileset choose which it wants.  This is actually not that hard and will
make later changes easier.

-jason