I don't know of any intricacies Cobra has in this kind of thing, as I don't use it myself, but I don't see anything glaringly obviously wrong here. The only thing I can thing is all those nested for loops, but those seem rather necessary.

Have you tried putting a timer on every stage of the code to see which bits are slowest, rather than just timing the whole thing?

The simple problem is that you are performing too much drawing. You are iterating over the whole screen, multiple times, performing lots of calls.

So my first suggestion is to use a hardware accelerated graphics library, either with Cobra or something else. A 10 year old graphics card can trivially draw 1000 2D images to the screen, so there is no reason why all these calls should be slowing you down.

But if that is not attractive, here is an alternative 'dirty rectangle' approach. You split the screen into a series of off-screen buffers or images. This means the screen is made up of 4, 16, or more 'big tiles'.

You render your world map to these big tiles, and then render the big tiles to the screen. The advantage is that if the contents of a big tile has not changed, then you don't draw to redraw it. If it's contents does change, then your only redrawing a quarter (or less) of the screen.

Now lets say you scroll the world to the left, how is that handled? First move all big tiles to the left, and now you've correctly scrolled about 80% of the map. You then add new big tiles on to the right hand side, and redraw the new section of the world to those new big tiles.

Any big tile that are no longer visible can be removed. You could also cache these, and re-use them later for your new tiles that scroll on to the screen.

If a tile is animated then you will have to clear a section of the big-tiles, and redraw that whole section. What size should be based on if the tile overlaps other tiles, and if it's surrounding tiles overlap more tiles. All of the tiles affected will need to be cleared, and then redrawn.

If a tile does not overlap a surrounding tile, then it only needs to clear and redraw it's self.

Other game elements, like characters and background, can just be rendered before and after the big tiles are drawn to the screen. They don't need to be rendered to the big-tiles.

That technique should reduce the number of drawing calls from around 1000 to just 4 or 16 (depending on how many big tiles you have). That should make it _much_ faster, but incorrect code could reduce in sections not updating correctly.