Bugs in SDL interface

Bugs in SDL interface

[Lincoln Peters]

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.


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

1. In the SDL interface, if I press 's' to put a unit to sleep, the unit
seems to drop to 0 ACP's.  In the TclTk interface, it retains its ACP's
even though it doesn't act during that turn.  Sleeping units seem to
retain their ACP's as usual on subsequent turns in both interfaces.

2. Units that can be developed but have not yet been developed do not
appear in the list of units that can be built.  This makes it impossible
to develop those units.  (I think that a similar bug existed in the
TclTk interface in 7.4.1 but was fixed in CVS a long time ago.)

3. The information panel at the bottom of the screen is not updated
after a mouse click, although it updates properly as soon as I move the
mouse or some other action takes place.  Perhaps the information is
being refreshed *before* the task is executed?

4. When I change the zoom, the main panel shifts to display a different
part of the map.  And strangely enough, it seems to shift to the same
spot every time, although a different spot for each level of
magnification.  I think we all agree that it should remain centered on
the same point when the zoom changes.

5. In the Standard game, roads do not appear at maximum zoom.  They seem
to appear properly at all other zooms (except the lowest, where they'd
be an eyesore).  I haven't tried it with other games.


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.

7. There also needs to be an easy way to tell if a unit is under
construction; unlike the TclTk interface, there is no visual indicator
whatsoever to distinguish between complete and incomplete units. 
Perhaps alpha-blending and/or tinting would be useful (either an
incomplete unit is semi-transparent or is tinted a particular color,
maybe orange).

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 *".

---
Lincoln Peters
<sampln@sbcglobal.net>

Virtue is not left to stand alone.  He who practices it will have neighbors.
		-- Confucius

Re: Bugs in SDL interface

[Hans Ronne]

>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

Re: Bugs in SDL interface

[Lincoln Peters]

On Sun, 2004-08-22 at 02:37, Hans Ronne wrote:
> 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).

It *has* changed.  I find that, when I use the TclTk interface, my CPU
is hammered continuously.  Even when I'm just looking at the Startup
dialog, my CPU is so hammered that the mouse starts skipping!

(I don't think that the mouse thing is a memory issue because at the
same time I upgraded to a 2.167GHz CPU, I upgraded to 1GB of RAM.)

> 
> 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.

I imagine that you could work around this by one of the following
methods:

1. Use an "alarm clock" rather than a loop to create a delay for the
animations.  The game would still be slower, but it wouldn't hammer the
CPU while doing absolutely nothing.

2. Run the animations simultaneously.  This would be slower than having
no animations at all, but it would be faster than running the animations
sequentially.  You could use the "alarm clock" mechanism again here.


One thing that might be a nice addition later on is sound effects like
those in the Mac interface.  Or better yet, sound effects that can be
set up by the game designer and support full surround sound (if the
computer is set up for surround sound), so that if a nuclear bomb
detonates in the north-west corner of the screen, you hear an explosion
in front of you and to the left.

---
Lincoln Peters
<sampln@sbcglobal.net>

I hope you're not pretending to be evil while secretly being good.
That would be dishonest.

Re: Bugs in SDL interface

[Jim Kingdon]

> 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.

I can confirm the observation of Lincoln Peters that there is
something going on besides hit-unit animations.

I have an xconq which is just waiting for me to move.  It is taking
90%+ of the CPU.  I suppose this could be the "crawling ants"
animation for the current unit.  But there are probably less
CPU-intensive ways of doing animation.

Even stranger, xconq still uses that much CPU when I minimize the
window.

Re: Bugs in SDL interface

[Eric McDonald]

On Sat, 21 Aug 2004, Lincoln Peters wrote:

> 1. In the SDL interface, if I press 's' to put a unit to sleep, the unit
> seems to drop to 0 ACP's.  In the TclTk interface, it retains its ACP's
> even though it doesn't act during that turn.  Sleeping units seem to
> retain their ACP's as usual on subsequent turns in both interfaces.

I was unable to reproduce this one. I haven't looked at the other 
problems yet.

Eric

Re: Bugs in SDL interface

[Eric McDonald]

Lincoln Peters wrote:

> 2. Units that can be developed but have not yet been developed do not
> appear in the list of units that can be built.  This makes it impossible
> to develop those units.  (I think that a similar bug existed in the
> TclTk interface in 7.4.1 but was fixed in CVS a long time ago.)

I have now changed my sources so that the build buttons either say 
"Develop and then Build" or "Build" depending on which is the case. I 
tested with 'bolodd3.g', and everything seemed to work as expected.

> 3. The information panel at the bottom of the screen is not updated
> after a mouse click, although it updates properly as soon as I move the
> mouse or some other action takes place.  Perhaps the information is
> being refreshed *before* the task is executed?

As with item 1, I could not reproduce this.

> 4. When I change the zoom, the main panel shifts to display a different
> part of the map.  And strangely enough, it seems to shift to the same
> spot every time, although a different spot for each level of
> magnification.  I think we all agree that it should remain centered on
> the same point when the zoom changes.

I am looking into this and the other issues you raised, plus a few of my 
own.

Eric

Re: Bugs in SDL interface

[Eric McDonald]

Lincoln Peters wrote:

> 4. When I change the zoom, the main panel shifts to display a different
> part of the map.  And strangely enough, it seems to shift to the same
> spot every time, although a different spot for each level of
> magnification.  I think we all agree that it should remain centered on
> the same point when the zoom changes.

I have fixed this in my sources.

> 5. In the Standard game, roads do not appear at maximum zoom.  They seem
> to appear properly at all other zooms (except the lowest, where they'd
> be an eyesore).  I haven't tried it with other games.

I was able to reproduce this. I am not ready to fix it yet.

> 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.

This was a remarkably simple fix. One line, in fact. The SDL interface 
in my sources now automatically selects the next unit to act, just as in 
the Tcl/Tk interface.

> 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 *".

I think this feedback should go in a panel along the bottom of the 
screen. I have been somewhat tempted to move the panel with the unit 
info off to the right side of the screen to help square up the aspect 
ratio (as in TOAW), and make room for notices along the bottom. Still 
not sure yet, especially since it looks like a line or two could be 
squeezed out of the unit info panel on the bottom, and, depending on how 
text is rendered, there could be severe truncation of the unit info 
strings, if they were put on a narrower panel on the right side of the 
screen.

Eric