Re: [AD] native image loaders

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

On 9 Apr 2010, at 19:05 , Elias Pschernig wrote:
> On Fri, 2010-04-09 at 17:33 -0500, Matthew Leverton wrote:

> I wouldn't see it as a big problem... and it would be consistent with
> how our audio addons work. But then again I don't think it's necessary.

I agree, more or less. Although it actually annoyes me that I have to do something extra to load a .ogg file in the audio addon. So I wouldn't particularly like the image addon to work the same way.

>> What about just getting rid of the functions like al_load_png,
>> al_load_jpg, etc in favor of simply:
>> 
>> 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?

>> Or even:
>> 
>> al_load_bitmap_type(filename, const char *type)
>> 
>> and keep al_load_bitmap() as is.
> 
> I think I prefer that.

Ditto (as I more or less said in a round-about way above).

> UIImage (what we use on IPhone OS) supports all of those as well and
> likely same is true for the OSX version.

Yes. 

> What about the save functions? I guess we could just have the same three
> functions you suggested for loading:
> 
> al_save_bitmap(bitmap, name)
> al_save_bitmap_type(bitmap, name, type)
> al_save_bitmap_f(bitmap, name, type, file)
> 
> (Also, why do our current al_save_bitmap functions have the parameters
> swapped?)

Matter of taste, I guess. I would argue that you have them backwards above. ;)
If I had to give a reason, I'd say "filename first, data second" makes the most sense to me (and is what I've always used myself).

Evert