[crossfire] Release of 1.11 in a week or two

[Mark Wedel]

Nicolas Weeger wrote:
>>   It shouldn't be.  It's possible that a few things or other changes were
>> outside of #ifdefs.  For both client & server, having curl shouldn't be a
>> requirement.
> 
> What's the point of metaserver2, then? :)
> I think curl is needed, so newer clients use newer servers.

  There is a difference of something being highly desirable and something being 
strictly required.

  I can think of some number of cases where people may not use the metaserver2 
for various reasons, and thus don't really want to bother downloading what may 
be extra libraries.

  The configure in the client is supposed to error out if curl is not found, but 
there is also an option to bypass that and compile the client without it.  Now 
any ones I compile and official distribute will have metaserver2 support, but if 
it isn't hard to remove requirements of certain libraries, then probably not a 
bad thing to do so.

> 
>>   Having pthread, at least for client, may be, as even for metaserver1
>> support, it now uses pthread to get the data from the server in its own
>> thread.
>>
>>   pthread may get used for more stuff - threading the client is an
>> interesting idea (one thread to deal with drawing, another for socket) - in
>> this way, GUI is always snappy, and the number of locks needed to make this
>> happen actually isn't that many.
> 
> Actually, pthread is probably harder to get for Windows than curl ;)
> And threading the client, what for? I mean, that's not a small task, what is 
> the point of threading for now?

  I didn't say I was going to hop right on it and do it.

  The most basic would be something like what is done right now for metaserver - 
have one thread to deal with handling the gui, and another thread to deal with 
taking the data from the socket and figuring out what to do with it.  In this 
way, the gui should always remain responsive even if the client is spending a 
bit of time digesting data from the socket.

  And in retrospect, having the sound stuff done in a separate thread instead of 
a separate program would likely have been better.

> 
>>   Haven't tried, but see comment about SDL map support getting removed in
>> other message.  While I know there is always desire to have as many options
>> as available, as the person that has done considerable work with SDL and
>> opengl for drawing logic, opengl seems a much better solution (it seems to
>> provide many more acceleration options than SDL.  For example, if at some
>> point we move lighting effects to the client, opengl has interfaces for
>> that.  For SDL, we'd need to write our own lighting routines)
>>
>>   Now I realize that everyone may not have working opengl, etc, but for
>> those people, pixmap mode is still there.
> 
> Well, SDL is nice because you can use audio things too, so you get sound 
> support. But maybe openal could be used, as another thread mentioned.

  There are like 20 different sound mechanisms for linux it seems.  I do think 
openal would be a better long term solution, as it supports more advanced sound 
handling, so instead of the client having to deal with mixing, etc, openal would 
take care of it.

> 
> Also, if I remember correctly, pixmap does not support alpha transparency, 
> which is something it'd be great to have (ok, in a few years / centuries, 
> when we have artists...)

  opengl also supports alpha transparencies also.

  I won't really dispute that SDL is better than pixmap mode.  I'm just not sure 
if both SDL and opengl support really makes sense.  Also, I'd have to look at 
how the SDL code was done - while I know SDL does support alpha transparencies, 
I'm not sure if the implementation done in the client does or not.