Calculer les coordonnées des coins d'un rectangle - Page 1

Hello les gens.

En Objective-C j'aimerais calculer les coordonnées des 4 points définissant les coins d'un rectangle.
En sachant que j'ai un CGRect( x, y, width, height) son anchor point (en plein milieu, centré en H/V, c'est mon x et y du CGRect).

Je peux également récupérer le minX/minY et maxX/maxY de mon CGRect a tout moment.
Sauf que le truc, c'est que mon CGRect tourne sur lui meme en permanence, ce qui fait que je peux pas utiliser les minX/minY + width & height pour calculer les coordonnées de mes 4 coins.

Pour un infos c'est la création de la bounding box pour un portage de Kuru Kuru Kururin GBA.

Quelqu'un aurais une petite idée ?

...je vais faire un dessins....

Tu connais l'angle de rotation de ton rectangle ?
Sinon, on peut le retrouver avec ce que tu connais, mais avec une ambiguïté de pi/2...

C'est plus une question de maths ou de prog ?
Autrement dit, tu saurais le calculer à la main mais tu te demandes si ça n'est pas déjà implémenté, ou il te faut de l'aide pour le calcul ?

C'est plus du coté math en fait que ca coince.


L'angle de rotation oué je le connais, parce que c'est moi qui le set.
Donc le but c'est pour faire une détection de collision avec les coins de mon rectangle, a la place de savoir si mon rectangle collide avec un autre rectangle seulement.

Donc ce que je connais :

