PNG loader might be broken in 1.2

[dunce]

In my mind there is a table that was formed long ago when I began program for 32bit platforms and I don't have any idea now how this happened:
char: 8
short: 16
long: 32
int: depends on CPU
I guess it's time to have a look at standards.

[Laurent]

I made some modifications to the code. Can you try the latest sources and see what happens now ?

I basically replaced every unsigned long with uint32 (I really don't know if it's going to make a difference), and I changed the error reporting mode so that we'll at least have the exact location of the error.

[zarka]

In my mind there is a table that was formed long ago when I began program for 32bit platforms and I don't have any idea now how this happened:
char: 8
short: 16
long: 32
int: depends on CPU
I guess it's time to have a look at standards.

you can never be sure that long is 32 bits ...
and in the end it is all upp to the compiler ... and then it's the funny deal about memory alignment and the like

[dunce]

I hate to go off-topic. But I found the Borland's help source that misled me when I started with Borland C++ Builder:
 

The long keyword designates a 32-bit integer. It can be preceded by either the keyword signed or the keyword unsigned. The int keyword is optional and can be omitted. To the MIDL compiler, a long integer is signed by default and is synonymous with signed long int. On 32-bit platforms, long is synonymous with int.

[jbadams]

I hate to go off-topic. But I found the Borland's help source that misled me when I started with Borland C++ Builder:
 

The long keyword designates a 32-bit integer. It can be preceded by either the keyword signed or the keyword unsigned. The int keyword is optional and can be omitted. To the MIDL compiler, a long integer is signed by default and is synonymous with signed long int. On 32-bit platforms, long is synonymous with int.

That would have been true for that compiler, but it doesn't neccesarily apply to others or to the language itself.

[armage]

I am also having problems loading an Image.

Code: [Select]

sf::Image anImage;
anImage.LoadFromFile("graphics\\background.png");

At first I thought it was the Bit Depth of 64 is the problem
1280X768, Bit Depth 64bit
but when reduced to 32 bit stilla problem
1280X768, Bit Depth 32bit

Just a suggestion, have you thought about using FreeImage? It has wide support for a lot of formats.

[dunce]

You should not use doubled slash in the image file path I guess.

Code: [Select]

"graphics/background.png"

[armage]

I will try what you suggest. But I have successfully used the same path naming with other smaller files. But the paths are stored in an xml file.

Will update you guys.

[Lord Delvin]

Is there by the way any information available whether you can use new sfml on 64bit linux now or not?

[skwurp]

I confirm that replacing every unsigned long with uint32 in stb_image_aug.c seems to fix the problem.

[Laurent]

I confirm that replacing every unsigned long with uint32 in stb_image_aug.c seems to fix the problem.

Are you talking about the last changes I made, or did you have to do it yourself ? I don't remember if I replaced every unsigned long

[skwurp]

No, I made the changes myself, to the file included in version 1.2 of sfml.

I see that changing them to uint32 makes them unsigned ints, as defined in stb_image_aug.c on line 74:

Code: [Select]

typedef unsigned int   uint32;
I don't know if they should be unsigned ints, but image loading seems to work fine after the change.


Ahh, now I see that line 645 is the culprit:

Code: [Select]

static unsigned long  code_buffer; // jpeg entropy-coded buffer
If I change that to:

Code: [Select]

static uint32  code_buffer; // jpeg entropy-coded buffer
it no longer gives the "Failed to load image "thenameofyourimage.png". Reason : Corrupt PNG" error.

I don't know, maybe the other unsigned longs need changing (to be safe with 64 bit) as well?

[Laurent]

I don't know, maybe the other unsigned longs need changing (to be safe with 64 bit) as well?

I don't really know, it depends on the specs of the file formats. The author of the library is not sure about this, too.

Anyway, thanks a lot for finding the exact location of the problem

[fixus971]

Hi.

I make a nice program with SFML but
I can't run it on some others PC:
go on: WinXP(old=full of applications) and other WinXP(office)
don't go: WinXP(of my developer friend), WinXP(new in office), WinXP(old), win2000.


 :!: I found the problem  in the x dimensions of image:
if I use images of any type greater than 1024 (pixel x)
I'm don't get any error but simply see that
win start and exit after 0.13secs.

I try to move files and put *.dll on many PC.

So.. witch file of SO can I check to work on others PC? :?:


Thanks Laurent

[Laurent]

Maximum image size depends on the GPU, you can't assume > 1024x1024 will be supported on every system.