Intérêt des sprites?

[Xenos]

[@lucard]

Impossible d'être catégorique.
tout dépend du besoin.

Si ce sont les ressources complètes du Jeu, cela n'a effectivement aucun intérêt si ce n'est que le Graphiste n'a qu'un truc à faire/modifier (un peu dans la même veine que les "textures" des modèles 3D).

Si c'est une sprite animée, alors ça vaut le coup d'avoir une image png. pour "simulé" un gif (l'avantage c'est de pouvoir avoir une transparence progressive, et plus de 256 couleurs).

Voici un exemple :
http://codepen.io/CyrilLevallois/pen/NGZjgZ

[Argorate]

Oui, il faut faire des sprites si tu as un projet un peu sérieux, tu auras nécessairement pas mal d’icônes.

Tu économises de la place dans le cache (client ET serveur)
du temps et de la bande passante pour le dl
de la rapidité pour le client à le dl car moins de requête http (qui sont limité en parallèle)
ce qui fait également que tu seras mieux référencer par google qui regarde bcp le temps de chargement global
et enfin, si tu es malin tu ne fais plus tes sprites à la main donc il y a 0 cout de maintient.

Quand à l'argument sur le cas de la modif, passé la Beta, tu ne modifie plus très souvent tes sprites, donc il ne tien pas.

[Xenos]

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.

[@lucard]

@xenos : 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...)
effectivement ça existe. le APNG (Animated PNG)
mais, par exemple, Photoshop ne sais pas générer ce genre de fichier Tout comme tous les logiciels "standards" d'édition/création d'image.
Il y a uniquement des convertisseurs, des "éditeurs de fichiers existants". C'est très loin d'être répandu.

De plus, en terme de compatibilité, Seul FireFox gère pleinement le support de ces images. (puisque c'est Mozilla qui développe cet extension au png)
Exit Chrome, IE, Opéra (sous Webkit) ...

Donc le apng est à laisser de côté pour la compatibilité.
L'avantage c'est qu'on peut afficher une image sur le web (une série de frame qui peuvent-être différente de la frame d'origine) et lors de l'enregistrement sur PC l'affichage sera la frame d'origine
-
Sous FireFox : cette image est verte (affiche frame#2)

Sous IE, Chrome, etc..  l'image est rouge (affiche la frame d'origine)
Si vous l'enregistrez, sur PC/Mac, elle sera rouge aussi.

Edit : Désolé pour le Hors-Sujet

[Xenos]

Ok, je croyais le format standardisé officiellement. Donc dans un tel cas, d'accord pour les sprites PNG pour faire de l'animation. Ma question reste ouverte pour les sprites PNG qui sont une fusion d'icônes dans le but "d'optimiser les chose" (parce que là, cette optimisation m'échappe).

L'avantage c'est qu'on peut afficher une image sur le web (une série de frame qui peuvent-être différente de la frame d'origine) et lors de l'enregistrement sur PC l'affichage sera la frame d'origine

C'est du bug using pour moi, c'est donc à proscrire (que le format soit standard ou pas): le jour où le format sera pris en charge par Windows, ce ne sera plus fonctionnel. Et quid d'un utilisateur Linux?

[@lucard]

C'est pas vraiment un bug.
Pour expliquer simplement
l'image "d'origine" ou par défaut qui est affichée sur les navigateurs (et les OS) n'acceptant pas l'animation png, peut-être différente de l'animation en elle même,
C'est un peu le principe des "images" de vidéo Youtube, si on prenait la 1er image de la vidéo, toutes les images "thumbnails" des vidéos seraient noires

Exemple :
dans ce cas, la première image de la séquence est aussi affichée comme image par défaut.

Numéro de séquence - Bloc
(aucun) - « acTL »
0 - « fcTL » (première trame)
(aucun) - « IDAT » (première trame — utilisée comme image par défaut)
1 - « fcTL » (deuxième trame)
2 - « fdAT » (premier « fDAT » pour la deuxième trame)
3 - « fdAT » (deuxième « fDAT » pour la deuxième trame)

Dans ce cas là : l'image par défaut n'appartient pas à la séquence.

Numéro de séquence - Bloc
(aucun) - « acTL »
(aucun) - « IDAT » (image par défaut)
0 - « fcTL » (première trame)
1 - Premier « fdAT » pour la première trame
2 - Deuxième « fdAT » pour la première trame
... - ...

---

si effectivement on parle de faire un sprite géant avec toutes les ressources du jeu, ça sera aussi complexe pour le Graphiste.
un png de 4000px x 4000px est beaucoup moins pratique que 10 png de 400 x 400 px.

[Sephi-Chan]

Avec HTTP 2 (et déjà SPDY), les sprites appartiendront au passé, tout comme la concaténation.
Si aujourd'hui tu n'utilises pas de générateurs, ce n'est même pas la peine de s'y mettre.

[Xenos]

Et iil y a quelques années (disons 5 ans), est-ce que tu conseillais l'utilisation de ces sprites? Pourquoi? Qu'est-ce qui a changé depuis? (j'adresse la question à tous ceux qui lisent, pas forcément qu'à Sephi )

Même sans tenir compte d'HTTP2, j'ai l'impression que ces sprites ne sont pas rentables, car dès la 1ere mise à jour, on en a perdu tout l'intérêt (Cache-Control + chaque icône dans son PNG m'a l'air plus efficace).

[Argorate]

Avec HTTP 2 (et déjà SPDY), les sprites appartiendront au passé, tout comme la concaténation.
Si aujourd'hui tu n'utilises pas de générateurs, ce n'est même pas la peine de s'y mettre.

Tu peux développer? ça m’intéresse

@xenos :

Le cache supprime les moins utilisé, pas les plus grosse (ou plus certainement les deux conditions à la suite, mais dans cette ordre).


Le changement des sprites en prod n'arrive presque jamais, par contre des nouveaux visiteurs qui télécharge l'ensemble de ton design est un événement avec un très grosse proba (en tout cas je te le souhaite ^^). Le gain me semble évident.

Il gagne en rapidité à cause de la règle des 2 requêtes http en parallèle maximum, si tu as 10 icones, il en téléchargera que deux et devra attendre qu'une se finisse pour lancer les autres. Le sprite résous pour partie ce problème. Le rendu progressif n'a aucun intérêt de mon point de vue : le jeu/site est afficher ou il ne l'ai pas (je me fiche de tout ce qui est intermédiaire, ce n'est pas un état satisfaisant du système).

Le FW entretient le FW tout seul, et l'outils du FW me permet d'avoir des images png distinct, il les colle en une seule image tout seul, avec le css associé tout seul aussi.
Je ne m'occupe de rien...

Les dernières modif du sprite de DVO date de 2 ou 3 version en arrière avec l'ajout de terrain (et peut être d'arme, je ne me souviens plus trop). Mais en gros, y a pas eu trop d'évolution. Et quand bien même, cela sera une modif unique. C'est pas comme du code qui doit être débugé, le graphisme tu le test en local, donc tu es sur de ta modif en prod, il n'y a donc qu'un seul changement.
De plus, si tu fais plusieurs sprites, par catégorie, tu évites de faire reDL tout ton site aux users, uniquement les parties modifié.


Bref, y a pas à douter de la chose pour moi^^
Sans parler des animations, un sprite est parfait pour gérer ça.