Re: [AD] Skater + AllegroGL

[Elias P. <el...@us...>]

On Tue, 2007-09-18 at 19:17 +0200, Milan Mimica wrote:
> Elias Pschernig wrote:
> > 
> > Would it be hard to use an alpha bitmap in that case? I.e. just have two
> > textures on disk, use the pink one for the Allegro version, and the
> > alpha one for AllegroGL.
> 
> Yes, that is an option too. But I think it would be less confusing for 
> the average allegro user with only one texture and the less AGL related 
> #ifdefs possible. After all, the demo game is here mostly for 
> educational purposes and we have to keep the code clean.
> It was very clean before I started editing it. But I don't think it too 
> messy now either.

Yes, the educational purpose is why I would want that option - so it
gets clear that you *can* have transparency with AllegroGl as well in
this case - just you need to use an alpha texture (which at the same
time would not work with plain Allegro I think).

> > Indeed. In one of the meetings, we said we want to "merge" AllegroGL
> > into 4.3.10. Where merge could mean nothing more than just copying it in
> > there, but still keep it as separate library.
> 
> I'm fine with not merging the code. The nice thing about AGL is that it 
> merges itself automagically at runtime.

So, what do you think about putting AllegroGL into an addons/allegrogl
(or similar) subfolder of the 4.3.10 branch? Then we can try to maybe
make the build process somewhat more unified (probably not a lot, as to
really fix it we'd have to drop autotools and manual makefiles).
Anything speaking against that? Everyone with commit access to AllegroGL
already has commit access to Allegro I think, so not a lot should
change. Alternatively, we could keep allegrogl separate, and just merge
it into the 4.3.10 SVN from time to time.

The other idea for 4.3.10 was to also add png, ogg and ttf support (only
if libpng, libogg, and freetype are available, respectively). And some
other minor changes, the resizable windows patch and some unified sprite
drawing patch come to mind. So 4.4.0 would support a somewhat more
modern set of things out of the box, to bridge the gap until 5.0.0
appears.

> > Any reason the patch shouldn't be applied to SVN?
> 
> No. You?

Neither, so I was wondering if I could just wait for the commit and try
it then, not having to manually apply the patch :)

-- 
Elias Pschernig <el...@us...>