La Place des Développeurs [En COURS] Moteur de Sprites Moteur de Sprites
Toujours dans mon Projet Joe&Mac, voici la toute première ébauche d'un moteur de Sprite avec pesanteur.
SPRITES.dsk
Voici le code:
SPRITES.dsk
Voici le code:
Code TEXT :
Edité par
igal
Le 15/02/2015 à 16h33
10 'save"SPRITE03.asc",a
20 SCREEN5,2:'VDP(24)=VDP(24)+44
30 VH=32:VM=32:VS=32:VC=32:VD=32:P=8:M=0:Z=80
32 'VH=>Haut / VM=>Monte / VS=>Saute / VC
40 X=128:Y=128:T=211-16:U=211-64:W=80
42 'X et Y => Hero / T=>Plateau 1 / U=>Plateau 2 / W=Mobile
50 GOTO 250
70 PUTSPRITE0,(X,Y)
75 PUTSPRITE1,(14,T),1,0:PUTSPRITE9,(14,U),1,0
80 PUTSPRITE2,(45,T),1,0:PUTSPRITE10,(45,U),1,0
90 PUTSPRITE3,(76,T),1,0:PUTSPRITE11,(76,U),1,0
100 PUTSPRITE4,(107,T),1,0:PUTSPRITE12,(107,U),1,0
110 PUTSPRITE5,(138,T),1,0
120 PUTSPRITE6,(169,T),1,0
130 PUTSPRITE7,(200,T),1,0
140 PUTSPRITE8,(231,T),1,0:PUTSPRITE16,(Z,W),5,0:PUTSPRITE17,(Z-31,W),5,0
150 S=STICK(0):ONS+1GOSUB 160,170,180,190,200,210,220,230,240:Z=Z+4AND255
155 IFM=0THENY=Y+P
157 GOTO 70
160 X=X:Y=Y:ONSPRITE GOSUB1000:SPRITEON:RETURN:'statique
170 X=X:Y=Y-VM:M=0:ONSPRITE GOSUB1010:SPRITEON:RETURN:'haut
180 X=X+VS:Y=Y-VS:M=0:ONSPRITE GOSUB1020:SPRITEON:RETURN:'haut droite
190 X=X+VH:Y=Y:ONSPRITE GOSUB1030:SPRITEON:RETURN:'droite
200 X=X+VC:Y=Y+VC:ONSPRITE GOSUB1040:SPRITEON:RETURN:'droite bas
210 X=X:Y=Y+VD:ONSPRITE GOSUB1050:SPRITEON:RETURN:'bas
220 X=X-VC:Y=Y+VC:ONSPRITE GOSUB1060:SPRITEON:RETURN:'bas gauche
230 X=X-VH:Y=Y:ONSPRITE GOSUB1070:SPRITEON:RETURN:'gauche
240 X=X-VS:Y=Y-VS:M=0:ONSPRITE GOSUB1080:SPRITEON:RETURN:'haut gauche
250 FOR I=1TO16:READA$:S$=S$+CHR$(VAL("&B"+LEFT$(A$,8))):NEXTI
260 RESTORE 300
270 FORI=1TO16:READA$:S$=S$+CHR$(VAL("&B"+RIGHT$(A$,8))):NEXTI
280 SPRITE$(0)=S$
290 GOTO 70
300 DATA 1111111111111111
310 DATA 1000000000000001
320 DATA 1000000000000001
330 DATA 1000000000000001
340 DATA 1000000000000001
350 DATA 1000000000000001
360 DATA 1000000000000001
370 DATA 1000000000000001
380 DATA 1000000000000001
390 DATA 1000000000000001
400 DATA 1000000000000001
410 DATA 1000000000000001
420 DATA 1000000000000001
430 DATA 1000000000000001
440 DATA 1000000000000001
450 DATA 1111111111111111
1000 SPRITE OFF:M=1:RETURN:'SCREEN0:PRINT"colision statique":END
1010 SPRITE OFF:M=1:RETURN:'SCREEN0:PRINT"colision haut":END
1020 SPRITE OFF:M=1:RETURN:'SCREEN0:PRINT"colision haut droite":END
1030 SPRITE OFF:M=1:RETURN:'SCREEN0:PRINT"colision droite":END
1040 SPRITE OFF:M=1:RETURN:'SCREEN0:PRINT"colision droite bas":END
1050 SPRITE OFF:M=1:RETURN:'SCREEN0:PRINT"colision bas":END
1060 SPRITE OFF:M=1:RETURN:'SCREEN0:PRINT"colision bas gauche":END
1070 SPRITE OFF:M=1:RETURN:'SCREEN0:PRINT"colision gauche":END
1080 SPRITE OFF:M=1:RETURN:'SCREEN0:PRINT"colision haut gauche":END
Voici DSK en chaire et en os 
SPRITES.dsk
(Me rend compte que j'ai pas de compresseur sur le Pc de ma femme)
SPRITES.dsk
(Me rend compte que j'ai pas de compresseur sur le Pc de ma femme)
Les Sprites me serviront principalement à matérialiser le sol et induire des causalités.
Seuls le hero, le tir et un ou deux ennemis seront visibles sous forme de "cube".
Les Sprites me serviront en les superposant au scroll mais ils devront être invisibles.
Par exemple, je voudrais créer un groupe de Sprite qui sera matérialisera le sol.
Je suis en train de reprendre le code pour mieux le mettre à plat.
Seuls le hero, le tir et un ou deux ennemis seront visibles sous forme de "cube".
Les Sprites me serviront en les superposant au scroll mais ils devront être invisibles.
Par exemple, je voudrais créer un groupe de Sprite qui sera matérialisera le sol.
Je suis en train de reprendre le code pour mieux le mettre à plat.
heu ... igal...
je peux me tromper mais'sur un sprite invisible tu ne peux pas détecter de collision.
La detection se fait uniquement sur les pixels colorisés (il me semble
)
je peux me tromper mais'sur un sprite invisible tu ne peux pas détecter de collision.
La detection se fait uniquement sur les pixels colorisés (il me semble
)
Il me semble que ce sont là différence des "profondeurs des plans" qui rend les collisions impossibles.
ON SPRITE GOSUB ne fait qu indiquer une action à suivre en cas de collision.
Je me trompe peut être mais le sujet est ouvert pour ça et surtout aborder la question sous des angles autres que ceux habituels.
Par exemple, on m'a TOUJOURS dit "Non, on ne peut pas créer les Sprites comme tu le pense" à savoir:
Plaquer un dessin (16×16) dans sur l'écran et en faire un vrai Sprite!
Pourtant, il suffit de rendre visible les zones réservées par VDP (24)=VDP (24)+44 Pour rendre la zone visible.
Ensuite tu baisses la vitesse de l emulateur au minimum.
Tu lances le programme et tu verras apparaître le sprite codé dans data à paraître furtivement mais parfaitement "généré" de façon cohérente dans la zone réservée.
Peut être qu'en copiant un dessin labas au moment voulu, on pourrait dessiner un Sprite facilement.
ON SPRITE GOSUB ne fait qu indiquer une action à suivre en cas de collision.
Je me trompe peut être mais le sujet est ouvert pour ça et surtout aborder la question sous des angles autres que ceux habituels.
Par exemple, on m'a TOUJOURS dit "Non, on ne peut pas créer les Sprites comme tu le pense" à savoir:
Plaquer un dessin (16×16) dans sur l'écran et en faire un vrai Sprite!
Pourtant, il suffit de rendre visible les zones réservées par VDP (24)=VDP (24)+44 Pour rendre la zone visible.
Ensuite tu baisses la vitesse de l emulateur au minimum.
Tu lances le programme et tu verras apparaître le sprite codé dans data à paraître furtivement mais parfaitement "généré" de façon cohérente dans la zone réservée.
Peut être qu'en copiant un dessin labas au moment voulu, on pourrait dessiner un Sprite facilement.
igal :
Pourtant, il suffit de rendre visible les zones réservées par VDP (24)=VDP (24)+44 Pour rendre la zone visible.
Ensuite tu baisses la vitesse de l emulateur au minimum.
Tu lances le programme et tu verras apparaître le sprite codé dans data à paraître furtivement mais parfaitement "généré" de façon cohérente dans la zone réservée.
Ensuite tu baisses la vitesse de l emulateur au minimum.
Tu lances le programme et tu verras apparaître le sprite codé dans data à paraître furtivement mais parfaitement "généré" de façon cohérente dans la zone réservée.
Bien observé
igal :
Peut être qu'en copiant un dessin labas au moment voulu, on pourrait dessiner un Sprite facilement.
Oui tout à fait.
C'est de mémoire comme ça que je faisait pour les enmis et aussi les animations de M-Kid.
Les blocs de sprites étaient copier avec une fonction COPY du VDP, encore de mémoire mais faidrait vérifier dans le code assemleur c'est un COPY RAM vers bloc graphique genre: COPY adresse Z80 to (x,y).
En 2001 j'avais commencé une routine de tunnel et je métait rendu compte que envoyer des données en but de RAM Z80 à VRAM étaient dans certaines conditions bien plus rapide qu'une fonction COPY du VDP... Mais vu les conditions ça serait compliqué voir impossible en BASIC.
Concernant te remarque:
igal :
Plaquer un dessin (16×16) dans sur l'écran et en faire un vrai Sprite!
Toujours pour M-Kid, les sprites étaient des dessins en screen5 et une moulinette en BASIC qui convertissait les pixel en bit dans des matrices de forme de sprites et ça remplissait aussi les couleurs de lignes des sprites en question, et ça supperposait les blocs de sprite 16*16 pour avoir plusieurs couleurs par sprite avec l'activation du bit OR.
C'est pas hyper compliqué à refaire (oui j'ai plus le programme, ni les sources de M_KID d'ailleurs...)
C'est MAGGOO le dernier gardien des sources, il doit possèder un sanctuaire pour nos projets inachevés
TurboR GT (1Mo), CANON V20! ( en kit, modif 2+ en cours)
Pas encore retrouvés: V9990, Grafx9000, SUNRISE IDE 2x CF, SUNRISE MOONSOUND, FM PAC, MUSIC MODULE, NMS8280, SD SNATCHER,...
z80, tu fais fausse route : ce que igal imagine c'est pouvoir dessiner le sprite de façon "visible" et ensuite le copier ailleurs en VRAM pour en faire un sprite, illico presto. C'est évidemment impossible, car le codage des pixels pour l'écran et le codage des pixels pour les sprites est bien entendu différent. C'est d'ailleurs pour cela que tu expliques avoir eu recours à un programme de conversion.
igal : la VRAM est pour le VDP une zone de travail. Les octets qui sont dans cette zone de travail sont interprétés différemment en fonction de l'exploitation que le VDP en fait. En SCREEN5 par exemple, les octets qui font partie de l'écran affiché codent 2 pixels et contiennent l'information de couleur. Mais les octets qui définissent les sprites codent 8 pixels et l'information de couleur est contenue ailleur. Tu vois donc bien qu'il est impossible de "dessiner" un sprite à l'écran, et ensuite le copier ailleurs pour en faire un sprite.
Et d'ailleurs, tout simplement, les 2 zones ne peuvent pas correspondre :
- un carré de 16x16 pixels en SCREEN5 est codé sur 128 octets
- un sprite de 16x16 pixels est codé sur 32 octets + une 2e zone de 16 octets située ailleurs pour les couleurs
Maintenant, il est possible de faire ce que z80 explique : tu dessines un sprite, et puis, par un programme qui va lire le dessin, l'analyser et le transformer, réécrire les données correspondantes en VRAM pour en faire un sprite. Ca c'est possible. Mais pas une copie directe. Edité par Metalion Le 16/02/2015 à 10h57
igal : la VRAM est pour le VDP une zone de travail. Les octets qui sont dans cette zone de travail sont interprétés différemment en fonction de l'exploitation que le VDP en fait. En SCREEN5 par exemple, les octets qui font partie de l'écran affiché codent 2 pixels et contiennent l'information de couleur. Mais les octets qui définissent les sprites codent 8 pixels et l'information de couleur est contenue ailleur. Tu vois donc bien qu'il est impossible de "dessiner" un sprite à l'écran, et ensuite le copier ailleurs pour en faire un sprite.
Et d'ailleurs, tout simplement, les 2 zones ne peuvent pas correspondre :
- un carré de 16x16 pixels en SCREEN5 est codé sur 128 octets
- un sprite de 16x16 pixels est codé sur 32 octets + une 2e zone de 16 octets située ailleurs pour les couleurs
Maintenant, il est possible de faire ce que z80 explique : tu dessines un sprite, et puis, par un programme qui va lire le dessin, l'analyser et le transformer, réécrire les données correspondantes en VRAM pour en faire un sprite. Ca c'est possible. Mais pas une copie directe. Edité par Metalion Le 16/02/2015 à 10h57
MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)
Metalion :
Maintenant, il est possible de faire ce que z80 explique : tu dessines un sprite, et puis, par un programme qui va lire le dessin, l'analyser et le transformer, réécrire les données correspondantes en VRAM pour en faire un sprite. Ca c'est possible. Mais pas une copie directe.
Et tu converti TOUTES les phases d'animation de ton/tes sprites pour ensuite de devoir QUE copier les données de formes (32 octets) et de couleur (16 octets) dans la zone des sprite en VRAM et zou le tour est joué!
TurboR GT (1Mo), CANON V20! ( en kit, modif 2+ en cours)
Pas encore retrouvés: V9990, Grafx9000, SUNRISE IDE 2x CF, SUNRISE MOONSOUND, FM PAC, MUSIC MODULE, NMS8280, SD SNATCHER,...
Après deux semaines à me torturer les méninges, j'ai trouvé un début de solution.
La grande difficulté tient dans cette phrase:
Comment appliquer une pesanteur sans avoir besoin de tester la présence du "sol" en permanence
Si tout va bien, je posterai une video demain .
Comme d'habitude, la technique est rudimentaire mais efficace.
Fallait juste y penser
Nb: les ressources sont si peu utilisées que le mixage BLOAD " BRIBE + VDP (24) + Moteur de Sprites devrait être jouable.
A suivre
La grande difficulté tient dans cette phrase:
Comment appliquer une pesanteur sans avoir besoin de tester la présence du "sol" en permanence
Si tout va bien, je posterai une video demain .
Comme d'habitude, la technique est rudimentaire mais efficace.
Fallait juste y penser
Nb: les ressources sont si peu utilisées que le mixage BLOAD " BRIBE + VDP (24) + Moteur de Sprites devrait être jouable.
A suivre
Voici le Code avant que je fasse une connerie 
Y a encore plein de choses régler, mais le principal est là
Comme je l'expliquai précédemment, j'utilise les SPRITES comme des BALISES de "collision".
Après tout, le VDP gère ça parfaitement en Hardware donc autant en tirer partie
Il me semble qu'on ne peut pas créer des catégories de SPRITES ce qui simplifierait beaucoup le processus.
J'ai pensé à utiliser les "Différentes Profondeurs de Masques" pour faire des Groupes différents de SPRITES, mais j'y suis pas encore.
L'idée étant qu'en fonction de la "COUCHE" utilisée par les SPRITES, leurs donnerait une qualité différente.
Par exemple, supposons une "Collision Gauche" avec un SPRITE du "Masque 2 (donc groupe2), induirait une "Chute".
Dans le même temps, "Collision Gauche" avec une SPRITE du "Masque 3 (Donc groupe3), induirait un STOP. C'est à dire la présence d'un mur qui empêche d'aller plus loin.
Ainsi, simplement en distinguant les SPRITES par le MASQUE, on pourrait leur attribuer différentes qualités.
On peut envisager très simplement que la collision Gauche avec un SPRITE du Masque 4 induit l'élévation du Héro de quelques pixels. Ainsi, plusieurs SPRITES mis bout à bout donneraient l'illusion d'une PENTE à monter.
Etc etc...
Ma question est donc la suivante:
Savez vous si l'on peut Distinguer les SPRITES en les identifiant par leurs MASQUE?
Merci de votre aide
Y a encore plein de choses régler, mais le principal est là
Comme je l'expliquai précédemment, j'utilise les SPRITES comme des BALISES de "collision".
Après tout, le VDP gère ça parfaitement en Hardware donc autant en tirer partie
Il me semble qu'on ne peut pas créer des catégories de SPRITES ce qui simplifierait beaucoup le processus.
J'ai pensé à utiliser les "Différentes Profondeurs de Masques" pour faire des Groupes différents de SPRITES, mais j'y suis pas encore.
L'idée étant qu'en fonction de la "COUCHE" utilisée par les SPRITES, leurs donnerait une qualité différente.
Par exemple, supposons une "Collision Gauche" avec un SPRITE du "Masque 2 (donc groupe2), induirait une "Chute".
Dans le même temps, "Collision Gauche" avec une SPRITE du "Masque 3 (Donc groupe3), induirait un STOP. C'est à dire la présence d'un mur qui empêche d'aller plus loin.
Ainsi, simplement en distinguant les SPRITES par le MASQUE, on pourrait leur attribuer différentes qualités.
On peut envisager très simplement que la collision Gauche avec un SPRITE du Masque 4 induit l'élévation du Héro de quelques pixels. Ainsi, plusieurs SPRITES mis bout à bout donneraient l'illusion d'une PENTE à monter.
Etc etc...
Ma question est donc la suivante:
Savez vous si l'on peut Distinguer les SPRITES en les identifiant par leurs MASQUE?
Code TEXT :
0 'Sauvegarde Travail en cours*****
10 'save"SPRITE06.asc",a
15 'Mode ecran*********************
20 SCREEN5,2:VDP(10)=0
25 '
27 'Variables Sprites Mobiles******
28 '
30 X=1+96:Y=0:'Position initiale du HERO
31 XB=32:YB=127-64:' Position initiale ASCENCEUR
32 VS=16:'Vitesses du HERO
33 SH=1:SD=1:SG=1:'Empeche les sauts.
34 P=1:UP=0:' Active la pesanteur
35 RI=0:LE=0:' Desactive le passe muraille Droite et Gauche
36 '
40 'Variable Sprites fixes*********
42 GOTO 1250:'Forme des Sprites
50 T=175:U=111-16:V=95-16:' Latitude des Sprites Fixes
55 '
60 'Sprites Fixes
61 '
70 'PUTSPRITE1,(16,V),4,0
80 PUTSPRITE2,(48,T),1,0
100 PUTSPRITE3,(80,T),1,0:PUTSPRITE12,(80,U),2,0:PUTSPRITE1,(80,V),4,0
120 PUTSPRITE4,(112,T),1,0:PUTSPRITE13,(112,U),2,0
121 PUTSPRITE5,(144,T),1,0:PUTSPRITE14,(144,U),2,0
122 PUTSPRITE6,(176,T),1,0:PUTSPRITE15,(176,U),2,0:PUTSPRITE16,(176,V),4,0
123 PUTSPRITE7,(208,T),1,0
124 PUTSPRITE8,(240,T),1,0
125 '
148 'Sprites Mobiles***************
149 '
150 'XB=XB+1AND255:'MOTEUR ASCENCEUR
151 'PUTSPRITE30,(XB,YB),7,0:PUTSPRITE31,(XB+16+4,YB),7,0:'ASCENCEUR
152 PUTSPRITE0,(X,Y),2,0:'HERO
153 S=STICK(0):ONS+1GOSUB 160,170,180,190,160,160,160,230,240:'Renvoie selon Stick ZERO
154 GOTO150
155 '
156 'Gestion des Mouvements
157 '
158 'STATIQUE
160 ONSPRITE GOSUB1000:SPRITEON:'Si colision aller a 1000
161 'IFRI=1THENP=1
162 'IFLE=1THENP=1
163 IFP=1THEN210:'Si pesanteur alors Chute de 8 Pixels
164 RETURN
167 '
168 'SAUT HAUT
170 ONSPRITEGOSUB1010:SPRITEON:'Si colision aller a 1010
172 IFSH=3THEN210:'Si Saut deja utilise alors aller a 210
173 IFUP=1THENY=Y+1:UP=0
174 X=X:Y=Y-16:SH=SH+1:P=1:'Saut Haut utilisé! Pesanteur active
176 RETURN
177 '
178 'SAUT DROITE
180 ONSPRITEGOSUB1020:SPRITEON:'Si colision aller a 1020
182 IFSD=3THEN210:'Si Saut Droite deja utilise alors aller a 210
183 IFUP=1THENY=Y+1:UP=0
184 X=X+16:Y=Y-16:SD=SD+1:P=1:'Saut Droite utilisé! Pesanteur active
186 RETURN
187 '
188 'DROITE
190 ONSPRITEGOSUB1030:SPRITEON:'Si colision aller a 1030
192 X=X+16:'Deplacement a droite
193 '
194 IFP=1THEN210:'Si pesanteur alors chute de 8 Pixels
196 RETURN
197 '
198 'CHUTE A DROITE
200 ONSPRITEGOSUB1040:SPRITEON:SI COLISION ALLER A 1040
202 X=X+VS:'Deplacement a Droite
203 IFUP=1THENY=Y+1:UP=0
204 IFP=1THENY=Y+16:'Si pesanteur alors chute de 8 pixels
206 RETURN
207 '
208 'CHUTE
210 ONSPRITE GOSUB1050:SPRITEON:'Si colision alors 1050
211 IFLE=1THENLE=0:P=1:'Si RI actif alors Pesanteur Actif
212 IFRI=1THENRI=0:P=1:'Si RI actif alors Pesanteur Actif
213 IFUP=1THENY=Y+1:UP=0
214 IFP=1THENY=Y+16:'Si pesanteur alors chute de 8 pixels
216 RETURN
217 '
218 'CHUTE A GAUCHE
220 ONSPRITEGOSUB1060:SPRITEON:SI COLISION ALLER A 1060
222 X=X-16:'Deplacement a Gauche
223 IFUP=1THENY=Y+1:UP=0
224 IFP=1THENY=Y+16:'Si pesanteur alors chute de 8 pixels
226 RETURN
227 '
228 'GAUCHE
230 ONSPRITE GOSUB1070:'SPRITEON:Si colision aller a 1070
232 X=X-16:'Deplacement a Gauche
233 '
234 IFP=1THENY=Y+16:'Si pesanteur alors chute de 8 Pixels
236 RETURN
237 '
238 'SAUT GAUCHE
240 ONSPRITEGOSUB1080:SPRITEON:'Si colision aller a 1020
242 IFSG=3THEN210:'Si Saut Droite deja utilise alors aller a 210
243 IFUP=1THENY=Y+1:UP=0
244 X=X-16:Y=Y-16:SG=SG+1:P=1:'Saut Gauche utilisé! Pesanteur active
246 RETURN
998 '
999 'COLISION STATIQUE
1000 P=0:SH=0:SD=0:SG=0
1001 SPRITEOFF
1002 IFRI=1THENP=1
1003 IFLE=1THENP=1
1004 IFUP=0THENY=Y-1:UP=1
1005 GOTO70
1008 '
1009 'COLISION SAUT HAUT
1010 P=0:SH=0:SD=0:SG=0
1011 SPRITEOFF
1013 IFUP=0THENY=Y-1:UP=1
1014 RETURN
1018 '
1019 'COLISION SAUT DROITE
1020 P=0:SH=0:SD=0:SG=0
1021 SPRITEOFF
1023 IFUP=0THENY=Y-1:UP=1
1024 RETURN
1028 '
1029 'COLISION DROITE
1030 P=1:SH=0:SD=0:SG=0:RI=1
1031 X=X+16:SPRITEOFF
1033 IFUP=0THENY=Y-1:UP=1
1034 GOTO70
1038 '
1039 'COLISION CHUTE A DROITE
1040 P=0:SH=0:SD=0:SG=0
1041 SPRITEOFF
1043 IFUP=0THENY=Y-1:UP=1
1044 RETURN
1048 '
1049 'COLISION BAS
1050 P=0:SH=0:SD=0:SG=0
1051 'SPRITEOFF
1053 IFUP=0THENY=Y-1:UP=1
1054 RETURN
1058 '
1059 'COLISION CHUTE A GAUCHE
1060 P=0:SH=1:SD=0:SG=0
1061 SPRITEOFF
1063 IFUP=0THENY=Y-1:UP=1
1064 RETURN
1068 '
1069 'COLISION GAUCHE
1070 P=1:SH=0:SD=0:SG=0:LE=1
1071 X=X-16-1:SPRITEOFF
1073 IFUP=0THENY=Y-1:UP=1
1074 GOTO70
1078 '
1079 'COLISION SAUT GAUCHE
1080 P=0:SH=0:SD=0:SG=0
1081 SPRITEOFF
1083 IFUP=0THENY=Y-1:UP=1
1084 RETURN
1088 '
1200 DESSIN DES SPRITES
1201 '
1250 FOR I=1TO16:READA$:S$=S$+CHR$(VAL("&B"+LEFT$(A$,8))):NEXTI
1252 ' DESSIN DES SPRITES
1260 RESTORE 1300
1270 FORI=1TO16:READA$:S$=S$+CHR$(VAL("&B"+RIGHT$(A$,8))):NEXTI
1280 SPRITE$(0)=S$
1290 GOTO 50
1300 DATA 1111111111111111
1310 DATA 1000000000000001
1320 DATA 1000000000000001
1330 DATA 1000000000000001
1340 DATA 1000000000000001
1350 DATA 1000000000000001
1360 DATA 1000000000000001
1370 DATA 1000000000000001
1380 DATA 1000000000000001
1390 DATA 1000000000000001
1400 DATA 1000000000000001
1410 DATA 1000000000000001
1420 DATA 1000000000000001
1430 DATA 1000000000000001
1440 DATA 1000000000000001
1450 DATA 1111111111111111
Merci de votre aide
Citation :
Ma question est donc la suivante:
Savez vous si l'on peut Distinguer les SPRITES en les identifiant par leurs MASQUE?
Savez vous si l'on peut Distinguer les SPRITES en les identifiant par leurs MASQUE?
En lisant ton descriptif je pensais justement à cette question, de la distinction des sprites.
Et, pour moi la réponse est non, depuis le Basic il est impossible de savoir quel sprite rentre en colission avec tel autre.
Dans les registres du VDP pourtant, cette information existe bel est bien.
Mais son accès depuis le Basic n'est pas possible. IL faut utiliser de l'assembleur.
La seul possibilité d'identifier qui entre en collision avec qui en Basic, est de le calculer en identifiant les positions X et Y de chaque sprites et d'interpoler le resultat.
Ce qui veut dire, beaucoup de ressource utilisée pour pas grandchose !
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie