Logicielsmoto.com

Nous sommes le 28 Mar 2024, 20:04

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 276 messages ]  Aller à la page Précédente  1 ... 6, 7, 8, 9, 10, 11, 12 ... 19  Suivante
Auteur Message
MessagePosté: 15 Mar 2021, 02:14 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Pourquoi tu ne map pas une des banques dans l'espace ROM ? Tu aurais ainsi pratiquement de $0 à $9FFF (40ko) de ram presque complète puisque tu peux même utiliser les 8ko de ram VIDEO comme de la vraie ram non visible si tu affiches une autre page physique que la 0 (ou la 1, je ne sais jamais son numéro physique).

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 15 Mar 2021, 07:05 
Hors ligne

Inscription: 21 Avr 2019, 21:48
Messages: 433
Localisation: Var
Si tu utilises les pages 2 et 3 pour l'affichage et que tu n'utilises pas la page 0, celle-ci est montée et accessible au CPU en permanence par "moitié" dans l'espace $4000 à $5FFF.

edit: feux croisés de réponse :lol: sam a été plus rapide


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 15 Mar 2021, 08:31 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
Pourquoi tu ne map pas une des banques dans l'espace ROM ? Tu aurais ainsi pratiquement de $0 à $9FFF (40ko) de ram presque complète puisque tu peux même utiliser les 8ko de ram VIDEO comme de la vraie ram non visible si tu affiches une autre page physique que la 0 (ou la 1, je ne sais jamais son numéro physique).


Je ne suis pas sûr que ça soit indispensable pour un jeu tel que PacMan (pas besoin de retracer le décor de fond). Vu que les personnages se déplacent tous sur fond noir -ou fond noir avec des sprites pastilles).

Par contre, pour Bubble Bobble, je l'envisage sérieusement : les sprites coupes des morceaux de décors


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 15 Mar 2021, 13:52 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
ok donc pour comprendre,
en faite pour le swap écran j'ai utilisé une zone auquel je peut accéder en permanence ?
et si je déplace la zone du swap écran ailleurs , je libère cette place accessible tout le temps !

C'est bien ça que vous me dites ?

PS : @Neotenien, je n'affiche pas le decors de fond, il est affiché 1 seul fois au début et je gère seulement le fond des sprites :)

_________________
Image


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 15 Mar 2021, 14:07 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Oui si tu affiches la page 2 ou 3, alors la 1 (ou 0, je sais jamais) est libérée. Cela veut dire que la zone $4000->$5F40 peut être utilisée comme bon te semble. Si de plus du mets une des autres pages en zone ROM, ca te fait pratiquement tout de $0000 à $9FFF (40ko) d'utilisable sans interférer avec l'affichage. C'est vraiment énorme comme place pour mettre du code et des données.

Pour info dans TO8 deMODed, j'utilise de $0000 à $DFFF pour mettre le player et les "mod"s (~56ko rien que pour moi).

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 15 Mar 2021, 14:18 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
Je vais voir comment de vais mettre en place cela, car j'ai un seul fichier asm buildé en 1 fichier BIN, qui commence à ORG 7300.

je sais qu'on peut faire plusieurs ORG dans le même fichier asm.
mais je sais pas 2 ORG dans un même BIN se charge tout seul, enfin bref je dois voir comment ça marche ça !

ok cool c'est top ça. merci... :bien:

_________________
Image


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 15 Mar 2021, 14:31 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Sisi ca marche bien plusieurs ORG.. le BIN généré contiendra plusieurs blocs logiques avec le code et les data de ton programmes. Ca fait un binaire à trou qui charge dans l'ordre de compilation de tes ORG. Ca marche bien.

A noter: Sur TO8/TO9+ tu peux même mettre un ORG en $E7E5 qui contient un FCB numéro-banque suivi d'un ORG $A000 avec du code ou des data, et dans ce cas lors du chargement des machins en $A000, cela ira dans la banque RAM choisie par le FCB de $E7E5 car le loader écrira pour toi le numéro de banque en $E7E5 juste avant. C'est tout simple, et très puissant.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 15 Mar 2021, 14:41 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
Super merci pour ces précisions :bien: :jap:

