[CF-Devel] sdl client

[Mark Wedel]

Michael Toennies wrote:
>
     
     
     >
     
      The point of performance is not as easy as many of you perhaps think -
     
     >
     
      what not a wonder is because it is hard to determinate.
     
     >
     
      Even people with some experience (and i had experience since dx 2 with it)
     
     >
     
      need some tries to get the right setup of software & hardware use.
     
     >
     
      In first times, i can't boost the frames of the sdl client >15 frames on my
     
     >
     
      system (p3 500/ voodoo 3000).
     
     >
     
     
     >
     
      Now, it runs with >75 frames in windowed mode and >90 frames in full screen
     
     >
     
      mode.
     
     >
     
     
     >
     
      The right setup is the key. Mess only one thing up, and you have 9 frames
     
     >
     
      instead of 90.
     
     >
     
      Thats also true on 100% high performance win32 game computers.
     
     
 I guess one of the big things here would then be to make it easy for users to
get this setup done right.

 Being able to get really good performance doesn't do much good if most people
don't know how to do it or it is otherwise complicated/not possible for them to
do.

>
     
     
     >
     
      If you setup the sdl client for maximum hardware use and run it then on a
     
     >
     
      linux system, it will be slow.
     
     >
     
      So, we need a setup part, where you can tweak it - even better a test part,
     
     >
     
      where you can see the performance of your system to the different options.
     
     
 Note that best of my knowledge, SDL high performance has only really been
worked on with linux and local displays.  This does not help the people on unix
varieties other than linux, or people who are doing remote displays.

>
     
      Iam not sure about the x pixmaps. Remember that crossfire.png has 2 mb and
     
     >
     
      the
     
     >
     
      crossfire.xbm has 3.5 mb. The XBMs are significant bigger then the pngs.
     
     >
     
      But iam not sure how this has a effect on things like remote displaying.
     
     
 Those data sizes are not meaningfull - that just reflects the size of the data
format itself, and not what X does with them.  Whatever the source form (.png,
.xpm, .xbm), X will basically convert it into the same internal format.

 What X does when you create an X pixmap (not related to xpm) is it takes the
data and creates a private data structure within the X-server (in comparision,
sdl surfaces remain available to the client).  In the creation of hte X pixmap,
the data bits need to get sent to the server, and you get returned a unique
identifier.  After that, the protocol between the client and X server is
basically 'draw image 543 and 32,32'.  Very fast - few bytes, and the X-server
was free to create the image in the most efficient form for blitting to the
screen.

 If you are using SDL with direct video access, performance is also good.  But
if you are using it remotely or on a system with direction video access is not
available, what is basically happening is you are manipulating the bits throught
SDL, and when you say blit it to the screen, SDL is converting the data at that
point into an X pixmap.  It is this creation time that is slow, and over a
remote link, probably not bearable.

 While I don't disagree that having a complete game environment can add many
things, many people may be playing in a circumstance where they really don't
want that (ie, killing some time while a compile goes on, yet they still want to
be able to monitor it).  The fact is that in crossfire, there are a lot of lulls
in the action where you can be doing something else outside the game environment
for a few minutes while you regain sp, or just between the action)

 What is hard to know is what people really want.  We can hypothesize all we
want, but if a sizable portion of people want Q, we should provide them with Q,
whatever it may be (and provided it is feasible of course).