SFML community forums
Help => Graphics => Topic started by: Lord Delvin on February 03, 2008, 07:13:47 pm
-
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!
-
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.
-
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 ?
-
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.
-
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!:)
-
Ok, I see. I'll check this with the authors and try to fix it as soon as possible. Thanks for your feedback ;)
-
Before I send an e-mail to the author... did you properly recompiled SFML for your system ?
-
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)
#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;
}
-
Can you post the picture here in order we can test it ?
-
Ok, I'll contact the author of stb_image. I'll keep you informed.
-
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;)).
-
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.
-
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?
-
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 :)
-
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.
-
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. :)
-
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.
-
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 ;)
-
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.
-
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.
-
I am also having problems loading an Image.
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.
-
You should not use doubled slash in the image file path I guess.
"graphics/background.png"
-
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.
-
Is there by the way any information available whether you can use new sfml on 64bit linux now or not?
-
I confirm that replacing every unsigned long with uint32 in stb_image_aug.c seems to fix the problem.
-
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 :)
-
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:
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:
static unsigned long code_buffer; // jpeg entropy-coded buffer
If I change that to:
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?
-
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 :)
-
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
-
Maximum image size depends on the GPU, you can't assume > 1024x1024 will be supported on every system.
-
Hi Laurent.
I think at GPU issue but
VideoMode(1200, 900, 32) go nicely if I resize background image.
On Win2000 PC I have a good radeon 9800
My friend (developer) have a good one and newer.
It seem a loading problem, not sprite problem.
emm.. can be a problem regarded to the windowed mode?
-
Ok, then I'll need more details. Which version of SFML ? What does the error output says ? Can you write a minimal code which reproduces the problem ?
-
Hi Laurent.
My dev friend said me that he try on ATI and IBM GPU of Laptop because now he use only Linux on the big PC.
Because now I have need to use it on laptop with a max graph of 1024..
I catted all big images and compress all texts.
I'm give that program to all my friends to test. ..
.. if you want to see what I do with your kindly SFML..
Now....
I made and tested new minimal test program
Can I send you .zip with im.png & .cpp & .cbp that I make for it?
Do you want to see my first application on SFML?
im.png is an image 1026x32 of 27kb
Program:
#include <SFML/Graphics.hpp>
int main() {
sf::RenderWindow App;
sf::String sfs;
sf::Image im;
App.Create(sf::VideoMode(1200, 900, 32), "Trasporter"); //1024x768
if (!im.LoadFromFile("./im.png")) return EXIT_FAILURE;
bool IsRunning = true;
while (IsRunning) { // Programma simulazione in funzione
sf::Event Event;
while (App.GetEvent(Event)) { // Controllo eventi finestra applicazione compresi tasti premuti
if (Event.Type == sf::Event::Closed) IsRunning = false;
if (Event.Type == sf::Event::KeyPressed) {
switch (Event.Key.Code) {
case sf::Key::Escape:
IsRunning = false;
break;
default:
break;
}
}
}
sfs.SetLeft(0);
sfs.SetTop (0);
sfs.SetText("OK, loaded! Press Esc to exit");
App.Draw(sfs);
App.Display();
} // while IsRunning
return EXIT_SUCCESS;
}
Thanks, Fixus
-
Why don't you use 1024 instead of 1026 ? If your GPU doesn't support non-power-of-two textures, you will end up with a 2048x32 texture internally.
-
Hi, my test code is only an example.
I don't know GPU very well but
I don't understand why I can't load a simple image
if others soft don't have this problem.
Now it's not a problem for me.. no urgency.. I only want to learn.
Thx Laurent
PS: There is a place to put my SFML program as picture or exe.
I love to share source but in this I put a firm reserved code.
-
SFML uses hardware and 3D acceleration, so it depends on GPU capabilities. And the maximum image size is one of them.
-
OK, Laurent.
I appreciate your SFML strategy :lol:
and your help in forum :P
Good work! Thanks. :wink:
-
I forgot to say that I'll try to add an automatic large image handling in version 1.4 ;)
-
I forgot to say that I'll try to add an automatic large image handling in version 1.4 ;)
Is there currently any kind of internal image space-optimization planned (or there now?) (i.e. automatically grouping images together on one texture to reduce wasted white space)
-
No, this kind of thing is not planned.
-
automatically grouping images together on one texture to reduce wasted white space
And binds! these are so time expensive!
-
And binds! these are so time expensive!
Yes. If Laurent is not doing this, I likely will. My project is targeting old hardware, so I'm trying to keep the specs as low as possible. If I end up with something that cleanly implements with SFML, I'll probably post it. But that is months down on my roadmap.
I'd also wait for Laurent to finish whatever he'll be doing with automatic image chopping of large textures before even touching it.