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

[Kenneth Gangstoe]

Quoting Alexandre Courbot (address@hidden):
> > > 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 ;))

The problem is with low-level manipulation. In most cases modern hardware
acceleration doesn't go to well along with low-level manipulation. What
exactly are you're needs for manipulation ?

The current display API in ClanLib is one of the oldest part of the whole
ClanLib API, and it is noticably so (at least compared to the newer parts
like Network and GUI, which is very nicely designed). The OpenGL support here
is just a matter of adding a few sourcelines at init-time. The worst part
is low-level manipulation.

We are currently making a new ClanDisplay, which will be a "modern" API,
with full support for features in modern hardware - like alphablending
(transparency and translucency), rotation and scaling - all done with 3d
acceleration hardware. This is under development, and not usable for general
use yet, but we're rapidly remedying that :) Hopefully this new API fixes
all the weaknesses in the old one, while making it using new hardware to the
max.

It means we are deprioritizing "normal 2d" targets like xlib and similar
for now, and just use OpenGL, but xlib target and similar can easily be added
later (for those who doesnt have proper OpenGL support, but they would also
miss out the great features of rotation and stuff). 

So, if you decide to try a ClanLib target (in addition to SDL), I'm
glad to help (and even code it) (and Im sure I can get other clanlibbers
on the team).

- Kenneth