Category Archives: programmation

Telegram, autocollants animés Lottie, Python et Glaxnimate

→ English version here

Sommaire

* Introduction
* Un bon flux de travail
* Publication sur le web (SVG)
* Bot Telegram

Introduction


Je suis un grand fan de l’interface de l’application de chat Telegram. Si le serveur est à sources fermées, l’application bureau et Android sont à sources ouvertes, l’interface est bien pensée, intuitive, relativement légère et plein de fonctionnalités intéressantes par rapport aux autres applications de ce type. Il serait d’ailleurs sans doute intéressant de la patcher pour une compatibilité Jabber/XMPP. Il a été le premier à ma connaissance, à utiliser Lottie, dès juillet 2019 (et l’API pour bot qui va avec) un format d’animation vectoriel dont je rêvait depuis des décennies, devenu un standard de fait et ouvert. Les animations de cette page ont été crées avec Glaxnimate, un outil pour réaliser des animations au format Lottie, que l’on peut également exporter au format SVG animation. Les auteurs de Lottie fournissent des JavaScript pour le web, la bibliothèque libre, rlottie de Samsung (en C++, avec version WASM) permet de les jouer et comporte des adaptations pour différents langage de programmation. Qt intègre sa lecture par défaut et il existe différents outils pour en créer.


Le logiciel libre multiplate-forme d’animation Glaxnimate permet d’en réaliser avec une interface graphique d’un type assez classique pour les logiciels d’animation. Son auteur à également fait une bibliothèque python, python-lottie (AUR : python-lottie-git, pip : Lottie), permettant d’en générer algorithmiquement et les 2 permettent de convertir différents formats (export SVG animé, Lottie JSON, page HTML toute prête, Telegram, mpeg4, PNG, wepb, gif, et je dois en oublier), et en entrée de vectoriser des gif animés, etc… Le logiciel d’animation vectoriel 2D Synfig à également un exportateur, ainsi que Blender3D (voir aussi Blender3D.fr en français), un plugin/greffon (distribué avec python lottie) fait également par l’auteur de Glaxnimate. Les choix ne manquent donc pas pour en créer.


Glaxnimate permet de faire facilement des animations au format Lottie, dont le format .TGS, une version aux spécifications volontairement plus limitées et compressée en gzip de Telegram. Le format de ce dernier est plus compact mais comportes quelques contraintes, cela n’a pas empêché d’avoir quelques merveilles depuis plus de 2 ans :
* format 512×512 pixels
* 3 secondes
* 64 Kio par autocollant animé
* Le tout peut être mis dans un paquet d’animations (sticker pack) regroupant différentes expressions (comme les émotiĉones/emoji).

Pourquoi 512×512 pixels alors que c’est un format vectoriel ? L’application cliente Telegram rendra dans cette dimension l’animation et la compressera en local, pendant la première boucle, en animation WebP de 512×512 pixels pour la conservation en cache. Cette dimension est déjà grande pour les certains écrans mobiles. Cela permet d’économiser la bande passante (animation vectorielle compacte transférée), d’avoir la haute qualité du vectoriel (généralement calculé par GPU, des accélérateurs SVG étaient déjà présent sur les téléphones Symbian des années 2000), et d’avoir des boucles d’animation qui ne prennent pas trop de CPU/GPU après la première boucle, ni trop de mémoire (compression WebP). WeChat/微信 a choisit des GIF animés il y a une bonne décennie, les GIF sont probablement convertit en MPEG aujourd’hui ? La messagerie instantanée Discord, populaire en Extrême-Occident, utilise aussi le format Lottie depuis juillet 2021.


Pour référence, l’animation du haut fait :
* 1109 octets (1,1 Ko) en TGS (format Telegram compressé binaire)
* 4682 octets (4,5 Ko) en json uglifié (plus d’indentations ni re retours chariots)
* 508054 octets (500 Ko) en WebP
* 9710 octets (9,6 Ko) en SVG animé (il y avait un path inutile en trop, je sais pas pourquoi).
* 1804 octets (1,7 Ko) en SVGZ animé (SVG compressé via gzip), il peut être plus intéressant de laisser le serveur compresser via brotli (Nginx, Apache) ou de pré-compresser (.br) Il est bien supporté par les navigateurs
* 6114 octets (6,1 Ko) en SVG, sortie optimisée Inkscape (basée sur Scour), on peut encore gagner, aujourd’hui si l’option de précision du nombre de chiffres après la virgule est inférieure à 3, elle reste à 3. Dans les parties animation non gérées on se retrouve à six 0 (1.000000 ou 0.000000). On peut encore l’optimiser à la main en attendant de l’intégrer (voir les sed plus bas), soit :
* 5827 octets (5,8 Ko) en SVG, retravaillé un peu à la main.
* 5559 octets (5,5 Ko) en supprimant des groupes intermédiaires inutiles (attention à ne pas tout casser, tester groupe par groupe) et en remplaçant 1.0 par 1


