Logicielsmoto.com

Nous sommes le 28 Mar 2024, 23:33

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 69 messages ]  Aller à la page Précédente  1, 2, 3, 4, 5  Suivante
Auteur Message
 Sujet du message: Re: [Etude] Slap Fight
MessagePosté: 16 Mai 2021, 19:20 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
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
Image
Alors qu'on trouve sur C64
Image
Amstrad
Image
et même ZX des écrans bien plus beaux :
Image

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 :)
Image

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
i1.gif [ 12.07 Kio | Vu 8538 fois ]
Fichier(s) joint(s):
Commentaire: De la triche avec une capture écran totalement bidon.
i2.gif
i2.gif [ 14.85 Kio | Vu 8538 fois ]

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: [Etude] Slap Fight
MessagePosté: 16 Mai 2021, 20:48 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
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
Slap Fight TO8.png [ 6.62 Kio | Vu 8532 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.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: [Etude] Slap Fight
MessagePosté: 16 Mai 2021, 22:05 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 464
Bon boulot :good:

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 ...


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: [Etude] Slap Fight
MessagePosté: 17 Mai 2021, 01:09 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
:bien:

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 :D tu va changer les sprites aussi :lol:

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

_________________
Image


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: [Etude] Slap Fight
MessagePosté: 17 Mai 2021, 02:28 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
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 >><<, 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). :W

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
aa.gif [ 12.33 Kio | Vu 8523 fois ]

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: [Etude] Slap Fight
MessagePosté: 17 Mai 2021, 14:47 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
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 commentaires
Code:
CAB3 3476       PSHS   U,Y,X,B,A          13
CAB5 2004       BRA    $CABB               3
CAB7 3476       PSHS   U,Y,X,B,A          13
CAB9 AE43       LDX    $03,U               6
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.
Code:
CABB 108E6590   LDY    #$6590              4
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
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.
Code:
CAC8 A6C4       LDA    ,U                  4
CACA 2703       BEQ    $CACF               3
CACC 308820     LEAX   $20,X               5
CACF 1F23       TFR    Y,U                 6
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.
Code:
CAD1 A68810     LDA    $10,X               5
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
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).
Code:
CB85 3576       PULS   A,B,X,Y,U          13
CB87 39         RTS                        5
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.
Code:
INDEXED MACRO
  IFEQ \1
    \0      ,\2
  ELSE
    \0      \1,\2
  ENDC
    ENDM
Cette macro optimise "OPCODE n,Reg" en "OPCODE ,Reg" quand n=0. Cela va être utile plus loin.
Code:
* sprites 8x8
    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
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.
Code:
    LDD     ,U
    LDU     #$6590+$60  ; début écran de jeu interne
    LEAU    A,U
    LDA     #24
    MUL
    LEAU    D,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.
Code:
MSK MACRO   
    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
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:
Code:
CAB3 3456       PSHS   U,X,B,A            11 Les deux points d'entrée sont préservés
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
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!

Samuel Devulder a écrit:
Peut-être ai-je trouvé des "super boss" de fin de niveaux.. je sais pas.
Ben maintenant je sais :beuh: :
Fichier(s) joint(s):
Commentaire: Un méga-boss de fin de niveau en 64x32.
dcmoto01.png
dcmoto01.png [ 12.37 Kio | Vu 8509 fois ]
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 :D
Fichier(s) joint(s):
Commentaire: Ouais, ben nous aussi on en a une grosse. Non mais !
dcmoto03.gif
dcmoto03.gif [ 8.66 Kio | Vu 8509 fois ]
(bon en vrai on perd super vite notre armement. Il faut tricher)
Note: je n'ai pas encore trouvé la routine pour notre vaisseau amélioré :voyons:

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: [Etude] Slap Fight
MessagePosté: 17 Mai 2021, 16:41 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
Beau travail !

Heureusement que sous DCMOTO on peut baisser la fréquence processeur :ptdr:
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).


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: [Etude] Slap Fight
MessagePosté: 17 Mai 2021, 17:14 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
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.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: [Etude] Slap Fight
MessagePosté: 17 Mai 2021, 17:27 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
pufff travail de ouf, bravo,
Je vais relire tout ça quant j'aurai un peu de temps, deg j'ai trop de boulot .... :bien:

En tout cas cette analyse c'est comme un cours d'assembleur pour moi, j'apprends plein de truc ... merci.
++

_________________
Image


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: [Etude] Slap Fight
MessagePosté: 17 Mai 2021, 18:20 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
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 ...


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: [Etude] Slap Fight
MessagePosté: 18 Mai 2021, 00:21 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
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
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
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:
Code:
CBDF 847F       ANDA   #$7F                2 Tout un calcul sur le flag
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
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..

Bon allez, pour le fun :bouffon: essayons de réécrire ceci en optimisant sans se compliquer la vie:
Code:
* sprites 48x32, 80x32
    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
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.
Code:
SP2 ANDA  #$7F    ; sprites 80x32
    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
Ici on gagne 40 cycles par ligne, donc 1280 cycles au total pour l'ensemble du sprite.

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 :dodo: 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

_________________
Good morning, that's a nice Tnetennba


Dernière édition par Samuel Devulder le 18 Mai 2021, 01:23, édité 4 fois.

Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: [Etude] Slap Fight
MessagePosté: 18 Mai 2021, 01:07 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
Tu me prête ton cerveau juste le temps que je fasse un jeu vite fait :lol:

(j'ai tout lu !)

_________________
Image


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: [Etude] Slap Fight
MessagePosté: 18 Mai 2021, 01:17 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
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. :dodo:

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: [Etude] Slap Fight
MessagePosté: 18 Mai 2021, 01:27 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
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. :bien:

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 :D

_________________
Image


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Re: [Etude] Slap Fight
MessagePosté: 22 Mai 2021, 22:31 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Bon, désolé pour le petit retard de publication, mais j'étais quelques peu en transit.

Où en étions nous ? :voyons: 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
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 ?
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:
Code:
* sprite 24x24
    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"
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:
Code:
    LDX #next ; adresse de retour
    BRA label ; appel sous-routine
next:
    ...

label:
    ...
    JMP ,X    ; 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.

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 ?


Fichiers joints:
Commentaire: Patch à appliquer entre $C8EA et $CC6A pour avoir tous les sprites accélérés.
C8EA_CC6A.zip [7.76 Kio]
Téléchargé 344 fois

_________________
Good morning, that's a nice Tnetennba
Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 69 messages ]  Aller à la page Précédente  1, 2, 3, 4, 5  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 42 invités


Vous ne pouvez pas poster de nouveaux sujets
Vous ne pouvez pas répondre aux sujets
Vous ne pouvez pas éditer vos messages
Vous ne pouvez pas supprimer vos messages
Vous ne pouvez pas joindre des fichiers

Rechercher:
Aller à:  
cron
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com