[Résolu] Programmation directe du blitter : décalage

[sporniket]

Bonsoir,

Je suis en train de tester la programmation directe du blitter pour compléter le tutorial, et j'obtiens un resultat étrange : pendant près d'une vingtaine de ligne, tout va bien (note : en faisant des tests sur le nombre de mots copiés par ligne, je dirais même que tout va bien pendant un certain nombre de mots), puis à partir d'un moment les données sont décalé d'un mot supplémentaire.

Est-ce ma faute ? Un bug du blitter ?

Ci joint : le programme de test, la capture d'écran du résultat en couleur et en monochrome.

PS : au passage, pour la programmation directe, j'initialise des variables avec la directive ABSOLUTE, de sorte que la lecture/écriture de ces variables reviennent à lire/écrire les registres du blitter.

PPS : j'ai testé le programme à la fois sur Hatari (cf les captures d'écran) et sur un vrai Atari STE (en monochrome seulement, ce rougnougnou de cable péritel m'ayant laché... )

[leglod]

Salut, le probleme viens peut etre de la "dest%=XBIOS(2)+16000"
Sur STE la memoire video est a la fin de la ram et la taille est de 32000 , si t veux un buffet propre le mieux est d'utiliser des Malloc , si non tu prend l'adresse de l'ecran%-32000

Apres j'ai pas tester et je parle d'un 520STE ca change peut petre avec les mega et TT ??

[sporniket]

Ben en fait le coup du xbios(2) + 16000, c'est pour que le résultat apparaissent dans la moitié basse de l'écran, les données sources résidant dans la moitié supérieure de l'écran. Bref à priori je ne "déborde" pas, et d'ailleurs, je n'avais pas eu de problème en faisant ça avec les fonction bitblt de VDI et de la Line-A.

Je vais tout de même faire un essai, par acquis de conscience.

[sporniket]

J'ai fait l'essai avec différentes façon d'allouer le buffer source et cible : xbios(2), STRING$(32000,0), malloc(32000).

Dans tous les cas j'ai le même problème.

[leglod]

Utilise tu un double buffet avec Vsync j'ai pas regarder le listing en entier si tu ne fait pas de double buffet ecran avec swap et la syncro vertical c'ets normal ton probleme !

[sporniket]

Non pas de vsync, mais quand j'ai fait mes essai avec deux buffers alloués (pour l'écran source et cible), ces buffers n'avaient rien à voir avec l'écran (je faisais un bmove du buffer cible vers xbios(2) pour voir le résultat).

En faisant des tests, j'ai établi que je peux copier 128 mots correctement. C'est lors de la copie du 129eme qu'il y a un schmillblick...

J'ai essayé avec vsync, mais ça ne change rien.

[leglod]

Il faut que tu utilise la technique du swap ecran et pas la recopie d'ecran c'est trop lent !
Je ne me rappel plus trop bien mais ca peut se faire avec des xbios !
Tu travail sur un ecran virtuel tu fait tes trucs avec le blitter dans cet ecran virtuel tu applique le vsync puis tu dit au STe de changer l'adresse ecran d'affichage (xbios) dans l'adresse de l'ecran vituel !
Tu fait une boucle et quand tu recommence le programme sauf que cette fois l'ecran virtuel et l'ancien ecran logique !

Je crois que pour change l'adresse ecran c'est XBIOS 5

C'ets loint tout ca!

[sporniket]

Il faut que tu utilise la technique du swap ecran et pas la recopie d'ecran c'est trop lent !

Là c'est un programme pour tester le transfert, je n'ai pas besoin d'un affichage rapide avec utilisation de buffer offscreen qu'on échange avec xbios.
De toutes façon, le problème ne vient pas des emplacements mémoires sur lesquels je travail, donc j'utilise directement l'écran.

Là mon problème c'est de comprendre pourquoi ce **** de blitter ne veux pas transferer mes données correctement quand je déplace plus de 128 mots...

Je sais que j'ai fait une erreur quelque part, le tout est de trouver où...

[sporniket]

Je sais que j'ai fait une erreur quelque part, le tout est de trouver où...

Bon ben, il semblerait qu'utiliser des ABSOLUTE pour tripoter les registres ne soit pas une si bonne idée... en faisant directement des LONG/WORD/BYTE{...} ça marche impeccable...

*grunt*