J'ai crée un fichier Font se présentant de la façon suivante:
XY Registre des X et Sprite
X=Longeur d'un sprite
Y=Hauteur d'un sprite
Registre X=Taille de chaque caractère en X (256 octets=1 octet par caractère)
Sprite=Sprite de chaque caractère les uns à la suite des autres.
Pour les fonts X doit être >=9 et <=16
Pour afficher le caractère e question j'utilise Sprite16_OR d'extgraph et je fait ceci:
void W_DrawChar(short x,short y,unsigned char CharCode,void *Dest)
{
Sprite16_OR(x,y,Font_Y,(void *)(HeapDeref(font->Sym->handle)+2+2+256+(font->OctetSize*CharCode)),Dest);
}
OctetSize=(((x-1)>>3)+1)*y
Font_Y=y
Je voudrais savoir si cette méthode peut être amélioré pour gagner de la vitesse. A savoir que je n'est besoin que d'un pointeur.
Mais au point de vue de la structure du fichier Font, est-ce que c'est correct?
Oui, c'est une des nombreuses solutions "correctes" possibles.
Je préfère plutôt créer des polices de taille variables car les utilisateurs pourront créer toute sorte de font mais rien n'empêche de créer des polices de tailles fixe, il y aura juste une perte de 256 octets.
J'ai recodé tout sur les font est j'arrive à une vitesse de 2000 caractères/s et 1000 caractères/s en italique. mais je ne sais pas si c'est pas assez et comment optimiser plus. J'utilise sprite16_or peut être que je doit utiliser une autre fonctions, la quelle me conseillerais vous?
XDanger n'est pas sur le forum mais c'est un membre de XLIB ?
D'accord, je suis nouveau est donc je ne connaît pas grand monde donc excuse moi pour mon ignorance.
Je résume:
Les sprites de mes caractères on tous la méme hauteur et longeur, pour afficher un sprite correctement sans passer pas spritex8_or je suis obligé de faire des fonts ayant comme longeur >=9 et <=16 car je veut que les utilisateurs créer leurs propres fonts.
La longeurs des caractères en X peuvent être variables (pas pour le sprite qui reste identique mais plutôt pour l'affichage).
Ca serait bien que tu m'envoye la nouvelles version d'extgraph...
Je voudrais savoir quel est la méthode graphique qui pourrais m'accélérer l'affichage des fonts.
Si c'est très important, sans cette information je ne peut pas trouver le sprite correspond au caractère voulu. Je sais mais si je fait une largeur de sprite inférieur à 8 je serais obligé de faire une variable temporaire et compléter avec des 0, au point de vue de la vitesse le problème est toujours là!
Je voudrais bien faire ton exemple mais tu n'as pas bien compris le problème: Les sprites du font... sont dans un fichier et donc il sont codé en octet et non en short donc pour convertir un sprite qui est en char en short je doit faire une variable temporaire et extraire les octet un par un puis complèter avec des 0 la variables temporairie. Je veut que les utilisateurs puisse créer leurs propres fonts dans un fichier et que les caractères soit variables ou pas. Pour ce qui est de X et Y j'en ais besoin pour 2 résond:
-Information sur le font pour des centrage...
-Trouvais l'adresse de début d'un sprite correspondant à un caractère car X et Y me donne la taille du sprite en octet et donc ça position dans le fichier.
mais un short = deux octets, donc tu peux recoder ce que j'ai mis en octets. Et de toute façon, un sprite de largeur supérieure ou égale à 9 pixels ne tiendra que sur des short au moins, donc ça ne veut rien dire, que ton sprite est codé en octets. Tu écris peut-être un octet à la fois, mais en réalité, la fonction Sprite16 les lit par 2.
D'ailleurs, fais attention à ce qu'ils ne soient pas à des adresses impaires, tes débuts de sprites, parce que je doute que tigcc aligne les char sur des adresses paires.
Je sais que Sprite16 lit 2 octets à la suite mais je n'est pas crée le fichier de font avec TIGCC mais avec un programme que j'ai fait sur PC qui transforme un BMP en BIN et que j'ai transformé en variable avec TOVAR. Je sais que un sprite >=9 pixels tient sur un short c'est pour ça que j'ai fait ça.
J'ai juste à faire ça avec Sprite16_or(x,y,h,(void*)(Adresse du sprite),dest)
Et sprite16_or lit 2 octets à la suite...
Oui mais il y une perte en mémoire:
00000000 00|000000
01111100 00|000000
00010000 00|000000
00010000 00|000000
00010000 00|000000
00010000 00|000000
00000000 00|000000
Voici le caractère T, pour convertir ce caractère en BIN (en prenant en compte dans ce cas que le sprite fait du 9*7) mon programme code octets par octets mais il y a une perte de 7 octets par sprite *256 =1792 octets mais pour que je puisse afficher un caractère inférieur à 9 pixels en largeur avec la fonction sprite16 je doit convertir ce caractère:
00000000
01111100
00010000
00010000
00010000
00010000
00000000
en ce qui est tout en haut sinon j'obtient cela ce qui est normal:
00000000 01111100
00010000 00010000
00010000 00010000
00000000 00000000
00000000 00000000
00000000 00000000
00000000 00000000
Mais mon but n'est pas de perdre du temps en convertissant un sprite du type char en short.
A savoir que avec de nombreux teste et comparaison avec istudio mon programme fonctionne parfaitement même mieux que istudio car il prend en compte des images <16 pixels en hauteur et en largeur.
Je sais que c'est possible mais au point vue de la vitesse? Il faut convertir donc la vitesse sera lente!
Il ne faut convertir rien du tout! Tu stockes tes sprites avec une largeur 16 et tu n'utilises que les premiers x bits, où x peut être entre 0 et 16 compris. Il y a quoi que tu n'as pas compris là-dedans???
