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

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


> > 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..

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.
There is nothing bitmap specific about the code other than it being the
most common format for Allegro fonts.

> loading a .ttf font, but with font ranges extracted out of
> different other .ttf fonts?

Well, that's only possible if the ttf font loader code is capable of doing
that anyway.

> Not much point I'd say..

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 ;)

> 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?
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.

> 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..

Exactly. The reason I'm concerned with this is that it matters if GK was
based on the documented behavior or on the actual source code.

> 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.

Neither do I, but it sounds fairly interesting. I think we should ask him
once 4.3 becomes mainline. Right now it's still a bit of a side-line and
it'll probably a bit harder to get people to contribute to that. ;)

> 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.

I agree. My vote is for a seperate src/opengl directory though.

> What we need for sure
> is better integration, i.e. Allegro must be able to already create the
> OpenGL context,

Personally, I think you would just call al_create_display(GFX_OPENGL,...),
or maybe it could even be the default with GFX_AUTODETECT. It should be
possible to use OpenGL through the new API without any reference to the
fact that we're using OpenGL in the drawing code (which isn't possible now
because of the need to flip the display; the new API has a flip_display()
function anyway).
Maybe we could have a GFX_SOFTWARE, GFX_ACCEL etc in place of/in addition
to the platform specific GFX_DGA2/GFX_DIRECTX etc. Anyway, side issue for
the moment.

> else too much code is duplicated (like window creation,
> AllegroGL programs have no alex icon because of it :().

Hmm... that should not be too hard to fix, I suppose. I'll have a look at
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..

I think I'd love to see that :)
This reminds me of one thing I noticed in the new API branch: it has the
same event-queue flooding that used to affect expal about a year ago in the
4.1 branch (reproducible, for instance, with exupdate if it is modified to
use the new API - which makes the example /really/ simple). I think it had
something to do with the need to call XSync() somewhere?

> 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

Yes, that would be great! We should probably write down how we think that
should work. I think Peter said somewhere, and I agree with him, that
#include <allegro.h> would (ideally) just include the `old' API but not the
new one. That means we need a different include for the new API, which
could be as trivial as something like  #include <allegro/main.h> as far as
I'm concerned.

> I will get to it evenually, but probably only after 4.2.0 is out.

That's fine. We should focus on getting 4.2.0 out first anyway.

> 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.

Well, we could try to start using it and see how far that takes us.
Or, *if* we decide we want to switch at some point anyway (I still need to
browse through the list of messages related to Thomas' offer to host the
mailinglist) we could start in a small way if Thomas could host the task
tracker?

> 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.

> 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?

Evert




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/