Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: ExtendedImage - Support for unsupported texture sizes in RAM  (Read 3328 times)

0 Members and 1 Guest are viewing this topic.

krisando

  • Newbie
  • *
  • Posts: 20
    • View Profile
ExtendedImage - Support for unsupported texture sizes in RAM
« on: April 23, 2011, 10:54:57 am »
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

  • Full Member
  • ***
  • Posts: 213
    • View Profile
ExtendedImage - Support for unsupported texture sizes in RAM
« Reply #1 on: April 23, 2011, 11:17:43 am »
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

  • Newbie
  • *
  • Posts: 20
    • View Profile
ExtendedImage - Support for unsupported texture sizes in RAM
« Reply #2 on: April 23, 2011, 11:28:10 am »
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

  • Full Member
  • ***
  • Posts: 213
    • View Profile
ExtendedImage - Support for unsupported texture sizes in RAM
« Reply #3 on: April 23, 2011, 11:29:18 am »
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

  • Full Member
  • ***
  • Posts: 213
    • View Profile
ExtendedImage - Support for unsupported texture sizes in RAM
« Reply #4 on: April 23, 2011, 11:43:14 am »
Quote from: "krisando"
[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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
ExtendedImage - Support for unsupported texture sizes in RAM
« Reply #5 on: April 23, 2011, 11:59:13 am »
Quote
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.

Quote
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.
Laurent Gomila - SFML developer

krisando

  • Newbie
  • *
  • Posts: 20
    • View Profile
ExtendedImage - Support for unsupported texture sizes in RAM
« Reply #6 on: April 23, 2011, 12:23:41 pm »
Ohail Laurent. :oops:

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

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
ExtendedImage - Support for unsupported texture sizes in RAM
« Reply #7 on: April 23, 2011, 12:31:33 pm »
Quote
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.
Laurent Gomila - SFML developer

Wizzard

  • Full Member
  • ***
  • Posts: 213
    • View Profile
ExtendedImage - Support for unsupported texture sizes in RAM
« Reply #8 on: April 23, 2011, 01:06:19 pm »
Quote from: "Laurent"
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.

Quote from: "Laurent"
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
ExtendedImage - Support for unsupported texture sizes in RAM
« Reply #9 on: April 23, 2011, 01:10:33 pm »
Quote
... 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.
Laurent Gomila - SFML developer

NoIdea

  • Full Member
  • ***
  • Posts: 149
    • View Profile
ExtendedImage - Support for unsupported texture sizes in RAM
« Reply #10 on: June 20, 2011, 06:42:02 pm »
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

 

anything