I found some errors.

[kolofsson]

Hello. I'm not an experienced programmer, but i'd wish to report some bugs i noticed. My platform is Windows XP and the IDE is CodeBlocks.

Error one: the tutorial example, where the F1 key is bound to make a screenshot ends with a windows error message Memory could not be "written".

Code: [Select]

if (Event.Key.Code == sf::Key::F1)
{
    sf::Image Screen = App.Capture();
    Screen.SaveToFile("screenshot.jpg");
}

Error two: Another tutorial sample, where it is supposed to load an image, works fine on my PC, but when i tried it out on a laptop, i did not work with a 1600x1200 jpg image. I had to reduce the size of the image. The same happened when it was emulated in Wine: Failed to create image, it's internal size is too high (1600x2048).

Code: [Select]

sf::Image Image;
if (!Image.LoadFromFile("image.jpg"))
return EXIT_FAILURE;

I want to make a racing game that loads a track from a file, and it's supposed to be a considerable resolution. I'm worried that on some machines it won't work.

[Laurent]

Error one is already fixed.

Second one is not really an error, it's just that your graphics card can't load images bigger than a certain size (probably 1024x1024 -- you can check this with sf::OpenGLCaps::GetMaxTextureSize()).
SFML can't help much about this issue.

What you can do is split your large images into a few smaller ones.

[kolofsson]

OK, there seems to be something wrong with the sf::OpenGLCaps::GetMaxTextureSize() value. I tried it on two laptops and it returned 2048, however the biggest image i could load was 1024x1024.

To get things more confusing, the value on my PC was 4096, and i could load images up to that resolution.

Slicing an image into squares and loading them separately would force me to generate some complex calculations, especially when zooming/rotating the scene. I'm also worried about the aliasing at the edges. This all makes me wonder how is this MAX_TEXTURE_SIZE problem solved in pro games.

[Laurent]

There's a bug in the version 1.2, you can't load an image of the maximum supported size. It will succeed only if size is less than the lower power of two. that explains your 1024x1024 problem. However, it's fixed in the current sources

In pro games, big files are split and complex calculations are used.

[kolofsson]

Sorry that i keep bugging you. But let me suggest something.

When i load an image that is too big for a texture, then this task fails. What if i could load an image without any limits, and the size check would be done when creating a sprite? This way i would be able to create a sprite from a part of that image. Without this i will have to split the image manually.

[Laurent]

But you really can't load the image if it's too big. It doesn't matter if the sprite only uses a small region of it, it must still be loaded completely in memory.

[kolofsson]

OK, i get it. I just thought the IMAGE is loaded into RAM, and the SPRITE is then loaded into VRAM.

I really don't want to split my big image manually. But the only option to load the image is to load the whole image at once. What i'm missing is some kind of image.loadfromfile(source, left, top, width, height).

[Laurent]

Ya, I guess I have to add some features to make this possible

I'll keep you informed if I update the code.