Bon vous moquez pas du bordel :D faire son premier code en assembleur from scratch bah ça donne ça !

Fichier(s) joint(s):
pac_2_17.ASS.zip [30.75 Kio]
Téléchargé 221 fois


Bon y'a vl'a des trucs à réécrire pour optimiser c'est sûr ;)

_________________
Image


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 15 Mar 2021, 16:10 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Quelques petites remarques simples qui pourraient te faire gagner à la fois du CPU et de la place.

Je vois que pour la palette tu fais pas mal de boucles avec A allant de 0 à 16. Du coup tu as toujours un CMPA #16 qui traine. Si tu démarrais ta boucle avec A=16 que tu décrois (DECA), tu n'a pas besoin de CMP #0 car elle est implicite avec le DECA qui peut être immédiatement suivi d'un BNE. D'une façon générale, en ASM on aime bien décompter plutôt que compter à cause de ca.

Dans le même ordre d'idée (la détection à 0 implicite), pour le joystick je te vois faire CMPA #1 + LBEQ right, puis CMPA #2 + LBEQ left, puis #3 top, et #4 bottom. Tu peux gagner des cycles et de la place en faisant juste DECA + LBEQ right, puis DECA + LBEQ left, DECA + LBEQ top, DECA + LBEQ bottom. Mais en fait, ici tu peux carrément faire beaucoup mieux que tout ca en utilisant une table de saut:
Code:
   LDX #dir_tab
   LDA  player_dir ; A=0 .. 4
   LSLA      ; il faut 2 octets par adresse, donc on double A ici
   JMP  [A,X] ; on saute directement à joy_XXX ou afterPDIRtest suivant la valeur de player_dir
dir_tab
   FDB afterPDIRtest ; A==0
   FDB joy_right ; A==1
   FDB joy_left ; A==2
   FDB joy_top ; A==3
   FDB joy_bottom ; A==4
afterPDIRtest
   ...
Ensuite dans ta macro PALETTE, je vois CLRA suivi de LDA #\0. Ce CLRA est inutile (le LDA écrase le 0 du CLR). Ensuite ce LDA #\0 est suivi par un ASLA. Or tu peux faire LDA #2*\0 qui combine les deux et te fais gagner 1 instruction (c'est l'avantage des macro aussi que de pouvoir laisser les calculs constants être faits lors de la compilation).

Par contre attention avec les macros, leur répétition mange très vite de la place. Parfois il vaut mieux passer par un appel de procédure. Je vais te montrer un truc que j'ai pas mal utilisé dans les intros de 1Ko à savoir MACRO + méthode + param dans le code le tout saupoudré de modification du compteur programme. C'est très pratique quand on a beaucoup d'appel à la même macro mais avec des paramètre constants mais différents d'un endroit à l'autre du programme:
Code:
MACRO PALETTE  ; n=\0, valeur_palette=\1
   JSR  setPAL
   FCB  2*\0   ; on laisse le compilateur faire la multiplciation par deux pour nous.
   FDB  \1     ; valeur palette (16 bits).
   ENDM

* ceci ne figure a un seul endroit du code, donc c'est factorisé au maximum
setPAL
   PSHS  D,X   ; on sauve les registres utilisés
   LDX  4,S    ; X pointe sur l'adresse de retour, c'est à dire ici le FCB avec 2*n
   LDA  ,X+    ; chargement de 2*n puisque X pointe dessus. A la sortie X pointe sur le FDB.
   STA  $E7DB  ; mise à jour de l'indexe palette.
   LDD  ,X++   ; chargement de la valeur palette. A la sortie X pointe sur l'instruction suivant le FDB
   STB  $E7DA  ; poids faible
   STA  $E7DA  ; poids fort
   STX  4,S    ; on met à jour le PC de retour avec l'adresse de l'instruction suivante le FDB
   PULS D,X,PC ; on récupère les valeurs des registres + le PC à jour
