views:

128

answers:

4

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.

A: 

Without source code and/or output examples, it would be very hard to answer (e.g. your implementation could be at fault). But note that trigonometric functions are less safe in terms of error when near multiples of 90 degrees. If you really think your problem is rounding - you may want to try to use a different level of accuracy and see if that gives you any effect.

Ofir
A: 

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.

badp
+1  A: 
Norman Ramsey
A: 

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.

Charles Merriam