1

Bon comme j'ai finit mon premier (vrai) projet ASM, je me suis mis à quelque chose d'un peu plus compliqué, il s'agit d'un jeu de shoot... Mais j'ai plusieur problèmes :

-En premier, j'arrive pas à compiler le projet (je peut compiler tout les autres programmes mais pas lui sad)... Voici ce que me marque le compilo :
tasm: pass1 complete.
Divide error ----- There were errors.


J'ai eu ce problème lorsque j'ai ajouter une sprite 16x16, je pense que lorsque le programme découpe la sprite (avec ionLargeSprite), il doit faire une erreur (d'où le Divide error), mais je suis pas du tout sur que c'est due à ça...

-Ensuite, le programme va trop vite (pas le temps de voir s'afficher les sprites...), comment je pourrai faire pour ralentire l'éxecution ? Est-ce qu'il éxiste des rom_call ? J'ai déjà essayer en incrémentant l'accumulateur jusqu'a ce qu'il vaille 255, mais c'est encore bien trop rapide...

2

Bon, j'ai regler le problème du "Divide error" en mettant la sprite en héxa au lieu de l'écrire en Binaire. Par contre, je sais toujours pas comment ralentir tout ça....

3

Pour ralentir le jeu, tu peux peut-être utiliser la commande HALT qui passe le processeur en mode d'économie d'énergie jusqu'à la prochaine interruption. Si tu règles les interruptions sur une vietesse lente et que tu fais une petite boucle contenant les halt, y'a peut-être moyen. Mais il y a à coup sûr plein d'autres possibilités.

4

Heu... Comment j'utilise cette commande ?

5

ben, t'écris :
halt

wink


6

Ha d'accord cheeky... Sinon c'est quoi "la prochaine interruption" ?

edit : Toujours trop rapide...

edit2: Voilà ce que ça donne :

gunznc4.gif

En gros je voudrai ralentire l'affichage des monstres afin qu'on puisse tirer juste lorsque le monstre ce met devant le pistolet... Parce que là, tout marche, mais c'est hyper trop rapide, et l'arme tire trop rapidement (20 tires en une seconde cheeky).

7

   ld b,255
wait:
   halt
   djnz wait
-pacHa

8

sad Maintenant les sprites s'affichent, mais elles disparaissent aussi vite... Voilà la source pour ceux que ça interesse :
.nolist
#include "ion.inc"
#define bcall(xxxx) rst 28h \ .dw xxxx
#define Var1 8265h
#define Var2 8266h
_rclX .equ 4AE0h
;Groupe1 : $FE
kDown .equ 254
kLeft .equ 253
kRight .equ 251
kUp .equ 247
;Groupe2 : $FD
kEnter .equ 254
kClear .equ 191
.list

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

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

Start:
bcall(_clrLCDFull)
bcall(_indicatorOff)
bcall(_homeup)
ld hl,text1
bcall(_puts)
call getKey
bcall(_clrLCDFull)
ld a,0ffh
out (1),a

Jeu:
call Affichage_I1
ld a,$FD
out (1),a
in a,(1)
cp kEnter
jp z,Affichage_I2
call Affichage_Monstre
cp kClear
jp z,End
jp nz,Jeu

Affichage_I1:
ld hl,sprite1
ld de,PLOTSSCREEN
ld bc,768
ldir
bcall(_grbufcpy)
ret

Affichage_I2:
ld hl,sprite2
ld de,PLOTSSCREEN
ld bc,768
ldir
bcall(_grbufcpy)
ld hl,sprite3
ld de,PLOTSSCREEN
ld bc,768
ldir
bcall(_grbufcpy)
jp Jeu

Affichage_Monstre:
ld b,100

Attend:
halt
djnz Attend
ld b,3
call ionRandom
cp 0
jp z,Pos1
cp 1
jp z,Pos2
cp 2
jp z,Pos3

Pos1:
ld a,1
ld (Var1),a
jp AfMoN1

Pos2:
ld a,2
ld (Var1),a
jp AfMoN2

Pos3:
ld a,3
ld (Var1),a
jp AfMoN3

AfMoN1:
ld b,16
ld c,2
ld a,4
ld l,0
ld ix,monstre
call ionLargeSprite
bcall(_grbufcpy)
ret

AfMoN2:
ld b,16
ld c,2
ld a,36
ld l,0
ld ix,monstre
call ionLargeSprite
bcall(_grbufcpy)
ret

AfMoN3:
ld b,16
ld c,2
ld a,68
ld l,0
ld ix,monstre
call ionLargeSprite
bcall(_grbufcpy)
ret

getKey:
ld a,0ffh
out (1),a
ld a,$FD
out (1),a
in a,(1)
cp kEnter
jp z,ret
jp nz,getKey

ret:
ret

End:
bcall(_clrLCDFull)
bcall(_homeup)
ret

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

[Sprite]

.end END

9

j'ai aps le temps de lire la source, mais est-ce que tu fais bien ces choses dasn l'ordre :

affichage sprite
attente (et ptet détection de tir pendant ce temps)
effaçage sprite

?
-pacHa

10

Là je fait dans l'ordre :

-Affichage de la main avec le flingue;
-Choisit un nombre entre 1 et 3;
-Grace à ce nombre il determine la position de la sprite monstre;
-Affichage du monstre (sans pour autant l'éffacer);
-Détection très courte de la touche (parce que je ne sais pas comment proceder pour attendre et en même temps vérifier l'appui d'une touche);
-On recommence tout.

Voilà, c'est un petit résumé de ce que j'ai essayer de faire...

11

huh tout d'abord, tu devrais faire un 'push af' avant le 'call Affichage_Monstre', puis un 'pop af', sans quoi ton cp n'a aucun sens, étant donné que a sera très vraisemblablement détruit dans tout ce que fait 'Affichage_Monstre'

sinon, pour attendre tout en détectant les touches, je pense (c'et loin tout ça dans ma tête) que tu peux simplement te permettre de faire la boucle de ralentissement, puis de lire le clavier _après_
à essayer...
-pacHa

12

Oui mais avec quel fonction je ralentit ma boucle ? Pour ce qui est du "push af" et du "pop af", je testerai plus tard, mais je suis pas sur que ça vienne de ça...

13

Tu peux très bien insérer un getcsc dans la boucle de ralentissement...

14

bah il va surement en falloir des tonnes pour ralentir la boucle...

15

des tonnes de quoi ? Pas de getcsc j'espère... Tu n'as qu'à mettre cinq "halt" à la suite dans la boucle de Pacha, tu verras bien ce que ça fait...

16

Oui mais ça me permetera pas de tester les touches du clavier en même temps... C'est ça que je voudrai éviter, mais ça à l'aire difficile à faire...

17

ah, oui, je vois...

Cela dit, une boucle avec un halt et un getcsc, ça marche trés bien, car la vitesse standard des interruptions est de une tous les 200 ième de secondes... C'est ce que j'utilise dans penalty...

18

Finalement je vais faire quelques tests et je verrai ce que ça donne parce que là j'vais plus avoir internet avant 3-4 jours donc j'aurai surement le temps de trouver la solution...

19

Ca marche pas parce que tu ne fait que ralentir le jeu avec les boucles halt, il faut ralentir seulement les monstres: pour cela tu peux mettre un compteur au début de ta routine Afficher_monstre: à chaque fois que tu arrive dans la boucle Jeu, tu augmente ce compteur de 1, quand le compteur arrive à 5000 (environ), tu apelle la routine Afficher monstre.
comme ça du détecte les touches normalement, mais tes monstres sont ralentis. Ca donne ceci:

Jeu:
call Affichage_I1
ld a,$FD
out (1),a
in a,(1)
cp kEnter
jp z,Affichage_I2
ld hl,(compteur)
inc hl
ld (compteur),hl
ld de,5000
call CP_HL_DE
call z,Affichage_Monstre
cp kClear
jp z,End
jp nz,Jeu


; ...

Affichage_Monstre:
ld hl,0
ld (compteur),hl
;...

20

Ok, je pense que j'essairai cette solution un peu plus tard (en ce moment je travail mon jeu pour le concours 2007).

21

Bon finalement j'ai essayer plein de truc, en fait, mon programme marche bien (du moins au niveau du monteur du jeu), le truc qui bug c'est l'affichage des sprites. En effet, lorsque j'utilise l'affiche à partir d'Ion, il effacer le graph buffer donc on ne voit plus le flingue. Ensuite, j'affiche le flingue avec les fonctions :
ld de,PLOTSSCREEN
ld bc,768
ldir bcall(_grbufcpy)


Et là tout bug... Enfaite il faut que j'affiche tout avec Ion plutot qu'utiliser les fonctions citées plus haut. 'fin bref, tout ça pour dire, est-ce que quelqu'un à un logiciel pour faires ses sprites puis les éxporter sous forme d'un code binaire et non pas héxadécimal comme CalcGS ?

22

Bon, désoler pour le double post, mais je viens de modifier entierement mon code et je l'ai un peu optimisé... J'ai aussi trouver un logiciel pour créer mes sprites en binaire et maintenant mon code ressemble plutot à ça :
.nolist
#include "ion.inc"
#define bcall(xxxx) rst 28h \ .dw xxxx
#define Var1 8265h
#define Compteur 8266h
;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(_clrLCDFull)
bcall(_indicatorOff)
bcall(_homeup)
ld hl,text1
bcall(_puts)
call getKey
bcall(_clrLCDFull)
ld b,100
ld a,0ffh
out (1),a
call Affichage_I1

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

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

Affichage_I2:
ld b,32
ld c,4
ld a,29
ld l,32
ld ix,sprite2
call ionLargeSprite
call ionFastCopy
bcall(_grbufclr)
ld b,32
ld c,4
ld a,28
ld l,32
ld ix,sprite1
call ionLargeSprite
call ionFastCopy
ld a,(Var1)
cp 2
jp z,gagne
jp nz,perdu

Affichage_Monstre:
bcall(_clrLCDFull)
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
jr AfMoN1

Pos2:
ld a,2
ld (Var1),a
jr AfMoN2

Pos3:
ld a,3
ld (Var1),a
jr AfMoN3

AfMoN1:
ld b,16
ld c,2
ld a,4
ld l,0
ld ix,monstre
call ionLargeSprite
call ionFastCopy
ret

AfMoN2:
ld b,16
ld c,2
ld a,36
ld l,0
ld ix,monstre
call ionLargeSprite
call ionFastCopy
ret

AfMoN3:
ld b,16
ld c,2
ld a,68
ld l,0
ld ix,monstre
call ionLargeSprite
call ionFastCopy
ret

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

ret:
ret

gagne:
bcall(_grbufclr)
bcall(_clrLCDFull)
bcall(_homeup)
ld hl,text2
bcall(_puts)
call getKey
jr End

perdu:
bcall(_grbufclr)
bcall(_clrLCDFull)
bcall(_homeup)
ld hl,text3
bcall(_puts)
call getKey
jr End

End:
bcall(_clrLCDFull)
bcall(_homeup)
ret

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

text2:
.db "Bravo ! Tu as "
.db "reussis a tuer "
.db "le monstre ! ",0

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


sprite1:
[Sprite]

sprite2:
[Sprite]

monstre:
[Sprite]

.end END


J'ai modifier les "jp" par des "jr" lorsque c'était possible pour augmenter un peu la vitesse et aléger le jeu. J'ai aussi utiliser le 'call ionFastCopy' à la place du simple "bcall(_grbufcpy)", donc en tout le programme fait 1 ko... J'ai refaite les images, maintenant ça donne ça :

gunz2sl4.gifmain1lr7.pngmain2xu8.png

(je sais, on voit pas grand chose sur les images...)

Donc les graphismes n'ont pas trop changés, mais je pense les améliorer prochainement...

Ce qu'il me reste à faire pour que ce soit un jeu correcte :

-ajouter des munition (simple à faire);
-n'afficher qu'un monstre à la fois (j'vais voir ce que je peut faire à ce niveau là);
-ajouter des menus (simple aussi).

Je précise que pour l'instant ce jeu est compatible TI 83/83+.

23

ça commenece a prendre de l'ampleur...
bravo!
continue!

24

cheeky Je vais essayer de l'améliorer d'ici le début du concours (lorsque le site pour s'inscrire sera pret), comme ça je pourrai peut être le présenter lui aussi.

Aufaite, qui va s'inscrire au concours ? (juste pour voir si je serai tout seul dans la catégorie basic étendu et/ou asm...)

25

moi!!!
je te battrai!!!
^^ boing

26

trinon En asm ou en Basic (étendu) ?

27

Boah les deux si tu veux ^^
non jdeconne le pro en asm de nous deux c'est toi oui

en basic etendu donc tripaf

28

Nan je débute juste en ASM, il me reste beaucoup de trucs à apprendre...

29

oui mais par rapport a moi...
enfin revenons au sujet, jvoudrais pas me faire kicker...

30

genre ça t'es souvent arrivé tellement les modos sont méchants et opressent le peuple dans une terrible dictature triso
«Les gens exigent la liberté d’expression pour compenser la liberté de pensée qu’ils préfèrent éviter.» - Sören Kierkegaard

La République, c’est comme la syphilis : quand on l’a attrapée, soit on se fait sauter le caisson, soit on essaie de vivre avec.