Plusieurs problèmes - Page 2

On peut pas ce faire kicker sur un forum ( )...

Deeph> ahem.

Ok, je le saurai maintenant (même si pour moi, quand on est kicker on peut toujours revenir (comme sur les chats quoi...), donc c'est pas vraiment un kick...).

Juste pour revenir au sujet, comme j'ai pas arreter de coder aujourd'hui (j'ai avancé dans mon jeu de shoot), j'ai fait ça vite fait :



Mais j'ai un problème... Enfaite, je voudrai faire la sprite en niveau de gris (j'y arrive déjà plus ou moins), mais la fonction 'ionLargeSprite' d'Ion ne me copie les sprites qu'en XOR (c'est à dire que si j'affiche un pixel sur un autre allumé, il me l'éteint et si je l'affiche sur un pixel éteint, il me l'allume...), donc comment faire pour l'afficher normalement (il me l'affiche comme je veux, que les pixels soient allumés ou éteints...) ? (d'ailleur je sais pas si ça ce dit OR ou AND...)

very (./30) :
genre ça t'es souvent arrivé tellement les modos sont méchants et opressent le peuple dans une terrible dictature

souvenirs de tigen ou il bannaient a tour de bras

Je connais pas trop les routines de ION (je programme surtout les TI82) mais je pense que c'est l'instruction OR qui marche pour afficher des pixels comme tu veux, et AND pour les effacer...

Oui mais plus précisement, comment je fait pour afficher mes sprites comme je veux (genre comme tu peut faire sur 82...) ?

Bon bah pour mon problème avec les Sprite j'ai plus ou moins trouvé le truc : il faut utiliser les masques, mais je sais pas encore trop m'en servir...

Pour ce qui est de mon jeu, voilà une screen :



Le problème, c'est que dans ma source, j'ai fait en sorte qu'on est trois chance de toucher la cible, hors là j'en ai qu'une ().

Voilà la nouvelle source :

.nolist
#include "ion.inc"
#define Var1 8265h
#define Compteur 8266h
#define balles 8267h
#define PosC 8268h
#define CoorX 8269h
#define CoorY 8270h
;Groupe1 : 0feh
kDown .equ 254
kLeft .equ 253
kRight .equ 251
kUp .equ 247
;Groupe2 : 0fdh
kEnter .equ 254
kClear .equ 191
;Groupe7 : 0bfh
k2nd .equ 223
.list

#ifdef TI83P
.org ProgStart-2
.db $bb,$6d
#else
.org ProgStart
#endif

ret
jr nc,Start
.db "GunZ - Deeph",0

Start:
bcall(_ClrScrnFull)
bcall(_grbufclr)
bcall(_indicatorOff)
call Deeph_Aff
bcall(_homeup)
ld hl,text1
bcall(_puts)
call getKey
bcall(_ClrScrnFull)
bcall(_grbufclr)
ld hl,0
ld (Compteur),hl
ld a,3 ; J'y met bien 3 balle pourtant...
ld (balles),a ; là normalement je met la valeur de l'accumulateur (donc 3) dans la variable 'balles'...
call AffMain
call Aff

Jeu:
ld hl,(Compteur)
inc hl
ld (Compteur),hl
ld de,700
bcall(_CpHLDE)
call z,Aff
ld a,0ffh
out (1),a
ld a,0bfh
out (1),a
in a,(1)
cp k2nd
jp z,Tire
ld a,0ffh
out (1),a
ld a,0fdh
out (1),a
in a,(1)
cp kClear
jr z,End
jr Jeu

End:
bcall(_ClrScrnFull)
bcall(_grbufclr)
bcall(_indicatorOn)
ret

Aff:
bcall(_grbufclr)
call AffMain
ld hl,0
ld (Compteur),hl
ld b,3
call ionRandom
cp 0
jr z,Pos1
cp 1
jr z,Pos2
cp 2
jr z,Pos3

Pos1:
ld a,1
ld (Var1),a
ld a,4
ld (PosC),a
jr AffC

Pos2:
ld a,2
ld (Var1),a
ld a,36
ld (PosC),a
jr AffC

Pos3:
ld a,3
ld (Var1),a
ld a,68
ld (PosC),a
jr AffC

AffC:
ld b,16
ld c,2
ld a,(PosC)
ld l,0
ld ix,cible
call ionLargeSprite
call ionFastCopy
ret

Tire:
bcall(_grbufclr)
ld b,32
ld c,4
ld a,29
ld l,30
ld ix,sprite2
call ionLargeSprite
call ionFastCopy
ld b,16
ld c,1
ld a,41
ld l,13
ld ix,Tire2
call ionLargeSprite
call ionFastCopy
bcall(_grbufclr)
call AffMain
ld a,(balles) ; ici je copie la valeur des balles dans l'accu
cp 0 ; j'la compare à zero
jr z,Perdu ; si c'est vrai on a perdu
dec a ; sinon je décrement l'accu
ld (balles),a ; et je copie la valeur de l'accu (donc 'balles'-1) dans la variable 'balles'
ld a,(Var1)
cp 2
jr z,Gagne
jp jeu

Perdu:
bcall(_grbufclr)
bcall(_clrLCDFull)
bcall(_homeup)
ld hl,text3
bcall(_puts)
call getKey
jp End

Gagne:
bcall(_grbufclr)
bcall(_clrLCDFull)
bcall(_homeup)
ld hl,text2
bcall(_puts)
call getKey
jp End

AffMain:
ld b,32
ld c,4
ld a,28
ld l,32
ld ix,sprite1
call ionLargeSprite
call ionFastCopy
ret

getKey:
ld a,0ffh
out (1),a
ld a,0fdh
out (1),a
in a,(1)
cp kEnter
jr z,ret
jr getKey

ret:
ret

text1:
.db "Appui sur ENTER "
.db "pour tirer avec "
.db "ton flingue...",0

text2:
.db "Bravo ! Tu as "
.db "reussis a tuer "
.db "la cible ! ",0

text3:
.db "Perdu ! Desoler "
.db "mais tu est un "
.db "peu trop nul...",0

#include "Deeph.z80"

sprite1:
[SPRITE]

sprite2:
[SPRITE]

cible:
[SPRITE]

balle:
[SPRITE]

Tire2:
[SPRITE]

.end END

J'ai noter les endroit où je vérifie/stocke les balles (wai je sais j'suis nul en ASM...).

Bon bah finalement j'ai fait une version 0.1 dans laquelle on ne peut que tirer une fois et voir son score en miliseconde (c'est pas très parlant mais la flemme de convertir des miliseconde en seconde en ASM ). Sinon bah j'ai refait un peu le code (j'ai repris les bonnes partie et j'ai enlever le reste) et maintenant ça rend mieu je trouve. Si vous voulez tester : GunZ80. Donc quand j'aurai enfin fait ce que voulait avec ce jeu (c'est à dire ajouter le nombre de balle que je veux, afficher tout ça sur l'écran, ajouter un autre menu et faire un score plus 'lisible'), bah ça fera mon vrai premier 'jeu' en ASM . Après j'essairai surement de faire un pong ou un tunnel... (le pong est déjà commencer mais il me reste pleins de trucs à refaire...).

