[ Vectrex ] VeKtorX et KdrawX de quoi faire de zolies dessins vectoriel sur sa Vectrex

[hlide]

Par contre l'amplitude "max - min" entre les deux points extrémaux de la courbe vaut 126.

Certes mais l'amplitude max devrait être |[-127, +127]| = |[-127,0[| + 1 + |]0,+127]| = 127 + 1 + 127 = 255 pas 127.

[6502man]

@Hlide: J'utilise pas le C pour Vectrex mais directement l'assembleur et la commande Draw_vlc demande que des coordonnées relatives ca c'est sur sinon mon programme ne fonctionnerais pas et il afficherais n'importe quoi

@sam:si l'amplitude max vaut 126 ca peut être la le problème quoi que il faudrait recalculer en valeur absolue pour en être sur si on dépasse le cadre ????

-127 > 0 < +127

avec ce paramètre :
-8 , -69 ; Start coordinates

A plus ....

[hlide]

Après le problème est peut être lié à la manière dont le VIA gère les DAC X et Y.

[hlide]

@Hlide: J'utilise pas le C pour Vectrex mais directement l'assembleur et la commande Draw_vlc demande que des coordonnées relatives ca c'est sur sinon mon programme ne fonctionnerais pas et il afficherais n'importe quoi

C ou ASM peut importe, le source C représente ce que fait Draw_vlc de manière intelligible pour ceux qui ne connaissent pas bien le 6809.

[Falkor]

Donc à priori il y aurait bien une limite d'encombrement du polygone... Je regarde pour tenter de contourner le problème. Si on considère une limite d'amplitude de 127, en gros un polygone ne pourrait pas être plus gros qu'1/4 de l'écran ?

[6502man]

@Falkor: non il n'y à pas cette limitation .

On peut remplir l'écran avec un polygone aucun soucis, la seul contrainte c'est de ne pas dépasser -127 ou +127 en relatif et de rester dans un cadre de -127 <> 0 <> +127 .

Je sait pas si j'ai était clair

Ce que je n'ai pas compris c'est pourquoi ce polygone plante alors que plus loin dans ton fichier il y à un autre 80 vecteurs qui fonctionne bien !!!

[Falkor]

Ce que je n'ai pas compris c'est pourquoi ce polygone plante alors que plus loin dans ton fichier il y à un autre 80 vecteurs qui fonctionne bien !!!

Oui voilà je ne comprends pas non plus... La remarque de sam quelques messages plus haut laisse à penser qu'il y a peut-être un souci sur l'amplitude totale des points dans le polygone concerné... Je n'explique pas encore trop le problème.

[hlide]

S'il n'y a pas de dépassement d'écran avéré, alors le problème peut se situer du côté hardware avec le VIA à qui on soumet des valeurs X et Y : on tombe peut-être dans un cas extrême. Je vais tenter de retrouver le code assembleur de la routine pour éclaircir cette histoire de valeur relative passée à un DAC VIA tel que l'on voit dans la routine C parce que j'ai du mal à comprendre pourquoi elle serait passée en relatif au VIA. Imaginez que je passe N fois +64 au DAC du VIA, il se passe quoi quand on sort de l'écran ? Il est placé où le point d'origine dans le VIA ? bref, il y a un gros mystère autour de ce VIA sur la façon de gérer les coordonnées.

[hlide]

D'autre part vu que le problème se situe vers le 63-ème point du polygone, il faut considérer l'amplitude entre le premier et le 63-ème.

[6502man]

J'ai vérifié en valeur absolue ca ne dépasse pas les limites :

Code : Tout sélectionner

X	Y
-8	-69
	
-6	-67
-7	-65
-12	-67
-21	-66
-24	-61
-24	-54
-20	-49
-17	-52
-15	-51
-19	-44
-19	-35
-17	-31
-12	-30
-10	-32
-10	-35
-8	-36
-7	-30
-4	-25
4	-23
4	-16
6	-13
13	-13
15	-15
16	-12
14	-9
16	-7
19	-7
16	2
15	-3
8	-2
4	1
4	4
6	6
14	9
9	12
9	18
12	21
11	23
9	23
10	27
0	27
-2	34
0	34
2	37
-1	38
-5	34
-8	38
-7	47
-9	48
-12	44
-14	46
-15	52
-17	51
-16	43
-12	41
-16	35
-16	31
-22	31
-24	33
-24	42
-18	45
-24	54
-25	49
-23	46
-26	43
-27	34
-26	25
-31	22
-32	19
-35	20
-38	17
-56	20
-65	19
-68	23
-68	33
-66	34
-68	36
-71	35
-70	24
-74	34
-78	39
-77	42
-81	46
-84	41
-84	22
-82	13
-87	15
-88	9
-83	-3
-78	-10
-79	-38
-75	-38
-72	-34
-72	-31
-68	-23
-67	-25
-64	-24
-64	-19
-51	-16
-30	-16
-21	-21
-17	-26
-22	-35
-22	-47
-27	-55
-27	-60
-25	-63
-26	-64
-23	-68
-16	-70
-14	-72
-13	-70

