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