dans le code tu aura des
Code:
   PALETTE 0,4095
   PALETTE 2,123
comme avant, mais ce sera étendu en un code super conpact où le JSR est suivi par les valeurs attendues. Le code de setPAL se chargeant de mette à jour le PC à la sortie pour sauter par dessus les constantes (cela nécessite un peu de temps pour comprendre le truc, mais ca vaut le coup)

Plus loin dans le splash-screen je vois des STA ,Y suivi par LEAY 1,Y. Pourquoi ne fais tu pas directement STA ,Y+ ? Par ailleurs pour aller plus vite, le LDD/STD est plus rapide que de faire 2x plus de LDA/STA.

Plus loin encore je vois plein de code répétitif sur blinky (en fait sur tous les autres aussi):
Code:
p_set_anim_blinky_r
            LDX #blinky_r_anim
            STX blinky_anim
            LBRA setanimblinkyend
p_set_anim_blinky_b
            LDX #blinky_b_anim
            STX blinky_anim
            LBRA setanimblinkyend
p_set_anim_blinky_l
            LDX #blinky_l_anim
            STX blinky_anim
            LBRA setanimblinkyend
p_set_anim_blinky_t
            LDX #blinky_t_anim
            STX blinky_anim
            LBRA setanimblinkyend
p_set_anim_blinky_blue
            LDX #blinky_blue_anim
            STX blinky_anim
            LBRA setanimblinkyend
p_set_anim_blinky_grey
            LDX #blinky_grey_anim
            STX blinky_anim
            LBRA setanimblinkyend
p_set_anim_blinky_eyes
            LDX #blinky_eyes_anim
            STX blinky_anim
            LBRA setanimblinkyend
            * pinky ------------
...
setanimblinkyStart              * set blinky anim
            LDA  blinky_set_num
            CMPA #0                         ;RIGHT
            LBEQ  p_set_anim_blinky_r
            CMPA #1                         ;LEFT
            LBEQ  p_set_anim_blinky_l
            CMPA #2                         ;UP
            LBEQ  p_set_anim_blinky_t
            CMPA #3                         ;DOWN
            LBEQ  p_set_anim_blinky_b
            CMPA #4                         ;set blue
            LBEQ p_set_anim_blinky_blue
            CMPA #5                         ;set grey
            LBEQ p_set_anim_blinky_grey
            CMPA #6                         ;set eyes
            LBEQ p_set_anim_blinky_eyes     ;//TODO sprite address
setanimblinkyend
            RTS
Or tu pourrais factoriser bien plus et gagner pas mal d'octets:
Code:
p_set_anim_blinky_r
            LDX #blinky_r_anim
            bra p_set_anim_blinky
p_set_anim_blinky_b
            LDX #blinky_b_anim
            bra p_set_anim_blinky
p_set_anim_blinky_l
            LDX #blinky_l_anim
            bra p_set_anim_blinky
p_set_anim_blinky_t
            LDX #blinky_t_anim
            bra p_set_anim_blinky
p_set_anim_blinky_grey
            LDX #blinky_grey_anim
            bra p_set_anim_blinky
p_set_anim_blinky_eyes
            LDX #blinky_eyes_anim
p_set_anim_blinky ; <==== point de rencontre qui factorise tous les STX/LBRA d'avant
            STX blinky_anim
            LBRA setanimblinkyend
Mais là encore on peut faire bien mieux sachant que blink_set_num va de 0 à 6 avec un table de valeur avec
Code:
setanimblinkyStart              * set blinky anim
            LDA  blinky_set_num
            LSLA
            LDX #setanimblinkytab
            LDX A,X
            STX blinky_anim
setanimblinkyend
            RTS
setanimblinkytab
            FDB blinky_r_anim
            FDB blinky_b_anim
            FDB blinky_l_anim
            FDB blinky_t_anim
            FDB blinky_grey_anim
            FDB blinky_eyes_anim