Angle de rotation.
Anchor point (x & y du rectangle situé a l'intersection des 2 diagonale de celui-ci (donc centré en H/V).
Width & Height aussi, c'est la taille de mon image (bounding box).

Donc avec ca, je possède un CGRect(x, y, width, height)
Ce que je peux aussi avoir : CGRectGetMinX / CGRectGetMinY / CGRectGetMaxX / CGRectGetMaxY


Voici une toff :



Dans le but de faire ca (zappez a 00:35):

http://www.youtube.com/watch?v=yuGYk106PDI

Pour le point du haut, X = maxX - cos(angle) * Width.
Pour le point de gauche, Y = maxY - cos(angle) * Height.

Pour les autres points, c'est pareil avec des min au lieu des max et des plus au lieu des moins

Bien sûr, c'est à adapter pour chaque quart de cercle

oh yeah, thx ^_^ je vais tenter ca.

c'est rigolo comme jeu.

il devrait pouvoir t'aider

Pour la réponse de RHJPP :

RHJPP (./5) :
Pour le point du haut, X = maxX - cos(angle) * Width.
Pour le point de gauche, Y = maxY - cos(angle) * Height.

Pour les autres points, c'est pareil avec des min au lieu des max et des plus au lieu des moins

Bien sûr, c'est à adapter pour chaque quart de cercle

L'angle c'est l'angle dans le coin tout a droite c'est cela (par rapport a l'hypoténuse) ?

Parce que le seul angle que je connais c'est l'angle de rotation que je lui colle sur son anchor point.

tu pars du anchor (centre)

les 4 coins sont à une demi-hypothénuse du centre

radius = 0.5 * sqrt(width*width+height*height)

après tu connais l'angle theta, zéro quand le rectangle est horizontal - plus pratique que si tu te bases sur l'hypothénuse, comme ça tu dépends pas des proportions du rectangle.

tu calcules en plus l'angle que forme un coté du rectangle avec son hypothénuse

alpha = arctan2 ( height/2, width/2) = arctan2 (height, width) (théorème de thalès)

ça marche aussi si tu inverses height et width, ça fera juste un rectangle tourné de 90 degrés.

maintenant tu connais donc les angles qui visent les 4 sommets à partir du centre

le premier est à l'angle theta + alpha
le 2eme " " " theta - alpha
le 3eme " " " theta + alpha + 180 = symétrie centrale du premier
le 4eme " " " theta - alpha + 180 = symétrie centrale du 2eme

pour rotater un point A à partir du centre C tu fais

XA = XC + radius * cos(angle)
YA = YC + radius * sin(angle)

C'est l'équation d'un cercle.

tu peux faire "sioux" si tu sais que cos(angle+180) = -cos(angle) et que sin(angle+180)= -sin (angle) ou que les points sont symétriques par rapport au centre.

tu connais XC,YC (anchor) radius et les 4 angles, WIN.

du coup pourquoi t'as besoin d'une bounding box? tu peux utiliser une bounding box pivotée, cad que tu compares les coordonnées des 4 points de ton rectangle pour voir si elles sont dans le mur, pas besoin de min max, ce sera faux.

-

une objection?

La bounding box se fait automatiquement autou de mon sprite rotaté.
Actuellement, je test les collision avec une fonction qui me crache un BOOL si 2 rectangle s'overlap.

Le but étant de faire un test de collision sur les 4 coins, a la place du rectangle.

Je vais appliquer ta méthode, et essayer d'optimiser le truc pour pas que ca me bouffe trop de ressources, thx squalyl.

déja avec la symétrie ça fait deux sin/cos de moins.

atan2 peut être approximé par une division pour les petits angles, je pense que c'est le cas vu la vidéo que t'as postée.

mes angles ne changerons jamais, vu que mon sprites aura toujours la meme taille.

En tout cas, j'ai testé ta technique, et ca marche, j'ai juste au final une rotation de - 180 sur mes points, mais j'ai patché
Merci beaucoup en tout cas

Je cleanerais et je posterais le code (même si tout le monde s'en cogne).
Je tente un portage iPhone de kuru kuru kururin, et meme si y a du CPU sous le capot, je préfère optimiser a fond le truc (table de cos/sin)

Mouais... fais des essais, avec les processeurs récents, on peut être surpris (le gain apporté par une table précalc peut être négligeable, et même parfois négatif si l'accès à la mémoire est lent).

oui en effet alpha est fixé si c'est un sprite.

c'est bien d'optimiser!

une table permet de stocker des valeurs entières, et puis sinon rien n'empêche de préstocker (calculer une seule fois) une table trigo remplie de floats.

la table est plus lente si le FPU de l'ARM sait calculer des trucs trigos en hard avec peu de cycles CPU, ce qui m'étonnerait mais on sait jamais. Dans tous les autres cas la table gagne.

edit: http://www.heyrick.co.uk/assembler/fpops.html il semblerait que oui mais alors il faut savoir si la stdlib d'IOS l'utilise et combien de couches de soft se trouvent entre l'utilisateur et le hardware si c'est utilisé.

Je comptais calculer les tables des cos/sin au load.

Ca devrais rouler au poil je pense, de toute manière je ne testerais pas les collisions a chaque update, c'est pas nécéssaire.

Bon, j'arrive peut-être un peu tard, mais dans les formules que je te donnais, c'est bien l'angle de rotation qu'il faut utiliser (c'est celui que tu as).

Je t'ai donné les formules qui me semblent les plus simples pour calculer ce qui te manque dans l'exemple du ./4. Il n'y a qu'un seul calcul de cosinus à faire, deux multiplications et 4 additions / soustraction. Après, il faut voir les performances du calcul des bornes du conteneur, mais c'est peut-être toujours connu (pas calculé lors de l'appel, mais calculé une fois par rotation de toute façon). Bon, il faut aussi savoir dans quel cadran on se trouve, ça demande deux tests.

iceman (./13) :
Actuellement, je test les collision avec une fonction qui me crache un BOOL si 2 rectangle s'overlap.

Fix'd

J'arrive encore plus après la bataille que tous les autres (j'avais pas les yeux en face des trous en lisant le topic hier), mais pourquoi ne pas utiliser des vecteurs pour tes calculs mathématiques ?
T'as toujours un calcul de trigo à faire (un sinus et un cosinus ) comme partout, mais le reste c'est juste additions et multiplications. (cf. photo attachée: cliquer ici, et de toutes façons le résultat est exactement le même que pour tous les autres posts du topic…)

Mais surtout, tu n'as peut-être rien à calculer ! (Enfin… Par toi-même, il s'entend)
Ça dépend comment tu t'y prends pour ton affichage:

Si tu essayes de reproduire le mode old-school alors tu connais déjà la position exacte des pixels à chaque étape de la rotation (je sais plus combien il y en a mais c'est pas la folie… je dois avoir un projet vb.net avec les valeurs sur mon disque dur, datant de l'époque ou je voulais coder ça sous TI ).

Et si tu veux faire ça en mode « moderne » en dessinant toi-même le rectangle rotationné… Ben tu as certainement déjà la matrice avec toutes les valeurs à appliquer ! (Genre dans un CGAffineTransform je pense)
Dans ce cas pas besoin de calculer quoi que ce soit une seconde fois.
Il te suffit d'appliquer la matrice… Par exemple avec CGRectApplyAffineTransform si tu as une structure CGAffineTransform… (Ou autre chose si tu utilises OpenGL pour le rendu, à toi de voir)

(PS: les vecteurs et les matrices, ça rend tous les calculs complètement bidons ! )

Sinon, Kuru Kuru Kururin, c'est bien, mais Kururin Paradise est plus sympa encore (Dommage qu'il ne soit pas sorti en Europe (à ma connaissance))

(je vois pas ce que ça "simplifie" les matrices, c'est juste strictement les mêmes calculs sous une autre forme)

(Bah disons que les fonctions de calcul sur les matrices sont déjà présentes dans tous les environnements graphiques un tant soit peu modernes… (Y compris iOS) Ce sont surtout les vecteurs qui déchirent pour la simplicité des calculs… Mais on est d'accord qu'à la fin le résultat est toujours le même quelle que soit la méthode employée )

voui bon ok, ça t'économise les 2 lignes de code qu'il aurait fallu ajouter pour définir les vecteurs toi-même

J'utilise cocos2D iphone pour l'API graphique, et les transformation (translate, scale, zoom, rotate) se base sur CGAffineTransform.

Je vais tenter la méthode de GoldenCrystal pour comparer laquelle est la plus rapide.

Merci a tous en tout cas pour votre aide, faut vraiment que je me fasse une petite remise a niveau en géométrie, parce que c'est pas cool de bloquer sur de la merde comme ca, alors que coté code, ca va bien.

En fait j'ai écrit une connerie dans mon post, c'est CGPointApplyAffineTransform qu'il faut utiliser sur les 4 points, et pas CGRectApplyAffineTransform, qui donnera un résultat inintéressant

./24 > Aussi, les fonctions de vecteurs et/ou matrices du "système" (de l'API) sont normalement implémentées avec des instructions vectorielles (par exemple des instructions SSE sous x86) si celles-ci sont disponibles sur la plateforme. Normalement cela doit améliorer un peu les performances, sauf si tu utilises déjà toi même les instructions vectorielles. (dépend aussi du compilateur)
En plus de cela, si les mêmes matrices sont déjà utilisées (voire obligatoires) pour le rendu, c'est tout benef

sauf qu'il y a un GPU sur les iPhones, donc une bonne partie des opérations pour le rendu sont faites en shader, non ?

Zerosquare (./16) :
Mouais... fais des essais, avec les processeurs récents, on peut être surpris (le gain apporté par une table précalc peut être négligeable, et même parfois négatif si l'accès à la mémoire est lent).

Si c'est sur ARM, c'est rapé ^^ (et comme je le pensais plus tard il parle d'iPhone, sur n'a pas de FPU, enfin c'est complexe ^^)

./27 > Ouep mais le calcul de tes matrices est a priori toujours fait sur le CPU. Les shader font le boulot ensuite, pour le rendu. (Hors geometry shader il s'entend. Mais je ne pense pas qu'il y en ait sur iPhone)
Effectivement après tu dois toujours appliquer ta matrice "à la main" pour la "physique", mais si tu as déjà la matrice toute prête avec les fonctions qui vont bien, autant l'utiliser. Déjà, ça réduit la duplication de code (c'est le mal ! J'espère que tu en conviendras ) et ça évite notamment d'utiliser deux chemins de code différents pour calculer la même chose. C'est aussi une optimisation (enfin plutôt une non désoptimisation ) mais bon, après on va me taper dessus en disant "L'optmisation prématurée..." et tout...

En tout ca avec la solution se Squalyl implémentée "a la porc" (test a chaque update, sur chaque points, sur chacun des blocs de collisions avoisinant les coordonnées du persos) ben ca ralentis pas d'un pète.....60 FPS

Normal quoi, mais bon, je vais cleaner