Re: [AD] native image loaders

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


On Fri, Apr 9, 2010 at 6:41 PM, Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:
>>> al_load_bitmap(filename, const char *type)
>>>
>>> * if type is null, auto detect based on extension
>
> Hmm. I have to say I don't really like an extra argument that I don't really see the use of. Especially if we already have al_load_bitmap_f() that does pretty much that already.
> When and why would that extra argument be useful in practice?
>
You would need it if there were no explicit al_load_type()

al_load_bitmap("foo"); // which handler to call?
al_load_bitmap("foo.dat"); // extension changed

But in real usage that would rarely happen because most common image
types will have extensions, in which case there could be this format:

al_load_bitmap_type("foo", ".png");

It's a convenience method for:

ALLEGRO_FILE *f = al_fopen("foo", "rb");
ALLEGRO_BITMAP *bmp = al_load_bitmap_f(f, ".png");
al_fclose(f);

The purpose of getting rid of explicit functions is to make sure the
image add-on always has the same public API, regardless of what is
loaded into it. I also think it simply looks ugly to have all of those
functions when they aren't really needed.

> Although it actually annoyes me that I have to do something extra to load a .ogg file in the audio addon.
>

Peter Wang:
> I think it would be annoying.  I definitely want to see PNG/JPEG in the
> main allegro_image addon.  allegro_image can support further formats on
> different platform if they come "for free", though we should strongly
> encourage developers to stick to PNG/JPEG/BMP/TGA/PCX for portability.
> If acodec were all-inclusive and was without explicit loaders, you wouldn't have to.
>
I'm currently of the opinion that both image and audio add-ons should work like:

* no explicit functions (e.g., load_bmp, load_pcx, load_ogg)
* everything supported at compile time is part of the acodec/image addon
* if you want to add extra formats that aren't deemed worthy of
inclusion into Allegro proper, you can make your own add-on. But by
rule, any officially supported format would be part of acodec/image.
* [optional] some way to query which formats are supported (probably a
list of registered handlers by extension)
* the docs mention which platforms support which formats

This would mean ogg/flac/modaudio would be rolled into one single
'acodec' addon. And of course, none of them would be required to build
acodec.

It would be trivial for somebody to create (e.g.) allegro_ogg (or just
include the C source file directly with their program) if they wanted
to have conditional support. There would be no name collisions if
somebody else then linked your program with a version of acodec that
already contained ogg; the worst that would happen is the register PNG
call would fail because allegro_init_acodec_addon() would have already
registered. (Or you could register yours first.)

On Windows, I've tested it and there's no problem with linking against
static ogg / flac libs, such that you wouldn't be forced to distribute
extra DLLs when you don't use the functionality. So I don't see
all-in-one modules being troublesome, and in fact, I think it makes it
easier to use since you could then query what functionality is
available.

--
Matthew Leverton




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