The very slight overhead with virtual methods is because the program has to lookup the function in a vtable at run-time (every time the method is called using a pointer or reference). It's this very mechanism that allows inheritance and polymorphism. Nearly every language that supports these concepts will implement it in a similar way. It's nothing to be concerned about. It will almost never be a bottleneck in your code.

@J-Gamer: /me is writing an example program. It's nearly 500 lines and counting, but that initial overhead should be outweighed by the code reuse later on (in a real game, when there's many different types of objects to be drawn). I think all I should have to do now is A5 stuff (initializing A5, loading some bitmaps, etc.). Well, and then debug it.

I think the Speed game included in the latest Allegro 5 releases demonstrates well a situation where you render the same objects in different ways:

While the Speed game is pure C, it uses different "view" structures for rendering the same game objects.

I kept it all in one file to keep it simple on the forum, but I would put each class in its own header and source file for real. The actual main program stuff is hacked in and hard coded, but the polymorphic API is what matters anyway. Sadly, I have noticed one annoying shortcoming of my particular implementation. The player has dynamic dimensions. In order to retrieve them you need to query the current animation for the current frame, which requires the current animation to be set and started, and therefore requires game time as well. It's a little bit heavy doing all of that to determine the width and height, but one could always code static dimensions if they needed it to be cheaper/easier. The only reason I really needed it was to center the "player" on the screen for aesthetic reasons. I was able to get it done with prior knowledge anyway.

The code is pretty long. I counted 745 lines using wc. It's obviously a lot of overhead for what little it accomplishes in this simple example, but the code is reusable now. You can create n different types of objects that follow these same interfaces. It should save a lot of code, though you may find the interfaces need revision to deal with cases that I haven't accounted for.

The program mostly just dumps errors and exits if anything goes wrong, but it doesn't have to. It's built using RAII types and exception handling, so in theory it should be easy to handle errors gracefully (as can be seen in the drawing section of the main loop). I will say this: it's a lot easier to write this sort of code using Allegro 5 than it was with Allegro 4. Intern's Quest^[1] wasn't designed as well as this from the start (though I learned a lot from it that lead me to here). That aside, it was still a lot more difficult to write because of all of the global state in Allegro 4 that we had to try to wrap and work around. With Allegro 5 there's less global state to deal with, and the global state that you are stuck with is already neatly hidden beneath interfaces. If I wore hats I would take one of them off to honor the developers!

Teh Codez

(A.cc seems to be wrongly counting my post as 90 KB long, when in fact it's only 19 KB long, so I'm forced to attach the code and link to it instead of inlining it, which would have been a much more convenient way to read it IMHO, but I digress)

           (see below)

that --> al5polytut.tar.gz <-- that

            ^ this

The following QnD GNU Makefile was used during the development of this demonstration and could be used to build it given a compatible platform.

If you're on an incompatible platform then you'll just need to know how to compile a single C++ source file and link to the core of Allegro 5.

Meh. This is the way that I like to code. It's more fun for me, but then I've never finished a game... I also find it a lot easier to work with though. It's a lot less error prone because you're writing once instead of writing over and over again.

The code could still use revision, but I think it's a pretty good start. If anybody actually finds it useful enough to use directly in a game then I would appreciate a mention in any credits or whatever, but I'm not going to demand it.

Update: moving camera now so you can see it working.

When writing a class method, you don't need to use the this pointer to refer to data members, but you can if it helps you keep your code straight. You probably don't want to hardcode Buffer into your classes either, but use a parameter for the bitmap to draw to.

It counts the actual size of the post-processed contents, after its done transforming bb-code and <code> tags, and highlighting code causes the size to bloat up significantly.

My Solution:

This is the solution I liked...Suggestions will be very apreciate..
But I still have doubts...
I create a vector and doesnt work...

The compiler says that vector SpriteObjects has no member named length();
If I use .size(), .capacity(), it accepts....but not length()..
I use allegro 4.2 and DevC++...
Someone???

Ok..but when a put size it doesnt draw anything on screen...
Sorry if I am making a topic too long...
What is the problem with my logic??

Also: the code you're giving us shouldn't even compile...

masked_blit(Sprite[Object->GetImage()], Buffer, Object->GetFrame() * Object->GetW(); Object->GetStance() * Object->GetH(); Object->GetX() - Camera->GetX(); Object->GetY() - Camera->GetY(); Object->GetW(), Object->GetH());

I didn't know that... thanks
But I think it's still better to make them private, just for OOP's sake

I hope you don't think this is a dynamic array... You need to replace the x by a hard-coded number, OR you should make it a vector/list/deque/whatever to let it be able to have a costumable size.

What is this supposed to do? In this case, Object->GetImage should return the index in the Sprite array of the current sprite that should be drawn... This makes code from the object to change when the order of the sprites in the Sprite array changes...

When compiling, the compiler wants to know how much memory it should allocate for each instance of a class... this means that when using an array, it needs to know the size on beforehand. This way, you can't do this:

BITMAP *Sprite[11];
//then load all bitmaps
Sprite[0] = load_bitmap(.......);
...
...
...

In a constructor/initialisation function because the amount of bitmaps in the array sprite is set to x, for which the compiler will throw an error if it can't find an int called x that is already been given a value(it has to be global to do this, somebody please correct me if I'm wrong).

This means that the Object needs to know which location the image to be drawn has in the Sprite array(which is in another class)...

Thanks... I was wondering how you guys all do that :p
Edited the quotes in the previous message

Could somebody please explain to me why the getImage() function is a function returning an int and is part of the class cObject, while it is giving the index of an image in an array of the class cDrawManager?

This would mean the cObject class should be aware of the contents of the cDrawManager's Sprite array.