Allegro 5.1 problem with PNG (possible bug confirmed).
AMCerasoli

Well, now I'm not using the Michael GDI library but instead that which comes with MinGW. And I'm not using libpng nor libjpg neither. And this is what I get with my game.

{"name":"604941","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/e\/0e7bff9e761888b8ae381e896f9c13d9.png","w":806,"h":634,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/e\/0e7bff9e761888b8ae381e896f9c13d9"}604941

{"name":"604942","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/4\/74ca489d291ee0c0b3c1590e21817733.png","w":806,"h":634,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/4\/74ca489d291ee0c0b3c1590e21817733"}604942

I thought it was working fine with my game but I wasn't linking to Allegro 5.1 correctly.

With .TGA files doesn't happens (a5teroids).

Allegro.log

Elias

Can you try converting one of your .png files to .tga and see if that really helps?

AMCerasoli

With TGA doesn't looks so bad but the problem seems to persist.

{"name":"604944","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/1\/a1560f0f28cd6d4afb276820f228f603.png","w":806,"h":634,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/1\/a1560f0f28cd6d4afb276820f228f603"}604944

In the borders, something weird is happening but I can't tell what... Why a5teroids works?

{"name":"604945","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/1\/11c6d4160a78f86e526cf29e603212ce.png","w":348,"h":292,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/1\/11c6d4160a78f86e526cf29e603212ce"}604945

But there is something even more weird and it's that I modified only one of the "plants", the internal plant (the little one), and by modifying just that it seems that the other one gets "fixed" too.

This couldn't have something to do with the shaders addon?

kenmasters1976

I can't confirm this because I don't have the GDI+ headers for MinGW. I'm using libpng and PNG images are fine, so it must be related to GDI+.

Can you attach the PNG images you're using?.

AMCerasoli

Why don't you have GDI+ in your MinGW package?, which version are you using?. Besides I have also compiled 5.0.4 (using GDI+) and I have no problem.

I was trying to compile libPNG but I can't do it, it seems that library is very buggy.

How did you compile libPNG?, can you send me the binaries? ;D

Edit: I'm using an old binaries that I downloaded, and with libPNG the problem has disappear.

So the conclusion is: There is something wrong in the way that GDI+ is used now.

Edgar Reynaldo
libpng/INSTALL said:

On Unix/Linux and similar systems, you can simply type

./configure [--prefix=/path]
make check
make install

...

Instead, you can use one of the custom-built makefiles in the
"scripts" directory

cp scripts/makefile.system makefile
make test
make install

Or you can use one of the "projects" in the "projects" directory.

If you want to use "cmake" (see www.cmake.org), copy CMakeLists.txt
from the "scripts" directory to this directory and type

cmake . [-DPNG_MMX=YES] -DCMAKE_INSTALL_PREFIX=/path
make
make install

I can't remember if I used the custom makefile or if I used MSYS and configure, but I know it built fine for me.

What errors are you getting?

AMCerasoli

I'm using libPNG 1.5.5 which includes a CMakeLists file so I'm using Cmake-GUI. I tell where to find zlib and everything and when compiling I get this:

c:\libpng-ready>mingw32-make
Scanning dependencies of target png15
[  3%] Building C object CMakeFiles/png15.dir/png.obj
[  6%] Building C object CMakeFiles/png15.dir/pngerror.obj
[  9%] Building C object CMakeFiles/png15.dir/pngget.obj
[ 12%] Building C object CMakeFiles/png15.dir/pngmem.obj
[ 15%] Building C object CMakeFiles/png15.dir/pngpread.obj
[ 18%] Building C object CMakeFiles/png15.dir/pngread.obj
[ 21%] Building C object CMakeFiles/png15.dir/pngrio.obj
[ 25%] Building C object CMakeFiles/png15.dir/pngrtran.obj
[ 28%] Building C object CMakeFiles/png15.dir/pngrutil.obj
[ 31%] Building C object CMakeFiles/png15.dir/pngset.obj
[ 34%] Building C object CMakeFiles/png15.dir/pngtrans.obj
[ 37%] Building C object CMakeFiles/png15.dir/pngwio.obj
[ 40%] Building C object CMakeFiles/png15.dir/pngwrite.obj
[ 43%] Building C object CMakeFiles/png15.dir/pngwtran.obj
[ 46%] Building C object CMakeFiles/png15.dir/pngwutil.obj
Linking C shared library libpng15.dll
Creating library file: libpng15.dll.a
CMakeFiles\png15.dir/objects.a(png.obj):png.c:(.text+0x192): undefined reference to `_imp__crc32'
CMakeFiles\png15.dir/objects.a(png.obj):png.c:(.text+0x234): undefined reference to `_imp__crc32'
CMakeFiles\png15.dir/objects.a(png.obj):png.c:(.text+0x117a): undefined reference to `_imp__inflateReset'
CMakeFiles\png15.dir/objects.a(pngpread.obj):pngpread.c:(.text+0x1bb8): undefined reference to `_imp__inflate'
CMakeFiles\png15.dir/objects.a(pngpread.obj):pngpread.c:(.text+0x2abf): undefined reference to `_imp__inflate'
CMakeFiles\png15.dir/objects.a(pngpread.obj):pngpread.c:(.text+0x2ade): undefined reference to `_imp__inflateReset'
CMakeFiles\png15.dir/objects.a(pngpread.obj):pngpread.c:(.text+0x2cfe): undefined reference to `_imp__inflateReset'
CMakeFiles\png15.dir/objects.a(pngread.obj):pngread.c:(.text+0x1c0): undefined reference to `_imp__inflateInit_'
CMakeFiles\png15.dir/objects.a(pngread.obj):pngread.c:(.text+0x10b9): undefined
reference to `_imp__inflate'
CMakeFiles\png15.dir/objects.a(pngread.obj):pngread.c:(.text+0x2257): undefined
reference to `_imp__inflateEnd'
CMakeFiles\png15.dir/objects.a(pngrutil.obj):pngrutil.c:(.text+0x5ce): undefined reference to `_imp__inflate'
CMakeFiles\png15.dir/objects.a(pngrutil.obj):pngrutil.c:(.text+0x67d): undefined reference to `_imp__inflateReset'
CMakeFiles\png15.dir/objects.a(pngrutil.obj):pngrutil.c:(.text+0x5c9d): undefined reference to `_imp__inflate'
CMakeFiles\png15.dir/objects.a(pngrutil.obj):pngrutil.c:(.text+0x5dc1): undefined reference to `_imp__inflateReset'
CMakeFiles\png15.dir/objects.a(pngwrite.obj):pngwrite.c:(.text+0x157f): undefined reference to `_imp__deflate'
CMakeFiles\png15.dir/objects.a(pngwrite.obj):pngwrite.c:(.text+0x17be): undefined reference to `_imp__deflateEnd'
CMakeFiles\png15.dir/objects.a(pngwutil.obj):pngwutil.c:(.text+0x31c): undefined reference to `_imp__deflateEnd'
CMakeFiles\png15.dir/objects.a(pngwutil.obj):pngwutil.c:(.text+0x3af): undefined reference to `_imp__deflateInit2_'
CMakeFiles\png15.dir/objects.a(pngwutil.obj):pngwutil.c:(.text+0x41f): undefined reference to `_imp__deflateInit2_'
CMakeFiles\png15.dir/objects.a(pngwutil.obj):pngwutil.c:(.text+0x5c3): undefined reference to `_imp__deflateReset'
CMakeFiles\png15.dir/objects.a(pngwutil.obj):pngwutil.c:(.text+0x7ca): undefined reference to `_imp__deflate'
CMakeFiles\png15.dir/objects.a(pngwutil.obj):pngwutil.c:(.text+0x98d): undefined reference to `_imp__deflate'
CMakeFiles\png15.dir/objects.a(pngwutil.obj):pngwutil.c:(.text+0x3476): undefined reference to `_imp__deflate'
CMakeFiles\png15.dir/objects.a(pngwutil.obj):pngwutil.c:(.text+0x4f02): undefined reference to `_imp__deflate'
collect2: ld returned 1 exit status
mingw32-make[2]: *** [libpng15.dll] Error 1
mingw32-make[1]: *** [CMakeFiles/png15.dir/all] Error 2
mingw32-make: *** [all] Error 2

I have being reading and there is a lot of people which also get those errors, and were talking about disabling "-DZLIB_DLL" or something like that, but I don't really have time right now... Those are Zlib errors, and a guy here had that problem when compiling zlib, not libpng, but are the same errors: http://www.allegro.cc/forums/thread/608407

I also compiled zlib without problems, the examples did work, so I don't know what to do to get libpng compiled.

What the hell... I took the time and yea by commenting out "DZLIB_DLL" as explained here did the trick. :)

But when configuring (using Cmake-GUI) you need to choose a shared lib even when you want a static link, because if you choose only static, drops another error :-/.

{"name":"604964","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/f\/9f93f77fe3a4d0a1e91cca59f4e7cbc3.png","w":460,"h":325,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/f\/9f93f77fe3a4d0a1e91cca59f4e7cbc3"}604964

Thanks anyway!.

kenmasters1976

Why don't you have GDI+ in your MinGW package?, which version are you using?.

I have an older version of MinGW with gcc 3.4.5. I also have a more recent version installed but I always use the older version for some reason. Anyway, if the GDI+ headers are included with recent versions of MinGW, I may try building Allegro 5.1 with it to see if I have the same problem with PNG images.

I don't remember if I had any problems building libpng as I did it a while ago (I'm using libpng-1.2.31) but it's good to see you found the solution.

[EDIT:] OK, I managed to build Allegro 5.1 using GDI+. Weird thing, with the GDI+ headers I got I was able to build Allegro with gcc 3.4.5 but not with gcc 4.4.0.

Anyway, PNG images are working fine with the GDI+ build of Allegro. AMCerasoli, perhaps the bug is caused by the way transparency is saved in your PNG files? what software did you use to create your PNGs?.

AMCerasoli

AMCerasoli, perhaps the bug is caused by the way transparency is saved in your PNG files? what software did you use to create your PNGs?

Is not, remember that the skater example also fails.

The problem IMO is in the way GDI+ is used now, because I compiled Allegro 5.0.4 an it worked fine.

Why did you use MinGW 4.4.0? You should try with 4.5.2, since is the one that I'm using, you know, to be completely sure. Maybe GDI+ changed between versions. But there is always the possibility that I'm doing something wrong.

kenmasters1976

I forgot that it was working fine with Allegro 5.0.4. That's weird. Have you tried running you executable on other machines to see if it has the same problem?.

Why did you use MinGW 4.4.0?

It's the version I have installed but that I barely use. I'll try updating MinGW but I don't think the gcc version has anything to do with this.

AMCerasoli

Have you tried running you executable on other machines to see if it has the same problem?.

Yep.

Quote:

I'll try updating MinGW but I don't think the gcc version has anything to do with this.

Well I was thinking more in the GDI+ library rather than gcc.

You said: "Weird thing, with the GDI+ headers I got", where did you get it?, MingGW 4.4.0 doesn't have it included?, because MinGW 4.5.2 it does. And for that reason I thought you might have a different GDI+ version.

kenmasters1976

The version of MinGW with gcc 4.4.0 that I have doesn't include the GDI+ headers and, while searching for the headers, all seemed to imply that MinGW didn't include the GDI+ headers at all, but now I see that more recent versions actually include them so I'll try to build Allegro again with an updated version of MinGW.

[EDIT:] I downloaded the most recent version of MinGW. It comes with gcc 4.6.1 and includes the GDI+ headers. Allegro 5.1.0-r15031 built successfully using the included GDI+ headers and PNG files are working fine. So I guess the problem is definitely on your side. You should try updating your MinGW installation, although I don't think that the MinGW version is the cause.

AMCerasoli

Well, you beat me... :( I have used MinGW 4.6.1 and the problem still there... I have no idea what the problem could be... All the steps that I'm following are on the wiki, so if everything is correct there that would make it even more bizarre.

I compiled Allegro 5.0.4 and it worked fine... So this is very weird... I should try to recompile it again to see if I was using libpng but I'm 99% sure that I wasn't...

kenmasters1976

Are all PNG images presenting this issue? are you using the shader addon?.

AMCerasoli

Are all PNG images presenting this issue?

Yes.

Quote:

are you using the shader addon?

Nope.

Really I have no idea, what could be happening. But to be honest I haven't invest too much time on it. :-X

kenmasters1976

Try writing a small program that loads a PNG image and post your code and executable to try it on my machine.

AMCerasoli

Sorry for taking all this time to answer, but I haven't been at home lastly.

I have deleted all Allegro 5.1 from my PC, I have no time right now to spend on it, I want to finish my project and I have get distracted with a lot of things lately, I don't want to add another reason.

I think what I have said is enough for the Allegro developers, if there is something wrong, they can check step by step what I'm doing in the wiki, if there, there is no problem, then I have no idea.

I think Edgar also compiled Allegro 5.1, I don't know if he was using libpng thought, I guess he was, because he told me he didn't have any problem building it once :-X it was in this thread :-/... But if didn't have any problem compiling without libpng, then obviously there is something wrong in what I'm doing. The thing is that, I have no time just right now.

Now, I'm remembering that I uploaded the binaries, what you could do, is link your project to these static libraries, and if you get the same than I, then it's a compiling problem.

Aww.. forget it... You have MinGW 4.6.1, and it's a kick in the balls now to download MinGW 4.5.2 without the installer...

Forget it man, maybe when Allegro 5.2 is released, I'll try again. I'm going to change my image to Allegro 5.0.4 again >:(

Edgar Reynaldo

I think Edgar also compiled Allegro 5.1, I don't know if he was using libpng thought, I guess he was,

I compiled Allegro 5.1 SVN revision 15012 with lib png enabled and I don't have any problems displaying translucent png's.

Niunio

I'm squeezing my brain but I can't see what's wrong. Can anybody explain me what's the problem? ???

I'm just curious. ::)

Elias
Niunio said:

I'm squeezing my brain but I can't see what's wrong. Can anybody explain me what's the problem?

Are you able to reproduce it? So far everything points to some strange incompatibility with certain versions of the GDI+ libraries which cause the alpha channel to get modified somehow - but as far as I can tell we don't have enough information to say anything conclusive yet.

Niunio
Elias said:

Are you able to reproduce it? So far everything points to some strange incompatibility with certain versions of the GDI+ libraries which cause the alpha channel to get modified somehow - but as far as I can tell we don't have enough information to say anything conclusive yet.

No, I didn't reproduce it. Actually I was trying to figure what's happening just looking at the screen-shots (my fault :-[). BTW your last sentece explains it. ;)

AMCerasoli

If you want me to do some tests, I have some time these days. But no one seems to be able to reproduce it...

kenmasters1976

If you want me to do some tests, I have some time these days. But no one seems to be able to reproduce it...

As I said, you could write a small program that presents the bug and attach your code, executable and, if possible, images so that we can try it.

Elias said:

So far everything points to some strange incompatibility with certain versions of the GDI+ libraries

How do you know the GDI+ version you're using. It would help if AMCerasoli could tell us what version he has.

AMCerasoli

@kenmasters1976

Hi man, I don't want to sound rude, but:

As I said, you could write a small program that presents the bug and attach your code, executable and, if possible, images so that we can try it.

This problem has nothing to do with the code... I could give you a very simple code, but isn't necessary, the examples and other games that compile fine on your PC, doesn't work on mine... So code here is useless.

Quote:

How do you know the GDI+ version you're using. It would help if AMCerasoli could tell us what version he has.

I don't know which version of GDI I'm using (if you tell me how to get the version, I'll post it), but again, I tried with MinGW 4.6.1 as you did and it didn't work, if you're using MinGW 4.6.1 and I'm using MinGW 4.6.1, then we should have the same version, isn't?

So I don't think this is related to GDI+ anymore, since no one can reproduce it, I must be doing something wrong.

Another thing that may not be related: I'm not using any kind of OpenGL SDK, just the one that comes with the O.S, and since Cmake doesn't give me any warning, I think there is no problem.

Arthur Kalliokoski

Nobody's mentioned a buggy video card driver yet?

AMCerasoli

The thing is that I'm 80% sure that I compiled Allegro 5.0.4 without libPNG, and worked fine... So at least that there is a bug with something new, that shouldn't be the problem. In the other hand, I have this new PC, and I haven't tried to compile A5.1 in the old one... So it could be possible.

SiegeLord

This problem has nothing to do with the code... I could give you a very simple code, but isn't necessary, the examples and other games that compile fine on your PC, doesn't work on mine... So code here is useless.

The code is so that the people have something simple to try to reproduce your problem. Also, by writing the code, you'll see if it's your fault or Allegro's. Either way, the simple code is useful for everyone.

Oscar Giner

GDI+ is linked dynamically, so the version you have depends on your OS, and if it's upgraded.

AMCerasoli
SiegeLord said:

The code is so that the people have something simple to try to reproduce your problem. Also, by writing the code, you'll see if it's your fault or Allegro's. Either way, the simple code is useful for everyone.

Here you go... ::)

#SelectExpand
1 2int main(){ 3 4 al_init(); 5 al_init_image_addon(); 6 7 ALLEGRO_DISPLAY *disp = al_create_display(800,600); 8 ALLEGRO_BITMAP *bmp = al_load_bitmap("bmp.png"); 9 10 al_draw_bitmap(bmp,200,200,0); 11 12 al_flip_display(); 13 al_rest(2); 14 15 al_destroy_display(disp); 16 al_destroy_bitmap(bmp); 17 18 return 0; 19}

GDI+ is linked dynamically, so the version you have depends on your OS, and if it's upgraded.

GDI+ comes with MinGW, and for what I see it's a static link. I'm talking about Windows.

Trent Gamblin

GDI+ is part of Windows. What comes with MinGW is headers and an import library.

AMCerasoli

In MinGW I have a gdiplus.h header (along with others) but also a gdiplus.a library, which is where Cmake is linking to. If I modify the gdiplus file that comes with MinGW then it finds GdiPlus.dll that comes with Windows. So what I'm linking? :o
Edit:
Ohhhh... And shouldn't their be using gdiplus.dll.a instead of just .a?

Elias

Here you go...

Can you attach the image with which it happens?

AMCerasoli

Yes I can, tell me of which size would you like it?.

Elias

Doesn't matter, just anything to reproduce it.

AMCerasoli

;D;D;D
There it is.

{"name":"605054","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/e\/5e49a8c10ad7e76c1a639c2498c6265c.png","w":314,"h":274,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/e\/5e49a8c10ad7e76c1a639c2498c6265c"}605054

In case you forgot it, Haiku and Skate images didn't work neither.

Elias

Yes, but if everyone uses another image it's more confusing. And since this does seem to be hard to reproduce it's better to avoid anything which makes it harder/more confusing to test.

Now we have a simple test file (you should edit it to add the two missing includes) we can compare. Here it looks like this:

{"name":"605055","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/c\/fc318a7ee00dc55257d9ae6dad9fc6bc.png","w":802,"h":626,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/c\/fc318a7ee00dc55257d9ae6dad9fc6bc"}605055

[edit:] It should be fixed in SVN now: https://github.com/elias-pschernig/allegro5/commit/961848657e3d256857fca2ee6fbab6a17915c598 :)

Peter Wang

Can you add a test case?

Elias

I don't think it's possible to force the libpng/GDI+ loaders at runtime. Other than that the current test cases would have catched it already I believe, just nobody ever was running them with GDI+.

Peter Wang

I see. I do run the tests on Windows, but only on the 5.0 branch just before a release.

Any chance you could set up your daily tests to run under Wine as well? Allegro 5 works pretty well with Wine, though maybe not with a virtual X server.

Elias

Hm, shouldn't be all that hard to set it up to run all combinations of opengl/directx/libpng/gdi+ I guess. My tests run on a system with only 512MB and very limited disk space though so I'm not sure if I can run (or even install) Wine :/

kenmasters1976

So there was actually a bug? I see it was about premultiplied alpha. How come none of us was able to reproduce it even when building Allegro with GDI+?.

Elias

You needed special images like that palm leaf above to clearly see it. It had some hidden things in the color channels where alpha was 0. I only was able to fix it after analyzing it in GIMP and figuring out what exactly the problem must be (thanks again for posting it AMCerasoli).

With "normal" images likely only the color of anti-aliased parts changed slightly.

Thread #608588. Printed from Allegro.cc