Re: Bugs in SDL interface

[Hans Ronne <hronne at comhem dot se>]

>I noticed that the SDL interface doesn't hammer my CPU like the TclTk
>interface does (and I now have a 2.167GHz CPU; not many things could
>really hammer it), so I thought I'd give it a try.

Right. Though I share your (and Elijah's) enthusiasm for SDL interface, I
have to point out one thing in all honesty: the speed increase that you now
perceive is mostly illusion. By this I mean that most of the CPU cycles in
the Mac and tcltk versions of Xconq are spent in the hit-unit animations.
Each blast has to be shown for at least a fraction of a second, and if
there are many units and many blasts this soon becomes the most
CPU-consuming part of Xconq.

This is something we have discussed before, but perhaps it is worth
repeating. I did some profiling which I posted to this list, and up to 90%
of the CPU time was spent in the hit-unit animations. This was some time
ago, so the numbers may have changed, but they are still a huge CPU drag.
You can see this for yourself if you start a game with see-all off, several
sides and a big map. You will find that if you position the window in a
part of the map that you cannot see, and where no hit-unit animations
therefore are played, the game picks up a lot of speed. The same is true
for sides in the game that are not shown on the map - they finish their
turn much more quickly than those who are not (in sequential games).

So the fact that this essential feature is still lacking in the SDL
interface is important. With hit-unit animations it would become much
slower.

>The following bugs are *not* UI features that have not yet been
>implemented; just features that do exist but don't behave properly:

Thanks. I have tried to update the SDL interface with all new common
interface features, such as the new unit view code. Little has been done,
however, about existing bugs, not to mention unimplemented features. So
your list will be useful once we get that far.

>The following are deficiencies in the interface that may or may not have
>been considered yet (and in either case, I consider them to be pretty
>big deficiencies):
>
>6. There needs to be an easy way to tell which units have remaining
>ACP's and are not in Reserve or Asleep *without* clicking on them,
>unless the unit focus will automatically switch to the next such unit
>when the currently-selected unit cannot perform additional actions this
>turn.  Otherwise, making sure that all units have acted in a given turn
>is a real pain.

Or to put it differently, working current units/selected units, as in the
other interfaces.

>8. There should be some kind of feedback for combat situations.  Not
>necessarily explosions (although that might be useful, if done
>correctly), but some way to tell what happened without having to run
>Xconq from an XTerm and flip between the two windows up to 20 times per
>minute.  The best way I can think of to do this is by using a status bar
>for messages such as "Your * can never do this!", and a collapsible log
>panel for messages such as "You completed your *".

There are actually two types of essential feedbacks that are missing. One
is the hit-unit animations. The other is a notices pane for the standard
messages, so that you don't have to switch to the terminal.

These are indeed the most obvious missing features. To that I would add
setup dialogs and network code. Other things, such as a help window/pane
would also be nice, but are not essential.

Hans