Image too large?

[dpixel]

Hi all,

I was getting a "white sprite" problem.  It shows up fine on one computer and as a white box on another. 
And I thought it was the sf::Sprite, sf::Texture scope, after reading around.    I narrowed it down that the image was too big for the vid card.  The width was 2089 and I cut it back to 2048 and everything was fine.

Anyway, I have a lot of graphics in this game and there will be more.  I've read in the tutorials that it's best to have as few textures as possible, but I did not understand why from the reasoning.  Could someone explain in more simple terms.   Thanks.

[Nexus]

I've read in the tutorials that it's best to have as few textures as possible, but I did not understand why from the reasoning.

Is it really written in such a general way? There is no fundamental problem with multiple textures. It takes some time to switch between different textures (far more than to switch texture rectangles), but unless you draw loads of elements, this won't be an issue. On the other hand, by creating overly large textures, you lose compatibility to older graphics cards.

In case you need bigger continuous textures, for example to display a background image, you could have a look at thor::BigTexture. It automatically splits the texture into smaller textures that can be stored by the graphics card, providing a transparent API to the user.

[dpixel]

I guess I'm confused about "switching between different textures".   I don't know if I'm doing that...lol

Every .png file I have is loaded into a texture and then assigned to a sf::Sprite.  Then I just blit parts of the sprite I need.
I just want things running effeciently as possible.
This is what I'm doing:

    sf::Texture interfacetexture;
    sf::Sprite interface;

void init()
{
    interfacetexture.loadFromFile("interface.png");
    interface.setTexture(interfacetexture);
}

void Blit(int x, int y, int srcX, int srcY, int srcW, int srcH, sf::Sprite sprt)
{
    sprt.setPosition(x, y);
    sprt.setTextureRect(sf::IntRect(srcX, srcY, srcW, srcH));
    window.draw(sprt);
}

 

[Nexus]

Texture switches occur every time a sprite (or another drawable) is rendered with a different texture than the one before. I'm not entirely sure how smart SFML and OpenGL are when the same texture is bound multiple times in a row, but I strongly assume it will be faster than binding different textures.

Anyway, your blit mechanism is quite questionable. Have you used SDL before? The typical use case in SFML is: You have a sprite and set a texture, which doesn't change after initialization. Depending on the game logics, you set the transforms (position, rotation, scale), possibly color and texture rect (for animations). Don't try to mimic blitting or immediate rendering as you know it from ancient graphic APIs. Also, don't copy sf::Sprite if it's not necessary; pass it by const reference.

[dpixel]

I'm always using the same texture with the same sprite.  Just the x, y source is changing to get the right frame.

And yes.  I ported my game from SDL to SFML.  Except for the audio, which crashes on exit.  (Already have a post on here about that)

This Blit function works surprisingly well, which is mostly used on animations...which is why my .png files are large...I try to keep all the frames on the same X position, so the png width gets long.

Is there some sort of performance problem with the way I'm doing this?  My goal was to put something on the screen with one line of code.

[Nexus]

I'm always using the same texture with the same sprite.  Just the x, y source is changing to get the right frame.

No, you're not. As already mentioned, you're copying the sprite every time you draw. Thus, you have a different sprite for every Blit() call.

But why don't you store different sprites in the first place, instead of recycling sprites and adjusting their texture rects again and again? I hope it's not for performance reasons...

And yes.  I ported my game from SDL to SFML. [...] This Blit function works surprisingly well

Of course it works, but you should not try to apply SDL 1.2 concepts (which are antiquated, to say the least) directly to SFML. This tutorial explains how to render objects with SFML, using the object-oriented approach of sprites instead of immediate drawing.

My goal was to put something on the screen with one line of code.

But with this approach, every caller of Blit() has to know the texture rect. If you draw the same sprite multiple times, you have to pass the coordinates multiple times. You have magic numbers across your whole application. If a texture rect changes, you have to adapt many different places.

[dpixel]

But why don't you store different sprites in the first place, instead of recycling sprites and adjusting their texture rects again and again? I hope it's not for performance reasons...

That would be a lot of sprites.  I didn't think it would be done that way. 
How big of a performance hit am I taking adjusting the texture rect every time?

using the object-oriented approach 

Yeah, I'm a bit old school with bad habits.  I'm using no Classes, only structs...lol

You have magic numbers across your whole application.

Yes I do.  LOL

I'll try and wrap my head around that tutorial

[Nexus]

To be clear: Performance is not the crucial factor for one or the other way. It will really take a lot until you reach the limits, and once you do so, the bottleneck will be somewhere else.

Much more important is clean code, as it will shrink the development, maintenance and debugging time dramatically. If you're used to old habits, you should probably read a current C++ book, maybe even one that deals with C++11. It's of great advantage to know the programming language well, as it will save you a lot of time and pain.

