Problem loading large images

[kolofsson]

Hey, I posted a very early version of a game ive been working on (the game called Screenway in the Projects section). It uses a texture of a car and a track. The texture of the track is about 6000 x 2000 pixels. Now, my GeForce supports maximum textures of 8192x8192, so the game works fine. However, on a majority of PCs and Laptops the max size is 4096x4096 or even 2048x2048.

AFAIR, this value is stored in GL_MAX_TEXTURE_SIZE.

I can't imagine chopping down the image into smaller pieces and then calculating all the sprites to follow the movement and rotation, so that the puzzle doesn't fall apart.

So my question is: is the biggest possible loadable image in SFML limited to the maximum texture size of user's graphics card? Are there plans to change that? What do you suggest me to do to overcome this obstacle?

Another problem is, on a laptop which is able to run windows 7 with the Aero transparent interface, the game behaves really bad. It's choppy, like the vertical sync was not working correct. What would that be?

[Laurent]

So my question is: is the biggest possible loadable image in SFML limited to the maximum texture size of user's graphics card?

Yes.

Are there plans to change that?

It's very complicated. In SFML, images and classes that use them are completely separated. So a sprite always makes the assumption that an image can be bound in a single call, return a single set of texture coordinates for a single quad, etc. which is not possible if the image is internally composed of several textures.

Another problem is, on a laptop which is able to run windows 7 with the Aero transparent interface, the game behaves really bad. It's choppy, like the vertical sync was not working correct. What would that be?

Dirvers problem? Did you try other OpenGL apps?

[Ashenwraith]

I remember reading something years back on opengl.org about how opengl had lots of problems running on Windows Vista--especially stuff about the windows gui, flicker, and choppiness.

This might require updated drivers.

BTW, I recommend getting the Mappy add on and using mappy to handle the tiles and tilesheets for your game. You can make the tiles as big as you want, ie 1024x1024.

http://www.sfml-dev.org/forum/viewtopic.php?t=2340

[Laurent]

I can add one thing:

I can't imagine chopping down the image into smaller pieces and then calculating all the sprites to follow the movement and rotation, so that the puzzle doesn't fall apart.

If you draw your sub-images inside a parent Drawable, then you can manipulate it as one piece and nothing will fall apart

[kolofsson]

If you draw your sub-images inside a parent Drawable, then you can manipulate it as one piece and nothing will fall apart

I don't understand. How do you draw an image inside a "parent drawable"? I'm really confused. Can you place images inside some class called sf::drawable?

Lets say i have an image of 4000 x 4000. I cut it in IrfanView into four pieces of 2000 x 2000. Now i load these four images to SFML and convert them to sprites. Now I have four sprites. How do I make them stick together and refer to it in a single reference (like draw, move, delete)?

It's very complicated. In SFML, images and classes that use them are completely separated.

OK, so i understand that it is impossible to display a large image in a single sprite. But am I right, that it should be possible to load even a very large image to SFML? Then, you could create a sprite from a slice of an image with something like sf::sprite::load(sf::image, rectangle);

Right now, if I have a large image, it is just impossible to use with SFML. Note, that many images made using modern cameras are bigger than a single texture size. I am saying that only to point out, that support for large images is a feature that SFML would benefit from.

[Ashenwraith]

You have mutliple textures/sprites and move them together using like an array/loop.

It's inefficient to have one giant texture to be the track because you can only view a small part of the track at one time. It's much better if you have tiles because you can have bigger tracks AND use less memory.


BTW, the problem with supporting large images in SFML is that for it to be useful you need to be able to get the gfx card's max texture size. SFML should be able to load one giant pixel array with a w and h attached to it.

[Laurent]

I don't understand. How do you draw an image inside a "parent drawable"? I'm really confused. Can you place images inside some class called sf::drawable?

Lets say i have an image of 4000 x 4000. I cut it in IrfanView into four pieces of 2000 x 2000. Now i load these four images to SFML and convert them to sprites. Now I have four sprites. How do I make them stick together and refer to it in a single reference (like draw, move, delete)?

Like that:

Code: [Select]

class BigSprite : public sf::Drawable
{
public :

    // whatever to load and setup the big sprite

private :

    virtual void Render(sf::RenderTarget& target) const
    {
        for (std::vector<sf::Sprite>::const_iterator it = sprites.begin(); it != sprites.end(); ++it)
        {
            target.Draw(*it);
        }
    }

    std::vector<sf::Sprite> sprites;
};

BigSprite sprite;
sprite.SetPosition(...);
sprite.SetRotation(...);
// everything inherited from sf::Drawable
By the way, I think that somebody already wrote such a class. However it doesn't seem to be on the wiki; maybe it's somewhere on the forum.

