Image too large?

[Ixrec]

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.

[dpixel]

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.   

[Ixrec]

A method is simply a function that's in a class.  The term applies to OOP in any language.  Since Java requires that everything be a class all functions are automatically methods (to oversimplify it).

What methods you put in a zombie class depends entirely on how you want your game to work, but aside from the constructors (you'll read about those) some obvious possible candidates are draw(), setPosition(), setPatrolRoute(), takeDamage(), attackPlayer(), and maybe takeDamage() will call a private function like explode() if it discovers the zombie lost its last HP, etc etc.  And later on you might find yourself duplicating these functions in several enemy classes so instead you might make a base class called Enemy and have each class inherit from that.  We could go on and on.

By the way, Java's OOP really isn't that different from C++'s OOP, so you'll see a lot of other terminology that carries over.  The biggest differences I know of offhand is that Java adds Interfaces (in C++ terms these are like abstract classes with no concrete parts) because that provides a simple solution for multiple inheritance in the rare cases you need it, and C++ has a bunch of extra features Java doesn't like operator overloading and templated everything and god knows what else (and C++11 added even more!).  That probably sounds like gibberish now, but it'll make sense eventually.

[Nexus]

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

[dpixel]

Thanks.  I briefly touched on vector containers before for that very reason.  I will look into it more though.

The project I'm working on was actually supposed to be a learning tool, but it's turned into something I kind of like.  I'm a pixel artist as well and spend about half my time pixeling for this when I should be learning classes, etc.  I'm kind of a scatter brain, but I've accepted that.   

[dpixel]

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.   
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.

[Ixrec]

Yeah, trivial getters and setters tend to eat up a lot of space.  In theory you should only need to add those methods when getting or setting has some additional step (eg, checking the value is valid), and you can't simply make the members public or let the constructor handle it.  But in the real world it's best to add them early on so that all the code using this class won't need to be rewritten when you inevitably change how the class works internally.

With that said, it may be better to combine x and y into a single sf::Vector2i or std::pair<int,int>.

[dpixel]

Yeah, trivial getters and setters tend to eat up a lot of space.  In theory you should only need to add those methods when getting or setting has some additional step (eg, checking the value is valid), and you can't simply make the members public or let the constructor handle it.  But in the real world it's best to add them early on so that all the code using this class won't need to be rewritten when you inevitably change how the class works internally.

With that said, it may be better to combine x and y into a single sf::Vector2i or std::pair<int,int>.

This was just kind of a retrofit for the rest of the program.  Just to see how it would work.  I can start to see some possibilities tho.

Stupid Q #2:
Is it common for class methods to use other class methods or even plain old functions throughout the program.  Or are they generally self contained?

[Ixrec]

It's very common, and there's nothing wrong with it.

However, the class as a whole should be "self-contained" to some extent.  The idea behind putting functions into a class is so that you can exhaustively define all the operations the rest of program is allowed to perform on it, which makes it easy to debug/design the class separately from the code that uses it.