Ne pas oublier:
- une texture 32 bits 1024x1024 prend 4mb de vram
- une texture 8 bit de 1024x1024 prend 1mb de vram
- une texture ne doit "généralement" pas dépasser les 4096x4096,
  car la plupart des GPU ne supportent pas une taille plus grande
  (et certains sont limité a du 1024x1024 comme certaines vielles consoles).

Une des pierres angulaires d'un moteur de jeu 2d est l'affichage de sprites.
Il faut un système simple mais puissant.

Voici une liste des features attendues pour un moteur complet:
- afficher un sprite demande en moyenne 2 loc:
  - une pour charger les sprites (fichier de config, dossier de sprites)
  - une pour afficher le sprite en lui mee
- afficher un sprite ne doit pas demander de créer toute une pipeline graphique
  a la main, cela doit être déjà pres pour les usecase fréquents
- il faut pouvoir "bake" des commandes d'affichage (ex: dans un VBO)
- il faut un système de packing des sprites, avec la possibilité de charger ou
  décharger facilement des sprites au runtime => texture atlas dynamique
- il faut la possibilité d'utiliser un garbage collector efficace, qui s'occupera
  de charger et décharger des sprites automatiquement, dans le cas ou on n'a pas
  besoin de faire tout cela manuellement (soit 99% du temps).
- il faut la possibilité de générer des sprites a la volée, sans avoir a enregistrer
  des images via le filesystem
  ex:
  - particules procédurales
  - destruction de sprite existant (découpage automatique)
- le moteur de sprite doit être réutilisé pour l'affichage de texte
- le moteur de sprite doit être réutilisé pour le rendering de la GUI
- le moteur de sprite doit être backend-agnostic, potentiellement sur plusieurs
  niveaux d'abstraction
  => servira aux portages vulkan, 3ds et autres consoles
- il faut la possibilité d'utiliser des textures 8bit (pour par exemple l'affichage de
  texte, ou encore le rendu en couleurs indexées)

Packing:
- le packing de sprites peut être statique, il faut pouvoir l'effectuer directement
  sur une image sans contexte graphique (comme l'actuel ImagePacker et ImagePack)
- le packing dynamique quand a lui utile un framebuffer object
- il faut la possibilité de faire du packing par "polygones englobants"
  => avec la possibilité de faire des rotations pendant le packing: complexe!
  => il faut aussi un algorithme pour trouver le polygone recouvrant d'un sprite
  le plus "optimisé" (peu de vertex, mais pas trop de surface vides)
  http://cbna.forumactif.com/t13431-decouper-un-polygone-a-partir-d-une-image
  => on peut essayer de faire de l'espionage industriel, aux dernieres nouvelles
  aucun truc open source n'a été trouvé:
  https://www.spriteuv.com/#features-section
  https://www.codeandweb.com/texturepacker/tutorials/using-spritesheets-with-unity

Atlas:
- un atlas peut être statique ou dynamique (option)
- un atlas doit pouvoir gérer des textures en 32bits ou 8bits
- un atlas peut contenir plusieurs texture pages
- un atlas doit avoir des options pour définir la limite d'usage mémoire, et
  des options pour les texture pages
- il faut pouvoir paramétrer des groupes de sprites afin de:
  - forcer certains groupes a se charger sur la même texture page
  - forcer des groupes a se charger complètement ou non
- l'atlas ne doit pas être bloquant au moment du chargement
  => on peut bake des textures basse résolution et les utiliser dans le thread
  principal pendant qu'un thread secondaire fera le chargement depuis un dossier
  et le decoding avant de donner tout cela au thread principal
- l'atlas doit gérer le backing dans la mémoire, et être configurable
  - par exemple on peut vouloir garder certains groupes toujours en mémoire