un screen pour les feigniassent qui ont la flemme de tester, c'est possible ?

C'est bon j'en ai fait une vite fait (y'a presque rien qui a changer niveau mise en page, graphismes, etc... la plupart des trucs que j'ai refait c'est sur le moteur du jeu...) :



Je trouve que mon projet à quand même bien évoluer puisque c'était ça au départ :

c'est le screen qui lague ou la Ti ?

A mon avis c'est ton navigateur qu'est lent parce que chez moi c'est asser rapide... (Ou alors télécharger l'image pour pouvoir la visionner sur ton PC).

Mon navigateur n'est jamais lent. (l'image est rapide, c'est pas le problème, c'est juste que la 1ere donne l'impression que la cible switch rapidement entre 3 positions 'stables', tu l'a fait exprès p-t ? )

Bah oui, il y a trois positions pour la cible (mais bon, c'est la première 'vrai' version donc voilà ). Sinon sur vrai calc, c'est bien plus rapide.

Bon voilà, j'ai plus ou moins laisser de coter 'GunZ80' pour le moment car j'ai décider de faire un petit jeu que j'avais déjà l'intention de créer depuis longtemps :



Il s'agit d'un petit jeu d'ésquive, dans lequel on contrôle un petit vaisseau et où on doit éviter des missiles (les graphismes sont volontairement pourrits car à la base ça devait être un simple test, pour voir si j'en était capable). Mais comme d'habitude, il y a un problème : le jeu ne quitte pas bien et ça donne l'éspèce de tas de pixels qui bouge lorsqu'on essaye. Donc voici le code :

