How to calculate positions of holes in a game board?

I'm making a game with Python->PyGame->Albow and ran into a problem with board generation. However I'll try to explain the problem in a language agnostic way. I believe it's not related to python.

I've split the game board generation into several parts.

Part one generates the board holes.

Holes are contained in a list/array. Each hole object has a mapping of angles relating to other holes which are surrounding it, each of those holes also links back to it. (Sort of like HTML DOM siblings, the difference being any angle is possible)

A hole is something like:

开发者_开发技巧hole = {
    empty: True,
    links: {
        90: <other hole>,
        270: <another hole>,
        etc...
    }
}

Part two, calculate hole positions. The code is something like this.

def calculate_position(hole):
    for linked_hole in hole.links:
        if linked_hole.position == None:
            #calculate linked hole's position relative to this hole
            linked_hole.position = [position relative to first hole]
            calculate_position(linked_hole)

first_hole.position = (0, 0) #x, y
calculate_position( first_hole )

Part three, draw board.

Find the window height, expand the positions of holes (calculated in step two) to fit the window. Draw everything.

I believe that the problem is in step two I am calculating every hole relative to a previous hole. Rounding errors add up and the board goes squint shaped the further away from the starting hole the holes are and the bigger the board is. This only happens when making boards that aren't rectangular because otherwise there aren't rounding errors.

I am using simple trigonometry to calculate the relative positions of holes by converting the angle into radians and using built in sin/cos functions.

Any idea as to a solution or if I'm mistaken as to the problem is useful :)

PS: I will post the source code if it would help however feel it will clutter things up

Thanks for all the answers.

The people who said rounding probably wasn't going to be an issue were spot on. I had another look through the code with that in mind. I'm embarrassed to say I was generating the wrong angles in the first part of the board generation, the rendering part was correct.

I've marked Norman's answer as correct because it explains how to use a linear combination of vectors to solve the problem.

---

If hole positions are stored as integers, I don't doubt rounding error accumulates quickly enough to kill you. If hole positions are stored as floating point, and if you have an error of one unit in the last place (ULP) at each computation, I'm not quite sure how quickly error accumulates—but if error doubles at each step, then you have at most 53 links before even double-precision floating point would go wrong.

If you want to be rock-solid accurate, I would represent each position as a linear combination of vectors. You can represent each vector by its angle, and you have just a few angles, so you can represent the position of a hole as something like

Take six 30-degree steps and two 90-degree steps and four 180-degree steps

The numbers six, two, and four will be exact, and once you've computed all positions as vectors, you can then do the trig to convert to (x, y) coordinates all at one go. If you're worried about speed you can cache the arctangent of each angle and it will even be fast.

If this description is too terse, let me know.

---

The bit about accuracy becomes relatively important as soon as we realize these points are going to be converted to pixel coordinates, a.k.a. integers. Accumulate an error of 0.5 and bam! You're one pixel off.

So, either there is a huge problem with accuracy and rounding errors are climbing very very fast, or the source of the issue is elsewhere. I'm looking at this in step in particular:

expand the positions of holes (calculated in step two) to fit the window

Until I see a screenie, I'll assume "squint" means 'oval-kinda-sorta-thing'; sounds exactly what a bug in this step could produce.

---

I hate to be the one to suggest this, but, start in the the center. Also, you should look at your code and double check for an unfortunate conversion. The is, if a hole ends up at "138.2, 150.8", you need to keep the fractional parts until you have computed the next hole.