FTL Parser 2004 - Page 14

Mais fais attention aux images de moins de 8 pixels de largeur.

Ouais justement il y a toujours un bug quand je suis à -8 pixels de la finde l'écran.
Alors j'ai trouvé une autre optimisation mais qui risque d'être plus dangereurse par contre :

while(n--)
       {
  	     	 *(pointeur++) |=(x_>=0)*((*(pic)>>(mask1)));
  	     	 *(pointeur) |=(x_<=width_screen-8)*(((*(pic++)<<(8-mask1))));
  	       x_=x_+8;
       }

En effet ici dans tout les cas la routine va écrire quelque chose en mémoire. Si le test renvoit 0, la "moitié" d'octet va être effacé même s'il s'agit d'une partie en dehors de l'écran... il me semble. Je ne sais pas trop comment le compilateur traite ça.
C'est bon d'après vous ?

Je ne sais pas non plus comment le compilo traite ça, mais à mon avis dans le meilleur des cas, il génèrera le même code que si tu avais mis des if.

Ouais je viens de me rendre compte que c'était même pire.

bon, voilà, je suis enfin arrivée à la faire marché correctement cette routine !
Cette fois elle est vraiment rapide est ne comporte plus un seul bug :

__attribute__((regparm))void PutBitmap(short x, short y,BITMAP* BMP,unsigned char *video_plane)
{
	
  short j=0;
  short nb_c=BMP->NumCols; // on récupère le nombre de lignes du bitmap
  short nb_l=BMP->NumRows; // on récupère le nombre de colonnes du bitmap

  unsigned char *pic=BMP->Data; // on récupère un pointeur vers le Bitmap lui même
  if(y+nb_l>=height_screen) // si y + nombre de ligne > bas de l'écran
  nb_l=height_screen-y;     // nombre de ligne = bas de l'écran - y.
  short lenght = ((nb_c+7)>>3); // on calcule la longeur d'une ligne en octets : nombre de colonnes / 8
  short nb_sprite_out_up;
  if(y<0) // si le début du sprite est en dehors de l'écran en haut
  {
  	nb_sprite_out_up = -y*lenght;  // on calcule le nombre de sprite en dehors de l'écran : - le nb de ligne en dehors de l'écran * la longeur d'une ligne en octet
    pic=pic+nb_sprite_out_up;
    nb_l=nb_l+y;
    y=0;
    
  }
  short nb_sprite_out_right =0;
  
  if((x+(lenght<<3))>=width_screen)
  {
       nb_sprite_out_right = ((x+(lenght<<3)-(width_screen))>>3);
  	lenght = lenght-nb_sprite_out_right;
  }
  
  short nb_sprite_out_left=0;
  if(x<0)
  {
  	nb_sprite_out_left=((-1-x)>>3);
  	lenght = lenght - nb_sprite_out_left;
  }
  
  if(lenght<0)
  lenght=0;
  short mask1 = x&7;
  if(x<0)
  x=-1;
  for(j=0;j<nb_l;j++)
  { 
       
       
       short x_ = x;
       
       
       unsigned char *pointeur = (video_plane+(((y<<8)-(y<<4)+x_)>>3));
       /*                                    (256y-16y+x)/8       */
         
       short n=lenght-2;
       pic=(pic+nb_sprite_out_left);
          
       if(n>-2)
       {
           if(x_>=0)
  	     	 *(pointeur) |=((*(pic)>>(mask1)));
  	     	 *pointeur++;
  	       if(x_<=width_screen-8)
  	     	 *(pointeur) |=(((*(pic)<<(8-mask1))));
  	     	 pic++;
  	     	 
  	       x_=x_+8;
  	   }
       if(n>-1)
       {
          while(n--)
          {
  	     	     *(pointeur++) |=((*(pic)>>(mask1)));
  	     	     *(pointeur) |=(((*(pic++)<<(8-mask1))));
  	           x_=x_+8;
          }
           if(x_>=0)
  	     	 *(pointeur) |=((*(pic)>>(mask1)));
  	     	 *pointeur++;
  	       if(x_<=width_screen-8)
  	     	 *(pointeur) |=(((*(pic)<<(8-mask1))));
  	     	 pic++;
  	     	 
  	    
  	   x_=x_+8;
  	   }
       y++;
       pic=pic+nb_sprite_out_right;
       
  }
  
  
}

Par contre si vous voyez encore des optimisations je les accepterais volontiers Les derniers tests que j'ai rajouté pour le clipping l'on quand même pas mal ralentit... ah mais non en fait ! j'ai fait le bench sur VTI avec une Rom 92+. C'est normal que ça soit plus lent sous VTI avec une ROM 92+ ? Je précise que je n'utilise aucune routine pour copier ou effacer l'écran : je fais tout dans la LCD_MEM.
C'est peut-être le timer qui n'est pas pareil aussi ?

