Top down games need animations too but it's simple just have a pImage pointer that will point to the correct frame

mytimer will be decreased by some timer function

My method for animation works like this: you declare an array of *BITMAPS, one for every frame, then a number in the object, like int frame; to say which array element to draw. It works really well with draw_sprite functions too!

Think of it like this: instead of moving the camera, you're moving the world.

draw_sprite(playerspr, screenbuffer, x, y);
Draw playerspr on the buffer at x,y.

scroll_x = 10, scroll_y = 0;
draw_sprite(playerspr, screenbuffer, x - scroll_x, y - scroll_y);

Draw playerspr at 10 pixels left of the previous position. This is equivalent to the "camera" moving 10 pixels to the right.

No shit Sherlock - that's exactly what the concept of a camera does.
Moving the world is, however, just what you're doing when you're transforming world space coordinates into screen space.

Trying to take into account what you both say, I tried almost all methods here.

The camera wasn't too easy, as I was unable to workout how to implement it in my game (and I found it hard for objects to keep to the cam co-ordinates).

The scroll_x and scroll_y seems to work quite well. I just keep the player fixed in the centre and force the scroll_y and scroll_x to implement depending on what direction the player moves. The only trouble here is the AI. But I suppose, as the code above states, using -scroll_x and -scroll_y for the X and Y for all code, I'm sure it can work, right?

Btw, does this thread get locked if I say the question has been answered?

Thanks for the link.

A lot of code there, but it does seem useful. (Btw, opened the exe. Looks good).

At the moment I intend to stay simple - at least to get an engine of some sort fully operational, complete with a sample level and graphics, etc.

I intend to create some AI that fire invisible rectangles, which are destroyed with a collision with a wall, and, when collide with a player, cause the AI to attack. Hopefully, it will work. Even if it is just for the sake of getting everything else working.

Let me take a shot at explaining the camera.

First of all, forget that there is such a thing as a screen. All your object coordinates are "world" coordinates, and can be whatever you want them to be - meters, feet, yards, miles, you name it. For a simple 2d game, you may choose pixels, but for clarity's sake, I'll use meters as an example. Implement all your game logic (object movement and interaction) using this "world" coordinate set. All positions, velocities, sizes, and whatnot, are stored as meters (or whichever unit you chose).

Now comes the drawing part (which, ideally, is separated from logic). To draw the scene, you need to transform "world" coordinates into "screen" coordinates, and the object that achieves this is a camera or camera transform. The camera must do two things: Scale, and translate. Let's assume you specify the camera position in world coordinates; then you'd start with translating. This is easy: Just subtract the camera position from each object's position:

x_trans = x - cam->x;
y_trans = y - cam->y;

Now for the scaling. You need to define a scaling factor for the world units you use, in other words, you need to know how many pixels one unit has. Let's assume 32 pixels per meter:

cam->scalefac = 32;

x_screen = (x - cam->x) * cam->scalefac;
y_screen = (y - cam->y) * cam->scalefac;

And finally, you want the camera location displayed at screen center, not top-left, so we'll add another translation to the mix:

cam->scalefac = 32;

x_screen = (x - cam->x) * cam->scalefac + SCREEN_W / 2;
y_screen = (y - cam->y) * cam->scalefac + SCREEN_H / 2;

There you go. If you happen to choose pixels for your units, the scale factor is 1, so you can then leave out the multiplication step.

I leave it as an exercise for you to reverse the translation (read: find the world coordinates for a given screen position).