I am having some issues with trying to detect collision of two isometric tile.
I have tried plotting the lines between each point on the tile and then checking for line intercepts however that didn't work (probably due to incorrect formula)
After looking into this for awhile today I believe I am thinking to much into it and there must be a easier way.
I am not looking for code just some advise on the best way to achieve detection of overlap
I'll come straight out and say that I don't know how to solve the problem you have described in the question (collision detection between iso-tile-shaped rectangles), but I can tell you how others have solved it in the past:
The way it's done in other games is to separate the game world from the screen world. When you're starting out, it common to imagine them being the same thing, but then it leads to problems like the one you're describing.
The general idea is that the game world is stored completely in memory, behind the scenes, it's just numbers, references, and logic. The fact that you are drawing the game world in isometric is irrelevant. Your game world shouldn't have the concept of isometric, or square, or even if the screen is being draw as 3D. All of that is taken care of when you draw the game world to the screen (aka the screen world). The game world should be stored and maintained in the simplest way that makes sense for the game, in isometric games, you typically completely ignore the fact that it's iso and instead store the positions as if you were using an axis-aligned grid. Most games will have methods for converting coordinates between the two worlds, I call mine ScreenToWorld(x, y) and WorldToScreen(x, y). The conversion is often done with Matrix math, but can be achieved other ways. You'll use ScreenToWorld when you use the mouse, and WorldToScreen when you draw.
There are several advantages to splitting the game world and the screen world. One of the advantages is that collision detection and movement all happens in the game world, and is therefore usually quite straight forward because you're not dealing with a slanted grid, or skewed coordinates, or where the screen is, etc. In your case, you'd be dealing with axis-aligned rectangles and squares. Once the game world has been updated, then you draw a representation of the game world to the screen, keyword: representation. It may seem counter-intuitive at first, but your screen is only a representation of what's going on in the game world. This makes things like dedicated servers and terminal-like clients possible.
FreeCiv is actually a great example of all these things. You can view the same exact world as any of: a square North/South Grid, Isometric, or even Hex. Every game you run has a dedicated server running in the background, even for single-player games, therefore the client is also just a display port, nothing more.
Long story short: Separating the game world and logic from the screen world simplifies the game logic, reduces the game<->display coupling, and in turn, makes collision detection between "iso" tiles easier to handle and easier to visualize.
John's answer is quite right, but I will try to explain it in a different way:
There IS no isometric collision detection.
Collision detection does not care what your projection matrix / transformation looks like. Collision detection should not matter if you render things at all (after all, objects which are off the screen can still collide, right?)
It is a more philosophical question: Does a tree falling down in a forest still actually collide with the ground when there's nobody there?
Conventional wisdom would say: Yes. It doesn't matter how you look at it. Things collide in world-space, not view-space.
You can try allocating an array of pixels composing a bitmap of each getRGB() values of each individual pixel. Than compare the values with an if statement as the borders of the tile are a separate color value than that of what the tile represents(water, sand, grass). That for a basic isometric grid. Or you can have two layers of the map itself. One layer containing sort of like a green screen drawing the outline of each representative of an colliding object and the other layer will be the map itself.
You not composing a bitmap array of each pixel of the map layer instead you want to calculate a set of colors representing the effects it has when an object collides / intersects the border of the maintaining color value. Either you want values to decrease in value or increase of velocity in which the object is moving. Each object that moves is just a duplicate of memory stored in a different spot.
I would look into pixel perfect collision and the understanding of bitmap arrays. Each rectangle is a bounds of containing replicating data sort of like imprinted memory each event is triggered depending on where a object is rendered in a location or vector. Every point on the screen is on a 2D plane only that the depth of shadow providing an illusion that the object represents itself as 3D. Transformation of shapes in a skew give it sense the object is at an angle. There is a center point of where the camera presents it view everything is carried around this center point moving away from it decreasing in size or moving closer to it increasing in size.
