Font variables - Page 2

geogeo
a écrit : Ta méthode n'est pas interessante, il faut 10 ko par font, c'est énorme pour un résultat identique avec des sprites >=9 et <=16 en largeur mais prend moins de place selon la largeur.

Je ne comprends pas ce que tu racontes là.

Tu proposes un format en disant qu'on doit nécessairement avoir 9<=X<=16. Moi, je te dis qu'on peut avoir 0<=X<=16 sans aucun problème avec exactement le même format. (Il suffit de changer OctetSize=(((x-1)>>3)+1)*y en OctetSize=2*y.) Oui, ton format n'est pas le format optimal dans ce cas (on gaspille de la place avec du remplissage), mais c'est quand-même possible. Donc ta spécification de format ne devrait pas placer des limites arbitraires et totalement inutiles comme le critère X>=9. D'ailleurs, une largeur de 9 est énorme pour une calculatrice. AMS n'utilise jamais plus de 8 de largeur.

je sais quand même afficher un sprite de 16 mais si je doit afficher un sprite de 8 en largeur avec sprite16 je suis bien obligé de remplir une variable en complétant avec des 0.

Sauf si elle est déjà complétée avec des 0 dans le fichier, ce qui est ce qu'on (jackiechan et moi) te dit depuis le début.

À titre d'exemple, pour une largeur 7, tu ne coderais pas:

0000000|0
0111110|0
0001000|0
0001000|0
0001000|0
0001000|0 0000000|0

mais:

0000000|0 00000000
0111110|0 00000000
0001000|0 00000000
0001000|0 00000000
0001000|0 00000000
0001000|0 00000000 0000000|0 00000000

J'ai compris mais cela reviens au même car le caractère affiché fera 16 en largeur donc je ne voie pas l'utilité. Mais au point de vue de la place que ça prend c'est identique puisque que 9,10... juste qu'a 16 en largeur c'est égale à 2 octets soit 16 bits. La méthode que tu décrit en haut je l'ais fait depuis longtemps mais le problème est réglè, on ce mélange les pinceaux tout les deux, je sais bien qu'il n'est pas possible d'afficher un sprite de largeur 9 sans faire 16 bits de largeur soit 2 octets. Mais ce problème là est résolus. Je parlais tout simplement de largeur 9... pour des informations sur la police.
Le problème n'est pas là, il est réglé depuis longtemps: maintenant je code mon sprite sur 16 bits pour les caractère <=8 il sont complété avec des 0 avec mon convertisseur. En effet optimiser l'affichage des caractères car là j'en suis à 2000 caractères/s en mode gras et normal et 1000 caractères/s pour italique mais je pense que c'est lent et franchement je ne sais pas comment optimser plus, est-ce que la façon de faire mon fichier:

XY,RegistreX,Sprite

correspond ou tout simplement sprite16 est trop lent?

Oui, c'est lent.
Faut faire ses propres routines de sprite ... et de préférence, optimisées pour l'affichage de caractères ...

Et si j'utilise cette méthode:

void XChar_OR(unsigned short x,register unsigned char *map,short hau,unsigned char offset,unsigned char *Plane)
{
Plane += offset;
Plane += x>>3; //adresse de la premiere ligne du sprite
x&=7;
while(hau)
{
*Plane |= (*map)>>x; //avant la séparation du sprite entre 2 Bytes
*(Plane+1) |= (*map)<<(8-x); //après la séparation
Plane +=30; //une ligne au dessous
map++;
hau--;
}
}

Si y a mieux n'hésitez pas!

J'ai des routines de dessin de chaîne de caractères, mais elles ne sont pas faites pour une telle taille. Plus de 8 pixels de large c'est énorme ! Personne n'utilise jamais ça...
Le problème est qu'elles ne sont pas finies...

Envoye moi les routines sur mon @mail je les modifirais pour les adapters à 8 pixels et >8 pixels de largeur!

geoffrey.anneheim@wanadoo.fr

Merci d'avance.