Ce billet fait partie de la série « Dirty Hacky ». Le but de cette série est un objet critique sur les astuces de web-développement, et n'a pas pour vocation d'être une recette définitive, mais d'attirer l'audience par la polémique technique.
BANG! BANG!            BANG!

0. Je parse en HTML .357 S&W
1. Commentaires conditionnels
2. Magouilles dans les CSS
3. Des confettis troués en CSS
4. Liens serrés dans la police
5. Des Bleus et des Boss
6. Exécutions très rapides
7. Le script des bas-fonds
8. Préfixes frelatés

Le sprite canal historique

Note Importante du service Juridique : Les avocats de la production tiennent à préciser que le terme « sprite » désigne une technique et nullement une boisson gazeuse ou ses produits dérivés. Ce texte ne remet nullement en cause les trademark Sprite®, copyrights, industrials secrets et derivative rights détenus par The Coca-Cola Company, ni ne veut constituer une contrefaçon ou incitation à la contrefaçon.

Techniquement, sur les ordinateurs familiaux historiques de la génération 16/32 bits, un sprite est un objet graphique directement généré par le coprocesseur vidéo et qui ne laisse pas de place dans le raster de l'image affichée. À une époque où les accès RAM étaient couteux tout comme la moindre opération graphique, cette possibilité technique fut bien utile.
Oui, en cette ère de la Trois Dé triomphante jusque sur nos écrans de cinémas, ces considérations de graphisme 2D, utilisant des mémoires en raster ne doivent pas parler aux pitis jeuniots. Et pourtant, le sprite était une révolution qui subsiste encore de nos jours sur les ordinateurs de bureau.

La contrepartie non-directe était le bob sur Amiga (blitter object), et le hardware tiling sur consoles de jeux. Bien souvent, le curseur de votre souris est un sprite hardware, géré par votre carte vidéo, l'Amiga a été pionnier dans cette optimisation comme illustré ci-dessus. La technique des sprites permettait de créer de très nombreux effets, elle était au cœur de la Neo-Geo.

Leur méthode de stockage en mémoire est intéressante pour la suite : chaque dessin était stockée en mémoire dans une tuile d'une image, laquelle était en général de la taille de l'écran affichée. L'offset mémoire du début de la tuile était directement adressée au copro graphique, ou copiées/dupliquées entre les différents espaces mémoires pour les blobs, comme vous pouvez le voir sur cet exemple. Le changement d'aspect du sprite se faisait par un bête décalage d'adresse.

L'ère du sprite web

C'est cette philosophie qui a été adaptée au web, afin d'industrialiser le stockage, mais aussi de limiter au maximum le nombre de requêtes HTTP utilisées uniquement pour le décor. Plutôt qu'avoir 20 images à charger, n'en charger qu'une seule, et montrer 20 petites fenêtres différentes, comme le montre l'exemple à droite avec Google (repris du tutoriel de Nicolas Hoffmann pour Alsacréation). Une technique à la fois de layout html, de programmation css et de calculs de placements, devenus sibyllins par des outils web vous pré-mâchant le travail.

Au départ, je trouvais l’idée géniale. Il faut dire que j’ai toujours été attiré par les arts sacrés et mystiques par les demomakers. J’étais un fou de ce que pouvais faire mon Amiga. Je passais des heures à tenter de comprendre ces astuces en décortiquant la RAM les démos et les jeux (Team17 et Psygnosis).
(spécial big-up à Cyril Lambin, il se reconnaîtra dans ce premier épisode didactique et dans celui-ci qui résume bien le sujet).

Alors imaginez mon émotion quand j'ai entendu à nouveau parler de sprites, mais désormais appliqués aux navigateurs.

Caveat

Désolé, mais quand je parle de la vieille époque, j'ai des relents de latin qui remontent.
Néanmoins, cette méthode peut se montrer lourd, et les sprites se travaillent en pixels, avec des dimensions pré-définies, il rappelle une époque où les pixels étaient gros, et pas carrés, mais ovalescents de part le balayage des tubes cathodiques.
Le principe même du sprite pour les éléments décoratif est amené à disparaitre car la notion de pixel devient très relative avec les écrans à haute-densité. À mon sens, il est évident que nous allons basculer vers du design purement vectoriel, et là, nous avons deux outils qui ont les mêmes avantages (excepté le support) :

• le SVG, puisqu'on peut y mettre plusieurs images qu'on peut ancrer, et y faire référence via CSS
• les polices vectorielles avec support couleur dans un plan à usage interne, et là, revoir ce que je disais sur les emoji. À ce sujet, j'en remets une couche la semaine prochaine.

La technique fut belle, mais elle subira le même sort que les sprites hardwares quand les jeux sont passés à la 3D : un concept intéressant, passionnant pour son chalenge technique, mais qui va se marginaliser.

To be continued

Les polices ligaturées, serait-ce la meilleure solution possible aux emoji ? En attendant, mon flingue est libéré, et je suis de la vieille école, je tire d'abord, je pose les questions ↓ ici-bas.