What you are proposing is pretty much the fastest; as determining wether or not you are on the same tile would probably be more costly than just doing it. Doing it 9 times.
But as an alternative; consider if you will a space/time tradeoff.
Instead of doing this calculations at a critical time, do them when you are reading the map into memory; storing in each tile the location of their neighbours. It requires more space in memory per tile; but it does save time when doing lookups. If you have an application-wide enum (or similar) for directions, even better; then you could do something like:
aNeighboringTile = current.neighbors[NORTH];
The tradeoff can be tuned to use either cardinal neighbours only, or both cardinal and diagonal neighbours; the former being tighter and the latter being faster.
A question that you seriously need to consider, of course, is wether or not this is actually necessary, or if your current approach in practice is fast enough.
If you are already facing slowdowns due to the extra calculation; then it is likely that the only thing that will give any speedup is pre-calculating neighbors.
Edit: This can of course be compined with Gajet's suggestion to use a constant array of the index deltas to search to eliminate the extra calculations during generation/loading.
point ad[8]that has values {{-1,-1},{-1,0},{-1,1},{0,1},{1,1},{1,0},{1,-1},{0,-1}}. then just use one for loop from 1 to 8 to checkTiles[x+ad[i].x][y+ad[i].y]. it'll eliminate that one calculate you are trying to avoid. – Gajoo May 28 '11 at 18:36||, it could however be reduced tox || y. – eBusiness May 29 '11 at 0:36(x != 0 || y != 0)=>(x || y), that seems pretty basic to me, both code pieces will return 1 for every case but x=0, y=0. – eBusiness May 29 '11 at 23:45