So please don't favor ancient techniques because you think they are faster (such assumptions are usually wrong), instead focus on writing code that will be easy to maintain and extend. Typically, optimizations are then also simpler to achieve.

[Hanmac]

hm about Texture and BigTexture, exist a way to check if an Texture is to big to be an normal Texture from inside the program?
and wouldn't be some kind of TextureInterface/SpriteInterface class would be more nice for the programmers?

[Ixrec]

I believe the static function Texture::getMaximumSize() answers your first question.

Edit: The API documentation also gives this hint:

This maximum size is defined by the graphics driver. You can expect a value of 512 pixels for low-end graphics card, and up to 8192 pixels or more for newer hardware.

[Nexus]

and wouldn't be some kind of TextureInterface/SpriteInterface class would be more nice for the programmers?

What would it look like? Or how would it differ from thor::BigTexture and thor::BigSprite (see link in my first answer)?

[Hanmac]

and wouldn't be some kind of TextureInterface/SpriteInterface class would be more nice for the programmers?

What would it look like? Or how would it differ from thor::BigTexture and thor::BigSprite (see link in my first answer)?

if you compare them you will see that they are a bit different but not the same (some functions from Texture are missing in BigTexture, and some setter does not have corresponding getter methods), and i wanted to use something that automatically uses BigTexture if the Texture you want to use is to big ...

[dpixel]

To be clear: Performance is not the crucial factor for one or the other way. It will really take a lot until you reach the limits, and once you do so, the bottleneck will be somewhere else.

Much more important is clean code, as it will shrink the development, maintenance and debugging time dramatically. If you're used to old habits, you should probably read a current C++ book, maybe even one that deals with C++11. It's of great advantage to know the programming language well, as it will save you a lot of time and pain.

So please don't favor ancient techniques because you think they are faster (such assumptions are usually wrong), instead focus on writing code that will be easy to maintain and extend. Typically, optimizations are then also simpler to achieve.

To be honest, I've just started learning c++ about 6 months ago.  I've always wanted to, but thought the learning curve was too steep for me.  My programming experience goes back 20+ years though, with languages such as vb, pascal, etc.  And then to my surprise, c++ wasn't that hard after all.  And paired with a graphics library, I was able to do pretty much anything I wanted.  Plus the internet is a world of information I never had years ago.
I know my code isn't  modern by todays standards, but I still have fun making my little games.
And because oop is a new concept to me and I'm not one to ask a lot of questions, I tough it out in other ways.   Old dog new tricks syndrome.   
I do need to understand more concepts of oop, but I'd be asking 50 stupid questions on here before I finally get it...lol

[Nexus]

if you compare them you will see that they are a bit different but not the same (some functions from Texture are missing in BigTexture, and some setter does not have corresponding getter methods), and i wanted to use something that automatically uses BigTexture if the Texture you want to use is to big ...

I'm not sure if it's possible to have exactly the same API for normal and big textures, because of technical limitations.

E.g. setRepeated() is simple for sf::Texture: You pass the flag GL_REPEAT at texture creation, and OpenGL handles everything. thor::BigTexture would require to modulo the texture rect every time a thor::BigSprite is rendered, and choose the (up to infinite) correct sprites to display the desired rectangle. It would not only lead to a mess of an implementation, but be quite inefficient...

I do need to understand more concepts of oop, but I'd be asking 50 stupid questions on here before I finally get it...lol

Then be prepared to hear "Learn C++ first" again and again

On a serious note, there are tons of people like you: They know other languages, learn the bare bones of C++ and think that's enough. It is not, C++ is one of the most complex programming languages; it has many specific language features, rules and exceptions, and even more pitfalls. It is crucial to not only learn the basics, but also the paradigms, idioms and best practices. Of course it's possible to write simple games with easy-to-use libraries like SFML and without greater knowledge, but as soon as you want to develop something bigger with greater requirements regarding robustness, efficiency, maintenance, you'll be very glad about deeper C++ knowledge. The mistake people make is thinking they can save time by skipping advanced topics; eventually it will cost them triple the time to develop, maintain and debug ancient code -- additionally, it's a very frustrating experience.

I don't want to discourage you, but you should be aware of the complexity and not underestimate C++. If you just want to develop some simple games, one option would also be a simpler language. SFML has bindings for many programming languages.

[dpixel]

I'm aware of the complexities of c++.  This is why I held off learning it for so long.
What I liked right of the bat was how it kind of forces me to write cleaner code.  I wasn't expecting that.  If that makes any sense.
But, I do find myself chasing my tail when adding features to my programs, which I believe is some of what you were getting at.

Stupid Q #1:
Back to the sprite thing.  Is it normal to have 100's of sprites in a graphically intensive game? (All with their x, y, h, w sources set of course)
I'm writing a platformer zombie shooter/adventure thing.  I have 3 different zombie explosions of 14 frames each.  Would that be 42 sprites?  Plus all the other 100+ frames of other stuff.