Bonjour à tous smile
Etant débutant dans la programmation en asm Z-80, ma question sera simple :
Comment fait on pour vérifier l'état d'un pixel (savoir s'il est allumé ou non)? Ceci étant dans le but de gérer des collisions lors de l’exécution d'un jeu.
En TI basic il existe la fonction "pxl-Test"(très explicite), mais en asm je n'ai pas trouvé d'équivalent dans les tokens et je n'ai pas non plus trouvé un autre moyen me permettant de vérifier l'état d'un pixel sur l'écran ou dans le graphe_buffer.
En vous remerciant d'avance.
Déjà tu pourrais faire comme ça (attention je teste dans le graphbuffer pas le lcd réel) :
; a = x
; e = y
GET_BYTE:
; y * 12
ld hl, 0
ld d, 0
add hl, de ; 1
add hl, de ; 2
add hl, de ; 3
add hl, hl ; 6
add hl, hl ; 12

; x / 8
ld d, 0
ld e, a
srl e ; / 2
srl e ; / 4
srl e ; / 8
add hl, de

; A present on a le decalage dans hl

ld de, plotsscreen ; Prendre le debut du graphbuffer
add hl, de ; Puis ajouter le decalage

ld a, (hl)
ret

; a = x
; e = y
; retourne a = 1 si pixel allumé, a = 0 sinon
PIXEL_TEST:
ld c, a
ld b,00000111b
and b
ld b, a ; Sauver dans b pour la boucle

cp 0
jp z,aligne
ld a, 10000000b
jp nonaligne

aligne:
ld a, 10000000b
jp test

nonaligne:
srl a
djnz nonaligne

test:
ld b, a ; sauver dans b
push bc
ld a, c
call GET_BYTE
pop bc
and b
cp 0
jp z, return_zero
ld a, 1
ret
return_zero:
ld a, 0
ret


Et tester avec ça :
.nolist
#define EQU .equ
#include "ti83asm.inc"
#include "tokens.inc"
#define xcoord 8270h
#define ycoord 8272h

.list

.org 9327h

START:
; Turn the indicator to off and clear screen
call RINDOFF ; Turn off runindicator


loop:
call BUFCLR
call BUFCOPY

ld a, 0
ld e, 0
ld ix, sp
call DRAW_SPRITE
call BUFCOPY
call WAITKEY

; Test donne 1
ld a, 0
ld e, 0
call PIXEL_TEST
ld h, 0
ld l, a
call _dispHL
call WAITKEY

; Test donne 0
ld a, 1
ld e, 0
call PIXEL_TEST
ld h, 0
ld l, a
call _dispHL
call WAITKEY

; Test donne 1
ld a, 1
ld e, 1
call PIXEL_TEST
ld h, 0
ld l, a
call _dispHL
call WAITKEY

ret
.end
end



sp:
.db 10000000b
.db 11000000b
.db 11100000b
.db 11110000b
.db 11111000b
.db 11111100b
.db 11111110b
.db 11111111b

#include "sprites.routines.asm"



Y a aussi un fonction getPixel dans la librairie de ion mais je ne sais pas exactement ce qu'elle fait :
http://joewing.net/programs/calc/ti83/ion/libs.shtml#getpixel

Si tu as des questions sur mon code ou n'importe quoi d'autre à propos d'asm n'hésite pas, tu es au bon endroit smile
Euh... je suis désolé mais... je n'ai pas compris en quoi les premières lignes de ton code représentent un décalage.
Contra (./2) :
; a = x
; e = y
GET_BYTE:
; y * 12
ld hl, 0
ld d, 0
add hl, de ; 1
add hl, de ; 2
add hl, de ; 3
add hl, hl ; 6
add hl, hl ; 12

; x / 8
ld d, 0
ld e, a
srl e ; / 2
srl e ; / 4
srl e ; / 8
add hl, de

; A present on a le decalage dans hl

ld de, plotsscreen ; Prendre le debut du graphbuffer add hl, de ; Puis ajouter le decalage


N'aurait il pas fallu réaliser un modulo 8 sur l'abscisse pour avoir le décalage ? Car là, j'ai plutôt l'impression que l'on a l'adresse du graphe buffer à laquelle il faut ancrer le sprite non ? A moins que je n'ai rien compris fou ?
Enfin bon, je connais ta réputation dans le domaine et je pense que mon raisonnement doit être faux. J'attendrai donc que tu apportes tes lumières sur le sujet smile

Je n'ai pas eu le temps de te répondre ce week end désolé.

Le terme décalage porte à confusion, tu as raison dans ce que tu dis mais je vais t'expliquer le code et tu verras que c'est plutôt simple.
En fait la comparaison se fait en 2 temps. Tout d'abord on va chercher l'octet dans le graph buffer avec la fonction GET_BYTE qui mettra l'octet dans a.
Ensuite, comme on test un pixel et non un octet, on va decaler notre pattern de test pour le and en fonction du reste de x.
Donc on met 10000000b dans a, et si on est aligné (cad ld c, a \ld b,00000111b \ donne 0 dans a) alors on ne décale rien car le bit sera le bit le plus fort.
Sinon on mets dans b le nombre de shift à faire, et on decale a.
Lorsqu'on a décalé, on cherche l'octet avec GET_BYTE et on teste.
La fonction GET_BYTE ressemble au début d'une fonction de dessin de sprite car on va se déplacer dans le graphbuffer pour aller au bon emplacement.

Ton gbuf ressemble à ça :
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00100000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b
.db 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b, 00000000b


J'ai mis un pixel alumé en (2, 1).
Donc lorsqu'on appelle PIXEL_TEST on doit avoir a = 2 et e = 1
On commence par sauver a dans c pour après (pour le GET_BYTE) avec ld c, a
Ensuite on cherche à savoir le reste de la division entière x / 8 en faisant : ld b, 00000111b \ and b
Ensuite on regarde si le reste vaut 0 (dans ce cas la on est aligne : cp 0 \jp z,aligne
Sinon on doit décaler le pattern de test : ld a, 10000000b \ jp nonaligne
On avait mis le reste (< 8) dans b donc on a plus qu'à boucler et decaler : nonaligne: \ srl a \ djnz nonaligne
Ensuite on sauve le pattern : ld b, a \
On récupere le x qu'on a sauvé tout au début : ld a, c
On va chercher l'octet : call GET_BYTE
Et puis on test : pop bc \ and b \ cp 0 \ jp z, return_zero\ ld a, 1 \ ret \ return_zero: \ ld a, 0

Voila je te remets le code ci dessous.
; a = x
; e = y
GET_BYTE:
; y * 12
ld hl, 0
ld d, 0
add hl, de ; 1
add hl, de ; 2
add hl, de ; 3
add hl, hl ; 6
add hl, hl ; 12

; x / 8
ld d, 0
ld e, a
srl e ; / 2
srl e ; / 4
srl e ; / 8
add hl, de

; A present on a le decalage dans hl

ld de, plotsscreen ; Prendre le debut du graphbuffer
add hl, de ; Puis ajouter le decalage

ld a, (hl)
ret

; a = x
; e = y
; retourne a = 1 si pixel allumé, a = 0 sinon
PIXEL_TEST:
ld c, a
ld b,00000111b
and b
ld b, a ; Sauver dans b pour la boucle

cp 0
jp z,aligne
ld a, 10000000b
jp nonaligne

aligne:
ld a, 10000000b
jp test

nonaligne:
srl a
djnz nonaligne

test:
ld b, a ; sauver dans b
push bc
ld a, c
call GET_BYTE
pop bc
and b
cp 0
jp z, return_zero
ld a, 1
ret
return_zero:
ld a, 0 ret

Enfin bon, je connais ta réputation dans le domaine et je pense que mon raisonnement doit être faux. J'attendrai donc que tu apportes tes lumières sur le sujet


Tiens, je ne savais pas que j'avais une "réputation" grin
De toute façon ça ne m'empêche pas de dire des conneries, et d'admirer beaucoup d'autres programmeurs.

Si tu as d'autres questions...
Quel genre de jeu tu veux faire?
Merci pour tes explications détaillées Contra smile , je comprend mieux pourquoi tu me parlais de décalage au début de ton programme. De plus, cela m'a également permis de mieux comprendre comment est structuré le graphe buffer, vraiment merci top .
Cependant j'ai encore une toute petite question grin : (hl) correspond bien à la valeur contenue à l'adresse vers laquelle pointe hl (ici c'est donc bien 01000000b) ? De plus je crois que je n'ai pas saisi ce qu'est le "pattern" qui réaliserait un modulo sur 01000000b pour pouvoir tester si le pixel est allumé ou non :
Sinon on doit décaler le pattern de test : ld a, 10000000b \ jp nonaligne
On avait mis le reste (< 8) dans b donc on a plus qu'à boucler et decaler : nonaligne: \ srl a \ djnz nonaligne
Ensuite on sauve le pattern : ld b, a \
[...] Et puis on test : pop bc \ and b \ cp 0 \ jp z, return_zero\ ld a, 1 \ ret \ return_zero: \ ld a, 0

Quel genre de jeu tu veux faire?

Un jeu où le joueur représente un coureur qui va de plus en plus vite et doit sauter par dessus des hais ou se baisser pour éviter des obstacles en hauteur, ainsi qu'éventuellement sauter pour attraper des pièces afin d'accroître son score qui croît initialement avec la distance parcourue.
Tiens, je ne savais pas que j'avais une "réputation" grin

Eh bien je suis heureux de t'apprendre que le pseudonyme de Contra passe rarement inaperçu sur les forums dédiés à la programmation pour processeur z80 smile
En fait, ce que j'appelle pattern c'est le fait que l'on veut tester seulement un bit et non un octet entier.

Donc si un seul pixel est allumé, il faut decaler l'octet qui nou servira à comparer.
En fait, si on teste (0, 0) alors on fait un and avec 10000000b
Si on teste (1, 0) alors on fait un and avec 01000000b
Si on teste (2, 0) alors on fait un and avec 00100000b
Si on teste (3, 0) alors on fait un and avec 00010000b
Si on teste (4, 0) alors on fait un and avec 00001000b
Si on teste (5, 0) alors on fait un and avec 00000100b
Si on teste (6, 0) alors on fait un and avec 00000010b
Si on teste (7, 0) alors on fait un and avec 00000001b

Puis des qu'on teste (8, 0) alors ce sera un pattern comme ceci 10000000b (comme pour (0,0))

D'ou le décalage en fonction du reste de la division.

Pour ld a, (hl) tu as raison, on copie le contenu à l'adresse dans hl.

Si tu fais :
ld hl, plotsscreen ; ou gbuf (adresse de depart du graph buf)
ld a, (hl)

Tu récupères le premier octet du graphbuf.
Un jeu où le joueur représente un coureur qui va de plus en plus vite et doit sauter par dessus des hais ou se baisser pour éviter des obstacles en hauteur, ainsi qu'éventuellement sauter pour attraper des pièces afin d'accroître son score qui croît initialement avec la distance parcourue.


Je vois le genre de jeu que tu veux faire. Il existe des version flash de ce jeu sur le net.

Ca ressemble un peu à ce projet que j'ai quasiment terminé recemment :
gravity4.gif

Donc je pourrais t'aider sans problème si besoin est grin

Alors là merci Contra, je crois que j'ai tout saisi grâce à toi top
Sinon impressionnant ton jeu ! C'est un effet de changement de gravité que subit la balle lorsqu'elle s'accroche et se décroche des plate-forme en hauteur ? Est-ce un jeu destiné aux TI ?
C'est vrai qu'il "ressemble dans l'idée" au mien mais son concept est beaucoup plus poussé.
Je tiens encore une fois à te remercier, et je te promets que je n'hésiterai pas à solliciter ton aide dès que mon programme n'avancera plus, ce qui devrait vite arriver smile
Oui, la meilleure façon de tester un pixel ce n'est pas de lire directement du LCD, ça est très lent (la driveur LCD est tres lente).
Voici quelques optimisations (je ne l'ai pas encore essayé, il se peut qu'il y ait des bogues)
; a = x 
; e = y 
GET_BYTE: 
; y * 12
ld l,e
ld h,0 ;essentiellement ld hl,e
ld d,h ;h=0, comme ci c'est plus vite/petit
add hl,hl ;x2
add hl,de ;x3
add hl,hl ;x6
add hl,hl ;x12 colonnes dans le gbuf

; x / 8 
;ld	d, 0 ;d est toujours 0
and %11111000
rra ;/2 rra prend un octet, 4 t-states. en général, il est mieux de modifier "a" quand tu peux, les instructions qui fonctionnent sur "a" sont souvent plus vites/petites
rra ;/4
rra ;/8
ld e, a 
add hl, de ;ajouter offset x a gbuf

; A present on a le decalage dans hl 

ld	de, plotsscreen	; Prendre le debut du graphbuffer 
add	hl, de	 ; Puis ajouter le decalage 

ld	a, (hl) 
ret 

; a = x 
; e = y 
; retourne drapeau z(éro) est armé si pixel n'est pas allumé, desarmé si allumé
PIXEL_TEST: 
ld	c, a	
and %00000111
ld	b, a	 ; Sauver dans b pour la boucle 
or a ;or a fait la meme chose que cp 0, mais comme j'ai dit, les instructions qui operent sur a sont plus vites et plus petites 
ld	a, 10000000b ;ou ld a,%10000000, c'est la meme chose 
jr z,aligne 
rra 
djnz	nonaligne 

aligne:
push af
ld	a, c 
call	GET_BYTE 
pop	bc ;nous poussons af mais "popons" bc 
and	b
ret
Je suis content de voir un autre programmeur asm ici ! grin Si tu as des questions n'hésite pas a nous les poser !