un cercle en basic

Christian · Message par **Christian** » 10 avr. 2006 22:21

fabrice93fr a écrit :question subsidiaire un pixel c'est rond ou carré ?

rectangulaire

balou · Message par **balou** » 10 avr. 2006 22:27

Bon c'est pas le tout ça vous nous les montrez quand ces cercles en basic

Parce que bla bla cercle bla bla cercle avec des droites bla bla cercle avec des sinus cosinus bla bla

Va quand même pas faloir que je branche le TO9+ que je cherche comment faire dans la doc et me mettre au boulot

... si ben j'ai pas le cul sortie des ronces

jamais fait de basic moi pfff. Je vais avoir deux semaines de vacances pour faire des cercles en basic: "Alors ces vacances c'était bien ? Oui oui j'ai fait des cercles "
Vais me coucher moi ...

Christian · Message par **Christian** » 10 avr. 2006 23:25

Arrêtez de tourner en rond, passez au cercle problématique :
http://worldserver2.oleane.com/fatrazie/Cercle%201.jpg

jasz · Message par **jasz** » 10 avr. 2006 23:52

On sait que C=2PI*R. C étant le périmètre

A partir d'un centre précis ici 160 (x) et 100 (y), il s'agit d'organiser les points en s'inspirant de la formule sus-citée. Avec I compris entre 0 et 2PI on a X=160+R*cos(I) et Y=100+R*sin(I).

Soit

R=40:PI=3.14:FOR I=0 TO 2*PI STEP .01:PSET (160+R*COS(I),100+R*SIN(I)):NEXT

Ca devrait marcher.

Bien vu SbM

James · Message par **James** » 11 avr. 2006 07:32

trop lent ...

Message par **Torlus** » 11 avr. 2006 07:53

http://www.cs.unc.edu/~mcmillan/comp136 ... ircle.html

Pour les impatients, sauter directement à la fin du document, pour obtenir l'algorithme itératif optimisé qui permet d'avoir des cercles "complets", et sans overdraw (et sans trigonométrie).

Dans l'approche, il ressemble beaucoup à celui de Bresenham pour les droites.

foolduplex · Message par **foolduplex** » 11 avr. 2006 09:38

Bravo Torlus, enfin on s'approche de quelque chose de bien. D'ailleurs le midpoint, c'est l'algo de Bresenham pour les cercles.

Mais on peut faire encore un tout petit peu mieux en utilisant les differentielles de second ordre : l'avantage de cet algorithme c'est que non seulement il est en nombres entiers, mais en plus il n'utilise que des additions et des puissances de 2 (la multiplication dans le midpoint ca prend quand meme un peu de temps). C'est donc tres facile et rapide a implementer en assembleur.

Voici une "traduction" rapide en basic, pour un cercle de rayon 50 en (160,100) :

Code : Tout sélectionner

10 cls:defint a-z
20 r=50
30 h=1-r
40 x=0
50 y=r
60 dp=3:dm=5-2*r
90 pset(160+x,100+y)
91 pset(160+x,100-y)
92 pset(160-x,100+y)
93 pset(160-x,100-y)
94 pset(160+y,100+x)
95 pset(160+y,100+x)
96 pset(160-y,100+x)
97 pset(160-y,100-x)
100 if x>=y then end
105 x=x+1
110 if h<0 then h=h+dp:dm=dm+2 else y=y-1:h=h+dm:dm=dm+4
115 dp=dp+2
120 goto 90

On notera qu'on ne calcule qu'un seul octant, donc 8 fois moins de calculs qu'un cercle complet, puisque le critere de fin c'est x=y, comme dans le midpoint.

Cela etant dit, j'ai essaye ca hier soir sur mon MO5. Calculer 1/8 du cercle et reporter les points est effectivement quasiment 8 fois plus rapide qu'une boucle complete, par contre le passage a l'algo en entiers en BASIC n'apporte pas grand chose parce que c'est un langage interprete et les 8 PSET prennent plus de temps.

