CERCLE DISCRET (POINT PAR POINT) EN C++
MuPuF
Messages postés
536
Date d'inscription
mercredi 27 avril 2005
Statut
Membre
Dernière intervention
22 août 2008
-
3 nov. 2005 à 20:31
Galmiza Messages postés 573 Date d'inscription samedi 16 novembre 2002 Statut Membre Dernière intervention 9 avril 2008 - 7 nov. 2005 à 12:45
Galmiza Messages postés 573 Date d'inscription samedi 16 novembre 2002 Statut Membre Dernière intervention 9 avril 2008 - 7 nov. 2005 à 12:45
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/34466-cercle-discret-point-par-point-en-c
https://codes-sources.commentcamarche.net/source/34466-cercle-discret-point-par-point-en-c
7 nov. 2005 à 12:45
En assembleur, chaque opération modifie les états du flag et on peut directement faire un jump en fonction de l'état de ses bits.
Par exemple:
addition register, regiter
bcc \label ; <- branch carry clear, => aller à \label si le bit du flag qui correspond a un resultat nul est a 1
A la limite, un: if (hFile == NULL) {...} else {...} peut être parfaitement bien compilé.
Et encore c'est le plus simple. Certains bits du flag correspond a des débordements sur le registre d'"arrivé", des comparaisons des registres (plus grand ?, plus petit ?), des états des bits de poids fort et faible, et autres ...
Bref, beaucoup d'optimisation qui ne peuvent pas être automatiquement faites par un compilateur si l'utilisateur n'utilise pas volontairement (dans l'algorithme lui même) les avantages des flags.
2 -
2 programmes en assembleur en tournent pas forcement à la même vitesse.
sin et cos sont en assembleur mais plus lentes qu'une suite d'opérations élementaires rapides.
Dans le cas du cercle avec sin et cos tu calcules plusieurs fois la meme pixel, pas avec brensenham.
Quand je dis assembleur c'est le langage, genre le 8808, 8086, 80386, 80286, pas le module d'assemblage du compilateur.
Perso j'ai fait que du 68000 pour ti et l'assembleur change la vitesse de façon ultra-sensible.
Je code en anglais depuis un an, c'est plus stylé :D
7 nov. 2005 à 10:17
1 -> un compilo en mode release c'est loin d'etre stupide il te sort souvent un code plus rapide que le tien
2 -> de toute facon les fonctions sin et cos, eles y sont deja,em asm
[edit] heu j' ai un doute la, ad tu dis
'Seul l'assembleur permet d'optimiser ce code." tu parles duquel ? :p
et heu dit voir.... vu la qte d'anglais dans ton code, t'est sur que c'est toi qui l'a fait ? :p
4 nov. 2005 à 19:01
Les programmes C qui tracent des lignes en calculant le coefficient directeur ou des cercles en utilisant sin et cos
se font larguer par leur homologue VB qui utilise Brensenham.
Même avec un ordinateur qui a une puissante FPU et en créant une table de sinus et de cosinus, l'algo de Brensenham est plus rapide.
Seul l'assembleur permet d'optimiser ce code.
4 nov. 2005 à 18:30
4 nov. 2005 à 18:13
C'est l'algorithme de Brensenham, un ingé d'IBM qui a aussi fait un algorithme ultra rapide de tracé de ligne (algo utilisé partout).
4 nov. 2005 à 07:24
float rayon=10.0;
float angle=0;
int xc=100;yc=100;
int x,y;
float PI=3.1415;
for (angle=0.0;angle<(2*PI);angle=angle+0.01)
{
x=(cos(angle)*rayon)+xc;
y=(sin(angle)*rayon)+yc;
dessine_point(x,y);
}
3 nov. 2005 à 20:31