Comment calculer les positions des trous dans un plateau de jeu?

Question

Je fais un jeu avec Python-> PyGame-> Albow et j'ai rencontré un problème avec la génération de cartes. Cependant, je vais essayer d'expliquer le problème de manière agnostique. Je crois que ce n'est pas lié à python. J'ai divisé la génération de la carte de jeu en plusieurs parties.

La première partie génère les trous de carte.

Les trous sont contenus dans une liste/tableau. Chaque objet de trou a une cartographie des angles relatifs aux autres trous qui l'entourent, chacun de ces trous s'y rattache également. (Un peu comme les frères et sœurs HTML DOM, la différence étant un angle quelconque est possible)

Un trou est quelque chose comme:

hole = { 
    empty: True, 
    links: { 
     90: <other hole>, 
     270: <another hole>, 
     etc... 
    } 
} 

deuxième partie, calculer les positions des trous. Le code est quelque chose comme ça.

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) 

La troisième partie, au tirage bord.

Trouvez la hauteur de la fenêtre, développez les positions des trous (calculées à l'étape deux) pour s'adapter à la fenêtre. Dessine tout.

Je crois que le problème est à l'étape deux Je calcule chaque trou par rapport à un trou précédent. Les erreurs d'arrondi s'additionnent et la planche devient en forme de louchet au fur et à mesure que le trou de départ est plus éloigné des trous et plus la planche est grande. Cela se produit uniquement lors de la création de cartes qui ne sont pas rectangulaires, car il n'y a pas d'erreurs d'arrondi. J'utilise la trigonométrie simple pour calculer les positions relatives des trous en convertissant l'angle en radians et en utilisant des fonctions intégrées sin/cos.

Toute idée à une solution ou si je me trompe à ce problème est utile :)

PS: Je vais poster le code source si elle aidera à se sentir mais il va encombrer les choses

Merci pour toutes les réponses.

Les personnes qui ont dit arrondir probablement n'allait pas être un problème étaient sur place. J'ai eu un autre coup d'oeil à travers le code dans cet esprit. Je suis gêné de dire que je produisais les mauvais angles dans la première partie de la génération de la planche, la partie de rendu était correcte.

J'ai indiqué que la réponse de Norman était correcte car elle explique comment utiliser une combinaison linéaire de vecteurs pour résoudre le problème.

Answer 1

Si les positions de trous sont stockées comme entiers, je ne doute pas que l'erreur d'arrondi s'accumule assez rapidement pour vous tuer. Si les positions des trous sont stockées en tant que virgule flottante, et si vous avez une erreur d'une unité à la dernière place (ULP) à chaque calcul, je ne suis pas sûr de la rapidité de l'erreur — mais si l'erreur double à chaque étape, alors vous avoir au plus 53 liens avant même que le virgule flottante à double précision ne tourne mal.

Si vous voulez être précis comme du roc, représente chaque position comme une combinaison linéaire de vecteurs. Vous pouvez représenter chaque vecteur par son angle, et vous avez juste quelques angles, ainsi vous pouvez représenter la position d'un trou comme quelque chose comme

Prendre six étapes de 30 degrés et deux pas de 90 degrés et quatre 180 -degré étapes

les numéros six, deux et quatre seront exacte, et une fois que vous avez calculé toutes les positions en tant que vecteurs, vous pouvez alors faire l'TRIG pour convertir en (x, y) coordonne l'ensemble en une fois. Si vous êtes inquiet au sujet de la vitesse, vous pouvez mettre en cache l'arc tangente de chaque angle et ce sera même rapide.

Si cette description est trop laconique, faites le moi savoir.

Answer 2

Le bit sur la précision devient relativement important dès que nous réalisons que ces points vont être convertis en coordonnées de pixels, c'est-à-dire en nombres entiers. Accumuler une erreur de 0.5 et bam! Vous êtes un pixel désactivé. Donc, soit il y a un énorme problème de précision et les erreurs d'arrondi grimpent très très vite, ou la source du problème est ailleurs.Je regarde cette étape en particulier:

les positions de élargir les trous (calculés à l'étape deux) pour adapter à la fenêtre

Jusqu'à ce que je vois un screenie, je suppose « plisser les yeux "signifie" ovale-kinda-sorta-chose "; sonne exactement ce qu'un bogue dans cette étape pourrait produire.

Answer 3

Je déteste être le seul à suggérer cela, mais, commencer dans le centre. En outre, vous devriez regarder votre code et vérifier une mauvaise conversion. Le est, si un trou se termine à "138,2, 150,8", vous devez garder les parties fractionnaires jusqu'à ce que vous ayez calculé le trou suivant.