zelda:peut etre le retour - Page 7

J'abandonne la stabilisation des gris:

-Ca fait plusieurs dizaines d'heures que j'essaye de stabiliser les gris pour mon mapedit sans succes.
-($70001D) est toujours nul, meme quand je force tous les bits a 1.
-Le "graytest in assembleur", exemple fournit avec TIGCC fonctionne parfaitement.....SAUF que quand je modifie un tout petit peu le code de facon a ce que les graphlib:lanei soient rafraichis en permanence (sans modifier leur contenu pourtant), les gris deviennent affreux.
Donc le fait de mettre une boucle comme ci-apres dans le programme rend les gris hideux. Les gris se stabilisent si on met une TRES grande pause entre chaque affichage.

Ceci fonctionne:

move.l graphlib:lane0,a0
lea 1500(a0),a0
move.w #374,d0
\loop1 move.l #$FFFFFFFF,(a0)+
dbra d0,\loop1


move.l graphlib:lane1,a0
lea 750(a0),a0
move.w #374,d0
\loop2 move.w #$FFFF,(a0)+
dbra d0,\loop2

move.l graphlib:lane1,a0
lea 2250(a0),a0
move.w #374,d0
\loop3 move.w #$FFFF,(a0)+
dbra d0,\loop3

clr.w graphlib::choosescreen
jsr userlib::idle_loop

Mais les gris sont hideux ici:

\loop
move.l graphlib:lane0,a0
lea 1500(a0),a0
move.w #374,d0
\loop1 move.l #$FFFFFFFF,(a0)+
dbra d0,\loop1


move.l graphlib:lane1,a0
lea 750(a0),a0
move.w #374,d0
\loop2 move.w #$FFFF,(a0)+
dbra d0,\loop2

move.l graphlib:lane1,a0
lea 2250(a0),a0
move.w #374,d0
\loop3 move.w #$FFFF,(a0)+
dbra d0,\loop3
bra \loop

Arf, graphlib est un peu dépassée, non?

C'est peut-être une question bête, mais je suppose que tu ne testais pas sur VTI quand tu testais ton prog qui lisait $70001D... Ce port ne fonctionne que sur HW2

C vrai ca...

Utilise plutôt cet exemple-là:

 include "OS.h"
 xdef _nostub
 xdef _ti89
 xdef _ti92plus