OK, so i understand that it is impossible to display a large image in a single sprite. But am I right, that it should be possible to load even a very large image to SFML? Then, you could create a sprite from a slice of an image with something like sf::sprite::load(sf::image, rectangle);

Yep, but it would require some major modifications to the sf::Image class. And it wouldn't help with manipulating the images as a single piece.

I am saying that only to point out, that support for large images is a feature that SFML would benefit from.

Of course it would

By the way, why don't you use a view instead of transforming the whole track?

SFML should be able to load one giant pixel array with a w and h attached to it.

...and no OpenGL texture. I know. It would make things so much clean and powerful to separate "pixel arrays" and "video textures", but it would complicate things quite a bit too.

[kolofsson]

You have mutliple textures/sprites and move them together using like an array/loop.

It's inefficient to have one giant texture to be the track because you can only view a small part of the track at one time. It's much better if you have tiles because you can have bigger tracks AND use less memory.

OK, but you agree with me, that it should not be my problem how things get done. If my large track is consuming too much CPU, because it is being processed outside the visible area, then the graphics engine should know not to deal with the invisible part.

Besides, I'm not sure if checking which tiles are visible and which not, and them turning them ON or OFF is that much efficient than actually displaying the whole image.

And lastly, modern graphics cards are such killer devices, that displaying one big track and a car over only makes them laugh. Without Vertical Sync, my PC generated 10 000 Frames Per Second, with the track being the size of 6500 x 2400, and upscaled 3x3 (so it was about 20000 pixels wide).

[Laurent]

OK, but you agree with me, that it should not be my problem how things get done. If my large track is consuming too much CPU, because it is being processed outside the visible area, then the graphics engine should know not to deal with the invisible part.

SFML is not an engine. It just provides building blocks, no optimized rendering process or advanced algorithm.

[Ashenwraith]

OK, but you agree with me, that it should not be my problem how things get done. If my large track is consuming too much CPU, because it is being processed outside the visible area, then the graphics engine should know not to deal with the invisible part.

Besides, I'm not sure if checking which tiles are visible and which not, and them turning them ON or OFF is that much efficient than actually displaying the whole image.

And lastly, modern graphics cards are such killer devices, that displaying one big track and a car over only makes them laugh. Without Vertical Sync, my PC generated 10 000 Frames Per Second, with the track being the size of 6500 x 2400, and upscaled 3x3 (so it was about 20000 pixels wide).

SFML is not a graphics/game engine, it's a library.

You have to build the engine.

Your background eats up 42.7 megabytes of vram. That's nothing to laugh at when you are making a simple 2D game.

[Mindiell]

And lastly, modern graphics cards are such killer devices, that displaying one big track and a car over only makes them laugh. Without Vertical Sync, my PC generated 10 000 Frames Per Second, with the track being the size of 6500 x 2400, and upscaled 3x3 (so it was about 20000 pixels wide).

How lucky you are, I think my graphic card can't support textures more than 256x256...
Today, too much 2D Games are no more supporting old computers  :cry:

[kolofsson]

OK, so to sum up:

Is there a way to load and display an image that is larger than the maximum supported texture size using SFML?

Or is the only way cutting the big image into smaller images in some graphics program?

Or maybe there is a graphics library that would enable loading large images, and then feeding SFML with sizes it can handle?

Seriously, if some guys can't display textures larger than 256x256, what can be done? If was to cut my 6000x2000 track into small JPEGs the result would be over 200 small images!  :shock:

[Ashenwraith]

OK, so to sum up:

Is there a way to load and display an image that is larger than the maximum supported texture size using SFML?

Or is the only way cutting the big image into smaller images in some graphics program?

Or maybe there is a graphics library that would enable loading large images, and then feeding SFML with sizes it can handle?

Seriously, if some guys can't display textures larger than 256x256, what can be done? If was to cut my 6000x2000 track into small JPEGs the result would be over 200 small images!  :shock:

You can make your own tool in sfml or look for one online to download. There are scripts for photoshop and graphics programs. SFML doesn't support loading pixel arrays from an image it can't load.

I wrote a script that does this in photoshop if you want it.

[gsaurus]

By the way, I think that somebody already wrote such a class. However it doesn't seem to be on the wiki; maybe it's somewhere on the forum.

Well I wrote something like that (remember this thread?). I could submit it to the wiki, but I was hoping the drawable flip operations to be implemented on SFML :wink:

kolofsson, what comes to my mind is to create a class inheriting sf::Drawable to handle it on SFML. A class that loads the entire image to memory, split it into pointers of pixels of smaller size, and create an array of images with loadFromPixels. Then, on the Render method it draws the whole array.

I still didn't understand why you need such a big image (sorry I didn't read the thread entirely, quite busy atm ). I usually split my images with a program of my own. I store them all on some "Layer" class that displays only the parts that are visible on the screen at each frame.