.nolist
#include "ion.inc"
#define Vie 8267h
#define PosY 8268h
#define PosX 8269h
#define CoorX 8270h
#define CoorY 8271h
;Groupe1 : 0feh
kDown .equ 254
kLeft .equ 253
kRight .equ 251
kUp .equ 247
;Groupe2 : 0fdh
kEnter .equ 254
kClear .equ 191
.list

#ifdef TI83P
.org ProgStart-2
.db $bb,$6d
#else
.org ProgStart
#endif

ret
jr nc,Start
.db "Vaisseau Baston 1 - Deeph",0 ; super titre

Start:
bcall(_ClrScrnFull)
bcall(_grbufclr)
bcall(_indicatorOff)
call Deeph_Aff
ld a,3
ld (Vie),a ; on commence avec trois vies
ld a,0
ld (PosY),a
ld a,44
ld (CoorX),a
ld a,54
ld (CoorY),a

getKey: ; routine getKey et affichage sprite/gestion collision, etc...
call Aff
call AffE
ld a,0ffh
out (1),a
ld a,0feh
out (1),a
in a,(1)
cp kLeft
call z,DecX
cp kRight
call z,IncX
ld a,0ffh
out (1),a
ld a,0fdh
out (1),a
in a,(1)
cp kClear ; si on appuie sur CLEAR
jr z,Fin ; (normalement) c'est terminer
ld a,(Vie)
cp 0 ; si on a plus que 0 vies
jr z,Fin ; c'est aussi (normalement) terminer
jr getKey

