Re: [AD] New font types

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


> The *font* interface is fine, but when constructing a dat2c or dat2s
> datafile, we won't know about the new font vtable (remember that we
> currently use the "color flag" as a placeholder in the 'vtable' entry).

Right.

> And there is no way to load fonts except through datafiles,

The load_custom_font() function is by design font add-on territory. (Too bad
that [AD] is not archived, because I still find weird that Allegro doesn't
provide the load_custom_font() functions corresponding to the formats it
supports in the grabber).

> but grabber doesn't support the format...

Yes, a mecanism to handle sub-(object type) plugins is missing.

> But a way around this (without adding to the library but changing some
> parts) is to make dat2s/c emit a function for each datafile, so that
> when you call fixup_datafile() this function is called. In this
> function would be code to perform any necessary construction for every
> type of object - and that code simply needs to be copied into the
> datafile source from a text file.
>
> So by modifying dat2c, it would be possible to provide a text file
> describing every type of object and (therefore) no recompilation is
> needed to add new object types; just a new text file.

Nice mecanism. But how do you put your fonts in datafiles in the first place ?
Does the font creator directly output datafiles ?

> It would require *changes*, but not *additions*. What do you think?

I agree to make changes to the library datafile support and related tools.
But the whole picture should be coherent: for example, if we enhance dat2s/c
to support your object type, load_datafile() should support it too.

> > Does this mean that you want to merge a custom anti-aliasing
> > rendering engine into Allegro ?
>
> It only works for fonts, of course; nothing else. (Basically it draws a
> pixel with an alpha value). The code is very simple.

Ok, but this is a custom engine working on a custom format so I don't see
why it should be merged into the core library. AllegTTF also has a custom
anti-aliasing engine and it works nicely though the Allegro textout()
functions.

--
Eric Botcazou



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