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

[Elias Pschernig <elias@xxxxxxxxxx>]

On Tue, 2005-05-31 at 16:45 +0200, Evert Glebbeek wrote:

> It should work just fine with .fnt or .dat fonts (or even other .txt
> fonts). In fact, the example from the documentation has a .fnt font listed
> in the .txt file. It's quite possible that there are .txt fonts out there
> that use this.

I doubt there are any, since the possibility only was added in 4.1.16 or
so, and seeing how bitmap fonts were broken with .txt fonts since then,
it probably wasn't used that much..


> Wether we think there's a point to it or not, there's no reason to impose
> an arbitrary restriction if the alternative code is just as easy and
> actually a few characters shorter ;)

Ok, ok, I'll put it back :)

> > and then there's the transpose-by-32 issue..
> 
> Not sure if this is an issue... it depends on the (well defined) behavior
> of vtable functions, does it not?

Well, any fonts that won't start with character 32 will be broken.. of
course, changing the transpose_font to use font_begin_range() instead of
32 should fix that :)

> Oh, one thing we should probably check is if load_txt_font fails gracefully
> if one of the fonts listed in the .txt file cannot be loaded.

Yes, already tried that. grabber simply says "The font blabla.txt"
couldn't be loaded, or something like that.

> > 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).
> 
> Bleh, if it's true it's in their best interet to fix it anyway. :)
> It would be interesting to know if WineX has the same problems as Wine with
> Allegro programmes, but I'm not going to pay for it to find out. If not,
> then I think the two camps should consider backporting some changes from
> WineX to Wine.

Hm, no idea about that. I don't even know about the history of WineX..
is it a spin-off off the Wine code?

> 
> > 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 :)
> 
> Ooh... what's this Allegro-CVS-script you have? Anything worth sharing?

Hm, not really. Just a script with lots of hardcoded local pathes, which
updates Allegro from CVS and does things like applying my local patches
and auto-cross-compiling.. but well, it assume too much about where I
keep the base cvs, the backups, the working dir, the crosscompiler.. so
not much use. I attached it anyway in case you want to have a look
despite this.

-- 
Elias Pschernig

Attachment: getallegro.sh
Description: application/shellscript