Logicielsmoto.com

Nous sommes le 29 Mar 2024, 02:20

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 168 messages ]  Aller à la page Précédente  1, 2, 3, 4, 5, 6, 7, 8 ... 12  Suivante
Auteur Message
MessagePosté: 14 Aoû 2020, 22:07 
Hors ligne

Inscription: 13 Juin 2005, 21:50
Messages: 290
Localisation: Planete Zorg (31)
Neotenien a écrit:
C'était juste pour une démo pour voir quelle vitesse ça donnait (et 240 sprites en mode "avec masque" en 0.9 secondes, c'est assez satisfaisant je pense.

Le temps dans une machine ne se calcule pas en seconde mais en cycles ;)

Pour revenir à ce que je disais plus haut, tu peux précalculer la position des sprites dans le moteur de déplacement. Le MUL est trop chronophage alors que les déplacements sont de +/-1 colonne (si tu optes pour le déplacement de 1 octet), +/- 1 ligne (soit +/- 40 octets). Ce ne sont que des additions/soustractions. Alors je comprends mal l'utilisation d'un MUL à chaque fois que tu veux afficher tes personnages.

Neotenien a écrit:
Pour ce qui est du PSHS, désolé mais je ne l'utiliserai que dans le cadre unique d'un scrolling

Malheureusement la pile est très utile et tu seras contrait de l'utiliser quoi qu'il en soit ;)


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 15 Aoû 2020, 14:12 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
jasz a écrit:
Neotenien a écrit:
C'était juste pour une démo pour voir quelle vitesse ça donnait (et 240 sprites en mode "avec masque" en 0.9 secondes, c'est assez satisfaisant je pense.

Le temps dans une machine ne se calcule pas en seconde mais en cycles ;)

Pour revenir à ce que je disais plus haut, tu peux précalculer la position des sprites dans le moteur de déplacement. Le MUL est trop chronophage alors que les déplacements sont de +/-1 colonne (si tu optes pour le déplacement de 1 octet), +/- 1 ligne (soit +/- 40 octets). Ce ne sont que des additions/soustractions. Alors je comprends mal l'utilisation d'un MUL à chaque fois que tu veux afficher tes personnages.