Fin:
ret ; ça doit ce finir (mais c'est pas le cas)

DecX: ; on déplace la sprite à gauche
ld a,(CoorX)
cp 0
jr z,Ret
dec a
dec a
ld (CoorX),a
ret

IncX: ; on déplace la sprite à droite
ld a,(CoorX)
cp 72
jr z,Ret
inc a
inc a
ld (CoorX),a
ret

Ret:
ret

Aff: ; affiche tout le bordel
bcall(_grbufclr)
ld a,(CoorY)
ld l,a
ld a,(CoorX)
ld b,8
ld ix,Vaissau
call ionPutSprite
ld a,0
ld l,a
ld a,80
ld b,62
ld c,2
ld ix,Cadre
call ionLargeSprite
ld a,(Vie)
cp 1
call z,TeteN
cp 2
call nc,TeteO
ld a,(Vie)
cp 1
call z,Vie1a
cp 2
call z,Vie2a
cp 3
call z,Vie3a
call ionFastCopy
ret

TeteN: ; affiche la petite tête déçus qu'est en haut quand on a 1 vie
ld a,2
ld l,a
ld a,83
ld b,11
ld c,2
ld ix,Tete2
call ionLargeSprite
ret

TeteO: ; affiche la petite tête contente qu'est en haut quand on a 2 ou 3 vies
ld a,2
ld l,a
ld a,83
ld b,11
ld c,2
ld ix,Tete1
call ionLargeSprite
ret

Vie1a: ; on a une vie
ld a,26
ld l,a
ld a,84
ld b,17
ld c,1
ld ix,Vie1
call ionLargeSprite
ret

Vie2a: ; on a deux vies
ld a,26
ld l,a
ld a,84
ld b,17
ld c,1
ld ix,Vie2
call ionLargeSprite
ret

Vie3a: ; on a trois vies
ld a,26
ld l,a
ld a,84
ld b,17
ld c,1
ld ix,Vie3
call ionLargeSprite
ret

AffE: ; scroll le missile selon ses coordonnées
ld a,(CoorY)
ld b,a
ld a,(PosY)
cp b
call z,Coll
cp 0
call z,AffEnnemi
cp 63
call z,FinBoucle
ld a,(PosY)
inc a
inc a
inc a
ld (PosY),a
ld l,a
ld b,8
ld a,(PosX)
ld ix,Ennemi
call ionPutSprite
call ionFastCopy
ret

Coll: ; test la collision
ld a,(CoorX)
ld c,a
ld a,(PosX)
ld b,8

Loop1:
cp c
call z,CollY
dec a
djnz Loop1
ld a,(CoorX)
ld c,a
ld a,(PosX)
ld b,8

Loop2:
cp c
call z,CollY
inc a
djnz Loop2
ret

CollY:
ld a,(Vie)
dec a
ld (Vie),a
ret

FinBoucle:
ld a,0
ld (PosY),a
call AffEnnemi
ret

AffEnnemi: ; affichage d'un nouveau missile en haut de l'écran
ld b,72 ; au coordonnées X = nombre compris entre 0 et 72 (après y'a le cadre qui gène donc on ne peut pas aller à 96)
call ionRandom
push af
ld a,(PosY)
ld l,a
pop af
ld (PosX),a
ld b,8
ld ix,Ennemi
call ionPutSprite
call ionFastCopy
ret

#include "Deeph.z80" ; routine qui affiche mon pseud au début.

Ennemi:
[sprite]

Vaissau:
[sprite]

Cadre:
[sprite]

Vie3:
[sprite]

Vie2:
[sprite]

Vie1:
[sprite]

Tete1:
[sprite]

Tete2:
[sprite]

.end END

A mon avis, une des routines que j'ai appeler ne s'est pas terminer par 'ret' et ça doit tout faire bugger (mais j'ai tout vérifier et à prioris c'est pas ça). Sinon, à chaques fois que je quitte, je n'est pas le même bug, des fois c'est un 'ERREUR : SYNTAX' qui s'affiche (alors que c'est un programme ASM ), des fois l'écran s'éfface puis plus rien, etc...

J'adore ces codes de dizaines de lignes sans commentaires (ou presque)...

En même temps c'est long mais pas très compliqué... Les variables correspondent à :

#define Vie 8267h ; nombre de vie
#define PosY 8268h ; position du missile Y
#define PosX 8269h ; position du missile X
#define CoorX 8270h ; Coordonnée du vaisseau X #define CoorY 8271h ; Coordonnée du vaisseau Y

Mais de toute façons tout marche sauf le fait de vouloir quitter le jeu. Et puis sinon dit moi ce que tu ne comprend pas.

C'est pas une question de comprendre ou pas. Simplement, quand tu vois un code de cette taille avec aussi peu de commentaires, t'as pas envie de te lancer dedans...

'Le code est intrinsèquement explicite, il ne nécessite jamais de commentaire'

C'est pas une question de comprendre ou pas. Simplement, quand tu vois un code de cette taille avec aussi peu de commentaires, t'as pas envie de te lancer dedans...

C'est vrai, mais à mon avis, le peu que j'ai mis est suffisant...

Mouarf je viens de tester sur ma TI 84+ SE et ça marche, c'est VTI qui bug... ('tain j'ai passer du temps à chercher l'erreur et ça vennai de là >_< ). Je viens d'y ajouter des niveaux de gris mais comme VTI/PindurTI/etc... ont un problème avec mon jeu, je peut pas trop faire de screens...

Ça y est, je me suis remis un peu à coder en Asm, mais j'ai quelques questions sur la sauvegarde de donnée...

Enfaite, j'aimerai faire un classement des scores, mais je sais pas comment stocker les données pour ne pas qu'elle s'éffaces en quittant le programme (car je suppose que les variables définit avec les Saferam s'éffacent en quittant le jeu...). Je pense qu'on peut faire ça avec des matrices/listes mais là j'ai encore une autre question : Quelle est la différence entre '.db' et '.dw' ?

Ça avance bien, finalement je vais peut être le présenter à zContest (mais je vais surement pas gagner avec ).

Personne ne peut m'aider pour l'utilisation des listes ? Et sinon, j'ai un autre problème, à la fin on voit des signes s'affichés en dessous du "T'as perdu", je sais pas à quoi c'est dû (et mon programme ne fait que 3ko), personne ne sait d'où ça peut vennir ?

euh bah pour les score moi je n'utiliserai pas les liste mais j'inscrirais le resultat dans une zone du prog prevu pour:
je te passe un exemple trouvé dans asmguru
     push af                ; le score par exemple dans a            call _zerooop1      ; on utilise _chkfindsym pour trouver l'adresse du prog en memoire           ld de,op1           ld hl,prog           ld bc,13         ; le nombre d'octets a copier (le nombre de caractere du nom + 2)           ldir           call _chkfindsym           inc de        ; on calcule l'emplacement de HighScore dans le prog.           inc de           ld hl,highscore-$9D95           add hl,de           pop af        ; on rentre la valeur du score           ld (hl),a HighScore:     .db 0000h      prog:          .db 5,"NOM DU PROG",0
