Image loading question

[Grimshaw]

Hello, when a sf::Image is loaded, and it gives an error of the kind "resolution not supported by graphic card" because it is too big, i know it won't be usable as a Sprite, but are the pixels loaded? as if i wanted to manipulate the image?

Thanks

[Laurent]

Nop, it's either a full success or a failure, there's nothing in between.

I know I should separate the "image in RAM" and "OpenGL texture" concepts in two separate classes, but... I still haven't found how to make it easy enough

[Grimshaw]

I suggest a new parameter to LoadFromFile() with a default value.

Image.LoadFromFile("mypng.png", true);

being the "true" something like "Keep the pixels".

sf::Image::LoadFromFile(string Filename, bool KeepPixels = false){...}

What do you think?

No change at all for sfml users and a new option is added if thats the user's will

Plus, shouldnt be too painful to implement the new functionality

[Laurent]

How would that help to solve your problem? Isn't it the opposite, keeping the pixels but not the texture?

[Grimshaw]

I meant, in case of failure, allow the user to keep the pixels in sf::Image, while not having a GL texture

[Laurent]

Ah, I thought it was "store pixels in RAM or not".

So... I don't like your idea at all It would produce half-working objects. In my opinion this feature requires a new design, not just a boolean flag in a function.

Something like:

Code: [Select]

sf::Image image;
image.LoadFromFile(...);
// get/set pixels

sf::Texture texture;
texture.LoadFromImage(image);
// bind
But less complicated (three different classes to display something on screen is too much).

[Grimshaw]

I agree with your opinion, even tough it still makes sense to me that LoadFromFile actually loads something, even if too big for the gpu

LoadFromFile would still return false, as the texture failed to load, but the pixels were actually loaded in memory. I think it makes sense specially because we must check if the image loaded sucessfully or not.

Also, sf::Image could have a new method, for a RAM load only, something only for that purpose

But no hurries, think about it and decide whats best, i really trust your judgement

Thanks

[Laurent]

This is a very inconsistent design, if I add the option to load pixels only to the RAM (which is an important feature in my opinion) it will definitely not do it this way.

[devlin]

Perhaps separate Texture and Image? Although that would break a lot of existing code. Another option would be to subclass an ImageBuffer of sorts?

[Grimshaw]

Yeah, i agree to leaving Image as it is, and creating something else specificly for this

[OniLinkPlus]

I think sf::Texture (being the same as the current sf::Image) and sf::Image (RAM only, Texture can be built from it, possibly?) would be good.

[Laurent]

It's a good design but it makes things really complicated for people who just want to load a sprite:

Code: [Select]

sf::Image image;
image.LoadFromFile("sprite.png");

sf::Texture texture;
texture.LoadFromImage(image);

sf::Sprite sprite;
sprite.SetTexture(texture);
And if you want to modify pixels (set a transparent color, replace pixels, or whatever) you must keep the three objects.

[OniLinkPlus]

It's a good design but it makes things really complicated for people who just want to load a sprite:

Code: [Select]

sf::Image image;
image.LoadFromFile("sprite.png");

sf::Texture texture;
texture.LoadFromImage(image);

sf::Sprite sprite;
sprite.SetTexture(texture);
And if you want to modify pixels (set a transparent color, replace pixels, or whatever) you must keep the three objects.

It shouldn't be required to load a texture from an image, just an option, imo. I think you should still be able to load texture from files/memory/etc, just add images as one more option.

[Laurent]

It shouldn't be required to load a texture from an image, just an option, imo. I think you should still be able to load texture from files/memory/etc, just add images as one more option.

Good point.