Eh...this seems to be a fun thing every programmer goes through...converting screen to world coordinates. It's always been a hastle trying to get it to work in my previous game projects. Sometimes I managed to get a hacked up version of it working, but this time I wanted to consult the cboard and see if I could gain any wisdom in the process.
It seems my game projects have finally gone full circle. I started out making an RTS using DirectX 3 years ago, then I scrapped it to work on a 2d side scrolling game, then I scrapped that to work on a 3d mech game, and then I scrapped that to work once again on an RTS. I have, however, learned much over the past 3 years and feel I can do much more with the RTS environment than I was able to do 3 years ago.
3 years ago I created a hacked up way of converting from screen to world coordinates, but it was messy, and sometimes got wrong answers, so I decided to come here before plunging into it.
I am using hotspots, per say. For example, if I have a tree, I have a hot spot for that tree sitting at the bottom of its trunk. That hot spot will be used in all calculations for finding the world coordinate of that tree.
I am also using an isometric tile system. In essence, tiles look like diamonds when sitting alone and not with any other tiles. Therefore, if it is any help in the end, essentially they can be cut into 4 right triangles.
So I need a fast, efficient, low-cost way to convert from screen coordinates to world coordinates. Let's say I have a swordsman walking across the map, for example. His world coordinate will need constant updating according to where he is on the screen.
The very first option that comes to mind is this:
Knowing the width of a tile, use division to calculate how many tiles over from the left of the screen the character is.
Use the same method to calculate how many tiles down the character is. The resulting two numbers is the world coordinate.
At first glance this would work, and this is the method I used 3 years ago in my very early RTS game, however, when looked deeper into, it would not work at all.
Reason is because if the map is any larger than the screen, once you move over far enough on the map you would lose the correct world coordinate. For example, if you move far enough to the right, the screen would end up scrolling right, and then you would lose the calculation.
One way around this is the blit the whole map to a temporary surface, and then using an SDL_Rect (I am using SDL) I could blit the appropriate part of the map on to the screen, yet I wouldn't lose the coordinates I need because the current x and y offsets would be stored in the rect. I could use those offsets to help in the world coordinate calculation.
Still, this method seems clunky and slow. That would be performing division operations every frame of animation...for every unit.
I could of course optimize it to only perform those operations once at the very beginning of the game for those units that do not move (trees, rocks, gold mines, etc.), and that would speed it up quite a lot.
But anyways, anyone have any enlightening information on converting screen coordinates to world coordinates?
[edit]
I have also thought about the possibility of basing everything in world coordinates instead of screen coordinates.
Then I would do world to screen conversions instead of screen to world conversions.
I dont think this would work, however. That would make it seem much more turn based and not real time, because moving from one world coordinate to another is a much bigger jump than moving from one screen coordinate to another.
[/edit]
