Bon voila je suis sur un projet Open source avec 2 autres personne. Je suis en 2eme annee d'informatique et j'ai besoin de calculer le rayon d'un cercle entre deux points (x1,y1) et (x2, y2)  , ou (x1,y1) correspond au centre du cercle.
J'utlise un programme de SDL qui affiche en temps reel un cercle, sachant que son rayon varie tout le temps le programme ram quand le rayon depasse 500.  
Ce qui pose un petit probleme, est ce que quelqu'un aurait un autre formule que celle la   :
R = sqrt((x0 - x2) * (x0 - x2) + (y0 - y2) * (y0 - y2));
 
Merci d'avance  

il y a des methode de calcul plus rapide pour la racine carré, mais je serai surpris que ce soit ce calcul qui fasse ramer ( a moins que  tu ne fasse tourner ca sur du matériel embarqué )

bah y a deux truc qui font ramer le programme la premiere est sqrt pour le rayon et la deuxieme est le fais que je parcours une boucle while pour tracer le cercle sur 360 degres j'ai regler ce probeme en fesant un symetrie et en ne fesant que 90 degres du cercle.
Cependant si je met en commentaire ma boucle while le programme ram encore quand le rayon est trop grand... je cherche depuis ce matin un moyen efficace pour ce probleme. Mais je dois chercher mal malheureusement T.T

c surtout le coup du "500" qui me pose problème à moi.
 
à part que tu dessines ton cercle, tu tenterais pas de faire de la détection de collision ou autre ? genre quand t'arrive à 500 t'as beaucoup plus d'objets à tester et du coup ça effondre les perfs ?

Nan aucune gestion de collision, c'est juste que le cercle devient trop grand. Et pour le moment je ne test que mon cercle comme objet donc je n'ai pas d'autre objet a tester.
Mais sinon pour ce probleme de sqrt y a un autre moyen une autre formule ??

Que fais-tu avec le rayon, des fois on peut se contenter de la valeur carrée par ex si on cherche à savoir si un point est dans le cercle

preposterus a raison, en genral pour eviter de faire une sqrt, on change l'algo en le mettant au carré.

Je ne vois pas pourquoi pour tracer un cercle on a besoin de calculer des racines carrées, à la rigueur une si le cercle est défini par le centre et un point.

Voir http://homepage.smc.edu/kennedy_john/BCIRCLE.PDF par exemple.

En fait, ce qu'il calcule la, avec sa formule, c'est la distance entre deux points. Apres, si tu prends pour centre l'un des points et que tu traces un cercle passant par l'autre, cette distance est le rayon du cercle...
A+,

Et pourquoi le calcul du rayon serait plus lent quand le cercle est plus grand ???

ça, c'est bien le truc qui me fait tiquer, d'où ma question sur d'éventuels autres traîtements

ce ne serait pas tout bêtement que le rayon est calculé à chaque itération au lieu d'être calculé une seule fois et réutilisé ?
 
Edit : http://fr.wikipedia.org/wiki/Algor [...] _Bresenham ca peut aussi éventuellement te servir ...

ceci dit, si c'est calculé pour dessiner le cercle selon chaque degré d'angle, le nombre de points est le même quelle que soit la taille du rayon, donc pas de lien avec la dimension du cercle

 
tant que je n'ai pas vu l'algorithme utilisé, je ne ferai pas ce genre de suppositions Ca ne me surprendrait pas qu'il ait augmenté le nombre d'itération en fonction du rayon justemnt pour éviter d'avoir des blancs entre les points.
Reste que cet algorithme naïf n'est clairement pas le melleur choix si on se soucie des performances ...

en tout cas merci, pour toute vos reponse je pense avoir reussit a trouver mon probleme, vu que en SDL je creer une surface qui va contenir on cercle, seulement plus le cercle est grand plus la surface a creer va etre grand d'ou le lag de mon prog.
Jvais me poster sur ce probleme merci encore (ps: venez me voir au forum "paris capital du libre )

c'est lui qui a dit qu'il faisait le dessin en faisant un angle de 1° à chaque fois et que pour accélérer le truc il faisait le dessin sur 90° puis faisait des symétries

 
Trouve-moi où c'est précisé 1° à la fois
 
mais bref, osef

Ceci peut surement t'aider :
 

 
http://www.lomont.org/Math/Papers/2003/InvSqrt.pdf

thx

désolé, mais c'est écrit
 
faire une boucle sur 360° c'est faire une boucle pour chacun des 360° degrés

 
La formule du rayon d'un cercle est mathématique. Ca ne peut donc pas changer.
 
En revanche, tu peux utiliser cet algo issu de la propriété de la suite  
- U0 = X (X nombre quelconque différent de 0)
- Un+1 = ½ (Un + N/Un)
Et qui est croissante vers racine(N)
 

// Fonction "racine"
double racine(
    double nb)                // Paramètre recevant le nombre dont on veut la racine
{
    // Déclaration des variables
    double calc;            // Calcul de la racine dans la boucle
    double diff;                // Pour tester la différence avec la valeur précédente
 
    // Si la racine n'a pas besoin d'être calculée (pour "0" ou "1" )
    if (nb == 0.0 || nb == 1.0) return (nb);
 
    // Initialisation début de boucle
    calc=nb;                // Ou n'importe quel nombre différent de "0"
 
    do {
        // Récupération de "calc" pour comparer avec le calcul suivant
        diff=calc;
 
        // Approximation de la racine
        calc=0.5 * (calc + nb / calc);
    
    // Tant que le processeur peut faire la différence entre ce calcul et le précédent (limite)
    } while (calc != diff);
 
    return (calc);                // Ou bien "return (diff)" puisque ici, "diff" = "calc"
}

 
Je sais pas si c'est plus ou moins rapide que sqrt() mais c'est mathématiquement équivalent.

sinon, si tu veux rester sur ton algo, tu peux aussi assez facilement faire de la symétrie par coups de 45° et aussi faire des tables de précalcul (tableau de sinus et cosinus), t'assurer que tu ne calcules qu'une seule fois ton rayon (le sqrt hors de ta boucle, donc)
 
Précision : parce que je doute que ce soit juste d'avoir même 90 sqrt  pour tracer ton cercle qui te fasse un ralentissement notable si tu ne el fais qu'une fois