Re: [AD] Windows binary suggestion

[Trent Gamblin <trent@xxxxxxxxxx>]

Well I don't care too much about the DLLs, after all I can easily build Allegro myself... but the default distribution isn't very useful (IMO) outside of quick testing... I know I wouldn't use it to distribute anything... for one thing, all those DLLs take up a lot of space. Not sure if there's a way to statically link them into allegro_monolith dll... since MSVC is annoying about which runtimes you compile your libraries with... if it were possible though that would be the ideal way (IMO) to do it. But I guess in the end the best thing is to build Allegro yourself to meet your needs if you're going to be distributing anything, and use the binaries to get you started...

On 2015-08-03 6:54 AM, Elias Pschernig wrote:

Loading 8-bit .png images works fine, what I meant is if you load them *as* 8-bit (i.e. the palette indices), that's not implemented except with libpng as far as I know. It's a very special case which doesn't matter for most games, I only discovered it for the ex_palette example. It may even be fixed since.

On Sun, Aug 2, 2015 at 1:19 PM, Trent Gamblin <trent@xxxxxxxxxxxxxxxxxxxx> wrote:

First I've heard of this 8 bit PNG issue, I load a lot of 8 bit PNGs so it's strange...

The idea that it's "dangerous" to let the user load whatever format they want is pretty ridiculous.

As far as DLLs, it's more and more common for commercial games to have ZIP archive versions due to the installer fiascos (need some extra toolbars?)

That said, there are still a lot of other DLLs that you have to include and probably don't even use (theora, physfs isn't needed by many, etc)... So static linking is good, but it would be nice to have a single DLL that you could replace in case Allegro got some compatibility fixed after a game stopped being updated. Maybe I'm thinking about this too much...

On August 2, 2015 11:09:04 AM MDT, SiegeLord <siegelordex@xxxxxxxxxx> wrote:
>I don't mind doing it, although in my mind, once you have a dll, it
>doesn't matter how many there are: i.e. I'd just use static linking in
>this case.
>
>Maybe there's something to be said about making statically linked
>Allegro dlls, but I don't really know what's best. It's a bit of a pain
>
>to have to make 6-12 different kinds of binaries because people have
>this weird issue about dlls (shouldn't a professional game use and
>installer and just place a shortcut on the desktop, thus making the
>user
>not care about what actually is inside the game directory?).
>
>As for additional formats, we can either document that only those few
>are guaranteed to be cross platform, or remove those extra formats on
>Windows. I think that, with care, it's still possible to create a
>cross-platform game that loads different formats on different
>platforms.
>
>It is awkward with that 8 bit png limitation, however.
>
>-SL
>
>On 08/02/2015 07:35 AM, Elias Pschernig wrote:
>> I think that's risky for two reasons:
>>
>> 1. The native loaders understand additional formats, so someone might
>go
>> and read e.g. gifs then be surprised they don't work on other
>platforms.
>>
>> 2. The native loaders only support a limited subset of .png (e.g.
>> paletted ones don't work in 8-bit mode) - so for consistency it would
>be
>> better to always use libpng unless you really know what you are
>doing.
>>
>>
>> On Sun, Aug 2, 2015 at 3:48 AM, Trent Gamblin <trent@xxxxxxxxxx
>> <mailto:trent@xxxxxxxxxx>> wrote:
>>
>>     I think next time the Windows binaries are built they should be
>>     build with
>>     -DWANT_NATIVE_IMAGE_LOADER, so libpng/libjpeg aren't needed.
>>
>>
>>
>------------------------------------------------------------------------------
>>     --
>>     https://lists.sourceforge.net/lists/listinfo/alleg-developers
>>
>>
>>
>>
>>
>------------------------------------------------------------------------------
>>
>>
>>
>
>------------------------------------------------------------------------------


------------------------------------------------------------------------------
--
https://lists.sourceforge.net/lists/listinfo/alleg-developers

------------------------------------------------------------------------------