Vrally - Page 6

Ah, ta fonction n'est peut-être pas plus rapide que celle d'ExtendeD ?
Moi, en utilisant le même principe qu'ExtendeD, mais avec un code plus optimisé, j'arrive à quelque chose environ 13% plus rapide qu'ExtendeD.

Pen^2 > Tu as une division ou pas ?

tu l'as eu où son source ?
dans le source de extgraph ? la nouvelle version est sortie ?


faudrait en plus que je benche sur la meme calc pour comparer

division : oui, oui il me semble bien

et au fait c quoi le principe d'ExtendeD ? du bresenham segmenté ? implementé comment ? dessiné pixel par pixel ou segment par segment (ac un masque) ?
moi c pixel par pixel, ct obligatoire pour ce que je voulais en faire

Le source d'ExtendeD, il me l'a passé, je crois...
Il utilise l'algo standart de bresenham (on calcule l'erreur à chaque pixel affiché), mais il dessine en partant des deux bouts à la fois, et avec la même erreur pour les deux bouts (puisqu'une ligne est symétrique en son centre), donc c'est plus rapide, parce qu'il fait 2 fois moins de calculs d'erreur.

merci.
remarquable comme idée.

faudrait que j'ajoute ça à mon traitement segmenté pour diviser le nombre deja reduit de calculs d'erreurs !!
youuuhouuuu


je me demande combien de segments/s je v accrocher ac cette technique en plus !


( moi c du bresenham segmenté qui prevoit le cas des segments en diagonale )


ça me remotive presque pour reprendre le dev de mon jeu #huhu#

quelle bete cet ExtendeD

> moi c pixel par pixel, ct obligatoire pour ce que je voulais en faire
> moi c du bresenham segmenté qui prevoit le cas des segments en diagonale
Tu as au moins deux routines, donc ?
Et sinon, prévoir le cas des segments en diagonale, ça n'est à mon avis pas très utile... Ca gagne du temps pour ce cas précis, qui n'est pas très courant, mais ça augmente bien la taille... A la limite, il vaut mieux optimiser le cas "ligne horizontale", plus fréquent - mais c'est pareil, ça augmente pas mal la taille...

tu ne m'as pas compris : (il faut dire que je me suis mal exprimé aussi )
je parlais des multiples segments qui forment le segment complet que l'ont veut tracer.

dans le bresenham segmenté normal, on calcule l'erreur pour chacun des segments horizontaux ou verticaux. et bien moi je considere en plus qu'un segment de coordonnées 0,0 ; 150, 151 par exemple est constitué de 2 segments en diagonale (en effet pour ce cas là (c le cas de la moitié des segments en fait) la longeur maximale d'un traitement hz ou vert (ie un petit segment) est égale à 1 ou 2 maximum, ce qui rend l'algo de bresenham segmenté inefficace.
comme ça dans le pire des cas la longueur du petit traitement est égale à 2 pixels.

PS
je n'ai rien inventé, l'idée est suggérée dans le black book.

PPS :
pitit shema :

^ 
|            .
|           .
|          .    
|         .
|        .
|       .
|       .
|      . 
|     .
|    .
|   .
|  .
| .
|.
+----------------------------->

dsl le segment n'est pas equiblibré

>il faut dire que je me suis mal exprimé aussi
A peine

> dsl le segment n'est pas equiblibré
Pas grave.

Peut-être que je n'ai pas le chapitre du black book dont tu parles. Il faut que je vérifie...

>A peine
beuuuuuuuuuu #sniff# #mechannnnt#


>Peut-être que je n'ai pas le chapitre du black book dont tu parles. Il faut que je vérifie...
cette idée est évoquée tout à fait à la fin du chapitre qui traite des segments de bresenham segmentés. Mais M.A. ne l'a pas détaillée dans la mesure où sa routine était déjà à la limite de ce que sa mem video pouvait encaisser

Alors Julien, ta méga-routine, tu m'en passeras les sources

nEUrOO :
Pkoi je ne pourrais pas le faire ? Ca me parrait tout à fait logique de poivoir le faire, la priorité ds opérateur est une regle stricte !

Un petit article que j'avais écrit à propos de ça pour une FAQ qu'on faisait avec Ximoon pour la classe (pour des newbs) : http://membres.lycos.fr/tepc/faq/faq_1.php

Merci bcp ExtendeD

Thibaut :
Alors Julien, ta méga-routine, tu m'en passeras les sources

ba bien sûr