ExtendedImage - Support for unsupported texture sizes in RAM

[krisando]

Currently I am unaware of any method to load an image larger than the restrictions of the video card.

It may not be suitable for compatibility with many classes or maybe even performance wise, but it would be enough to extract the resources off, into much smaller images.

Since it is generally unsafe to load an image larger than 512x512, it would be great for compatibility during the loading stage. Many old and some Intel chips crash at any higher.

It would be an extremely beneficial feature. If only to allow you to copy sections of the image.

[Wizzard]

There is an interesting read here on some new stuff coming to SFML to make this easier.

I think you can do it with the current SFML 2.0 and SFML 1.6 by loading the large image and then making smaller copies of the large image using the copy member function.
There is no problem with loading images with massive sizes in SFML 2.0; the problem lies with drawing them.

[krisando]

Oh right, thanks for clearing that up, I now see what the issue could have been.

[Possible bug]
When giving an image to the sprite constructor and then change to a smaller one. If the first image was a larger image than your video card can handle, it will crash on drawing. Seems to remember something from the constructor, maybe just size of image?

[Wizzard]

It's a good idea for SFML to handle this internally, splitting textures into multiple internal textures if their size is too big for the hardware.

[Wizzard]

[Possible bug]
When giving an image to the sprite constructor and then change to a smaller one. If the first image was a larger image than your video card can handle, it will crash on drawing. Seems to remember something from the constructor, maybe just size of image?

If you're using SFML 2.0, you might have to set the "adjustToNewSize" parameter to true when using SetImage with an image that is smaller than the previous image that the sprite's size was adjusted to. That's just a guess I have as to what your problem may be.

[Laurent]

There is no problem with loading images with massive sizes in SFML 2.0; the problem lies with drawing them.

Wrong, the problem arises when trying to create the texture. It would be weird if OpenGL allowed creating a texture but not using it
This means that until I implement issue #18, there's no way to handle big images in SFML, you must split them before loading them in SFML.

It's a good idea for SFML to handle this internally, splitting textures into multiple internal textures if their size is too big for the hardware.

This is impossible, because if you split a texture into several pieces then you need several sprites to draw it.

[krisando]

Ohail Laurent. :oops:

Just out of curiosity, is it possible to draw textures directly from ram with opengl?

[Laurent]

Just out of curiosity, is it possible to draw textures directly from ram with opengl?

Not directly. The pixels must be transfered to the graphics card for drawing, so they have to be in a texture.

[Wizzard]

Wrong, the problem arises when trying to create the texture.

I was under the impression that the textures weren't created until they were first used. I read the source code and understand that I was wrong now.

This is impossible, because if you split a texture into several pieces then you need several sprites to draw it.

... or just one sprite that uses several different OpenGL textures to draw itself.

[Laurent]

... or just one sprite that uses several different OpenGL textures to draw itself.

Yep, but this is impossible to do with the current API. Textures and sprites are completely separated, to do so I would have to merge them somehow.

SFML is not high-level enough to completely handle this kind of problems internally.

[NoIdea]

One of my project is a solution (for sfml 1.6) to this problem.
However, youll have to install the soil library.
Here is the link : link