Je pense à 2 autres possibilités :
- l'envoie trop rapide de coordonnées ferait que l'e VIA ne suit pas ???
- Le fait d'envoyer des coordonnées rapidement dans des sens opposés ferait que l'e VIA ne suit pas ???

[hlide]

Voici en macro la même routine qui correspond en ROM (source version 3) :

Code : Tout sélectionner

;*****************************************************
; DEFINE SECTION
;*****************************************************
; load vectrex bios routine definitions
          INCLUDE "VECTREX.I"          ; vectrex function includes

DRAW_VLC macro
          direct  $d0                  ; following code uses d0
          LDA     ,X+
Draw_VL_a_macro\?
          STA     $C823
          LDD     ,X
          STA     <VIA_port_a          ;Send Y to A/D
          CLR     <VIA_port_b          ;Enable mux
          LEAX    2,X                  ;Point to next coordinate pair
          NOP                          ;Wait a moment
          INC     <VIA_port_b          ;Disable mux
          STB     <VIA_port_a          ;Send X to A/D
          LDD     #$FF00               ;Shift reg=$FF (solid line), T1H=0
LF3ED\?:
          STA     <VIA_shift_reg       ;Put pattern in shift register
          STB     <VIA_t1_cnt_hi       ;Set T1H (scale factor?)
          LDD     #$0040               ;B-reg = T1 interrupt bit
LF3F4\?:
          BITB    <VIA_int_flags       ;Wait for T1 to time out
          BEQ     LF3F4\?
          NOP                          ;Wait a moment more
          STA     <VIA_shift_reg       ;Clear shift register (blank output)
          LDA     $C823                ;Decrement line count
          DECA    
          BPL     Draw_VL_a_macro\?    ;Go back for more points
          JSR     Check0Ref            ;Reset zero reference if necessary
          endm

C'est la même chose que la version C donc on fournit des valeurs relatives et non absolues au DAC - on n'est pas protégé d'une sortie d'écran et je n'ai aucune idée de ce qui se passe alors après. Ensuite, il y a la question du timer T1 dont on comprend assez mal le fonctionnement : il serait question de pouvoir faire des motifs sur la ligne (bit = 1 -> trait, bit = 0 -> "blanc" - plutôt noir ici). Le compteur à 0 ? j'imagine que l'on sort de la boucle du timer T1 lorsque le rayon atteint l'objectif.

[hlide]

Je pense à 2 autres possibilités :
- l'envoie trop rapide de coordonnées ferait que l'e VIA ne suit pas ???
- Le fait d'envoyer des coordonnées rapidement dans des sens opposés ferait que l'e VIA ne suit pas ???

En suivant certains messages de FaceBook - en particulier PiTrex (PI contrôle le VIA) et Vectrex32 (un PIC32 génère une liste), il est spécifié que le VIA est "lent" et donc on ne peut pas aller plus vite pour en afficher plus. Par ailleurs, il m'a semblé avoir vu sur le blog de Vide des cas où il faut "ménager" la liste. Donc, oui, peut-être un cas extrême pour le VIA.

[hlide]

Et enfin, vu que c'est des données relatives, il peut y avoir une accumulation d'erreur à cause des dérives successives. Il ne faut pas croire qu'un rayon va frapper là ou on veut exactement, il y a une marge d'erreur. Pour un polygone fermé, le point d'arrivé pourrait ne pas terminer au point de départ, malgré la justesse totale des coordonnées relatives.

[6502man]

Je viens de faire unt est en rajoutant une grosse boucle d'attente entre chaque envoi de coordonnée relative.

Et résultat idem

[6502man]

ce midi je test sur machine réelle pour vérifier au cas ou, parceque avec les émulateurs on ne sait jamais ....