I think that J-Gamer starting giving one suggestion and ended up giving a better one. Ignore the part about the draw method. Game objects generally shouldn't know how to draw themselves (they should have no concept of a screen, etc.). A third-party, like the Renderer concept should know how to draw all objects. It's the getSprite or getFrame method that you'll want to be virtual (and likely abstract AKA pure virtual) in the base class.

Well, at least you were able to identify that your code looks ugly. That's an important step. Now you just need a decade or so of experience and you might be able to write some decent code.

You're mixing up two concepts here... You can do it by putting a virtual draw function in the cObject class, and making all classes like player,hud,enemy,... members of it with their own non-virtual draw that draws them. OR, you can have a cRenderer class draw function that checks all Objects for their type and draws them accordingly. In the latter, you have all drawing code in the cRenderer class, whereas in the former, you have the corresponding drawing code specified in each of the classes.

Most of the time: which of the bitmaps in the different sequences are drawn.

I have e.g.: a flying mode, propulsion mode, explosion mode, vanish mode, etc.
For the flying mode, nothing special, just a plain spaceship sprite.
Propulsion mode: increase frame, draw corresponding bitmap in the propulsion sequence
Explosion: idem as propulsion, except it doesn't loop trough the sequence.
vanish mode: get smaller and smaller, according to the frame(amount of frames is set beforehand)

I remember about 15 years ago when I first got started into game coding (at that point I thought there was something magical and complicated about how you display moving things, not knowing it was just a case of blanking the screen and drawing stuff elsewhere), I wondered whether when a player picked up an item and moved with it, whether I had to have a graphic with the player and the item and thought this will take a lot of graphics

That might be what it sounds like, but in actuality it's simplifying the design instead of complicating it. Instead of making 20 different redundant calls to blit or al_draw_bitmap or whatever, you make one (or a handful) and everything else just works the same way. Your objects have a visual state and another external class knows how to draw that state (but knows nothing of specific types, like spaceships or moonmen or whathaveyou). It's actually a lot simpler of a design, but it requires a bit of forethought.

It's more complicated language-wise because you need to understand polymorphism, but the solution is simpler than redundantly duplicating the same basic logic over and over again. IIRC, the OP said he was knowledgeable in C++. At least, he seems comfortable enough to be introduced to/reminded of polymorphism and its benefits.

You don't need design patterns to use polymorphism, and there aren't any design patterns being used here...

All it is is inheritance, to replicate an interface for different classes, so they can be used interchangeably through a base class pointer.

Good use of polymorphism as I said above helps you with loose coupling. What's worse - having a bit of thought before you write your code, or turning your code into spaghetti within a few weeks with either 30 case statements in a method or 10 methods that do the same thing but slightly different and having to remember what they all are?

I agree design patterns can be bad in the wrong hands and they do over-complicate things, but where it's relevant it makes things better. For example, most people end up coding using the Strategy, Adapter and Facade pattern without even realising it.

if you have sprites then a good idea is to let the renderer class handle it.just make a spriteholder class(basically a class with a map/list/vector<string,Sprite*> of all the Sprites in your level or even the whole game though it's not advised) and whenever you instantiate a sprite you register it(insert it) in the sprite holder('s map/list/vector).so in the game loop the first thing you do is call the renderer and have it blit everything visible on the screen and afterward do every other calculation to change the state of the game,player,character etc so that in the next loop the renderer has all the updated info on the sprites including the new destination point and possibly another frame of the same film.

i'm currently taking a course in my uni for 2D bitmapped games and this is the way we are doing it.it's simple enough imo.then again it might not fit in this situation,i didn't really see the code but it's a good concept to know.and you don't need to implement any design patterns.

you have to have priority given one way or the other if you want your characters to be able to go behind graphics as well.
this is called z-ordering.where each priority value represents something like a layer of graphics.where the layer with the lowest priority is the background,the next priority is anything else static or not that you always want your character or other characters to pass in front of,then it's your player's character with any other characters/enemies and stuff and then the highest priority is the layer with all graphics that you want your character or others to pass behind of.this is just an example nothing more.you can have more or less layers depending on what you want to do.

and principally Audric's solution is the same as what i said.

overhead is a term to describe the excess work that the CPU or any other part of the pc has to do when given a difficult task.for example if you call too many functions then you get an overhead in the call stack.you make too many records of function calls when you could have made less to attain the same goal.another example of overhead is polling.before interrupts where implemented the CPU had to poll the hard disk to see if a transaction had ended thus having to queue many other processes and perform context switches all the time just to make sure the transaction of a data transfer was completed.then interrupts came and then DMA.when a data transfer needs to be done it is approved and started and then DMA manages it until it's finished without having the CPU involved.

And virtual functions cause a little overhead because every object uses late binding to determine which function to use,that of the super class or the derived.but i don't think it's such an overhead to even be mentioned.i mean with today's hardware and all the object oriented programs in c++ lying around and very often well known ones at that you can see it doesn't pose a problem.