Je ne parlais pas des sprites animés, pour lesquels effectivement cela peut faire sens (faute de mieux; d'ailleurs un format PNG animé n'existerait-il pas? Je crois l'avoir déjà croisé un jour...)
Je ne sais pas si le fait d'avoir 1 seul fichier est un tel atout coté graphiste... Si jamais c'en est un, on pourrait envisager d'avoir alors 1 fichier unique pour le graphiste (type PSD, avec ses calques) et d'en sortir N fichiers PNG, 1 par icône (sur la base des calques par exemple, ou d'une grille de taille X;Y)? Cela implique évidemment de ne pas ré-écraser les PNG qui n'auraient pas été modifiés (donc ce script de génération 1 PSD→* PNG n'est pas hyper-trivial).
@Argorate:
En quoi économises-tu de la place dans le cache? La sprite étant plus grosse, elle a des risques d'être évincée si le cache est plein, au lieu de seulement perde les icônes les moins utilisées.
En quoi gagnes-tu du temps pour la bande passante et le DL sur le long terme, puisque tu obliges les utilisateurs à retélécharger toute la sprite PNG quand tu modifies/ajoute/supprime ne serait-ce qu'une icone?
En quoi le client gagne en rapidité puisque Cache-Control lui dit de ne même pas faire de requête HTTP? En gagne-t-il vraiment lors de la 1ere visite, puisqu'il doit attendre que toute la sprite PNG soit téléchargée (et donc, pas de rendu progressif, qu'on aurait avec 1 icone/PNG)?
En quoi as-tu 0 coût de maintiens puisque tu dois ou bien maintenir ton propre script de génération de sprite, ou bien maintenir celui d'un framework? Si, à la limite, c'est inclus dans un framework que t'utilise déjà, alors ok, ce sera mis à jour avec le framework. Sinon, c'est une tâche de plus; ne pas les grouper, c'est 0 travail de plus (mais là, vraiment 0).
Sur DVO, t'es plus en beta: tu n'as jamais modifié les sprites? Si tu ne modifies jamais les sprites passée la beta, le jeu finira par se démoder graphiquement.
Je ne sais pas si le fait d'avoir 1 seul fichier est un tel atout coté graphiste... Si jamais c'en est un, on pourrait envisager d'avoir alors 1 fichier unique pour le graphiste (type PSD, avec ses calques) et d'en sortir N fichiers PNG, 1 par icône (sur la base des calques par exemple, ou d'une grille de taille X;Y)? Cela implique évidemment de ne pas ré-écraser les PNG qui n'auraient pas été modifiés (donc ce script de génération 1 PSD→* PNG n'est pas hyper-trivial).
@Argorate:
En quoi économises-tu de la place dans le cache? La sprite étant plus grosse, elle a des risques d'être évincée si le cache est plein, au lieu de seulement perde les icônes les moins utilisées.
En quoi gagnes-tu du temps pour la bande passante et le DL sur le long terme, puisque tu obliges les utilisateurs à retélécharger toute la sprite PNG quand tu modifies/ajoute/supprime ne serait-ce qu'une icone?
En quoi le client gagne en rapidité puisque Cache-Control lui dit de ne même pas faire de requête HTTP? En gagne-t-il vraiment lors de la 1ere visite, puisqu'il doit attendre que toute la sprite PNG soit téléchargée (et donc, pas de rendu progressif, qu'on aurait avec 1 icone/PNG)?
En quoi as-tu 0 coût de maintiens puisque tu dois ou bien maintenir ton propre script de génération de sprite, ou bien maintenir celui d'un framework? Si, à la limite, c'est inclus dans un framework que t'utilise déjà, alors ok, ce sera mis à jour avec le framework. Sinon, c'est une tâche de plus; ne pas les grouper, c'est 0 travail de plus (mais là, vraiment 0).
Sur DVO, t'es plus en beta: tu n'as jamais modifié les sprites? Si tu ne modifies jamais les sprites passée la beta, le jeu finira par se démoder graphiquement.