So the notorious book that I've been reading for working with Allegro presents its sprite handler as a struct. Since C++ seems to be more in line with what's being used in the "industry" nowadays, I wanted to construct a class for my sprite handler. I've run into some problems though; the main one being that when I attempt to draw_sprite() to make sure it's being loaded, I get the following compile error:

base operand of `->' has non-pointer type `Sprite'

Here's the code in my program:

Can someone help me find the problem?

Change Sprite foo("tank.bmp"); to Sprite *foo = new Sprite("tank.bmp");, remove allegro_exit (you don't need it), and add delete foo; before returning from main.

Thanks, Kitty Cat. Figured it was something simple. Always is.

Actually, he could have replaced the -> with a period, like

draw_sprite(screen, foo.sprite_img, 200, 200);

Allthough the new/delete is to prefer and should be a habit.
It is okay to declare/create a class like he did in the first place, but it will only be available in the scope of that function.

He could, but placing objects on the stack like that is considered bad form. And later on if he makes it a global, he shouldn't construct it before he's in a graphics mode so he'd need to wait to create it anyway.

I know, I was just saying he could with the code provided

Appreciate all the responses guys!

I've actually advanced my code a little bit, but have now hit another wall. As you saw in my previous code, I was using a class as a sprite-handler. Once Kitty Cat helped me iron out that bug, it worked like a charm, and I even updated my code to the point of being able to move the sprite around, complete with direction changes. But now I want to animate it, and I'm kind of stuck.

With the code I have, I'm calling load_bitmap() each time the class is instantiated, but on that same token, every additional sprite is another object. So I'm kind of stuck as to how to modify my class to do what I need.

I thought about perhaps storing multiple frames per instance, maybe in some sort of container like a vector, but I'm just not sure exactly how to do it. Can any of you guys help me out on this?

(again, I apologize for my blatant newbie-ness!)

Edit: I actually did some tinkering and figured out how to store my multiple frames in a vector. It probably sound corny to the vets here, but I'm quite proud of my accomplishment!

Now I have a new problem... Animation... Given my code, does anyone have a suggestion as to how I could animate my sprite? I tried to do it with a for loop and a rest() call, but when I apply it to all directions, it slows the sprite's movement to a crawl and doesn't seem to animate properly.

Here's my code:

You basically have two choices, each has its own merits and drawbacks. You can either use multiple images, blitting the appropriate one at the appropriate time, or you can gather them all together into a single sheet, and blit the portion of the image that contains the correct frame.

Regardless of which one you choose, you need a more sophisticated object, one that defines a number of frames that your game can pick from. If you're like me and prefer a data-driven design, you can store all that information in a separate file and build a loader into your sprite class; that's a lot more flexible, and allows a game designer (if you have one) to create sprites without your intervention. However, if you're all alone and embedding the data into your code doesn't bother you, continue doing what you're doing, except load up several images into a single sprite - perhaps with a variable argument list:

Would using multiple, small sprites really have that adverse of an effect on animation though? What I've found is if I pull out the animation entirely, the program moves just fine. Once I put the animation in, it cuts the speed by half. The only other thing I tried was removing a call to "clear_bitmap()" following my blit() where I sent the buffer I'm updating to the screen, but without doing clear_bitmap(), I get copious amounts of artifacting (looks like my character has a motion trail).

Also, what does the ** mean in the code example you presented? I know a single * denotes a pointer, so what does the double-dose mean?

And any suggestions/comments on my animation issues?

It wouldn't have an adverse effect whatsoever - I just wouldn't personally do it that way. That's just me. If using an animation is cutting your speed in half, though, you're doing something wrong (maybe doing it twice).

It's a pointer to a pointer. If you're not very familiar with pointers, you need to get familiar with them very soon. If you have an array of objects (or anything else), and you don't know how large that array will be, you have to use a dynamic array.

So this:
int fixed[10];
becomes this:
int *dynamic = (int *)malloc(10 * sizeof(int));

That works for primitive types, but a BITMAP must be referred to with a pointer to begin with, since that single object itself is created dynamically (plus you don't want it to go out of scope and disappear). But because you potentially need more than one, you point to pointers.

So this:
BITMAP *fixed[10];
dynamic[0] = load_bitmap("bitmap0.bmp", NULL);
dynamic[1] = load_bitmap("bitmap1.bmp", NULL);
...
becomes this:

BITMAP **dynamic = (BITMAP **)malloc(10 * sizeof(BITMAP *));
dynamic[0] = load_bitmap("bitmap0.bmp", NULL);
dynamic[1] = load_bitmap("bitmap1.bmp", NULL);
...

Obviously I'm oversimplifying and throwing out error checking, but that's the gist of it. This is really, really fundamental. If you don't fully understand pointers you'll run into trouble very quickly. Find some tutorials, buy a copy of K&R, do whatever you have to do, but you definitely need to be very comfortable with this sort of construction.

All of what you're saying makes sense, but it doesn't seem like any of it would affect the speed of my program's execution. Would a pointer to a pointer really be faster than accessing a vector element like I am now?

If you could offer some suggestions for changes to my code, it would be much appreciated. I feel like I'm asking you to solve my problem, but that isn't my intention. I just catch onto concepts better when they're shown in context.

Here's the source below. A lot of the stuff I tried to fix my problem (to no avail) is still in there, just commented out (like using a rectfill instead of clear_bitmap):

Also, I know my animation process is kind of Frankenstein'ed... Any suggestions on a good tutorial for doing animation that preferably deals with their sprites as a class?

This suggestion may not be what you looking for, but this is what I have ended up doing in my project.

If you want to go OOP simply create a class for everything. So you would end up having a class for Frames, Animation, AnimationMgr, Objects, Tiles, Sprites, etc.

Think of this way, Tiles and Sprites are different, but they share common attributes and functions. Therefore, create an Object class and derive from it Tile and Sprite.

Object class would have an Animation Manager that could contain more then one animation. After all, a sprite would have a number of animations, such as waling, shooting, dying, etc. Tiles can also have multiple animations based on the events.
The Animation Manager (like the name says) manages animations. The Animation class only worries abut frames that build up this animation. While frame class contains the information in regards to a frame.

Frame could have an ID, Name, Delay, Counter, BITMAP
Animation then can have a list or an array of frames, current frame, etc.
Animation Manager can have a list of animations, current animation, etc.
Object has Animation Manager, along with other attributes.
Tile inherits Object class and implements its own attributes and functions.
Sprite, just like a Tile class does the same thing with a difference of its own needs.

From that you can then derive a Player class, Enemy, or whatever else you may need. Best of all, each derived object will be able to handle animations just like any other object.
If you feel that some of the Objects will not be in need for an animation, then all you do is create a single Animation with a single frame and that is it.

I get what you're saying... I think really my major problem is figuring out how to make part a relate to part b, and for part c to use part b when necessary. I have experience with OOP, though limited, but my biggest hurdle currently is my main source (in terms of reference material) is loaded with questionable practices. So I've been doing code my own way, in a manner of speaking, as not to duplicate the author's mistakes; instead, I'm making a lot of my own.

The best example I can give is my issue with doing animations. I've still yet to find a straight forward tutorial anywhere online.

Not to mention I am baffled by the performance hit between when I have my animation running (though messy in execution) and when my sprites are static and don't animate. From what I can tell about my code, I'm not breaking any major rules of programming, so such a hit in performance shouldn't be happening... But again, it just illustrates my inexperience in the matter, and a lack of a direct mentor doesn't help.

Game Programming All In One 2e? Me too. I recall it saying that the rotate and fliping algorithisms are long and complex. Maybe you should create all of the images at runtime, and then draw_sprite the right one. Use more of his code, it works. The BITMAP array that holds animations actually works. If you want, I'll post my sprite handler, also a class, but closer to what the book said.