One Big Image VS Lot Little

[Kerachi]

Hi everybody!

I'm pretty new to SFML, but I like it so far, and I would like to ask about that, should I use one big image and slice it, or use lot but little images as texture?

For example:
One big PLAYER.png file, but it contains all moves and animations, VS lot little png files, like:
player_animaton 1.png
player_animaiton 2.png
player_animaiton 3.png
...
and store them in a vector or list, like:  std::vector<sf::Image> ...

I thought store the player moves and acts in lot but little images is better organized, but whenever I see a tutorial everyone use the one big image mode 

Like:
Texture.loadFromFile("player.png", sf::IntRect(X_beginning, Y_beginning, X_end, Y_end));

But it seem slow to me, I do like better this way:
Texture.update(imageList[currentImage]);

//imageList is a vector which contains, the already readed images...
//currentImage is a number, which is the next frame...
/*btw, I don't know the difference between Texture.update() and Texture.loadFromImage(), but I assume the update is faster */

I'm not sure what's wrong with this mode, is it slow, or is it better? Why no one use it? Or if I try to make a game like diablo 2, then should I use 3D models, instead?

Sorry for the lot questions, but I'm not sure, I'm in the right way 

[eXpl0it3r]

When you have one texture with all the needed images on it, you can very cheaply change what part of the texture you want to use. The texture data is already loaded in VRAM and the texture is ready to be accessed.

When you have multiple textures with different animations, you always have to switch textures, which can impose a certain cost, but it many cases it's not as noticeable.

Updating a texture every time you need the animation costs a lot of time, because you're actually moving the image data from RAM to VRAM, which is slow and should be avoided if possible.

As for easy usage, just defining the texture various texture rects for a giving animation, then loading one texture and applying all the rects at the right time, seems quite easy to me. No need to handle multiple images and animation sets.

[Kerachi]

Thank you, it was very helpful, I didn't know that, that textures goes to the VRAM... (But I should have)

So, now I need to convert a couple hundred image to one big texture, and then navigate on it ... okay, I'll solve it!

But one more question, if there is some useless pixel on the sides, like in this picture:


That would be a problem, when I will deal with collisions, right?

[NGM88]

Not sure what you mean by "useless pixel", but collision doesn't care about transparency, it will check the whole texture rect.

[Kerachi]

NGM88, that is my problem:


(The background is transparent, I colored it just to see what I meant)

I'm sure removing the side useless pixels won't solve this problem entirely, but it's would be less annoying at collisions.

[achpile]

just use different Rectangle for collision check

[Hapax]

Using a larger texture and accessing using texture rectangles is often the best way but bear in mind that there is a maximum size and this varies depending on graphics card. You can find out the user's maximum size at runtime using sf::Texture::getMaximumSize(). 2048x2048 is relatively 'safe' but if you use higher ones, it may be prudent to build it 'on the fly' at program start.

btw, I don't know the difference between Texture.update() and Texture.loadFromImage(), but I assume the update is faster

A sf::Texture must be 'created' before it can be used. Update does not create the image but loadFromImage does.

[Kerachi]

Thank you Hapax and achpile, those comments helped me a lot.

So far I did this: https://github.com/Kerachi/Kerachi (sorry if it is unreadable, I tried my best )

I run into some problem with detecting player is before or behind the wall, and moving the collision Rectangle.
(Because if the collison Rectangle isn't moving then the player would be unable to move "behind the wall")

EDITED: I solved, but I'm pretty sure that there is a way better solution then mine...

Some weeks ago I couldn't even code in c++, so I'm think I'm in the right way

(I just assumed that I can right now? lol)