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

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

> So yeah, needs changing, and also for mono data. And I found some more
> places where it is wrong, should I fix them and commit?

Yeah, but post the patch first.

> Oh, and what do you think about a function:
>
> void attach_font(FONT *font1, FONT *font2)

I'd love it, but I think it would require an extra vtable entry. That this
would be very useful occured to me a while back too (when I was working on
the font example - if you've seen what it does, you'll see what I mean),
but I really don't want to poke at the vtable at this point.

> 9 font creations and 19 destructions, with 1+2+3+4+5+6+7+8+9 = 45 range
> creations (4500 create_bitmaps calls) and 36 range destructions... and
> so on... compared to the old grabber who used 0. attach_font would be as
> efficient as the old grabber again.

Note: you can't just copy the bitmap pointers from one font to the next for
any arbitrary pair of fonts - it will lead to a crash when one of the two
fonts and its bitmap parameters are destroyed. That means you would have to
call create_bitmap() anyway.
What we could do is cheat in load_txt_font in that we allow it to bypass
the vtable and manipulate the font data directly for font formats it
understands (ie, Allegro's buildin font types). It should then fall back on
the existing method for other font types. This doesn't help real-time on
the fly merging of fonts though.
How merge_fonts() should have been implemented, at least internally, is
with the option of just adding to an existing font instead of copying all
the existing data over.

What I would really love is the ability to have `sub fonts', a bit like
subbitmaps. You can then just import a range of characters from another
font with no copying at all - just store pointers to the appropriate
location in the target font. This would require a flag in the font range
structure to indicate that the `child' should not try to destroy that font
range.
Of course, this would require that both parent and child fonts be held in
memory at the same time.

Evert