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 : C - les VSprites
(Article écrit par Batchman et extrait d'Amiga News - mai 1991)
|
|
VSprite ne signifie pas "Vacherie de Sprite" mais "Virtual Sprite". Et pourtant, il y avait de quoi hésiter.
Cette possibilité intéressante de l'Amiga est complètement méprisée : une documentation officielle très
incomplète dans le ROM Kernel Manual, pas d'articles ou de programmes d'exemple en circulation pour expliquer
comment cela fonctionne. Pourquoi cette attitude de rejet face aux VSprites ? En collaboration avec l'équipe d'ISF
(Informaticiens Sans Frontières et non pas Impôt de Solidarité sur la Fortune), j'ai décidé de lever un coin
du voile sur leurs difficiles conditions d'existence, de briser les chaînes de leur ghetto.
Mesdames, mesdemoiselles, messieurs, voici, pour la première fois dans un journal occidental, un reportage sans
concessions, avec des témoignages parfois accablants sur la dure condition des VSprites.
Être un VSprite en 1991
La dernière fois, je vous ai exposé la mise en oeuvre des sprites ordinaires. Simple mais limité :
pas plus de huit sprites, avec trois couleurs différentes par groupe de deux. Alors si je vous annonce aujourd'hui
que vous pouvez afficher autant de sprites que vous l'avez toujours souhaité sans oser le demander, avec trois couleurs
au choix pour chacun, ne me traitez pas de pleutre, ni de faquin, voire de malotru. Sachez qu'il y a rarement des
miracles en informatique (en tout cas, il n'y en a pas eu depuis la mise au point de l'Atari ST).
En effet, si les Virtual Sprites permettent tout ceci, c'est parce qu'un gestionnaire de VSprite simule un
nombre arbitrairement grand de sprites à partir des huit sprites de base que peut gérer l'Amiga. Il ne s'agit
donc que d'une astuce, qui a ses limites.
Comment ça marche
Le principe est simple : une fois qu'un sprite a été affiché, il est possible de le réutiliser pour en afficher
un autre, dans le même balayage d'écran. Compte-tenu de la rapidité des circuits de l'Amiga, c'est tout à fait
faisable. Mais puisque le balayage se fait de haut en bas, le deuxième sprite devra se situer plus bas dans
l'écran. Je dirai même plus, nettement plus bas, car il faut en effet laisser au système le temps d'effectuer
les changements nécessaires pour afficher un nouveau sprite par le même canal. En particulier, le Copper
est chargé de copier les couleurs de ce VSprite dans les registres de couleur du sprite sous-jacent.
Ces opérations durent un certain temps, pendant lequel le spot balaie plusieurs lignes d'écran, ce qui explique
la hauteur nécessaire entre deux VSprite utilisant le même sprite.
Le système gère lui-même ces calculs plutôt complexes : il choisit la meilleure utilisation de ses huit sprites
matériels pour afficher tous vos VSprites. Il tient compte de leur position et de leurs couleurs pour assigner
tel sprite à tel VSprite, puis réutiliser ce sprite pour afficher ensuite un autre VSprite, etc.
Pas de miracle
Hélas, des problèmes peuvent rapidement se poser. Comme deux VSprites utilisant successivement le même sprite
doivent être séparés de plusieurs lignes, vous comprenez que l'on ne puisse pas avoir sur la même ligne
plus de huit VSprites. Et encore, à condition que leurs couleurs s'y prêtent : chaque VSprite peut avoir sa
propre palette, alors que les huit sprites matériels ont une palette par couple. Conclusion, si huit VSprites
alignés ont chacun des couleurs différentes, il y aura malaise.
Que se passe-t-il si un VSprite ne peut pas être affiché ? Et bien, rien. Il n'est pas affiché. C'est le hic
des VSprites : quand il y a un conflit entre les ressources (le nombre de sprites disponibles) et les requêtes
(les VSprites), les VSprites ne pouvant être satisfaits ne sont pas affichés. Mais le système en dessine
toujours le maximum possible.
Venons-en au fait
Ce programme d'exemple illustre ces possibilités et ces problèmes (il est tellement bien conçu
que je le qualifierai de fabuleux progiciel didactique, ma modestie dût-elle en souffrir). Il affiche
seize VSprites, tous de couleurs différentes. Ils sont tous au départ sur la même ligne : ce qui en est trop,
même pour un Amiga et seul les quatre premiers s'affichent (NB : s'ils avaient tous, ou certains, eu les
mêmes couleurs, on aurait pu en avoir jusqu'à huit).
Puis ils se déplacent d'autant plus vite qu'ils sont vers la droite de l'écran. Vous pourrez alors observer
des configurations plus favorables : en effet, les VSprites n'étant plus au même niveau, des sprites pourront
être réutilisés pour afficher un autre VSprite dans les lignes inférieures. Il y a des cas où l'on peut observer
l'ensemble des seize VSprites. Cliquez sur le gadget de fermeture de la fenêtre pour sortir du cauchemar.
Le but de ce petit programme d'exemple (soyons réalistes) est de vous montrer la puissance de ce système mais
il met en évidence ses défauts d'une façon assez fallacieuse : en fait, il serait tout à fait possible de l'appliquer
dans la réalisation de petits jeux.
Je ne détaille pas plus le programme, il y a quelques commentaires à propos de qui fait quoi. Les fonctions
utilisées n'étant généralement pas spécifiques aux VSprites, les décrire nous ferait sortir du sujet.
Batchman, l'amigaïste qui tient ses promesses
Je reviens tout de même sur un point que j'avais laissé dans l'ombre lors du précédent
article : la fonction "GetSprite"
permet dans le programme d'exemple de réserver un sprite matériel. A priori, ça n'était pas indispensable
mais aujourd'hui, tout s'éclaire : cette fonction permet de réserver un sprite matériel pour votre usage
personnel, les autres sprites étant disponibles pour le gestionnaire de VSprites.
Avantage : Noah. Non, je plaisante. L'avantage est que vous pouvez avoir en même temps des sprites
matériels qui s'afficheront toujours à coup sûr, et des VSprites.
L'inconvénient, c'est qu'en interdisant au gestionnaire de VSprites d'utiliser certains sprites, vous réduisez
ses ressources. Il devient donc de plus en plus difficile pour lui de répondre à l'affichage de tous les VSprites.
Et maintenant, voici de quoi affiner vos qualités de dactylo :
Voilà. Je ne pense qu'il n'y a rien à ajouter. J'espère avoir attiré l'attention de l'opinion publique
internationale sur les difficiles conditions d'existence des VSpriies. Pour qu'à l'avenir, leur nom ne
soit plus synonyme de rejet, s'il vous plaît, adoptez-en un.
|
