PNG loader might be broken in 1.2

[Lord Delvin]

I have a small standard Texture, which I use to show the user, that big texture will be loaded soon. This Texture cant be loaded with 1.2.(Corrupt PNG)
I tried a lot of encoding combinations and looked into the source of SOIL but I dont get why.
If you want to fix this I can send you the Image.(encoding it as tga leaded to a crash, so I stay on my modified 1.1 sources  )
Have fun!

[Laurent]

So far, nobody reported me such errors with PNG or TGA images.

If you want to fix this I can send you the Image

That would be great, thanks.

[Laurent]

I just got your image, thanks.

Actually, it loads without any error with the latest sources. And I'm pretty sure I didn't change the image loading code since the 1.2 release.

Are you on Linux, or Windows ?

[Lord Delvin]

Linux: Amd64 Ubuntu 7.10
I just downloaded the package from sf and did make clean/make/sudo make install.

Maybe its a 64bit issue, I could test that, but it would take me some hours until I have the time to do so.

[Lord Delvin]

The same code runs on my laptop on 32bit ubuntu, so its most probably a bug in SOIL which makes the png loader not 64bit capable.
It would be nice if you'd send me an email the nice day this bug's gone.(Its not that important to me to move to Version 1.2)
Have a nice day!:)

[Laurent]

Ok, I see. I'll check this with the authors and try to fix it as soon as possible. Thanks for your feedback

[Laurent]

Before I send an e-mail to the author... did you properly recompiled SFML for your system ?

[Lord Delvin]

I think so.

This also fails after comlete rebuild of everything with the same reason. (bild.png was produced by the screencapture feature from gnome)

Code: [Select]


#include <SFML/Audio.hpp>
#include <SFML/Graphics.hpp>

 int main()
 {
     // Create the main window
     sf::RenderWindow App;

     // Load a sprite to display
     sf::Image Image;
     if (!Image.LoadFromFile("bild.png"))
         return EXIT_FAILURE;
     sf::Sprite Sprite(Image);

     // Start the game loop
     bool Running = true;
     while (Running)
     {
         // Process events
         sf::Event Event;
         while (App.GetEvent(Event))
         {
             // Close window : exit
             if (Event.Type == sf::Event::Closed)
                 Running = false;
         }

         // Draw the sprite
         App.Draw(Sprite);

         // Draw the string
// App.Draw(Text);

         // Update the window
         App.Display();
     }

     return EXIT_SUCCESS;
 }

[Mindiell]

Can you post the picture here in order we can test it ?

[Laurent]

Ok, I'll contact the author of stb_image. I'll keep you informed.

[Lord Delvin]

Can you post the picture here in order we can test it ?

I've send the original picture to Laurent allready and he says its fine for him, but for me it doesn't work with any png i've testet(and i testet many;)).

[Laurent]

I've contacted the author, apparently there are some "unsigned long" variables used in the code (instead of a fixed size type like uint32), which might be the cause of the problem.

I'll check this and keep you informed.

[dunce]

apparently there are some "unsigned long" variables used in the code (instead of a fixed size type like uint32)

I always thought that in C++ "unsigned long" is 32 bit signless integer. Thus using "unsigned long" on both 32 and 64 platforms could not cause any difference in behaviour. "Unsigned int" - depends on a CPU registers width. Only on Win32 systems these two  types are equal. Am I wrong?

[Lord Delvin]

OT:

Am I wrong?

Not completely, as for some types all compiles try to use the same size, but for example size_t, what is mostly the same as unsigned long is the system bus'(which ever) width.
C++ does not tell you that a type has the length n bits but you can ask limits and you can ask sizeof

[Laurent]

I always thought that in C++ "unsigned long" is 32 bit signless integer

The standard just says that :
* sizeof(char) == 1
* sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)
So there is absolutely nothing saying that an unsigned long should be a 32 bits integer.
Actually, it will most likely be a 64 bits integer on 64 bits systems.