Path: zoy.org!not-for-mail From: "=?iso-8859-1?Q?Cl=E9ment_PILLIAS_=28HpFool=29?=" Newsgroups: hpcalc.dev Subject: Re: indexation des tuiles again Date: Sat, 30 Jun 2001 13:50:03 +0200 Organization: unavailable Lines: 62 Message-ID: <9hkeio$pto$1@zoy.org> References: <9hd0m7$dk9$1@zoy.org> <9hdh0e$tm9$1@zoy.org> <9het1u$a8m$1@zoy.org> <9hg0nk$e0j$1@zoy.org> <9hg27d$fca$1@zoy.org> <9hg8j6$lmj$1@zoy.org> <9hhfdf$snt$1@zoy.org> <9hihd3$um1$1@zoy.org> <9hk40a$flp$1@zoy.org> NNTP-Posting-Host: 217.11.170.156 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Trace: zoy.org 993901977 26552 217.11.170.156 (30 Jun 2001 11:52:57 GMT) X-Complaints-To: usenet@zoy.org NNTP-Posting-Date: 30 Jun 2001 11:52:57 GMT X-Newsreader: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Xref: zoy.org hpcalc.dev:2951 AnsNum a écrit dans le message <9hk40a$flp$1@zoy.org>... > > > >sgroumpf ! >alors en fait l'interêt de l'écran cyclique ne tient qu'au fait qu'il est >plus rapide de recopier 8 tuiles dans l'ecran cyclique et un ecran, entier >dans l'ecran d'affichage, plutot que de couvrir a chaque fois l'ecran >d'affichage par des tuiles ? Et oui ! Enfin il a aussi d'autres intérêts, comme permettre les scrollings différentiels multidirectionels... Et c'est surtout dans ce cas là qu'il est indispensable, parce que sinon la plupart du temps on peut se contenter d'une méthode plus simple et plus lente... Enfin j'avais fait tout un message aussi dans lequel j'évaluais les temps de diverses méthodes (je le cite même dans l'autre), peut-être que quelqu'un l'a conservé aussi ? ;-) Bon sinon on peut le faire rapidement... Une recopie d'écran c'est un truc du style : LC (34*64/16-1) % 6 cycles { A=DAT0.16 % 44 cycles DAT1=A.16 % 34 cycles D0+16 % 8.5 cycles D1+16 % 8.5 cycles C-1.B % 6.5 cycles UPNC %12.5 ou 4.5 cycles } ce qui fait 6 + (44+34+8.5+8.5+6.5+12.5)*(34*64/16) - 12.5 +4.5 = 6 + 114*136 - 8 = 15502 cycles. Notez que si je déroule la boucle une fois ca me donne 14210 cycles, et si je la déroule 4 fois ça me donne 13564 cycles (ce qui fait quand même gagner 2000 cycles Maintenant prenons le cas des tuiles les plus rapides à tracer : celles faisant 20 pixels de large, ca tient sur un champ A. Si je ne tient compte que des recopies mémoires (sans tenir compte de tous les accès a la matrice des tuiles, ni aux calculs de pointeurs, ni même aux boucles), pour mettre à jour tout l'écran il faut faire (34*64/5) recopies avec un champ A. Soit 435 fois A=DAT0 A DAT1=A A (qui fait 43.5 cycles), ce qui donne entre 18705 et 19140 cycles suivant la parité des instructions. C'est déjà bien plus que la recopie d'un écran, et ce n'est qu'une petite partie de l'affichage des tuiles. Et on s'est intéressé au cas le plus intéressant, celui de tuiles de 20 pixels de large ! Plus les tuiles sont petites, plus l'écart est grand. A titre d'exemple, avec des tuiles de 8 pixels de large (un champ B), on obtient 39168 cycles juste pour les recopies mémoires, c'est-à-dire environ un centième de seconde. A titre de comparaison, une VBL prends 1.5625 centièmes de secondes. Si on est en 4 nivs de gris, on a alors 3 VBLs pour faire l'affichage (soit 4.7 centièmes de secondes), et l'affichage du fond prends a lui seul 2 centièmes de seconde, soit 43% du temps de calcul disponible. Ajoute à cela les sprites qui sont assez lents aussi a afficher et la gestion des collisions, et tu atteins facilement les 3 VBLs, sans avoir eu le temps de faire bouger tes sprites. Enfin bien sur tout ca est très généraliste et il y a des tas de cas ou l'ont peut se contenter de réafficher tout à chaque fois, mais c'est quand même pas la majorité. A+