je sais pas si tu connait le fonctionnement de _chkfindsym donc j'ai mis des commentaires.

sinon je ne sais pas pour ion mais j'avais vu qu'avec mirageos il suffisait de rentrer les valeur dans le programme a partir de 9d95h pour que le prog enregistre définitivement le changement.
Enfin moi je programme sans shell donc je ne sais pas trop.


Sinon le probleme a la fin, pour moi c une erreur dans la pile. Tu n'a pas du retirer tout ce que tu a ajouté a la pile durant le prog du coup ton dernier ret final ne renvoi pas a l'os mais a une autre adresse.
Personnellement 90% des erreurs qui surviennent sont due a ça.

Ok, je vais tester ça.

Sinon, c'est quoi la différence entre '.db' et '.dw' ?

Et pour ce qui est de l'erreur à la fin, c'est peut être la pile (ou peut être pas...), mais ça me parai bizard que ça fasse ça car le programme ne se termine pas : je lui demande d'afficher un texte et j'appel ma routine de getKey avant de quitter... Au pire je vais mettre quelques 'pop af' et 'pop bc' pour voir si ça fait quelque chose (ça ne bug pas quand on demande au programme de prendre une valeur dans la pile qui n'éxiste pas ?).

Je n'ai jamais utilisé dw mais je crois que c la meme chose que db sauf que c pour definir un word (2 bytes successif)

sinon je te conseil de suivre attentivement ce que fait la pile dans ton code car je vois pas comment ca peut donner quelque chose de stable sinon.

J'aurais plutôt dit que dw. était fait pour un word...

Je viens de relire mon code, et à prioris le bug ne viens pas de la pile (il y a autant de 'push' que de 'pop' exécutés par le programme). Ça viens peut être d'une Rom call en rapport avec le format du texte...

Pour les 'high score', je vais voir ça un peu plus tard, histoire d'au moin bien coder cette partie du code .

C'est bon, j'ai trouver le bug de l'affichage, ça vennai du fait qu'une sprite dépasser d'un pixel en bas de l'écran (ça aurai été sur le côté, c'était pas grâve mais là ça a corrompu la mémoire). Donc bref, maintenant que j'ai régler ça j'essai de faire marcher les scores mais ça marche pas beaucoup... Voilà un bout de la source :

[...]
#define ScoreActu Saferam1+5
[...]
Fin: ; Label de quand on perd
bcall(_grbufclr) ; Efface le graph buffer
bcall(_clrLCDFull) ; Efface l'écran
bcall(_homeUp) ; Met le pointeur en (0,0)
ld hl,Text ; Charge le texte à afficher dans le registre hl
bcall(_puts) ; Affiche le texte à l'écran
call getK ; Appel ma routine de getKey (direct input)

ld a,(ScoreActu) ; Charge le score actuel dans l'accumulateur
push af ; Met la valeur du registre a dans la pile
call _zeroop1 ; On utilise _chkfindsym pour trouver l'adresse du programme en mémoire
ld de,op1 ; On charge la valeur d'op1 dans le registre de
ld hl,Prog ; On met la valeur de Prog dans hl
ld bc,13 ; Le nombre d'octets a copier (le nombre de caractère du nom + 2)
ldir ; copie, incrémente et recommence
call _chkfindsym
inc de ; on calcule l'emplacement de Score dans le prog.
inc de
ld hl,Score-$9D95
add hl,de
pop af ; On rentre la valeur du score (la variable ScoreActu, donc)
ld (hl),a

ret ; fin du programme

Text:
.db " T'as perdu ! ",0

Score:
.db 0000h

Prog: .db 5,"NOM DU PROG",0

(Donc ça c'est la fin du programme) Et v'là la partie du programme qui est supposée afficher le score :

[...]
lbl1:
[...]

lbl2:
bcall(_grbufclr)
bcall(_clrLCDFull)
bcall(_homeUp)
ld hl,(Score)
bcall(_puts)
call getK jp lbl1

Mais ça ne veut pas marcher, mais en même temps à mon avis c'est plus compliqué que ça...