15 lignes au lieu de 40+. Qu'en dis tu ?

Bon ca fait pas mal de remarques à digérer. Je vais m'arreter là, mais sache que tu peux, en utilisant un approche plus généraliste (avec tableaux) réduire ton code, le rendre plus maintenable (car un gros code comme ca d'un bloc est vraiment gros pour garder sa structure en tête), et même possiblement l'accélérer (accéder à la case n d'un tableau est plus rapide que de faire pleins de cmp pour tomber sur le bon "n").

_________________
Good morning, that's a nice Tnetennba


Dernière édition par Samuel Devulder le 15 Mar 2021, 18:21, édité 2 fois.

Haut
 Profil  
Répondre en citant le message  
MessagePosté: 15 Mar 2021, 16:38 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
Vu comme ça c'est vrai que je me rend compte de l'étalage que j'ai fais !
c'est juste que j'ai pas certain automatisme de l'assembleur.
Pour me rappeler de ma logique plus facilement, j'ai du coder comme ça..

mais avec tes explications, je me rend mieux compte du coup ...

J'ai été voir le gitHub de "Mr SONIC TO8" :D pour voir un peu, c'est super bien structuré, sur des fichiers asm séparé et tout. mais j'ai pas la pratique de faire comme ça pour l'assembleur encore .... :good:

En tout cas merci pour ces retours je vais les appliquer dès que je peux ... :jap:

_________________
Image


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 15 Mar 2021, 21:13 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
Oui si tu affiches la page 2 ou 3, alors la 1 (ou 0, je sais jamais) est libérée. Cela veut dire que la zone $4000->$5F40 peut être utilisée comme bon te semble. Si de plus du mets une des autres pages en zone ROM, ca te fait pratiquement tout de $0000 à $9FFF (40ko) d'utilisable sans interférer avec l'affichage. C'est vraiment énorme comme place pour mettre du code et des données.

Pour info dans TO8 deMODed, j'utilise de $0000 à $DFFF pour mettre le player et les "mod"s (~56ko rien que pour moi).


C'est exactement ça

L'affichage écran peux se faire avec les RAM physique 0, 2 et 3 (et pas d'autres). Pendant que, par exemple, la RAM physique 2 est affichée, on travaille avec la RAM 3 (en switchant la RAM Logique A000-DFFF vers cette RAM 3)

La 1 sert pour la zone utilisateur.

Et en RAM Logique 0-3FFF, espace cartouche, on peut y mettre n'importe laquelle des RAM physique (avec un switch du système). COmme ytu me l'avais dis SAm, pûr y insérer un décor de fond servant en double buffer. Mais comme je l'ai dit précédemment, inutile pour le Pacman d'ADNz puisqu'il ne se déplace que sur écran noir.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 16 Mar 2021, 19:34 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
bon j'ai fais tes 2 optimisations : palette et joystick,
Je suis passé de 192 octets à 312 octets de libre :bien:

et j'ai plein plein de cas similaire à l'optimisation comme joystick dans mon code, qui peut me faire gagner de la place ...

[EDIT] : encore optimisé les répétitions ==> 384 octes de libres :tourne:

_________________
Image


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 17 Mar 2021, 18:10 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
Citation:
15 lignes au lieu de 40+. Qu'en dis tu ?


ha! je viens de capter cette approche, c'est vrai que je peux appliquer ça à pas mal d'endroit dans mon code en faite...

15 au lieu de 40 :D je prends

merci.

_________________
Image


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 01 Avr 2021, 20:17 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
phpBB [video]


humm je viens de remarquer un bug dans l'incrément du score !

_________________
Image


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 02 Avr 2021, 00:29 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Hey, ca marche bien :bien:

Mais comme la vidéo est publiée un 1er Avril, j'ai comme un doute :voyons: C'est pas une blague ? :W

_________________
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  [ 276 messages ]  Aller à la page Précédente  1 ... 6, 7, 8, 9, 10, 11, 12 ... 19  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 21 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