Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Programmation : GFA Basic - 3617 Police
(Article écrit par Pierre-Philippe Launay et extrait d'Amiga News Tech - mai 1992)
|
|
Il est bien rare de ne pas afficher quelques lettres au cours d'un programme... Le problème est que pour aller vite, la
plupart d'entre nous utilisent encore les BOB alors qu'un codage élégant est tout à fait possible. Mais aujourd'hui,
pas de vitesse à l'état pur, afin de permettre un codage plus lisible : j'utilise PLOT. En GFA, la lenteur de PLOT
reste supportable, mais on est loin des 125 objets par seconde (25 puts + 100 textes) des BOB infinis de la
dernière fois...
Pour mieux comprendre la logique suivie, je vous propose de laisser les ROM Kernel Manual - Librairies And Devices,
page 191, pour relire la nouvelle Bible De L'Amiga : ce n'est pas que les RKM soient bogués, mais plutôt que
l'exemple proposé y est faux car trop imprécis. Je charge donc quelques polices, les active puis les dessine.
Je crée ainsi une structure TextAttr dans laquelle j'exprime mes quatre souhaits au système :
struct TextAttr
0 ta_Name Pointeur sur le nom LONG%
4 ta_YSize Hauteur souhaitée WORD&
6 ta_Style Algorithme souhaité BYTE|
7 ta_Flag Préférences souhaitées BYTE|
|
On modifiera "ta_Style" avec AskFontStyle() et SetFontStyle(), tandis que "ta_Flag" indiquera comment accéder
à la routine de création de chaque lettre :
- FPB_ROMFONT (0) : police en ROM (topaz 8 ou 9).
- PB_REVPATH (2) : lecture de droite à gauche (arabe).
- FPB_PROPORTIONAL (&H20) : chaque caractère de la police possède sa propre largeur (police proportionnelle).
XSize est alors inutile.
En réponse à ces quatre voeux, le système retourne un pointeur sur la structure TextFont disponible la
mieux adaptée. Puis cela se complique ensuite progressivement : tout d'abord, le graphisme des lettres pourrait être
assimilé à un dessin ayant pour hauteur YSize et pour largeur Modulo. Le bord gauche sera occupé par le
dessin de LoChar et le bord droit, par celui de HiChar. Ensuite, il faudra calculer chaque position de symbole
avec CharLoc, car par reliquat des temps anciens, il y a économie de place alors qu'il serait sans doute plus
judicieux de débuter chaque lettre avec un mot ou long mot ; cet anachronisme de l'ère des bouliers oblige
à tester chaque bit plutôt que d'afficher directement le contenu d'un mot ou d'un long mot.
Et ce n'est pas tout : troisième étape (Cf. le schéma suivant), CharKern est le nombre d'espaces entre le bord gauche
de la lettre et son bit gauche extrême. Mais rassurons Super OctetoPhage, car ce n'est pas fini, il reste
encore le plus étonnant pour la fin : chaque dessin de lettre est stocké en miroir, avec par exemple la barre
gauche du C mise à droite... Pourquoi faire simple quand on peut faire compliqué, si ça peut ralentir l'affichage
des textes ?
Voilà, pour accélérer, supprimez les PLOT que nous envie à tort le C, pour un codage plus percutant. Chargez et
modifiez la structure graphique de la police lue et utilisez le Blitter (ou BMOVE sur A3000...) comme pour un
défilement fait avec des BOB. Ou alors, moins rapide (mais tout de même !), utilisez simplement les fonctions
système comme ici pour print(). Et en résumé, que le Falcon tombe sur la tête de tous ceux qui créeront encore
des dessins pour leurs défilements de texte.
|
