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

[cirrus]

Alexandre Courbot wrote:
> 
> > > 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?
> 

I'm no expert here, but adding support for other alternatives can't be
bad. Like you said SDL is quite wide-spread so keeping support for it is
good. If another supported lib gives me better performance I'd use it
though. ...speaking of which - why not use OpenGL diirectly? :P

        -James
-- 
   ___    ___  ___       ___ 
  /    / /__/ /__/ /  / /__                 Reg. Linux User #148821
 /___ / / \  / \  /__/ ___/@linuxgames.com  www.twiddles.com
                                            adonthell.linuxgames.com