Re: [AD] Old problems that still persist on Allegro 4.2 beta 3

[Elias Pschernig <elias@xxxxxxxxxx>]

On Tue, 2005-05-31 at 15:22 +0200, Evert Glebbeek wrote:
> > Ah, yes, I grepped for all internal uses of those functions and adjusted
> > them by one. New attempt attached. The "last" variables are now actually
> > the last character, but "end" inside the font structure is one past the
> > last (well, the end :P).
> 
> Looks mostly good after a first look. One other thing (I may have missed it
> before):
> 
> -         f4 = load_font(font_str, pal, param);
> [...]
> +         f2 = load_bitmap_font(font_str, pal, param);
> 
> Any particular reason you want to restrict load_txt_font() to bitmap fonts?
> IMO, there's no reason to do that as load_font() will load bitmap fonts as
> well as load_bitmap_font() would and will actually be able to load other
> fonts as well (similar to calling load_bmp() instead of load_bitmap()). I
> guess historically Allegro could only handle fonts loaded from bitmap
> files, but at this point the limitation is artificial because the code
> should not care - or am I missing something?

Well, I'm not quite sure how it is supposed to work with anything but
bitmaps.. loading a .ttf font, but with font ranges extracted out of
different other .ttf fonts? Not much point I'd say.. and then there's
the transpose-by-32 issue..

> > For 4.3.x, we might be able to de-confuse this
> > and change it to always use inclusive range, which I agree is more
> > logical - but for now, not worth breaking AllegroGL because of it.
> 
> Indeed. Which reminds me - it might be a good idea to check how Glyph
> Keeper handles this to make sure that isn't broken now.

It doesn't use the color and mono vtable implementations, so GK wouldn't
be much of a problem. But yeah, might check if it gets the
inclusive/exclusive right.. not really our concern though :)

> > Speaking of AllegroGL, this reminds me again, we definitely should try
> > to get Bob to do a synchronized release of AllegroGL when 4.2.0 is
> > released. Judging from allegro.cc, AllegroGL is quite popular, either
> > directly or through OpenLayer, so releasing 4.2.0 with only the CVS
> > AllegroGL working together with it seems strange..
> 
> I agree. Telling people to use the latest stable Allegro and AllegroGL CVS
> is a bit awkward because not everyone is willing to set up a CVS client and
> go through the extra steps to get it. A new release of AllegroGL sounds
> like a good idea anyway.
> On the subject of OpenLayer, I've taken a look at it and it seems to me
> that it does a lot of things AllegroGL does too as well as some things that
> are missing from AllegroGL. Maybe Fladimir could be persuaded to help with
> AllegroGL development itself and we should try to enlist him if/when we
> want to make Allegro 4.3 come with an OpenGL graphgics driver by default?

Yes, sure, maybe he even could move code from OpenLayer into Allegro,
therefore improving Allegro, and simplyfying the OpenLayer code (e.g.
let's say if OpenLayer has a good circle function or something.. then it
could be moved to Allegro, and OpenLayer just calls it). Not really sure
how feasible that is though.

We also need to find the best way yet how to integrate AllegroGL. Could
leave it as a separate CVS repository, or else just an additional
src/opengl directory. Bob probably should decide. What we need for sure
is better integration, i.e. Allegro must be able to already create the
OpenGL context, else too much code is duplicated (like window creation,
AllegroGL programs have no alex icon because of it :(). Peter said he
has a test version of new_api_branch working with OpenGL already.. so we
should be able to start from that..

> Which reminds me that I have some 4.3 work lying around that I need to get
> back to.

It's just too much effort for me to start using it as of now :P 2 CVS
versions at the same time, and then I have set myself that task of first
making them installable into /usr/local at the same time without
interfering :P I will get to it evenually, but probably only after 4.2.0
is out.

> 
> > maybe even could have
> > an AllegroGL 0.3.0 (or whatever the next would be) beta1 together with
> > 4.2.0 beta4 (RC1?).
> 
> Should be RC1. I had a date in mind for sometime next week, I'll write a
> new message to propose/announce that later on. Also depending on wether or
> not we can fix all current known issues before then (I guess so, should
> make a more comprehensive list of what they are).

Yep. Reminds me of the idea of a task tracker, from allegro.cc.. we must
look into something like that for 4.3 for sure :) If just SF would be a
bit nicer, could exclusively switch to their bug and task trackers.

> On that subject, how are things going on the Wine front? I've seen that
> you've found and sortof fixed the bug in Wine; do you have any idea on
> wether it will be applied or not?

Well, I don't know more than what is on the bug tracker:
http://bugs.winehq.org/show_bug.cgi?id=2981

Basically, I sent there a working patch which fixes Wine (but someone
said it isn't likely to be applied, because of some DLL separation issue
I'm not sure I understand), and I offered them two other solution how to
fix it and told them their current way how they implement dinput is
flawed (thinking about it, maybe that wasn't such a good idea, even
though it's true :P).

Anyway, it's now clear that the fault is not in Allegro, so we shouldn't
apply my workaround. (Having said that, my Allegro-CVS-script
auto-applies it for me, so I can cross-compile and test the windows
version in Wine :)

-- 
Elias Pschernig