SFML & OpenGL, complaint that my image is too large?

[Weeve]

Well, first of all I'd like to know the limit, it loaded a 200x200, but when I try to load the 4096x4096, I get

"Failed to create image, its internal size is too high (4096x4096)"

, any way I could get a resolution that large, and is it a SFML complaint, or an OpenGL complaint?

[Nexus]

The limit can be retrieved with sf::Texture::GetMaximumSize().

I have written two classes thor::BigSprite and thor::BigTexture that are able to deal with large images. Internally, the image is split into smaller images that can be stored in graphics memory.

[Weeve]

Thank you, I might try to write a file opening function, if sf::image has a cap, but why wouldn't sfml just store it in a vector, and not an array, since I'm assuming that is the reason for the limit? or is it hardware based issues? and does the thor library contain support for sf::Image's functions? (all I need is height, width, and RGBA values), if it does, I might try that out first, thanks for the help :-)

[Laurent]

but why wouldn't sfml just store it in a vector, and not an array, since I'm assuming that is the reason for the limit?

Oh my gosh, why didn't I think about it before!!!!

Seriously, it is of course a hardware limit, every graphics card has its maximum texture size. The only way to have bigger images is to split them.

[Nexus]

and does the thor library contain support for sf::Image's functions? (all I need is height, width, and RGBA values)

You could just take a look at the two links I gave you
GetWidth() and GetHeight() are supported, but single pixels can't be extracted directly from textures, just like at SFML.

But thor::BigTexture is supposed to be similar to sf::Texture, not to sf::Image. The latter can store images that are bigger than the texture limit anyway -- sf::Image is a container class, not related to the graphics card.

[Weeve]

Hmm, but I never use sf::Texture, just sf::Image, why would it limit because of the graphics card, it makes little sense.. and laurent, will the update allowing larger sizes be implemented now or in version 2? I want to get the update as soon as possible

Oh, and is there an "easy" way to get a click location (x,y,z), or a click vector on a window using OpenGL, I'd hate to have to build one from archaic GL functions :roll: ?

[Nexus]

Are you using SFML 1.6? In this case, you cannot have bigger images.

If you are using SFML 2, the separation of sf::Image and sf::Texture allows to load large images, like I did in the thor::BigTexture class. But you must use sf::Texture in the end to display sprites.

To get the clicked coordinates, look at sf::Event, sf::Mouse and maybe sf::RenderWindow::ConvertCoords().

[Weeve]

Thanks, and I'm not displaying the image, I made a function to load and wrap it onto a 3D mesh I made

using sfml 1.6, and sf::RenderWindow::ConvertCoords() was not what I was looking for, I guess I'll build my own click vector when I get around to the camera class, I'm excited about my engine, its picking up pace, so far, it can load and display a .obj file, with a .png texture, and it has functions for rotation, inertial rotation, translation, local translation, and it calculates face or vert normals! next to my addition will probably be the camera, with click detection for AABBs and per face XD, do you think sfml would need any additions to its functionality in the 3D area, or is it a lean-style class?

[Nexus]

Ah, sounds interesting. So you search for a raycast facility? You won't find this kind of stuff in SFML, as it provides only 2D graphics functionality. But you could look at a Irrlicht for example.

[Weeve]

kk, I'm going to build my own, tho, I'm trying not to use any libraries but Qt, sfml, and OpenGL, (Qt very lightly, only for opening a file), after I build the function, do you think sfml might want functionality in that area, or is it not worth the bulk in the library?