Désolé mais j'ai aussi fait par addition avant et ça faisait au moins autant, voire plus de cycle d'horloge (17x2 pour être plus précis, alors qu'ici ça ne me fait que 33), parce que ça demande des accès multiple à la RAM.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 15 Aoû 2020, 14:36 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Niveaux de Bubble bubble ou comment avoir du 256x224 en 160x200 ?

Amstrad y est arrivé avec la version HomeBrew
phpBB [video]
, je ne vois pas comment! (Autre lien, les captures d'écran ici https://cpcrulez.fr/GamesTest/bubble_bobble_4_cpc.htm)
Apparemment, ils sont bien en 224 pxl de haut alors que l'Amstrad est sensé n'avoir que 200 lignes de haut max.

Je me suis dit dans un premier temps, de supprimer des lignes de 8pxl de haut pour tous les niveaux (la version Atari ST l'a faite en supprimant 1 ligne de 8pxl par niveau, en mettant le tableau des scores à droite, puisque eux sont en 320 de large, comparé aux 256 de la version arcade), mais pour le thomson ça supposerait de supprimer 3 lignes de 8 pxl, hors c'est pas possible pour certains niveaux.

Je me suis dis alors "et si j'essayais en adaptant à des lignes de 7 pxl de hauts ?", ça collerait, au niveau de l'espace de jeu on aurait 26x7 = 182 lignes de pixels, il en resterait 18 pour les 2 lignes du haut pour le score. Mais ça suppose de créer des tiles (de 8x7 pxls?) qui vont bien, mais je doute que ça soit possible...

Si le Thomson pouvait dépasser les 200 lignes...

Bon finalement, je crois que je pars sur une version où je n'aurai qu'une ligne de texte en haut (où il n'y aura d'affiché que les scores de Bubble et Boble) et supprimerai 2 lignes de 8. Ca me parait un bon compromis (adopté par le C64, BBC Micro notamment). 2 lignes supprimés sur 24 c'est pas désastreux.


Dernière édition par Neotenien le 15 Aoû 2020, 17:32, édité 1 fois.

Haut
 Profil  
Répondre en citant le message  
MessagePosté: 15 Aoû 2020, 17:28 
Hors ligne

Inscription: 13 Juin 2005, 21:50
Messages: 290
Localisation: Planete Zorg (31)
Neotenien a écrit:
Désolé mais j'ai aussi fait par addition avant et ça faisait au moins autant, voire plus de cycle d'horloge (17x2 pour être plus précis, alors qu'ici ça ne me fait que 33), parce que ça demande des accès multiple à la RAM.

:nanana: Tu as dû mal compter. Tu parles de 33 cycles mais x1 (couleur ou forme) et non x2 (couleur+forme).

Voilà comment réduire
Code:
     LDX    <$.bubble   ; adresse écran sprite bubble
     PSHS   X           ; on conserve l'ancienne position
     LDD    #1          ; on ajoute 1 pour avancer vers la droite
                        ; ou 40 pour descendre d'une ligne
     BSR    $.tests     ; on fait les tests qui vont bien

     LEAY   ,D          ; Y devient l'adresse physique de bubble
     PSHS   ,Y          ; on conserve Y pour y revenir après
/*  on pointe ici pour les données graphiques de bubble dans U ou X
     BSR    $.affichage ; et on affiche bubble en mode couleur (avec transparence)
     DEC    #$E7C3      ; on passe en mode forme
     PULS   ,Y          ; on récupère Y
     BSR    $.affichage ; et on termine d'afficher bubble

Dans cet exemple très succinct ton programme de 66 cycles ne prend plus que 9 + 15 cycles avec l'utilisation de la pile. Je n'ai pas inclus les datas graphiques de bubble qui je suppose sont dans X. Je ne fais ici qu'un seul appel RAM ($.bubble) dans le calcul de position. $.affichage est une routine unique qui affichera tout les sprites

[edit] Tu devras créer un tableau dans les données ou bubble évolura de la même manière que sur l'écran. Un tableau qui servira dans un premier temps à l'affichage puis dans un second temps aux tests de déplacement
Code:
.test
     ....
     BNE   $.ok        ; je ne peux pas avancer --> RTS
     ADDD  ,S++        ; on ajoute la valeur du déplacement contenue dans la pile
     STD   <$.bubble   ; on sauve la nouvelle position de bubble
.ok
     RTS



Dernière édition par jasz le 15 Aoû 2020, 22:08, édité 2 fois.

Haut
 Profil  
Répondre en citant le message  
MessagePosté: 15 Aoû 2020, 17:59 
Hors ligne

Inscription: 13 Juin 2005, 21:50
Messages: 290
Localisation: Planete Zorg (31)
Neotenien a écrit:
Si le Thomson pouvait dépasser les 200 lignes...

Je crois que le Thomson peut aller jusqu'à 224 lignes. Mais il faudrait alors utiliser les interruptions, trop coûteuses en TM.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 15 Aoû 2020, 18:57 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
@jasz il ya pas mal d'anomalie dans ton code ASM ;) (LEAY sur D seul (je pense que tu voulais travailler sur X en fait, et faire plutôt LEAX D,X (X = X+D), PULS au lieu de PSHS.. je te laisse corriger si tu veux). En gros tu fais 2 passe. Une sur la RAMA, et l'autre sur la RAMB en pushant sur la pile le pointeur dans la ram vidéo histoire de le récupérer sans calcul.

@Neotenien sur Amstrad tu peux bidouiller les registres vidéos à la volée et faire des trucs de dingues. Sur thomson rien de tout ca. L'automate d'affichage tolère juste le changement de mode GFX en cours de ligne pour la suivante, mais rien de bien folichon comme de l'overscan réel.

De mon coté, par rapport au code ASM que j'ai publié plus tôt qui contient du code auto-modifiable, je trouve la partie centrale quelque part "sous-optimale":
Code:
    LDA     ,X+     ; 6 X+ integre le LEAX 1,X couteux
*Debut transparence couleur 15                         
    CMPA    #$F0    ; 2                                   
    BLO     TRANSA  ; 3                                   
    LDB     ,Y      ; 4                                   
    BRA     TRANSB  ; 3
TRANSA                                                 
    LDB     -1,X    ; 5
TRANSB                                                 
    ANDB    #$F0    ; 2                                   
    STB     TRANSC+1    ; 5 (4 si DP) code auto-modifié           
    ANDA    #$0F    ; 2         |                       
    CMPA    #$0F    ; 2         |                       
    BLO     TRANSC  ; 3         |                       
    LDA     ,Y      ; 4         |                       
    ANDA    #$0F    ; 2         |                       
TRANSC SET *        ;           |                       
    ORA      #0     ; 2 <-------+     
* Fin transparence                                            |
    STA     ,Y+     ; 6

6+2+3+4+3+2+5+2+2+3+4+2+2+6 = 46 cycles max
6+2+3+5   +2+5+2+2+3   +2+6 = 38 min
Quand on fait les comptes ca fait entre 38 et 46 cycles pour un octet vidéo. Or si au lieu d'utiliser la valeur 15 comme couleur transparente, ce qui nécessite du masquage sur A, on utilisait plutôt la couleur 0.. on pourrait à la place avoir
Code:
LDA ,X+   ; 6 sprite
* Début transp
LDB ,Y    ; 4 ecran
BITA $F0  ; 2
BNE *+4   ; 3 on saute par dessus le ANDB qui suit
ANDB #$0F ; 2
BITA $0F  ; 2
BNE *+4   ; 3 on saute au dessus du ANDB
ANDB #$F0 ; 2
STB ,Y    ; 4
ORA ,Y    ; 4
* fin transp
STA ,Y+   ; 6

6+4+2+3+2+2+3+2+4+4+6 = 38 max
6+4+2+3  +2+3  +4+4+6 = 34 min
Dont l'execution la plus longue est égale à celle la plus courte de la routine précédente :good:

Mais on peut faire mieux: Les deux tests BITA/BNE/ANDB ne travaillent que sur un seul pixel. Je propose alors
Code:
LDA ,X+  ; 6
* Debut transp
LDB ,Y   ; 4
ANDB A,U ; 5
STB ,Y   ; 4
ORA ,Y   ; 4
* fin transp
STA ,Y+  ; 6
6+4+5+4+4+6 = 29 cycles min/max
Qui traite les deux tests BITA/BNE/ANDB ca en seulement 5 cycles avec le "ANDB A,U". En fait U contient une table précalculée qui résume tous les tests sans aucun surcout (on pert juste 256 octets de ram, c'est rien). La table est initialisée comme suit:
Code:
TABU RMB 256
 ...
* initialise U et TABU, à n'appeler qu'une fois au boot du moteur. (recharger U avec LDU si besoin par contre, ca coute rien)
INITTABU
   LDU #TABU+128
   CLRA
LOOP SET *
   CLRB
   BITA #$F0
   BNE  *+4
   ORB  #$F0
   BITA #$0F
   BNE  *+4
   ORB  #$0F
   STB  A,U
   INCA
   BNE  LOOP

Bref cette partie interne me plait carrément mieux à présent. Elle passe de 46 cycles max à 29 max soit 37% plus rapide.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 15 Aoû 2020, 21:33 
Hors ligne

Inscription: 13 Juin 2005, 21:50
Messages: 290
Localisation: Planete Zorg (31)
Samuel Devulder a écrit:
@jasz il ya pas mal d'anomalie dans ton code ASM ;)

Je l'avoue, je l'ai fait à la louche mais juste pour exemple. Pas top ;) Après je suis plus familiarisé ST, AMIGA :D Mais les astuces restent plus ou moins les même

Samuel Devulder a écrit:
je pense que tu voulais travailler sur X en fait, et faire plutôt LEAX D,X (X = X+D), PULS au lieu de PSHS.. je te laisse corriger si tu veux

Mince de bonsoir ...

Pour le LEAX non puisque je sauve sa nouvelle position avant de l'envoyé à Y :voyons:


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 16 Aoû 2020, 01:07 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Hihi je peux faire encore plus rapide en traitant 4 pixels d'uns coup (dans la même banque video)
Code:
LDD  ,X   ; (5) Lecture 2 octets de sprites en une fois
LDA  A,U  ; (5) Recup du masque pour le 1er octet
LDB  B,U  ; (5) Idem pour le 2nd octet
ANDA ,Y   ; (4) Masquage depuis la vidéo (1er octet)
ANDB 1,Y  ; (5) Idem avec 2n octet, donc D contient la vidéo où on a des "0" pour les couleurs non transparantes
ADDD ,X++ ; (9) Ajout des couleurs non transparantes pour le 1er et 2nd octet en une fois
STD  ,Y++ ; (8) Mise à jour en ram vidéo des 1er et 2nd octets en une fois et avancée de 2 colonnes
soit 5+5+5+4+5+9+8 = 41 cycles pour 4 pixels, au lieu de 2x29=58 si on travaille octet par octet avec le code juste au dessus. Le truc cool aussi c'est qu'on peut se permettre d'entrelacer le passage RAMA/RAMB si on ne supporte pas de voir à l'écran l'effet de peigne quand on attends trop entre le passage RAMA/RAMB:
Code:
LDD ,X      ; (5) lecture data sprite RAMA/RAMB en une fois
LDA  A,U    ; (5) Recup du masque pour RAMA
LDB  B,U    ; (5) Recup du masque pour RAMB
ANDA ,Y     ; (4) Masquage pixels RAMA
DEC <$E7C3  ; (6) Passage sur l'autre page video (utilisation mode DP)
ANDB ,Y     ; (4) Masquage pixels RAMB
ADDD ,X++   ; (9) Supperposition du sprite RAMA/RAMB en une fois
STB  ,Y     ; (4) Mise à jour écran RAMB
INC <$E7C3  ; (6) Retour en page RAMA
STA ,Y+     ; (6) Ecriture écran RAMA et avancée d'une colonne
5+5+5+4+6+4+9+4+6+6 = 54 cycles pour RAMA et RAMB dans la foulée là où le code d'origine nécessitait 2 passes de 44 cycles chacune.

Bref: je suis à présent convaincu qu'utiliser la couleur 0 comme transparence est une très bonne idée. Le plus ultime est ce qu'a fait Bentoc où là on réduit les opérations de masque au minimum, mais c'est pas applicable si on a un espace mémoire restreint.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 16 Aoû 2020, 16:15 
Hors ligne

Inscription: 13 Juin 2005, 21:50
Messages: 290
Localisation: Planete Zorg (31)
Quelle bonne idée! :bien:


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 18 Aoû 2020, 11:57 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Bonjour

Pour ce qui est de la transparence je reste sur mon code qui exécute la transpârence de 32 à 39 cycle d'horloge (et je crois même que ça va en dessous de 30 si je suis en DP) simplement parce que c'est une routine générique et que ça dépend de la largeur des sprites qui peuvent être à partir de 4 PXL (Manipulation d'1 octet) même si je n'ai pas de sprite aussi peu large pour le moment (mais ça peut venir avec des missiles par exemple)

Actuellement, j'en suis à la phase animation (mes routines d'affichage en RAMA et RAMB fonctionnent très bien, mais je pense à les transférer dans des b,nques mémoire où là, je n'aurai qu'à manipuler les adresse de 0 à 7999 (RAMA) et de 8000 ) 15999 (RAMB), il n'y aura plus de bascule à faire en E7C3, juste des ajout ou soustraction de 8000 octets. Vu que le TO8 et TO9+ peuvent gérer les adresse RAM écran en basculant d'une banque RAM (0, 2 et 3) à l'autre.

Maintenant donc j'en suis aux gestion d'interruption. J'écris un nouvel article à ce sujet dans la rubrique "programmation"


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 18 Aoû 2020, 20:42 
Hors ligne

Inscription: 13 Juin 2005, 21:50
Messages: 290
Localisation: Planete Zorg (31)
Neotenien a écrit:
Actuellement, j'en suis à la phase animation (mes routines d'affichage en RAMA et RAMB fonctionnent très bien, mais je pense à les transférer dans des b,nques mémoire où là, je n'aurai qu'à manipuler les adresse de 0 à 7999 (RAMA) et de 8000 ) 15999 (RAMB), il n'y aura plus de bascule à faire en E7C3, juste des ajout ou soustraction de 8000 octets


Tu fais comme tu veux mais un
Code:
LDX   #.RAMA
LDD   #8000
LEAX  D,X   ; bascule en RAMB par ajout de D

Prend plus de cycle qu'un simple INC/DEC #$E7C3 ;)


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 20 Aoû 2020, 22:31 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Des news sur les avancées pour l'animations de sprites.

Alors que c'est pleinement opérationnelle en dehors des routines d'interruption, le code suivant, sensé afficher 6 Bubble Bobble de haut en bas en train de se déplacer de gauche à droite avec "effacement" en début de chaque interruption, donne le drôle de résultat que vous voyez en vidéo.
phpBB [video]


Code:
*Equates
* Adresse ecran logique
ECRDEB EQU $4000
* Affichage d'un caractere
PUTC EQU $E803
*Timer
KBIN EQU $E830 a appeler fin procedure timer
STATUT EQU $6019 b5 pour valider timer
TIMEPT EQU $6027 Adresse routine timer
IRQPT EQU $6021 Adresse routine timer
TCR EQU $E7C5 Registre controle timer (???)
TSB EQU $E7C6 Valeur (16bits) timer en nombre de 8 cycles
*************************************
*Procedure affiche sprite avec
*transparence mode bm16c pour
*adresse ecran paire ET impaire
*Variable externe : RAMECR
************************************
 ORG $7200 Minimum en Basic 512
ASPRIT LDA $E7C3
 ORA #1
 STA $E7C3
SPRI01 LDA HSPRIP Boucle I HSPRIP
 STA ISPRIP Samuel Duvelver
 LDY >RAMECR
SPRI02 LDA LSPRIP Boucle J LSPRIP
 STA JSPRIP
SPRI03 LDA ,X Boucle J : LSPRIP
*Debut transparence couleur 15
 CMPA #$F0
 BLO TRANSA
 LDB ,Y
 JMP TRANSB
TRANSA LDB ,X
TRANSB ANDB #$F0
 STB BTEMPO
 ANDA #$0F
 CMPA #$0F
 BLO TRANSC
 LDA ,Y
 ANDA #$0F
TRANSC ORA BTEMPO
* Fin transparence
 STA ,Y+
 LEAX 1,X
 DEC JSPRIP Samuel Duvelver
 BNE SPRI03
* Fin boucle J
 LDA #40
 SUBA LSPRIP Soustrait largeur sprite
 LEAY A,Y
 DEC ISPRIP Samuel Duvelver
 BNE SPRI02
* Fin boucle I
 LDA $E7C3
 LSRA Samuel duvelver
 BCC FIPRO0
 LSLA
 STA $E7C3 Mis a 0 bit 0
 JMP SPRI01
FIPRO0 RTS
*************************************
*Procedure affiche tile. Meme
*fonction que pour sprite sauf
*qu'il n'y a pas de transparence.
*Variable externe : RAMECR
************************************
ATILE LDA $E7C3
 ORA #1
 STA $E7C3
TILE01 LDA HSPRIP Boucle I HSPRIP
 STA ISPRIP Samuel Duvelver
 LDY >RAMECR
TILE02 LDA LSPRIP Boucle J LSPRIP
 STA JSPRIP
TILE03 LDA ,X Boucle J : LSPRIP
 STA ,Y+
 LEAX 1,X
 DEC JSPRIP Samuel Duvelver
 BNE TILE03
* Fin boucle J
 LDA #40
 SUBA LSPRIP Soustrait largeur sprite
 LEAY A,Y
 DEC ISPRIP Samuel Duvelver
 BNE TILE02
* Fin boucle I
 LDA $E7C3
 LSRA Samuel duvelver
 BCC FIPRO1
 LSLA
 STA $E7C3 Mis a 0 bit 0
 JMP TILE01
FIPRO1 RTS Idem a FIPRO0!
****************************
*DATA pour fonctions affiche
****************************
ISPRIP FCB 0 Index I
JSPRIP FCB 0 Index J
HSPRIP FCB 16 Hauteur de Sprite
LSPRIP FCB 2 Nb octets RAM ecran de large
BTEMPO FCB 0
*************************************
*Effacement Sprite.Variables externe:
*RAMECR,DEBECR
*************************************
POSTIL *
 LDB >YSPRIT
 LDA #40
 MUL
 ADDB >XSPRIT
 ADDD #ECRDEB
 STD >RAMECR
 LDX #ADRTIL
 JSR >ATILE
 RTS
*************************************
*Positionnement Sprite.Variables externe:
*RAMECR,DEBECR
*************************************
POSSPR *
 LDB >YSPRIT
 LDA #40
 MUL
 ADDB >XSPRIT
 ADDD #ECRDEB
 STD >RAMECR
 LDX #ADRSPR
 JSR >ASPRIT
 RTS
**************
*Routine timer
**************
 ORG $7A00
FUTIMR *
 ORCC #50
 LDA >XSPRIT
 CMPA #39
 BEQ STOTMR Fin de la routine d'interruption
*On vide les sprites
VIDSPR *
 JSR >POSTIL
 LDB >YSPRIT
 ADDB #32
 STB >YSPRIT
 CMPB #192
 BLO VIDSPR
 LDA #0
 STA >YSPRIT
TMRRT0 *
*Affichage sprites
 LDA >XSPRIT
 INCA increment 4px droite
 STA >XSPRIT
TMRRT1 *
 JSR >POSSPR
 LDB >YSPRIT
 ADDB #32
 STB >YSPRIT
 CMPB #192
 BLO TMRRT1
 LDA #0
 STA >YSPRIT
 ANDCC #$AF
 JMP KBIN
STOTMR * Extinction statut timer
 LDA >STATUT
 ANDA #$DF
 STA >STATUT
 ANDCC #$AF
 JMP KBIN
********************************
*Programme principal
*Animation sprite bas de l ecran
*de gauche a droite
********************************
 ORG $8000 Apres les fonctions
MAIN LDB #$1B sequence d echappement
 JSR PUTC
 LDB #$5E Mode bm16c
 JSR PUTC
*INIT DP pour accelerer les fonctions
 TFR DP,A
 STA >DPINIT
 LDA #$72
 TFR A,DP
 SETDP $72
*Programme*
 LDA #0
 STA >XSPRIT
 STA >YSPRIT
 LDD #6249
 STD TSB
 LDA >STATUT
 ORA #$20
 STA >STATUT
 LDX #FUTIMR Routine d interruption
* STX IRQPT
 STX TIMEPT
*fin programme*
 LDA DPINIT
 TFR A,DP
 RTS
 ORG $A000
************************
*Data deplacement sprite
************************
XSPRIT FCB 0 par 4 px horizontal (RAMEcran)
YSPRIT FCB 0
***************
*Data divers
***************
DPINIT FCB 0
LIMITB FCB 0
STIMER FDB 0 Adresse routine timer init
SVLTMR FDB 0 Valeur timer init
RAMECR FDB 0
**************************
* Les Sprites
**************************
* Bubble Droite 1
ADRSPR FCB 255,243,255,51,243,34,255
 FCB 34,255,39,51,112,243,112
 FCB 255,112,51,112,243,39,255
 FCB 0,255,34,245,39,245,39
 FCB 242,153,34,153,255,255,255
 FCB 255,51,47,50,34,242,39
 FCB 50,32,34,32,45,32,45
 FCB 32,32,39,82,112,82,34
 FCB 82,127,82,127,34,121,41
 FCB 121
ADRTIL FCB 0,0,0,0,0,0,0,0
 FCB 0,0,0,0,0,0,0,0
 FCB 0,0,0,0,0,0,0,0
 FCB 0,0,0,0,0,0,0,0
 FCB 0,0,0,0,0,0,0,0
 FCB 0,0,0,0,0,0,0,0
 FCB 0,0,0,0,0,0,0,0
 FCB 0,0,0,0,0,0,0,0
 END


J'ai tout essayé depuis 3 jours, dans la modification du code. Rien n'y fait, ça donne toujours cette animation SANS le bon sprite. A part quand ce n'est pas en mode "interruption" Je ne comprend pas comment le sprite ne peut s'afficher correctement alors que c'est exactement le même code que pour l'algorithme de l'affichage des 240 Sprites. L'autre soucis est que l'effacement des Sprite (avec le "Tile" se situant à ADRTIL ne semble pas s'afficher au bon endroit pour effacer les Sprites.

Par contre au niveau vitesse... C'est + que correct! Ici les interruptions sont sensées se faire toute les 1/20s et ça se fait effectivement à cette vitesse (40 images "plans" en 2 secondes). Je l'avai aussi effectué pour du 1/10s et là, ça se fait bien en 4 secondes aussi.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 20 Aoû 2020, 23:41 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Citation:
La lecture sur d'autres sites Web a été désactivée par le propriétaire de la vidéo.

:(

Petite optim dans le code source au passage:
Code:
JSR >ATILE
 RTS
s'optimise en
Code:
JMP ATILE
et si ATILE n'est pas loin, un BRA sera encore plus rapide.

Sinon:
Code:
LDA >STATUT
 ORA #$20
 STA >STATUT
doit se faire après avoir initialisé TIMEPT, sinon tu active le détournement du timer alors qu'il n'y a pas de routine branchée. Ca peut faire n'importe quoi.

Autre truc que je pige pas:
Code:
*INIT DP pour accelerer les fonctions
 TFR DP,A
 STA >DPINIT
 LDA #$72
 TFR A,DP
 SETDP $72

Là où c'est placé ca n'accélère rien! SETDP doit être mis avant les endroits où tu veux utiliser le code DP donc avant les routines de sprites. Là où il est ca n'accélère rien. Pire, je me demande si tu n'as pas codé en te disant que "dans le code d'itnerruption DP sera initialisé automagiquement $72", sauf que non. Si tu ne l'assigne pas dans ta routine d'interruption DP gardera celle qu'il avait avant, et donc tu lira des données ailleurs que là où tu penses. Si ca marche quand même c'est parce que tu n'utiliser pas l'adressage direct parce que le SETDP n'est pas mis au bon endroit dans le code. En général SETDP se met au début, et pointe sur la page qui contient les DATA, pas le code. Donc moi ce qsue je ferais c'est déplacer les données en $7200, je mettrais le SETDP en début du code, et je regarderais l'ASM produit pour voir si c'est ben et bien l'adressage direct qui est utilisé dans le code (et je mettrais $72 dans DP via A dans la routine de timer.)

Ensuite je pige pas ceci dans le code d'interruption:
Code:
FUTIMR *
 ORCC #50
On ne doit pas bloquer les interruptions dans un code d'interruption. Ca n'a aucun sens. Elles sont déjà bloquées par l'appellant, et du coup quant du fais le ANDCC à la sortie ca fait des choses imprévisibles.

Enfin: mon nom est mal orthographié ;)

_________________
Good morning, that's a nice Tnetennba


Dernière édition par Samuel Devulder le 21 Aoû 2020, 00:01, édité 5 fois.

Haut
 Profil  
Répondre en citant le message  
MessagePosté: 20 Aoû 2020, 23:52 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
Citation:
La lecture sur d'autres sites Web a été désactivée par le propriétaire de la vidéo.

:(


C'est activé désormais... Mais je ne voulais pas mettre la vidéo en "public" parce qu'elle ne sert que pour des tests.


Samuel Devulder a écrit:
Sinon:
Code:
LDA >STATUT
 ORA #$20
 STA >STATUT
doit se faire après avoir initialisé TIMEPT, sinon tu active le détournement du timer alors qu'il n'y a pas de routine branchées. Ca peut faire n'importe quoi.


Ok c'est noté (mais ça ne change rien)

Apparemment ça viendrait des autres interruptions aussi. Ce qui est curieux est qu'i y a du changement dans le code basic initial une fois la routine terminée. Il me semble avoir vu quelque part quo'n pouvait mettre les routines assembleur dès $7200 dans la RAM logique, mais apparemment ça foire un peu le système. Alors que le binaire qui affichait les 240 sprite, sans intervention des timer, a lui aussi été installé dans ces mêmes adresses là sans problème.

Le truc vient bien de la gestion des interruptions, mais j'aouve que je ne sais pas trop ce qu'il se passe.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 21 Aoû 2020, 00:05 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
DP n'est pas initialisé dans ta routine timer. Tu récupère ce qu'il y avait avant (celui du basic) du coup tu modifie les vars du basic et ton adresse mémoire du sprite est fausse vu qu'il y a les data du basic sur cette page DP à ce moment là. Est-ce que tu vois le truc?

Petite remarque au passage, au lieu de sauver DP dans DPINIT, utilise la pile: PSHS DP au début, et PULS DP,PC à la fin. C'est plus rapide et plus élégant (DPInit utilise un octet en permanence alors qu'on soit juste sauver DP temporairement.)

_________________
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  [ 168 messages ]  Aller à la page Précédente  1, 2, 3, 4, 5, 6, 7, 8 ... 12  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

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