Re: [Adonthell-devel] I'm back !!!

[Alexandre Courbot]

> > Well, I'm rather for limiting callbacks at maximum (for the window
> > system and such, where they are nearly mandatory) - but I don't know
> > exactly what you have in mind.
> 
> Have you ever considered signals? They are a very powerful mechanism.

Which advantages would them have over callbacks? Do you mean using Unix
signals or make our own system? How do you Clanlib guys handle the
input? (this will prevent me from searching through the doc & code ;p)

> > Exact. This would also make the higher-level game layer totally
> > independant from SDL. That way, if we decide to make Adonthell runnable
> > on Clanlib, or anything else too, we could do it by only tweaking a bit
> > the image, audio and input classes.
> 
> Hey, now you're talking :)

Hehe. To be honest, my opinion about SDL is just about to change. I've
sent a mail to the SDL mailing list two days ago about the pertinence of
having an OpenGL accelerated backend, and I got nothing but ignorance. 
But damn, without something like this hi-res 2D graphics are only
reasonnably usuable on the directX backend. Isn't this a serious
problem? What's the use of using a cross platform library if my project
runs well only under Windows? Moreover, there is more serious even. I
realised that the SDL packages provided with Debian doesn't have OpenGL
support. Why that? Simply because all SDL's settings are set up at
compile time. When I for example look at Clanlib's Debian packaging, I
see that each backend is a module and is provided into a separate
package. There is one package for Clanlib base files, one additionnal
for each backend, one for OpenGL ability, etc... With SDL, there is one
SDL-with-oss package, one SDL-with-esd package, one SDL-with-all
package... all replacing each other. And of course no SDL-with-opengl.
It's obvious that Clanlib is much better designed in that respect (and
the Debian packages are quite old, 0.3 I think - why don't you guys also
package 0.5?). Moreover, SDL development seems to be idle currently,
with only a few bug fixes since several months. I wonder when the 1.3
branch will be launched, and I really hope they will fix these serious
flaws, or it won't have much interest. Anyway, with the current 1.2 it
looks like we can't do all the stuff we wanted regarding acceleration
(as at least Debian packages doesn't support OpenGL, and the OpenGL hack
backend I've seen needs it). So considering that using another library
in addition to SDL wouldn't be very hard, I'm already looking for some
alternatives. And remembered some CLanlib guys showed up at our last IRC
meeting ;)

If as you said Clanlib has an accelerated OpenGL backend (with
accelerated alpha blits and so on) and can be manipulated at the same
low-level than SDL (that is, it provides similar functions) I might well
write support for it one of these weekends. As I said, it's only writing
surface, input and audio classes for it. Not more than a few hours of
work, I'd say (also considering what's working in the 0.4 branch, I'd
only have to bother about the surface class ;))

Yeah, you guessed it - the lack of reaction from the SDL guys got on my
nerves ;) It's not even the first time the topic is raised. The guy that
made the OpenGL hack once proposed to integrate it into SDL's tree.
Apart from an enthousiast guy (that is - eh - me ;)) no one considered
this.

Anyway - feel free to continue this thread and give your opinion,
Kenneth and Ingo. I don't think we will definitely drop SDL because of
it's wide use, but we might support Clanlib in addition, especially if
we get better results with it. I'll have a look at the docs anyway, and
probably make a few tests.

Sorry to change the topic so quickly - what does the others think about
the situation with SDL? Kai, ZT, Cirrus, Ben, Nezu, Jol?

Alex.
-- 
http://www.gnurou.org