plane0 equ __D_plane ;On ne doit pas accéder directement à des variables
plane1 equ __L_plane ;commençant par __.

 movem.l d4/a5,-(a7) ;sauvegarde d4 et a5
 move.l $c8,a5 ;place la table des ROM_CALLs en a5
 pea.l 3840 ;taille à allouer
            ;(même chose que move.l #3840,-(a7), mais plus optimisé)
 move.l HeapAllocPtr*4(a5),a0
 jsr (a0) ;alloue les 3840 octets
 move.l a0,d4 ;sauvegarde l'adresse du bloc alloué en d4
 tst.l d4
 beq nomem ;si le pointeur est nul, quitte le programme
 move.l #3840,(a7) ;taille à copier
;Cette instruction n'est pas vraiment nécessaire puisque HeapAllocPtr ne modifiera
;pas la valeur qui est déjà sur la pile, mais mieux vaut ne pas se fier.
 pea.l $4c00 ;source: adresse de l'écran
 move.l d4,-(a7) ;destination: adresse du bloc alloué
 move.l memcpy*4(a5),a0
 jsr (a0) ;sauvegarde l'écran
 lea.l 12(a7),a7 ;nettoie la pile

;début du programme principal
 move.l ScreenClear*4(a5),a0
 jsr (a0) ;efface l'écran principal (premier plan)
 bsr GrayOn ;active les niveaux de gris
 move.l #$ef007f,-(a7)
 move.l plane1(PC),-(a7)
 move.l PortSet*4(a5),a0
 jsr (a0) ;active le deuxième plan
 addq.l #8,a7
 move.l ScreenClear*4(a5),a0
 jsr (a0) ;efface le deuxième plan
 move.l #20*$1000000+20*$10000+40*$100+40,-(a7)
 move.w #1,-(a7)
 move.l ScrRect*4(a5),a0
 pea.l (a0)
 pea.l 6(a7)
 move.l ScrRectFill*4(a5),a0
 jsr (a0) ;dessine un rectangle rempli en gris clair
 move.l #80*$1000000+20*$10000+100*$100+40,10(a7)
 move.l ScrRectFill*4(a5),a0
 jsr (a0) ;dessine le plan clair d'un rectangle rempli en noir
 lea.l 14(a7),a7
 move.l #$ef007f,-(a7)
 move.l plane0(PC),-(a7)
 move.l PortSet*4(a5),a0
 jsr (a0) ;active le premier plan
 addq.l #8,a7
 move.l #50*$1000000+20*$10000+70*$100+40,-(a7)
 move.w #1,-(a7)
 move.l ScrRect*4(a5),a0
 pea.l (a0)
 pea.l 6(a7)
 move.l ScrRectFill*4(a5),a0
 jsr (a0) ;dessine un rectangle rempli en gris foncé
 move.l #80*$1000000+20*$10000+100*$100+40,10(a7)
 move.l ScrRectFill*4(a5),a0
 jsr (a0) ;dessine le plan foncé d'un rectangle rempli en noir
 lea.l 14(a7),a7
 move.l ngetchx*4(a5),a0
 jsr (a0) ;attend l'appui d'une touche
 bsr GrayOff
;fin du programme principal

 pea.l 3840 ;taille à copier
            ;(même chose que move.l #3840,-(a7), mais plus optimisé)
 move.l d4,-(a7) ;source: adresse du bloc alloué
 pea.l $4c00 ;destination: adresse de l'écran
 move.l memcpy*4(a5),a0
 jsr (a0) ;restaure l'écran
 addq.l #8,a7
 move.l d4,(a7)
 move.l HeapFreePtr*4(a5),a0
 jsr (a0) ;libère le bloc alloué
nomem:
 addq.l #4,a7 ;nettoie la pile
 movem.l (a7)+,d4/a5 ;restaure d4 et a5
 rts

Merci tout le monde, en fait $70001D ne marche pas sur VTI, mes niveaux de gris sont stabilisés mais le programme tourne presque 2 fois moins vite.
Maintenant, c'est le gros dilemme.

Galmiza a écrit :
Merci tout le monde, en fait $70001D ne marche pas sur VTI, mes niveaux de gris sont stabilisés mais le programme tourne presque 2 fois moins vite. Maintenant, c'est le gros dilemme.

Au moins il est fluide, mais moins rapide.

Merde, je voulais mettre Editer, pas citer...

Ce qui explique le fps élevé

des shots

Tu as déjà créé un topic pour ça.

Qu'est-ce qui vous fait dire que ce n'est pas possible 170 FPS?
Je suis peut-être mal placé pour dire ça vu que je ne sais pas faire de véritable scrolling (je réaffiche tout en clippant sur les bords à chaque frame) mais déjà à ce point on peut facilement atteindre les 30 FPS. Sachant que le moteur du jeu demande à peu près 10% du temps de l'affichage... En utilisant une routine d'affichage un peu plus rapide on peut largement monter à 200 FPS assez facilement... théoriquement non?!

Non

L'écran ne fait que du 90 Hz, donc bonne chance pour avoir plus de 90 fps.

L'écran ne fait que du 90 Hz, donc bonne chance pour avoir plus de 90 fps.

J'avais mesuré 250 FPS avec mon casse-brique de merde lorsque je supprimais l'attente. (nbr de frames affichées pendant 19 AUTO_INT_5). Mais comme son nom l'indique, c'était un jeu de merde qui demandait pas grand chose. Si on n'attend pas la VSync (FS dans notre cas), on n'a pas de raison d'être bloqué à 90 FPS. C'est clair que c'était laid à 250 FPS car tu as un tiers d'une frame, un tiers d'une autre et encore un tiers d'une troisième sur le même écran en gros.

C'est le nom de frames calculés que tu as comptés, pas le nombre de frames affichés.

Oui. Mais pour moi du moment que j'en ai terminé avec le buffer écran et que je le recopie sur LCD_MEM, ça compte pour une frame. Bien entendu que je ne contrôle pas si l'écran l'a affichée ou non. La ça n'est plus de mon domaine, mais de celui du hardware TI.
De toutes façons tu ne peux pas jouer à 250 FPS. Tu DOIS mettre une attente... Ce que je veux dire par là, c'est qu'avec 250 FPS tu as une immense marge qui te permettrait de faire un prog jusqu'à cinq fois plus lent sans que ça saccade. Et même plus. Il suffit de supprimer l'attente inutile dans la boucle principale...

héhé tout est possible

Ça fait beaucoup quand même.
Même genlib n'arrive pas à ce framerate.

Mais si ton prog NE FAIT RIEN:

while(1) {
  memset(Ecran,0,LCD_SIZE);
  Sprite32(64,34,32,monPerso,Ecran,SPRT_OR);
  if (_keytest(RR_ESC))  break;
  LCD_restore(Ecran);
}

Fait ça et mesure le nombre de FPS que tu as... Ca ne veut pas dire que l'écran a tout affiché, mais tu as bien fait quelques bons milliers de fois la boucles au final... (donc 1000 FPS)

vachement utile un prog qui fait rien

C'était juste pour illustrer que ce n'est pas impossible de faire plus de 1000 FPS

avec un memset et un sprite32, tu ne montera pas à 1000 fps