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);
}
Yes it's normal to have hundreds of sprites. The sprite class itself is very lightweight, since it essentially just stores some information like position and rotation to be used when drawing the underlying texture. The texture is the expensive part.
For a fixed animation like a 14 frame explosion, I believe the right way to do it is put all 14 frames in one texture, and change the sprite's textureRect every frame (using setTextureRect()). I don't think there's much point in multiple sprites, not for performance reasons, but because it's more intuitive and logical to have one sprite changing each frame than 14 sprites you cycle through.
Of course it may be even better to put all your zombie related images in a single big texture and have for example one row with frames for the walking animation, one row for the idle animation, one row for each of your explosion animations, and so on. In the long run you'd probably abstract all this into a Zombie class with methods like startExploding(), so that only the Zombie class itself has to worry about exactly what textureRect to use every frame.
Thank you for this explanation. This clears some things up for me.
I should really start experimenting with classes. I understand how they are assembled, but it's the real world application part I don't quite get yet. Right now I use this:
struct undead{
bool alive;
int state;
int x;
int y;
int direction;
int animation;
int zombienumber;
int instruction_set;
int counter;
int old_count;
int explosion;
} zombie[400];
Which could be part of a class public part.
And when did they start calling functions, methods? I thought that was a java thing. :P
Also, instead of arrays with an arbitrary size (in your case 400), you can take STL containers such as std::vector, which are able to grow dynamically.
std::vector<undead> zombies;
zombies.push_back( undead(...) ); // insert new zombie
The STL is probably the most important and most often used part of the C++ standard library, you should definitely have a look at it :)
After all this talk about oop and classes. I created one. As well as shooting, my player can throw bombs.
I used to have:
struct bomb1{
int x;
int y;
bool available;
} bomb[99];
And now I have:
class BombClass{
public:
void setX(int X){
x = X;
}
void setY(int Y){
y = Y;
}
int getX(){
return x;
}
int getY(){
return y;
}
void setAvailable(bool a){
available = a;
}
bool getAvailable(){
return available;
}
private:
int x;
int y;
bool available;
};
BombClass bomb[99];
And it all works. :D
It seems like a lot of lines of code for what it does, but I had to start small and start somewhere.
Thanks for all the motivation and inspiration.