This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bugs in SDL interface


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]