CPU getting hammered with xconq-7.5.0-0pre.0.20040519

CPU getting hammered with xconq-7.5.0-0pre.0.20040519

[Jon Leech]

    I've been trying out Eric's xconq-7.5.0-0pre.0.20040519 RPMs on
Mandrake 10 (after some install bobbles involving, we suspect, a subtly
broken or behavior-changed version of RPM that came with the distro -
BTW, if anyone else is seeing weird checksum errors from rpm version 4.2
on these RPMs, resigning the RPM with '--resign' seems to fix it).

    Initially xconq works well, although it seems in general somewhat
more sluggish than 7.4.1 running on Mandrake 9.2. After a few
minutes/turns of playing, however, the CPU usage on my machine starts
getting hammered (top shows xconq consuming 98% of the CPU), and the
game becomes effectively unplayable - response time on the order of half
a second for each hex movement. This is invoking the standard scenario
with a bunch of computer opponents e.g.

    xconq -L /usr/share/xconq -e 8,ai -M 78x76

    Saving the game and restarting improves matters briefly,
but quickly returns to sucking up all the CPU.

    I looked back a few weeks through the list archive subjects and
didn't see any similar reports - but I haven't examined all the message
bodies, so apologies if this has already been reported.


    An unrelated issue: it looks like at least some of the options in
the 'View' menu aren't being saved. For example, if I start up a game,
disable 'Unit names' and 'Feature names', enable 'Meridians', save, and
restart with the saved game, those options are restored to their
original state rather than the state I set.

    Jon

Re: CPU getting hammered with xconq-7.5.0-0pre.0.20040519

[Eric McDonald]

Hi Jon,

On Thu, 2004-05-20 at 21:48, Jon Leech wrote:
>     I've been trying out Eric's xconq-7.5.0-0pre.0.20040519 RPMs on
> Mandrake 10 (after some install bobbles involving, we suspect, a subtly
> broken or behavior-changed version of RPM that came with the distro -
> BTW, if anyone else is seeing weird checksum errors from rpm version 4.2
> on these RPMs, resigning the RPM with '--resign' seems to fix it).

Thanks for the reminder. I intended to put that tidbit on the Web site,
but didn't get around to it.

>     Initially xconq works well, although it seems in general somewhat
> more sluggish than 7.4.1 running on Mandrake 9.2. After a few
> minutes/turns of playing, however, the CPU usage on my machine starts
> getting hammered (top shows xconq consuming 98% of the CPU), and the
> game becomes effectively unplayable - response time on the order of half
> a second for each hex movement. This is invoking the standard scenario
> with a bunch of computer opponents e.g.
> 
>     xconq -L /usr/share/xconq -e 8,ai -M 78x76
> 
>     Saving the game and restarting improves matters briefly,
> but quickly returns to sucking up all the CPU.

I think Hans is probably more of an expert in this area than I am. I
have not yet gotten around to profiling Xconq and I think he has.

IIRC, the heavy CPU usage has been reported under Windows sometime in
the past 6 months or so.

>     An unrelated issue: it looks like at least some of the options in
> the 'View' menu aren't being saved. For example, if I start up a game,
> disable 'Unit names' and 'Feature names', enable 'Meridians', save, and
> restart with the saved game, those options are restored to their
> original state rather than the state I set.

I don't think that display settings get saved with individual games at
present; I would have to check the code to make certain.

If there are certain settings that you would like to see applied to all
games, then you can set them via the 'Preferences' dialog.

Eric

Re: CPU getting hammered with xconq-7.5.0-0pre.0.20040519

[Hans Ronne]

>    An unrelated issue: it looks like at least some of the options in
>the 'View' menu aren't being saved. For example, if I start up a game,
>disable 'Unit names' and 'Feature names', enable 'Meridians', save, and
>restart with the saved game, those options are restored to their
>original state rather than the state I set.

This is how it should be. The view preferences and individual map view
settings were previously dependent on each other in a rather complicated
way which caused some problems. However, I untangled them recently. Now, if
you want to change the preferences, you use the preference dialog, and if
you want to temporarily change the view settings for a specific map, you
use the view menu that belongs to that map. It is only the preference
settings that are saved.

Hans