Un des principaux problèmes à la sortie optimisée de SVG depuis Glaxnimate est que Lottie est basés sur une forte utilisation des groupes, tandis-que SVG permet d’effectuer de nombreuses opérations équivalentes dur les objets eux-mêmes. Ainsi les matrices de transformation sont situées dans des groupes contenant les objets. Voir l’affichage XML d’Inkscape ci-contre. Cela demande donc aujourd’hui du travail manuel sur les fichiers. Il doit être possible d’automatiser ça.

Il semble que SVGO ai d’autres méthodes encore plus efficaces, mais basé sur du node.js, mais il casse complétement les animations. Je n’ai pas trop confiance, en raison de beaucoup de mauvaises habitudes autour de Node. Et le plugin Inkscape, inkscape-svgo ne déroge pas à ses nouvelles habitudes, si l’on essaie de le compiler avec le Makefile inclus, pas de test d’installation existante, récupération forcée de node 11 (x86_64, perd le multi-architecture), et recompilation de toutes les dépendances. On se retrouve une fois de plus avec une extension énorme de dizaines de méga-octets (75 Mo, contre 145 Mo pour Inkscape et 5 Mo pour la bibliothèque SVGO elle même), alors que ça devrait faire que quelques Ko grand maximum.

Continue reading

Lua, TIC-80, LÖVE, etc : Introduction aux systèmes de particles et jeux

English version here
Code par défaut de TIC-80 au lancement

Un langage intéressant pour déveloper des jeux, contenus interactifs et de l’art procédural est le langage de script Lua. C’est un langage fonctionnel simple avec quelques fonctionnalités limitées de langage orienté objet. C’est, en raison de sa simplicité et de la compilation en bytecode au démarrage par défaut, un des plus légers et rapides langages de scripts. Différentes intégrations comme le moteur de jeu/médias et (très puissante) API LÖVE, ainsi que TIC-80, qui est un ordinateur imaginaire virtuel inspiré par PICO-8 (qui utilise également Lua). Ils permettent des prototypages rapides, pour un produit fini dans le même langage ou bien porté plus tard dans l’avancement du projet dans un autre langage. Lua est également utilisé comme langage de systèmes de plug-in (greffons), dans de nombreux jeux, outils, dont des applications de bureau (comme Blender), des applications web (comme MediaWiki derrière Wikimedia), ou dans le mondede l’embarqué. Dans ce dernier domaine, les cartes de contrôle de drones populaires et open-source (logiciels libres à source ouvertes) BetaFlight ou le logiciel de commande-radio Open-TX notamment pour les commandes Taranis. Il y a une documentation en ligne complète de Lua (en anglais) sur le site web officiel. Il est possible d’inclure des fonctions ou bibliothèques en C dans les programmes en Lua programs avec libffi. Elle a été (je crois) crée à l’origine pour Python, avec CFFI, et il a également un support FFI for PHP à présent. Il est également possible d’intégrer des scripts Lua dans des programmes en C. J’ai également découvert en écrivant cet article (merci à l’auteur de TIC-80, qu’il existe également PicoC, un simple interpréteur du langage C, permettant donc un contrôle plus bas niveau/din des structures de données. La taille du binaire est similaire à celle de l’interpréteur de Lua.

Une demo interactive du fonctionnement et utilisation s fonctions trigonométriquesDonc, après plusieurs années à regarder de temps en temps ce langage et ces outils, J’ai commencé à jouer un peu plus avec, vers la fin de 2020, et en quelques mois, je peux dire que j’ai bien progressé dans la programmation temps-réel. Que j’ai réussi à faire et même finir des jeux légers. J’ai donc du étudier de nouveau la trigonométrie de base (suivez ce lien pour explication interactive simple), de l’algèbre vectoriel de base and et quelques autres éléments amusants des mathémtiques, que je considère personnellement comme des jeux de puzzles.

Banner of Falacy Gorx, pseudo 3d game, using lot of tables
J’ai également écrit (en anglais) une court article de making-off sur Itch.io en mars, 2021, pendant une compétition de bœuf de jeu (game jam, dans le même sens que les bœufs musicaux), au lieu de coder (malgré le temps limité à 2 semaines ^^). Tout cela m’a motivé à écrire d’avantage d’articles didactiques à propos de la programmation temps-réel/vectorielle et génération procédurale. Je vais tenter d’écrire une série une série d’articles expliquant les méthodes que j’ai utilisé. Je vais tenter de le faire avec autant de simplicité pour tout le monde, mais quelques connaissances de base en programmation générale et en mathématiques pourront beaucoup aider dans ce champs du développement, comme dans la vie en général.

Je commence donc ici une courte introduction avec ce que j’ai utilisé le plus dans ces développements. Des tables d’éléments et du hazard:,z
* Les tables et leur gestion de base commune, relative à une logique d’animation
* Créer une table
* Génération procédurale du contenu d’une table
* Exemple simple pour nettoyer une table
* Variation et nettoyage d’une table en fonction de tests
* Compacter un peu le code
* Génération procédurale du contenu de la table
* Exemple simple de système de particule graphique

Continue reading