Logicielsmoto.com http://www.logicielsmoto.com/phpBB/ |
|
[Etude] Slap Fight http://www.logicielsmoto.com/phpBB/viewtopic.php?f=1&t=645 |
Page 2 sur 5 |
Auteur: | Samuel Devulder [ 16 Mai 2021, 19:20 ] |
Sujet du message: | Re: [Etude] Slap Fight |
Samuel Devulder a écrit: Je crois que là on doit commencer à sentir que le jeu commence à être un peu différent. Peut-être de quoi rénover l'écran-titre ? En effet celui d'origine est moche de chez moche Alors qu'on trouve sur C64 Amstrad et même ZX des écrans bien plus beaux : Ne pas oublier que ce jeux était un jeu d'arcade à l'origine donc avec des graphismes faits pour attirer la monnaie des ados que nous étions. Sur Thomson on avait la couverture pour donner le change Alors bon je propose ces deux variations ... Fichier(s) joint(s):
Commentaire: Du classique, basé sur la jaquette. On y voit peu et c'est peut-être mieux i1.gif [ 12.07 Kio | Vu 8798 fois ] Fichier(s) joint(s):
Commentaire: De la triche avec une capture écran totalement bidon.
i2.gif [ 14.85 Kio | Vu 8798 fois ] |
Auteur: | Bentoc [ 16 Mai 2021, 20:48 ] |
Sujet du message: | Re: [Etude] Slap Fight |
Je préfère ta seconde proposition qui me semble plus lisible. S'il est possible d'utiliser le mode bitmap 16, c'est la version Amstrad suivante que je préfère (un peu différente de celle que tu as relevée, où le blanc semble avoir disparu) : Fichier(s) joint(s): Slap Fight TO8.png [ 6.62 Kio | Vu 8792 fois ] Merci pour cette étude en tout cas, très sympa a suivre et de pouvoir tester les modifs en direct c'est cool. Tout ça me donne envie de bosser sur un shoot 'em up ... j'avais récupéré les graphismes de R-Type Reloaded de easter egg qui correspondent au mode BM16 sur Thomson. Une fois mon moteur de jeu un peu plus éprouvé, il se pourrait que j'essaye de faire une petite démo jouable sur ce thème. Enfin c'est un autre sujet ... et c'est pas pour de suite. |
Auteur: | Fool-DupleX [ 16 Mai 2021, 22:05 ] |
Sujet du message: | Re: [Etude] Slap Fight |
Bon boulot Comment fonctionne la partie interaction joueur ? Je pense notamment à la scrutation clavier qui peut être très largement optimisée sur TO7(-70) et MO5 en ne scannant que les touches utiles au lieu de tout le clavier ... |
Auteur: | adnz [ 17 Mai 2021, 01:09 ] |
Sujet du message: | Re: [Etude] Slap Fight |
J'aime bien la clarté du splash de la version C64, mais j'aime bien le coté "peps" de la version amstrad... Tu va finir par changer tout le jeu lol tu va changer les sprites aussi Sinon un shoot ça me dirait bien, j'avais aussi récupéré et testé le level 1 de Rtype en BM16 sur photoshop ! Et j'ai tester des sprites et le splash de battle squadron aussi ... https://oxustudio.com/to8/forum/battlesquadron/splash.png https://oxustudio.com/to8/forum/battlesquadron/sprites.png https://oxustudio.com/to8/forum/battlesquadron/test1.mp4 https://oxustudio.com/to8/forum/rtype/level1.gif |
Auteur: | Samuel Devulder [ 17 Mai 2021, 02:28 ] |
Sujet du message: | Re: [Etude] Slap Fight |
Bon ce soir j'ai trouvé les routines des petits sprites (8x8 : les balles) et les gros sprites (32 x 32 : les ennemis je pense). Vu comme ca je trouve curieux que les ennemis fassent 32x32 quand ils ne me semble faire que 16x16. Peut-être ais-je trouvé des "super boss" de fin de niveaux.. je sais pas. Mais si ca se trouve le moteur de sprite est plus puissant qu'il ne le faudrait et pourrait aller encore plus vite s'il se contenait de 16x16. Bon je vais explorer cela demain, et j'espère poster d'autres trouvailles à l'occasion. Pour RType j'avais converti des images en mode BM4 thomson avec un beau résultat. Ca se passait >>là<<, mais hélas TinyPic a tout effacé (c'était avant qu'on ait la possibilité d'héberger les images dans le forum je crois.) PS: pour le blanc de l'écran titre AMSTRAD, je l'ai trouvé sur le site CPC-Rulez. Je pense que quelqu'un là -bas a merdé avec le flood-fill pour faire passer le tour en noir (qui a contaminé le rayon blanc). En tout cas pas besoin de mode BM16 pour une version similaire à celle d'AMSTRAD dans la mesure ou le ZX y ressemble fichtrement et a des contraintes de couleurs compatibles avec celles chez nous. Sinon mes moulinettes de conversion graphique peuvent faire ceci (ouais c'est "bof"): Fichier(s) joint(s): aa.gif [ 12.33 Kio | Vu 8783 fois ] |
Auteur: | Samuel Devulder [ 17 Mai 2021, 14:47 ] |
Sujet du message: | Re: [Etude] Slap Fight |
Samuel Devulder a écrit: Bon ce soir j'ai trouvé les routines des petits sprites (8x8 : les balles) Voici la routine, entrecoupée de mes commentairesCode: CAB3 3476 PSHS U,Y,X,B,A 13 Ah tiens la routine a 2 points d'entrée, l'une prend son paramètre X depuis la structure pointée par U, et l'autre est déjà passée dans le registre X. CAB5 2004 BRA $CABB 3 CAB7 3476 PSHS U,Y,X,B,A 13 CAB9 AE43 LDX $03,U 6 Code: CABB 108E6590 LDY #$6590 4 Le code au dessus met à jour le pointeur sur les données de sprites (Y). On peut remarquer le "LDD ,U++" peut être remplacé par un "PULU D" qui est plus rapide, et plus globalement si on pouvait passer par un autre registre que Y on gagnerait un peu dans le chargement de l'adresse $6590.CABF ECC1 LDD ,U++ 8 CAC1 31A6 LEAY A,Y 5 CAC3 8618 LDA #$18 2 CAC5 3D MUL 11 CAC6 31AB LEAY D,Y 8 Code: CAC8 A6C4 LDA ,U 4 Idée: utiliser LEAU ,Y qui est 2 cycles plus rapide que TFR Y,U. Mais aussi on voit que tout le calcul sur Y plus haut dans U. Ca aurait été bien de travailler sur U directement en remontant le test-ci-dessus avant le calcul en question. CACA 2703 BEQ $CACF 3 CACC 308820 LEAX $20,X 5 CACF 1F23 TFR Y,U 6 Code: CAD1 A68810 LDA $10,X 5 Bon pas grand chose à dire c'est un découlement du même bloc de masque AND/OR sur 8 lignes écran octet par octet. On doit pouvoir accélérer cela en travaillant sur les registres A et B simultanément (dommage qu'on ait pas de ANDD/ORD). A noter qu'à la fin du déroulement les indexes passent sur 16bits et rend les ANDA/STA très couteux (+3 cycles à chaque calcul d'adresse).CAD4 A4C4 ANDA ,U 4 CAD6 AA80 ORA ,X+ 6 CAD8 A7C4 STA ,U 4 CADA A68810 LDA $10,X 5 CADD A441 ANDA $01,U 5 CADF AA80 ORA ,X+ 6 CAE1 A741 STA $01,U 5 CAE3 A68810 LDA $10,X 5 CAE6 A4C818 ANDA $18,U 5 CAE9 AA80 ORA ,X+ 6 CAEB A7C818 STA $18,U 5 CAEE A68810 LDA $10,X 5 CAF1 A4C819 ANDA $19,U 5 CAF4 AA80 ORA ,X+ 6 CAF6 A7C819 STA $19,U 5 ../... CB6B A68810 LDA $10,X 5 CB6E A4C900A8 ANDA $00A8,U 8 CB72 AA80 ORA ,X+ 6 CB74 A7C900A8 STA $00A8,U 8 CB78 A68810 LDA $10,X 5 CB7B A4C900A9 ANDA $00A9,U 8 CB7F AA80 ORA ,X+ 6 CB81 A7C900A9 STA $00A9,U 8 Code: CB85 3576 PULS A,B,X,Y,U 13 Comme d'habitude on peut fusionner le PULS et le RTS ca fait gagner 3 cycles. C'est pas beaucoup car l'ensemble de cette routine utilise autour de 422 cycles, on gagnerait moins de 1%, mais je pense qu'on peut faire mieux avec le code ci-après qui met en avant ce pourquoi j'utilise un MACRO-ASSEMBLEUR, à savoir les... macros.CB87 39 RTS 5 Code: INDEXED MACRO Cette macro optimise "OPCODE n,Reg" en "OPCODE ,Reg" quand n=0. Cela va être utile plus loin.IFEQ \1 \0 ,\2 ELSE \0 \1,\2 ENDC ENDM Code: * sprites 8x8 Remarquez ici comment le LEAX 32,X (5 cycles) est transformé en ABX (3 cycles). Le #$10 au début permet d'éviter le passage aux indexes 16 bits plus loin.ORG $CAB3 PSHS D,X,U BRA L1 PSHS D,X,U LDX 3,U L1 LDB #$10 LDA 2,U BEQ L2 ADDB #$20 L2 ABX Code: LDD ,U Bon là on fait le gros calcul arithmétique directement sur U. A noter: On ajoute $60 à U pour éviter le passage aux indexes 16 bits dans la routine de masque.LDU #$6590+$60 ; début écran de jeu interne LEAU A,U LDA #24 MUL LEAU D,U Code: MSK MACRO Bon là c'est du basic avec la macro. Elle déroule l'algorithme de masquage en faisant en sorte qu'on ait bien un offset 0 (ca fait gagner un cycle, c'est toujours ca de pris) et surtout qu'on reste dans les offset 8 bits (car le passage aux offsets 16 bits est super super pénalisant). Une fois assemblé on obtient:INDEXED LDD,2*\0,X INDEXED ANDA,24*\0-$60,U INDEXED ANDB,24*\0-$5F,U INDEXED ORA,2*\0-16,X INDEXED ORB,2*\0-15,X INDEXED STD,24*\0-$60,U ENDM MSK 0 MSK 1 MSK 2 MSK 3 MSK 4 MSK 5 MSK 6 MSK 7 PULS D,X,U,PC Code: CAB3 3456 PSHS U,X,B,A 11 Les deux points d'entrée sont préservés Qui fait 146 octets contre 212 (30% plus court), et s'execute en 300 cycles au lieu des 422, on est 29% plus rapide sur l'affichage des bullets!CAB5 2004 BRA $CABB 3 CAB7 3456 PSHS U,X,B,A 11 CAB9 AE43 LDX $03,U 6 CABB C610 LDB #$10 2 Ajout de 32 à X si le drapeau pointé par U est non nul CABD A642 LDA $02,U 5 CABF 2702 BEQ $CAC3 3 CAC1 CB20 ADDB #$20 2 CAC3 3A ABX 3 CAC4 ECC4 LDD ,U 5 Calcul de l'adresse d'affichage CAC6 CE65F0 LDU #$65F0 3 U contient +$60 CAC9 33C6 LEAU A,U 5 CACB 8618 LDA #$18 2 CACD 3D MUL 11 CACE 33CB LEAU D,U 8 CAD0 EC84 LDD ,X 5 Bon 2 octets d'un coup CAD2 A4C8A0 ANDA $A0,U 5 $A0 c'est -$60 ce qui compense le +$60 en $CAC6 CAD5 E4C8A1 ANDB $A1,U 5 Ca aurait été bien de pouvoir faire un AND direct sur D CAD8 AA10 ORA -$10,X 5 le -$10 est compensé par le LDB #$10 en $CABB CADA EA11 ORB -$0F,X 5 Heureux les hc6309 avec leur unité logique 16 bits. CADC EDC8A0 STD $A0,U 6 Et voilà: on a masqué 2 octets du sprites ../.. (on fait pareil 7 fois) CB36 EC0E LDD $0E,X 6 Si on avait pas fait +$10 à X, ici on serait en offset 16 bits CB38 A4C848 ANDA $48,U 5 Grace au +$60, ici on reste sur un offset 8 bits CB3B E4C849 ANDB $49,U 5 CB3E AA1E ORA -$02,X 5 Ah zut, je loupe le 0,X.. il est utilisé dans le 1er LDD ($CAD0) CB40 EA1F ORB -$01,X 5 CB42 EDC848 STD $48,U 6 CB45 35D6 PULS A,B,X,U,PC 13 Samuel Devulder a écrit: Peut-être ai-je trouvé des "super boss" de fin de niveaux.. je sais pas. Ben maintenant je sais :Fichier(s) joint(s):
Commentaire: Un méga-boss de fin de niveau en 64x32. Le boss, que dis-je, le méga-boss de fin de niveau est ENORME ! Ah, mais j'oublie de signaler qu'en cours de chemin on peut amasser suffisamment de bonus pour que notre propre vaisseau couvre une surface gigantesque. Quand ces deux là se rencontrent, la bataille est épique dcmoto01.png [ 12.37 Kio | Vu 8769 fois ] Fichier(s) joint(s):
Commentaire: Ouais, ben nous aussi on en a une grosse. Non mais ! (bon en vrai on perd super vite notre armement. Il faut tricher)dcmoto03.gif [ 8.66 Kio | Vu 8769 fois ] Note: je n'ai pas encore trouvé la routine pour notre vaisseau amélioré |
Auteur: | Bentoc [ 17 Mai 2021, 16:41 ] |
Sujet du message: | Re: [Etude] Slap Fight |
Beau travail ! Heureusement que sous DCMOTO on peut baisser la fréquence processeur Désolé pour la blague ... et encore merci pour cette analyse très instructive. Un autre défi serait de réussir à augmenter la fluidité de déplacement du vaisseau principal, sans impacter le reste (collision, ...) et en conservant le gain de vitesse global déjà obtenu. Personnellement je trouve le "pas" de déplacement du vaisseau principal vraiment trop élevé, en particulier quand on a accumulé toutes les options "vitesse". Comme le jeu ne semble pas utiliser de double buffering et a priori (je ne suis pas sûr à toi de confirmer) ne semble pas être calé sur un refresh de VBL : Peut être en insérant un rendu intermédiaire (donc deux au total) du vaisseau dans la boucle principale ? Quitte à ne pas jouer la routine de collision sur ce rendu de vaisseau intermédiaire. On diviserait alors le pas de déplacement par deux (un appuie manette donnerait toujours le même déplacement, mais l'image intermédiaire apporterai un confort visuel). |
Auteur: | Samuel Devulder [ 17 Mai 2021, 17:14 ] |
Sujet du message: | Re: [Etude] Slap Fight |
Je ne pige pas ce que tu veux faire: tu veux diviser la vitesse du vaisseau par 2 ? Ca va être dur d'éviter les balles! Le vaisseau se déplace de 4 pixels horizontaux ou verticaux. On peut pas trop faire des déplacement de 2 pixels car il n'y a pas les masques de sprites pour ca. Il n'y a pas non plus de synchro VBL, ni de double buffering-hardware (le jeu tourne sur MO5 et TO7/70). L'espace de jeu est redessiné à chaque image dans un buffer caché, lequel est ensuite recopié à l'écran par le 1ere routine que j'ai dé-assemblée. C'est du "bourrin" et on aura difficilement plus rapide que 12FPS qui correspondent à remplir le buffer interne (disons 6ko) puis recopier à l'écran (disons 7ko), ce qui nous fait un débit total de 150ko/sec à 12fps, soit 6 cycles (~le temps d'un LDA/STA ,X+) entre les accès mémoire. Pour ainsi dire le CPU passe son temps à lire ou écrire un octet en mémoire dans le jeu. |
Auteur: | adnz [ 17 Mai 2021, 17:27 ] |
Sujet du message: | Re: [Etude] Slap Fight |
pufff travail de ouf, bravo, Je vais relire tout ça quant j'aurai un peu de temps, deg j'ai trop de boulot .... En tout cas cette analyse c'est comme un cours d'assembleur pour moi, j'apprends plein de truc ... merci. ++ |
Auteur: | Bentoc [ 17 Mai 2021, 18:20 ] |
Sujet du message: | Re: [Etude] Slap Fight |
Samuel Devulder a écrit: Je ne pige pas ce que tu veux faire: tu veux diviser la vitesse du vaisseau par 2 ? Ca va être dur d'éviter les balles! Le vaisseau se déplace de 4 pixels horizontaux ou verticaux. On peut pas trop faire des déplacement de 2 pixels car il n'y a pas les masques de sprites pour ca. Je reformule (en espérant être plus clair ... désolé) A chaque fois que tu prends une "arme" vitesse (tu peux en prendre 4) le pas de déplacement augmente. au départ : 4px de déplacement effectivement, mais avec 4 "armes" vitesse : 28px de déplacement (estimation pifométrique). je me disais qu'a cette vitesse ça serait intéressant d'avoir un affichage intermédiaire du vaisseau pour que ça rendre moins saccadé. Bon je reconnais que c'est un peu farfelu ... |
Auteur: | Samuel Devulder [ 18 Mai 2021, 00:21 ] |
Sujet du message: | Re: [Etude] Slap Fight |
Samuel Devulder a écrit: Bon ce soir j'ai trouvé (...) les gros sprites (32 x 32 : les ennemis je pense). C'est donc la routine dont je vais parler ici:Code: CB88 3450 PSHS U,X 9 Bon pas grand chose à redire de plus que pour les sprites 8x8, sauf que là il n'y a pas d'inline et une boucle de 32 fois a été préférée par l'auteur du programme. Pour une fois il n'y a pas de soucis avec les indexes 16bits car l'auteur a bien su utiliser le registre Y dans son code. A noter que suivant le flag $13,U on saute dans cette autre routine qui lui est moralement liée:CB8A A6C813 LDA $13,U 5 CB8D 2B50 BMI $CBDF 3 Flag de type de sprite CB8F 318900C0 LEAY $00C0,X 8 X = pointeur sur le masque "ET" du sprite, Y = le masque "OU" CB93 8620 LDA #$20 2 Boucle 32 fois CB95 3402 PSHS A 6 CB97 EC4C LDD $0C,U 6 Calcul du pointeur sur l'image interne CB99 CE6560 LDU #$6560 3 CB9C 33C6 LEAU A,U 5 CB9E 8618 LDA #$18 2 CBA0 3D MUL 11 CBA1 33CB LEAU D,U 8 CBA3 A6C4 LDA ,U 4 Rien de bien folichon ici, c'est du masque CBA5 A4A0 ANDA ,Y+ 6 classique de chez classique. On utilise X et CBA7 AA80 ORA ,X+ 6 Y simultanément car l'écart entre le masque ET CBA9 A7C4 STA ,U 4 et le masque OU est grand : 6*32 = $C0 CBAB A641 LDA $01,U 5 de $CB8F. CBAD A4A0 ANDA ,Y+ 6 CBAF AA80 ORA ,X+ 6 CBB1 A741 STA $01,U 5 On vient de traiter 2 octets horiz CBB3 A642 LDA $02,U 5 Les 2 octets suivants CBB5 A4A0 ANDA ,Y+ 6 CBB7 AA80 ORA ,X+ 6 CBB9 A742 STA $02,U 5 CBBB A643 LDA $03,U 5 CBBD A4A0 ANDA ,Y+ 6 CBBF AA80 ORA ,X+ 6 CBC1 A743 STA $03,U 5 CBC3 A644 LDA $04,U 5 Et encore 2, pour un total horizontal CBC5 A4A0 ANDA ,Y+ 6 de 8*6 = 48 pixels!!! CBC7 AA80 ORA ,X+ 6 CBC9 A744 STA $04,U 5 Ici on s'occupe de sacrés gros sprites CBCB A645 LDA $05,U 5 CBCD A4A0 ANDA ,Y+ 6 CBCF AA80 ORA ,X+ 6 CBD1 A745 STA $05,U 5 CBD3 33C818 LEAU $18,U 5 CBD6 6AE4 DEC ,S 6 Fin de boucle CBD8 26C9 BNE $CBA3 3 CBDA 3502 PULS A 6 Ouais classique: on peut fusionner ces PULS CBDC 3550 PULS X,U 9 et le RTS final en un seul et gagner plein CBDE 39 RTS 5 de cycles Code: CBDF 847F ANDA #$7F 2 Tout un calcul sur le flag Ok donc ici on traite un gros gros sprite qui n'apparait qu'en toute fin de jeu. On peut l'optimiser ou pas. C'est comme on veut..CBE1 4C INCA 2 CBE2 8104 CMPA #$04 2 CBE4 2D01 BLT $CBE7 3 CBE6 4F CLRA 2 CBE7 8A80 ORA #$80 2 CBE9 A7C813 STA $13,U 5 CBEC 847F ANDA #$7F 2 CBEE 1027FF9D LBEQ $CB8F 6/5 .. pour reboucler au truc standard plus haut CBF2 8ECC6B LDX #$CC6B 3 Pointeur sur sprite spécifique. CBF5 4A DECA 2 CBF6 48 ASLA 2 CBF7 AE86 LDX A,X 6 CBF9 31890140 LEAY $0140,X 8 Ah! ici Y = X + 320. Les masques ET/OU CBFD 8620 LDA #$20 2 Son séparés de 32*10.. Et oui on traite d'un CBFF 3402 PSHS A 6 sprite de 80 pixels horizontaux et 32 de haut. CC01 EC4C LDD $0C,U 6 A n'en pas douter c'est le big-boss celui-là! CC03 8002 SUBA #$02 2 CC05 CE6560 LDU #$6560 3 CC08 33C6 LEAU A,U 5 CC0A 8618 LDA #$18 2 CC0C 3D MUL 11 CC0D 33CB LEAU D,U 8 Calcul adresse écran interne CC0F A6C4 LDA ,U 4 Bon ici c'est du masquage de 10 CC11 A4A0 ANDA ,Y+ 6 octets horizontaux sans aucune CC13 AA80 ORA ,X+ 6 surprise... CC15 A7C4 STA ,U 4 CC17 A641 LDA $01,U 5 CC19 A4A0 ANDA ,Y+ 6 CC1B AA80 ORA ,X+ 6 CC1D A741 STA $01,U 5 c'est CC1F A642 LDA $02,U 5 CC21 A4A0 ANDA ,Y+ 6 CC23 AA80 ORA ,X+ 6 CC25 A742 STA $02,U 5 CC27 A643 LDA $03,U 5 CC29 A4A0 ANDA ,Y+ 6 juste CC2B AA80 ORA ,X+ 6 CC2D A743 STA $03,U 5 CC2F A644 LDA $04,U 5 CC31 A4A0 ANDA ,Y+ 6 CC33 AA80 ORA ,X+ 6 CC35 A744 STA $04,U 5 très CC37 A645 LDA $05,U 5 CC39 A4A0 ANDA ,Y+ 6 CC3B AA80 ORA ,X+ 6 CC3D A745 STA $05,U 5 CC3F A646 LDA $06,U 5 CC41 A4A0 ANDA ,Y+ 6 CC43 AA80 ORA ,X+ 6 CC45 A746 STA $06,U 5 très CC47 A647 LDA $07,U 5 CC49 A4A0 ANDA ,Y+ 6 CC4B AA80 ORA ,X+ 6 CC4D A747 STA $07,U 5 CC4F A648 LDA $08,U 5 CC51 A4A0 ANDA ,Y+ 6 CC53 AA80 ORA ,X+ 6 long ! CC55 A748 STA $08,U 5 CC57 A649 LDA $09,U 5 CC59 A4A0 ANDA ,Y+ 6 CC5B AA80 ORA ,X+ 6 CC5D A749 STA $09,U 5 CC5F 33C818 LEAU $18,U 5 Fini ==> On avance d'une ligne l'écran interne CC62 6AE4 DEC ,S 6 on répète tout ca 32x. CC64 26A9 BNE $CC0F 3 CC66 3502 PULS A 6 Oui bon ca on connait. CC68 3550 PULS X,U 9 CC6A 39 RTS 5 Bon allez, pour le fun essayons de réécrire ceci en optimisant sans se compliquer la vie: Code: * sprites 48x32, 80x32 Ici j'ai décidé de travailler sur des offset (4*6*5 cycles + 2*5 pour les LEA=130) plutôt que des auto-incrémentassions (4*6*6=144 cycles). Ca ne fait pas gagner grand chose (14 cycles), mais c'est multiplié par 32, donc pas loin de 500 cycles de gagnés.ORG $CB88 HEIGHT SET 32 ; Pour se marrer on peut réduire la hauteur du big-boss. PSHS U,X LDA $13,U BMI SP2 ; suivant le drapeau on part sur le 80x32 ou 48x32 SP1 LDD $0C,U LDU #$6560 LEAU A,U LDA #$18 MUL LEAU D,U ; ici on change rien LEAY $00C0,X LDA #HEIGHT ; sprite 48xHEIGHT PSHS A * Macro pour traiter 2 octets d'un coup M16 MACRO INDEXED LDD,\0+\1,U INDEXED ANDA,\0+0,Y INDEXED ANDB,\0+1,Y INDEXED ORA,\0+0,X INDEXED ORB,\0+1,X INDEXED STD,\0+\1,U ENDM L3 SET * M16 0,0 M16 2,0 M16 4,0 LEAU 24,U ; on avance U d'une ligne LEAX 6,X ; et X et Y de 6 octets LEAY 6,Y DEC ,S BNE L3 PULS A,X,U,PC ; oui donc rien de spécial pour le sprite 48x32 à part de travailler sur D Code: SP2 ANDA #$7F ; sprites 80x32 Ici on gagne 40 cycles par ligne, donc 1280 cycles au total pour l'ensemble du sprite. INCA CMPA #4 BLT L4 CLRA L4 ORA #$80 ; Alors là je pige rien du calcul qui STA $13,U ; est fait à part qu'on modifie le type ANDA #$7F ; de sprite pour retomber dans le BEQ SP1 ; cas 48x32 LDX #$CC6B DECA ASLA LDX A,X LDD $0C,U LDU #$6560-2 LEAU A,U LDA #24 MUL LEAU D,U LEAY $0140,X LDA #HEIGHT PSHS A L5 SET * M16 0,0 M16 2,0 M16 3,0 M16 4,0 M16 6,0 M16 8,0 LEAU 24,U ; Bon c'est juste pareil qu'au dessus LEAX 10,X ; sauf qu'on a le droit à 4 octets en LEAY 10,Y ; en plus DEC ,S BNE L5 PULS A,X,PC Ouais, rien d'extraordinaires au final. On pourrait peut-être grapiller quelques cycles en comprenant le calcul sur le flag au début de SP2 et en le réécrivant plus directement, mais j'ai dit "sans se compliquer la vie" (car là ca triture des bits en les effaçant ou ajoutant avec de l'arithmétique au milieu.. tout cela à l'air inutilement complexe, laborieux et oups.. soporifique.) [EDIT] Bon en fait ce truc ressemble à un compteur car le big-boss peut être petit (48x32) ou grand (3 sprites possibles en 80x32) suivant ce compteur. Je pense que l'auteur n'était pas à l'aise avec le bit de signe et l'efface pour calculer l'état suivant (INCA) et le remets ensuite alors qu'en fait cela est transparent: Code: SP2 INCA ; $80 -> $81 -> $82 -> $83 -> $80
CMPA #$84 ; et tout ce qui est hors de ce cycle BLT L4 ; retombe en... LDA #$80 ; ... $80 :) L4 STA $13,U ANDA #$7F BEQ SP1 ; $80 --> "petit" boss |
Auteur: | adnz [ 18 Mai 2021, 01:07 ] |
Sujet du message: | Re: [Etude] Slap Fight |
Tu me prête ton cerveau juste le temps que je fasse un jeu vite fait (j'ai tout lu !) |
Auteur: | Samuel Devulder [ 18 Mai 2021, 01:17 ] |
Sujet du message: | Re: [Etude] Slap Fight |
adnz a écrit: (j'ai tout lu !) Tu es courageux !Bah optimiser est facile: on a pas à réfléchir sur la logique du jeu, l'organisation mémoire, le chargement, les assets, etc. Il faut juste trouver une façon de faire la même chose en "plus rapide" et se convaincre qu'on ne peut pas faire mieux. C'est un exercice intellectuel très voisin des trucs genre mots-fléchés ou sudoku je trouve. Il faut faire preuve de logique et de sagacité. C'est très relaxant je trouve, et très satisfaisant de voir qu'on arrive à optimiser encore un peu plus. Le plus pénible est de se relire et corriger pour la quarantedouzième fois des typos ou le style "lourd" que je peux facilement avoir quand je retranscrit directement ce que j'ai en tête alors que les idées s'enchainent et se mélangent à toute vitesse. J'espère que c'est pas trop indigeste tout cela. Tu nous dira si tu passes une bonne nuit après avoir tout lu. |
Auteur: | adnz [ 18 Mai 2021, 01:27 ] |
Sujet du message: | Re: [Etude] Slap Fight |
Franchement j'aime bien lire tes explications car vu que j'apprends des astuces assembleurs en même temps, puis je compare à ce que j'ai fais dans le pacman, pour voir si ça peut m'aider à optimiser aussi mon code. Tant que j'apprends je pourrais lire du code expliqué pour m'en dormir même si il me faut plus de temps pour comprendre, faut laisser reposer pour assimiler |
Auteur: | Samuel Devulder [ 22 Mai 2021, 22:31 ] | ||
Sujet du message: | Re: [Etude] Slap Fight | ||
Bon, désolé pour le petit retard de publication, mais j'étais quelques peu en transit. Où en étions nous ? Ah oui on a vu les petits (8x8) et les gros/très gros sprites (32x32 à 80x32)... C'est bien, mais il manque le plus important des sprites: le notre. Comme par hasard, c'est la routine qui se trouve juste avant la précédente: Code: C8EA 3476 PSHS U,Y,X,B,A 13 On voit qu'ici les sprites font 24x24, mais à cause de l'alignement à octet ce sont des sprites de 16x24 dont on s'occupe. Ce code est important dans la mesure où il est déroulé au max et qu'on a pas utilisé la pile pour le compteur de boucle. Je trouve que ce choix n'est pas idéal. Certes le décompte ne prends que 2 cycles au lieu de 6, mais sur les centaintes entre chaque tour c'est marginal. D'autant plus qu'on se paye un LBNE à 6 cycles en plus. Si on avait fait un masque sur A/B peut être que le code déroulé serait peut-être plus court et un BNE tout simple suffirait. En l'état le code se déroule sur 1808 cycles. Essayons de voir si on arrive à faire mieux:C8EC 108EC7B9 LDY #$C7B9 4 C8F0 A680 LDA ,X+ 6 Lecture d'un type C8F2 8163 CMPA #$63 2 si type==$63 C8F4 102701B8 LBEQ $CAB0 6/5 --> On affiche rien C8F8 48 ASLA 2 C8F9 AEA6 LDX A,Y 6 Mise à jour du pointeur de data en fonction du type lu C8FB C602 LDB #$02 2 Ok on fait deux fois C8FD A68848 LDA $48,X 5 C900 A4C4 ANDA ,U 4 Du masque AND/OR bien classiqu C902 AA80 ORA ,X+ 6 C904 A7C4 STA ,U 4 C906 A68848 LDA $48,X 5 C909 A441 ANDA $01,U 5 C90B AA80 ORA ,X+ 6 C90D A741 STA $01,U 5 C90F A68848 LDA $48,X 5 C912 A442 ANDA $02,U 5 C914 AA80 ORA ,X+ 6 C916 A742 STA $02,U 5 on traite 3 octets horiz ...ca se répète 5 fois... C9BD A68848 LDA $48,X 5 C9C0 A4C90090 ANDA $0090,U 8 Ici c'est pareil sauf que les index sont sur 16bits C9C4 AA80 ORA ,X+ 6 C9C6 A7C90090 STA $0090,U 8 C9CA A68848 LDA $48,X 5 C9CD A4C90091 ANDA $0091,U 8 C9D1 AA80 ORA ,X+ 6 C9D3 A7C90091 STA $0091,U 8 C9D7 A68848 LDA $48,X 5 C9DA A4C90092 ANDA $0092,U 8 C9DE AA80 ORA ,X+ 6 C9E0 A7C90092 STA $0092,U 8 ...ca se répète ainsi 5 fois avec les index 16 bits (aïe aïe, c'est coûteux)... CA80 A68848 LDA $48,X 5 CA83 A4C90108 ANDA $0108,U 8 CA87 AA80 ORA ,X+ 6 CA89 A7C90108 STA $0108,U 8 CA8D A68848 LDA $48,X 5 CA90 A4C90109 ANDA $0109,U 8 CA94 AA80 ORA ,X+ 6 CA96 A7C90109 STA $0109,U 8 CA9A A68848 LDA $48,X 5 CA9D A4C9010A ANDA $010A,U 8 CAA1 AA80 ORA ,X+ 6 CAA3 A7C9010A STA $010A,U 8 CAA7 33C90120 LEAU $0120,U 8 On avance de 12 lignes CAAB 5A DECB 2 ca boucle 2x pour un total de 24 lignes CAAC 1026FE4D LBNE $C8FD 6/5 CAB0 3576 PULS A,B,X,Y,U 13 Arf.. est-il encore besoin de signaler CAB2 39 RTS 5 l'optimisation possible ici ? Code: * sprite 24x24 Bon il n'y a rien de spécial à part qu'on déroule les 24 lignes en 11 + 11 + 2. Pourquoi 11 ? Parce que c'est la valeur max i quelle que 24*(i-1)<=255 pour garder des offsets sur 8 bits. A noter: Comme je me retrouvais à avoir un registre d'adresse inutilisé, j'ai utilisé la construction:ORG $C8EA PSHS D,X,U LDA ,X CMPA #$63 BEQ L7 LDX #$C7B9 LSLA LDY A,X OFS SET 5 LEAU 24*OFS,U LEAY 3*OFS,Y M6 MACRO INDEXED LDD,24*(\0-OFS),U INDEXED ANDA,3*(\0-OFS)+$48,Y INDEXED ANDB,3*(\0-OFS)+$49,Y INDEXED ORA,3*(\0-OFS)+$00,Y INDEXED ORB,3*(\0-OFS)+$01,Y INDEXED STD,24*(\0-OFS),U INDEXED LDA,24*(\0-OFS)+2,U INDEXED ANDA,3*(\0-OFS)+$4A,Y INDEXED ORA,3*(\0-OFS)+$02,Y INDEXED STA,24*(\0-OFS)+2,U ENDM LDX #L8 ; 3 BRA L6 ; 3 => Un bsr sans pile L8 LEAU 11*24,U LEAY 11*3,Y LDY #L9 ; 3 BRA L6 ; 3 L9 SET * LEAU OFS*24,U LEAY OFS*3,Y M6 OFS M6 OFS+1 L7 SET * PULS D,X,U,PC L6 SET * M6 0 M6 1 M6 2 M6 3 M6 4 M6 5 M6 6 M6 7 M6 8 M6 9 M6 10 JMP ,X ; 3 ==> un RTS "sans pile" Code: LDX #next ; adresse de retour qui réalise l'équivalent d'un couple "bsr label/rts" (7+5=12 cycles) en 3+3+3=9 cycles sans passer par la pile (ca peut être utilisé dans des cartouches de diagnostiques avant d'avoir testé l'état de la RAM.) Au total ceci tourne en 1320 cycles au lieu des 1808 d'origine soit 27% plus rapide que le code initial d'affichage de notre sprite.BRA label ; appel sous-routine next: ... label: ... JMP ,X ; retour Au final en appliquant ce patch on tombe à 82ms entre 2 écritures écrans au lieu des 83ms précédents. C'est pas énorme, mais c'est vrai qu'on optimise qu'un seul sprite ici. Je me demande si on ne pourrait pas détecter le cas où le "milieu" de notre sprite n'a pas de transparence et que le masque ET/OU peut être remplacé par un simple LDB ?
|
Page 2 sur 5 | Heures au format UTC + 1 heure |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |