I'm writing a tile engine using Open layer

this is what I have thusfar

header

CPP

any advice ? speedup tips ?

It works?

yes it works

here is some working test from the map with some wacky AI code
use cursorkeys to scroll

Warning! The following are mostly stylistic issues, so read them with a grain of salt, don't get religious about it and ignore them at will.

Replace the magic numbers with named constants, like (camx+400), which I guess resembles (camx+SCREEN_W/2).

        if (n!=TI_NONE)
           {
               if (n<=tile.size()) tile[n-1]->Blit(DrawX, DrawY);
           }
        else
           {
             assert(false);
           }
        }

IMHO, that's improper use of assert.

Try to keep the lifespan of a variable as short as possible, meaning: limit its scope by declaring it only where you need it (and not at the top of the method body).

If you don't want camx or camy to be negative, declare them as unsigned int, and you can remove the checks if (camx < 0) etc.
(The same goes for m_nWidth).

Use consistent nomenclature. Sometimes you use Hungarian notation (m_nWidth), and sometimes you don't. I won't argue about which one to choose, just pick one and stick to it.

In your load method, use std::string.

Other than that, possible functional extensions:

• more layers

• arbitrary dimensions of tiles

• zooming in and out

• ...

if (n!=TI_NONE)
           {
               if (n<=tile.size()) tile[n-1]->Blit(DrawX, DrawY);
           }
        else
           {
             assert(false);
           }
        }

Yes, that would be a bad use of assert, especially considering assert doesn't exist if you compile without debugging enabled (-DNDEBUG on the compiler line), which should be done for all release executables.

This is a better, more appropriate use of assert:

assert(n!=TI_NONE);
if(n<=tile.size()) tile[n-1]->Blit(DrawX, DrawY);

This way, you have the same general effect when assertions are enabled (your program terminates with an assertion failed message). Additionally, you eliminate some unnecessary branches.

@Indeterminatus You've got a point there, I'll have to neat up my code anyway.
About that hungarian notation.. that's something I just learned.. I'm still getting used to it.

As some of you might ave noticed My sprites (units) can walk in any direction, but it makes AI a bit complicated. I thought it would be nice to combine a tilemap with vector AI ( since till now I only used vector AI) but maybe that is not a verry good idea... On the other hand It's fun if you can steer the player in a 2D game like you can in 3D games ( with mouse and WSAD )

what brings me to another subject.. aiming and shooting.. My NPC's really aim and fire a bullet but if you have only 8 directions... should you use a hit chance and just animate or ..?

Everything that Indeterminatus said.

If you want to improve your coding style, I thoroughly suggest reading Code Complete. I've read the second edition. You don't have to agree with every recommendation in the book, but it gets you thinking about writing readable and maintainable code.

As for Hungarian notation, I use it myself in C++. The only real problem is that it's not enforced (unless you know of an IDE that enforces it) so the compiler isn't going to complain if you don't use it properly or consistently. Also, Hungarian notated code isn't very readable to people that don't use the notation, but it is actually more readable to people that use the notation than 'regular' code. Another thing, you can extend Hungarian notation in any way you see fit. When I started playing with 3D, I used the 'mat' prefix for matrices. For example, m_matRotate would be a matrix that does some kind of rotation that belongs to an object. pmatRotate could be a matrix pointer passed in as a parameter. Enough about Hungarian notation though.

You also need to clean up your indenting style. For one thing, it's inconsistent. I see that you're placing your opening braces on a new line. That's a good start (in my opinion). You shouldn't indent the opening brace, because then it doesn't look like the code inside the braces belongs to its control structure. Also in some places, you're not indenting the code once it's inside the braces. Not good. Also, use one tab character per indent level instead of spaces. If your IDE is set to replace tabs with spaces, turn that setting off. ALWAYS use braces for if/else/while/do-while/for/etc. For one thing, it saves confusion (some of that confusion is caused by poor indenting) and it allows you to add more statements to the body if and when you need to (which happens quite often). What IDE are you using by the way?

Here's some code of yours, formatted nicely (take note of the added 'else's):

You could also do this to improve readability/maintainability/etc:

Personally I dislike the large amount of spaces (or spaces per tab) for that indentation style. I thought 2 characters in was supposed to be the optimum.

Thanks for your advice .

I use CodeBlocks, I also have MSVC but that one is not ANSI C++

there is for example no way to do this in MSVC:

and for some reason it does this wrong:

Allegro.cc forums use 8 spaces to represent a tab, even in the code areas. I used the TAB character there. I prefer four spaces to represent a tab, which is what most coders seem to use (and that's what MSVC and many other IDEs default to).

Ariesnl, are you using MSVC 6? It is pre-ANSI (although it tried to implement some ANSI features). You can get MSVC 2005 Express Edition free of charge. It's downloadable from MSDN.

The thing I liked about MSVC 6 is that it played the Microsoft Sound when you selected Help/About. But that was only on Win 95/98, before this XP orchestra crap.

Is that even possible to accomplish with a tile engine?

Well, I was thinking more along the lines of "don't limit a tile's size to 32x32".

It is possible, yes, you probably need an offset vector to place a tile on the map.

Example: The default tilesize is 32x32 pixels, and the grid is laid out accordingly (so that two neighbouring tiles, both 32x32 pixels match perfectly without overlap or gap). One tile's gfx is 16x16. If you don't want to scale it to 32x32 (which could wreak ugly artifacts), you can center it on a grid's cell by translating the tile by the vector (8, 8).

That most likely won't make any sense for the bottom layer (or you could end up having gaps between tiles), but it could be applicable for higher layers. Not telling that's the way to go, though, just pointing out it's possible, even though that's not what I meant originally.

edit: Rewrote most of my post to clarify point.

For the game logic, the tile is still 32x32. You won't be able to put 16 8x8-tiles in the space of one 32x32-tile using a conventional tile grid.