[CF-Devel] sdl client

[Michael Toennies]

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.

Let me explain why (i try to make it simple, so i explain some thing very
general):

The problem is, that sdl like directx is a kind of "driver layer".
They use direct the hardware driver of soundcards & gfx cards, which gives
maximum speed
access to the hardware.
Perhaps you read about "directx 8 hardware cards". On this cards, some
driver
calls are in the card bios (or other direct access), so you call direct the
hardware
without any driver and the hardware works like dirextx (and some other libs)
expect it.

In directx, you have about 20-30 options you can mix... mess one up, which
use then software
emulation instead of hardware and you mess your frames.

On sdl, the point is easier. There are only 3-5 options.

In fact, when you run full screen, you run the "use hardware" option. Then
it should be faster.
In windowed mode, they use only a few hardware systems inside, but he main
lib runs with
software emulation (reason is the OS concept of linux & windows and much
cards don't render
in windowed mode with all options).

A "surface" under sdl is a memory area which can hold gfx data. Your main
screen is a surface,
every loaded png is a surface, etc. Surfaces itself can be specialized type
like texture, buffer,
etc.

So, if you have a program which runs a sdl part and which runs smooth with
it, it will work with
pure sdl too - and faster.

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.

There is also OpenGL. You use OpenGL drivers on your system, using them as
blitter functions.
Its not included in sdl client yet, but it is easy and you has then direct
hardware access.
So, every system you can run a opengl game fast, you can run then the sdl
client fast too.

Remote display can be a problem - i had no idea how this is included for
OpenGL or so in linux
systems. Remember you has NOT a direct pixel access in SDL - all is doing
the drivers, even if you think
you call it direct. So you need a remote opengl driver or something, then
all is fine.

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.

The main difference is, that the linux clients are "window" games - using
window widget tools sets.
The SDL client is a native game enviroment - in fact, its same inside like
every game you can buy
in a store.

This invoke a great change in "look & feel" and how you "use" your program.
On the other side is this, how CF goes - more and more "real" game - like
the client/server cut
in the past.

All what i can say its, that CF is a game and using a "real game" interface
will invoke some great
options in the way you "look & feel" the world of CF.

One point is the sound - if you ever had played CF with sound (dx and sdl
client booth can it,
even in sdl i had not put in all sounds yet - some ambient/character sounds
are not included),
you will not go back.

Its very courious, like it change the game. Some maps will give you a
different game feeling
simply why they now gives you sound. Like crackling electricity sounds where
generators are and
some others.


Michael

>
     
       SDL was much slower on my system (dual p3-500).  For a 15x15 map, it took
     
     >
     
      around 100 ms (going higher if per pixel lighting is used and
     
     >
     
      going to a map
     
     >
     
      with such lighting).  In most cases, the gtk drawing routine was
     
     >
     
      less than 10
     
     >
     
      ms.  Being the gtk also uses x pixmaps, this performance is
     
     >
     
      probably pretty good
     
     >
     
      a remote display (ie, xterm), compared to the sdl drawing mode.
     
     >
     
      This is just to
     
     >
     
      put some more concrete numbers as one of the previous messages did mention
     
     >
     
      drawing speeds.
     
     >
     
     
     >
     
       Note that this does not really say anything about the SDL client
     
     >
     
      - it may draw
     
     >
     
      faster - I haven't tried it.
     
     >
     
      _______________________________________________
     
     >
     
      crossfire-devel mailing list
     
     >
     
     
      crossfire-devel at lists.real-time.com
      
      
     >
     
     
      https://mailman.real-time.com/mailman/listinfo/crossfire-devel