Re: [AD] SF.net SVN: alleg:[11766] allegro/branches/4.9/src/macosx |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: Coordination of admins/developers of the game programming library Allegro <alleg-developers@xxxxxxxxxx>
- Subject: Re: [AD] SF.net SVN: alleg:[11766] allegro/branches/4.9/src/macosx
- From: Elias Pschernig <elias.pschernig@xxxxxxxxxx>
- Date: Sat, 07 Mar 2009 19:33:09 +0100
On Sat, 2009-03-07 at 10:18 -0800, Evert Glebbeek wrote:
>
> There was a chunk of code similar to that in the OS X driver that was
> used to convert whatever pixel format the user set (well, actually,
> that was ignored and overwritten with ARGB_8888 or something similar)
> to a pixel size to pass to the OpenGL initialisation code. But that
> conversion is done by Allegro anyway, so I ripped it out.
> I can see why there would be more though.
What I'm thinking of mainly is formats like D3D9's 64-bit FP16 or
128-bit FP32 textures - would be nice to be able to use corresponding
Allegro formats. In fact, i could see use for allowing addons to add
additional pixel formats. Basically, all they should have to provide is:
- An enumeration value (maybe we can use ALLEGRO_ID for it?)
- A function to convert an image (or area, but have to make sure
compressed textures can work) in that format to a standard format
- A function to convert from a standard format
And then to have them accelerated:
- A corresponding D3D pixel format and a corresponding OpenGL pixel
format, if either exists
The latter probably means this can't easily be in an addon after all.
After talking in IRC just before, Trent seems to be working on the
al_lock_bitmap change right now, when that's done I'll try again adding
the two mentioned floating point formats - maybe I'll have a better idea
then how to make the list of supported formats extensible.
> OTOH, it is an external dependency that might be less common than
> libzip. But someone could implement both, of course.
>
I just looked at the two websites:
http://icculus.org/physfs/
http://nih.at/libzip/
Guess libzip is less of a standard than I thought... I somehow had put
it along with zlib. But it seems the authors of both the above libs
implemented the same things and none is very widely used - the only real
standard lib is zlib.
--
Elias Pschernig <elias@xxxxxxxxxx>