Obligement - L'Amiga au maximum

Vendredi 26 mai 2017 - 21:01  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

 · Accueil
 · A Propos
 · Articles
 · Galeries
 · Glossaire
 · Hit Parade
 · Liens
 · Liste jeux Amiga
 · Quizz
 · Téléchargements
 · Trucs et astuces


Articles

 · Actualité (récente)
 · Actualité (archive)
 · Comparatifs
 · Dossiers
 · Entrevues
 · Matériel (tests)
 · Matériel (bidouilles)
 · Points de vue
 · En pratique
 · Programmation
 · Reportages
 · Tests de jeux
 · Tests de logiciels
 · Tests de compilations
 · Articles divers

 · Articles in english
 · Articles in other languages


Twitter

Suivez-nous sur Twitter




Liens

 · Sites de téléchargements
 · Associations
 · Pages Personnelles
 · Moteurs de recherche
 · Pages de liens
 · Constructeurs matériels
 · Matériel
 · Autres sites de matériel
 · Réparateurs
 · Revendeurs
 · Presse et médias
 · Programmation
 · Développeurs logiciels
 · Logiciels
 · Développeurs de jeux
 · Jeux
 · Autres sites de jeux
 · Scène démo
 · Divers
 · Informatique générale


Jeux Amiga

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


Trucs et astuces

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


Glossaire

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


Partenaires

Annuaire Amiga

Amedia Computer

Relec

Hit Parade


Soutien

N'hésitez pas à soutenir le projet Obligement



Contact

David Brunet

Courriel

 


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 :

C
C
C
C

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.


[Retour en haut] / [Retour aux articles] [Article précédent]