RE: Re: [AD] Proposed changes for Allegro 5 (6?)

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


>Yes they do. I thikn they should be updated to be "smarter" - that is, 
>actually look at the header of the file (or meta data on the filesystem) to 
>determine its type instead of simply the filename. We could have a 
>registered function is_of_my_type(PACKFILE *), which would return true if 
>the file can be loaded by the registered format or not.
>If we have this system, then it makes the other load* redundant.

Just a thought that if you combine all these load* functions into one, that code to read in all the possible types gets included in your executable, even if it can never been used.  A good example of this is jpeg reading.  Jpeg decoding is quite a bit of code and including it in load_bitmap will make load_bitmap a very big function.

Please still give access to the load* functions, then the user can decide whether they want the bloat or not.  Forcing them to use a load_bitmap function does not give them any choice but to include code in their executable that cannot be run.

I think that this is actually a hard problem to make very transparent to the user.  The only thing I see working well is some kind of registering function or macros.  The users have to explicitly choose what decoding functions they want in the executable, but at least they are not forced to include useless code. 

Allegro executables are big enough.  Lets try not to make them any bigger.

Doug


------------------------------------------------------------
--== Sent via Deja.com ==--
http://www.deja.com/



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