En assembleur sur MO5, on peut gagner encore un peu en faisant sauter l'appel a la routine d'affichage de point et utilisant une seule variable (l'offset en memoire video) au lieu de (x,y) + un peu de code auto-modifiant pour dp et dm.

Fool

Invité · Message par **Invité** » 11 avr. 2006 09:51

en résumé c'est pas simple de faire des ronds en basic et c'est long, on tourne en rond!

Hier j'ai avancé dans la découverte du basic et j'ai trouvé l'instruction defgr$(i)= a,a,a,a,a,a,a,a
où i est une valeur entière et a est une valeur décimal de 1à 255.
Pour ceux qui ne connaisse pas cela permet de dessiner des caractère sur une grille de 8 par 8.
ensuite il faut afficher le caratère avec un print gr$(i)

J'ai trouvé cette instruction trés interessante pour faire des petit jeux.
en revanche pour l'animation je place deux caractère : un qui est mon "sprite" et un autre où je met que des 255 et la couleur du fond, ainsi je fais évoluer mon sprite à l'écran mais le seul problème est que l'on vois le curseur passé.
Comment optimiser cela?

foolduplex · Message par **foolduplex** » 11 avr. 2006 10:01

Pour faire des cercles en BASIC, le mieux est effectivement de coder la routine en assembleur et de rajouter l'instruction CIRCLE. Il faut savoir que le BASIC microsoft est conçu de maniere a pouvoir rajouter des instructions de cette maniere a volonte. C'est ainsi que fonctionnent d'ailleurs les complements DOS sur Thomson.

Pour ton curseur, rien de plus simple : fait un LOCATE 0,0,0 ou un PRINT CHR$(20) au debut de ton programme, ce qui aura pour effet de faire disparaitre le curseur. L'affichage sera meme un poil plus rapide. Le caractere 20 sur Thomson est un caractere de controle qui provoque la disparition du curseur clignotant. LOCATE X,Y,C positionne le curseur a l'ecran et selectionne son mode (clignotant ou eteint). Il reapparait quand tu interromps ton programme avec CNT-C.

Fool

Invité · Message par **Invité** » 11 avr. 2006 10:07

merci.

Ben même si le basic est lent il y a quand même pas mal d'élément pour faire des petits jeux. Ensuite il faut les idées!
je suis en train de faire un jeu en basic, mais le plus dure est d'organiser le programme et de mettre les idées en place.

chiss · Message par **chiss** » 11 avr. 2006 10:16

pacman a écrit : Ben même si le basic est lent

si tu veux un basic lent essaye le ti99.....quoi, je sort ?? ha non.....ok ok ...

Invité · Message par **Invité** » 11 avr. 2006 10:20

ben j'ai aussi 2 atari 800 xl et un xe system et j'ai testé un peu le basic.
Le basic de l'atari est plus complexe et l'avantage est le nombre de couleur plus important.
Domage que le mo5 n'a pas plus de 16 couleurs.
ceci dit j'ai aussi un ti mais j'ai jamais testé le basic.

jasz · Message par **jasz** » 11 avr. 2006 11:00

Euhm...

95 pset(160+y,100-x)

ne serait pas mieux

En tout cas c'est plus rapide que les algos trigos

James · Message par **James** » 11 avr. 2006 11:56

chiss a écrit :
pacman a écrit : Ben même si le basic est lent
si tu veux un basic lent essaye le ti99.....quoi, je sort ?? ha non.....ok ok ...

foolduplex · Message par **foolduplex** » 11 avr. 2006 12:54

Exact jasz, petite erreur de recopie ... merci

En assembleur l'approche par differentielles de second ordre est extremement rapide. Elle n'utilise que des instructions qui prennent quelques cycles. Par exemple, l'incrementation de x et y peut se faire avec du code auto-modifiant, soit seulement 5 cycles pour une addition ou soustraction sur 16 bits. Pour des cercles de taille modeste (de l'ordre de 50 pixels de rayon) tout hormis x,y peut etre calcule en 8 bits signes, car on ne sort jamais de l'intervalle -128..127. le test de signe se fait en une seule instruction et prend 3 cycles.

Je n'ai jamais mesure combien de cercles par seconde on peut tracer sur un mo5, je vais essayer tiens.

Fool