if (n>-2) => if (n<0)
if (n>-1) => else

Et ton indentation est complètement pourrie...

Ouais je sais. Mais bon le principal c'est que ça marche.
Et sinon est-ce que quelqu'un sait si PedRom supporte la fonction sprintf() ? Normalement je pense que oui mais bon on ne sait jamais.

Oui.

D'accord, merci.

Et sinon est-ce que quelqu'un sait si PedRom supporte la fonction sprintf() ? Normalement je pense que oui mais bon on ne sait jamais.

Dans la documentation de PedRom, il y a un fichier qui correspond au différend RC implémentés normalement.
il suffit de consulter ce fichier pour savoir si cela a été implémentés et testés.

(et voila un poste poster sans toucher le clavier ! )

ah oui en effet je n'avais pas remarqué, merci.

de rien

cela dit, certains RC sont implémentés, mais bugguent...
(parmi ceux qui ne sont pas testés)
(à moins que ça n'ai été corrigé)
(j'en avais reporté un ou deux dans le forum T3, il y a quelques temps)

Qui ont ete corriges.

LOL tjs la PpHd et Kevin Kofler !!!!!!!!!!!!!!!!!!!!!!!!!!!!

C'est un "ancien" de la communauté qui se rappelle de nous.

J'aurais ue question à propos de cette fonction :
void gray_idle(void)
{
pokeIO(0x600005,0b10111);
}

Sur Vti (hw1) elle ne ralentie pas du tout le programme alors que sur HW2 elle le ralentie pas mal et donc c'est dur de programmé pour les deux surtout lorsque que je l'utilise dans une fonction wait().
Je suis obligé d'utilisé un timer vu que cette fonction n'a pas l'air d'avoir le même effet sur les deux hardware.
Et j'ai remarqué la même chose avec la fonction idle.
Quelqu'un pourrait me dire pourquoi sur HW cette fonction ne ralentie pas autant le programme que sur HW1 et puis si elle est plus efficace sur un hardware que sur un autre ?

Ta fonction gray_idle() n'est censée attendre qu'un petit bout de temps, il n'y a à peu près aucune garantie sur le tps qu'elle attendra (VTI = pas d'attente, HW1 = attente courte, HW2 = attente un peu plus longue; sans compter que d'autres interruptions peuvent réveiller la calc). Donc tu es à peu près obligé d'avoir un timer externe...

il n'y a à peu près aucune garantie sur le tps qu'elle attendra

oui mais au départ je ne pensais pas qu'avec un même programme ce serait différents suivant les hardware.

C'est surtout VTI qui ne respecte pas les délais d'attente.

c'est surtotu qu vti est bon a mettre a la poubelle a pars le fait qu'il ne s'aggise que du seul emulateur de TI encore "valide"...

y'a TigerP aussi qu'est pas mal ^^

VTI est quand mm très bien ... ce n'est qu'un ému !
Puis rien n'empeche a qqn d'en faire un autre, ... GodZil ? XEmu powered by XLib v3 --PC-OGL ?

yep ^^

edit:

VTI est bien, mais il montre vite ces limites (surtout en se qui concerne les v200 et future 89platinium..)... d'ou l'interet de le remplacer..

Je veux essayer d'optimiser la rapidité de parsing (notament pour les gros fichiers parce-que c'est assez long) en utilisant des blocs de mémoires que j'alloue au fur et à mesure er selon les besoin au lieu de faire à chaque fois un malloc.
Jai déjà essayé mais je n'y suis pas arrivér car je ne sais pas comment determiné la fin de chaque données que je met bout à bout dans le bloc. En fait quand je veux afficher une chaîne de caractère dans ce bloc , ça affiche toute les chaînes et paramètres qui sont à la suite... Alors je ne sais pas trop comment faire.

Et sinon je pensais que ce serait intéressant de crypter les fichiers TEXT et que FTL Parser pourrait les lire décrypter. Mais c'est pas utile pour tout le monde () donc je pensais faire un système d'extensions qui permettrait au programme d'exécuter des petits sous programme de compression, de cryptage ou autres... vous pensez que ça peut-être une bonne idée ?
Mon programme fait 10 ko compressé et j'ai peur qu'après ça fasse un peu trop gros (surtout avec des trucs pas utile pour tout le monde).

Envoie un mini-msg à PpHd pour lui dire d'implémenter les plugins dans le nouveau format de kernel ^^

Oui bien sûr mais si à chaque fois il faut décrypter le programme avant c'est pas ce qu'il y a de plus pratique. C'est pour ça que je voulais savoir si ça valait le coup de permettre l'éxécution d'autre programmes lors de chaque chargement d'un fichier dans FTL Parser.