ton 'gros' fichier PNG sera surement plus petit que les 4 'petits' fichiers (factorisation des entêtes et du dictionnaire de compression).
Sans compter le bête fait que la place occupée sera plus grosse parce que 4 blocs non utilisés complètement seront utilisés au lien d'un seul, en effet :)
Le terme de "gros" fichier n'avait pas pour but d'indiquer un gain de place, mais bien un problème d'organisation des ressources.
Ne serait-ce que pour la création d'une frame, il me semble plus simple de créer la 1ère, copier le fichier pour en créer un nouveau, le modifier en fonction de ce que l'on veut, et ce, autant de fois que nécessaire, plutôt que de modifier un seul fichier, au risque de déborder sur l'image d'a côté.
Sans parler d'ajouter une frame à une animation que l'on trouve trop grossière, sait-on jamais.
tu n'auras peut être même pas besoin de découper : tes frames sont empilées verticalement
Arf mais quel boulet je fais… pourquoi je pensais à les concaténer à l'horizontale…
, il suffira de jouer sur les pointeurs (ta 1ère frame c'est les 128x128 premiers pixels, la 2ème les 128x128 suivants etc…).
Là, j'ai envie de dire que ça dépends de la technique utilisée pour lire l'image.
Je viens de regarder, le code est en C, ce que j'ignorais (ça va raccourcir mon post du coup).
Effectivement, les pointeurs sont une solution.
Mais j'ai aussi vu qu'il utilise la SDL, et, de ce que je me souviens de la SDL 1.2, la logique utilisée est très proche de l'orienté objet: une sructure de données, et un jeu de fonctions pour manipuler cette structure.
Impossible d'utiliser les pointeurs, donc, pour n'afficher que telle ou telle zone d'une image, il faudrait donc utiliser des instances de SDL_Rect: composées de 4 entiers, c'est très lourd et nécessiteras des calculs à chaque fois que l'on voudra changer de zone de dessin. Si les calculs ne sont pas fait dans le code du jeu, ils le seront par la lib de toute façon…
Utiliser des fichiers séparés permet de faire un simple
intnbFiles;char*files[nbFiles];// impossible in C, IIRCSDL_Surfaceanimation[nbFiles];// but easy to implement// code to fill files with the list of file names for that animationfor(inti=0;i!=nbFiles;++i)animation[i]=SDL_LoadImage(fichier);
NB: je ne me rappelle plus les noms et paramètres précis de la SDL, pas utilisée depuis au moins 2 ans…
Et avec un moteur 2D moderne (utilisant en fait des quad OpenGL et des textures) une simple translation des coordonnées de textures suffit à changer de frame.
L'openGL, c'est un truc qu'il faut que j'apprenne à utiliser et à l'intégrer dans wxWidgets, c'est justement sur ma todo list pour autorealm…
Faut que je prenne le temps de chercher des bouts de code à lire et modifier… donc je ne peux pas parler de la simplicité de ce dont tu parles :)
D'ailleurs, si trouver des ressources pour openGL 2 et plus récent me prends trop de temps, vais finir par lâcher l'affaire et rester sur l'openGL 1 pour laquelle j'ai de la doc, et qui me poserais pas de souci si j'avais réussi a appliquer la tesselation correctement.
Ce dont je doute en revanche, c'est que ta simple translation soit plus beaucoup plus simple que l'approche objet à laquelle j'aurai tendance à penser pour un code 2D (qui consisterais à chaque affichage de l'animation à incrémenter un compteur interne avec un p'tit modulo pour éviter l'overflow, pour afficher l'image correspondante précédemment chargée dans un tableau dynamique. Pas plus de 40 lignes de code réel pour la classe entière, et une seule pour l'utiliser.)
[^] # Re: Tuxfamily
Posté par freem . En réponse au journal Un planet francophone pour Blender. Évalué à 1.
Sans compter le bête fait que la place occupée sera plus grosse parce que 4 blocs non utilisés complètement seront utilisés au lien d'un seul, en effet :)
Le terme de "gros" fichier n'avait pas pour but d'indiquer un gain de place, mais bien un problème d'organisation des ressources.
Ne serait-ce que pour la création d'une frame, il me semble plus simple de créer la 1ère, copier le fichier pour en créer un nouveau, le modifier en fonction de ce que l'on veut, et ce, autant de fois que nécessaire, plutôt que de modifier un seul fichier, au risque de déborder sur l'image d'a côté.
Sans parler d'ajouter une frame à une animation que l'on trouve trop grossière, sait-on jamais.
Arf mais quel boulet je fais… pourquoi je pensais à les concaténer à l'horizontale…
Là, j'ai envie de dire que ça dépends de la technique utilisée pour lire l'image.
Je viens de regarder, le code est en C, ce que j'ignorais (ça va raccourcir mon post du coup).
Effectivement, les pointeurs sont une solution.
Mais j'ai aussi vu qu'il utilise la SDL, et, de ce que je me souviens de la SDL 1.2, la logique utilisée est très proche de l'orienté objet: une sructure de données, et un jeu de fonctions pour manipuler cette structure.
Impossible d'utiliser les pointeurs, donc, pour n'afficher que telle ou telle zone d'une image, il faudrait donc utiliser des instances de SDL_Rect: composées de 4 entiers, c'est très lourd et nécessiteras des calculs à chaque fois que l'on voudra changer de zone de dessin. Si les calculs ne sont pas fait dans le code du jeu, ils le seront par la lib de toute façon…
Utiliser des fichiers séparés permet de faire un simple
NB: je ne me rappelle plus les noms et paramètres précis de la SDL, pas utilisée depuis au moins 2 ans…
L'openGL, c'est un truc qu'il faut que j'apprenne à utiliser et à l'intégrer dans wxWidgets, c'est justement sur ma todo list pour autorealm…
Faut que je prenne le temps de chercher des bouts de code à lire et modifier… donc je ne peux pas parler de la simplicité de ce dont tu parles :)
D'ailleurs, si trouver des ressources pour openGL 2 et plus récent me prends trop de temps, vais finir par lâcher l'affaire et rester sur l'openGL 1 pour laquelle j'ai de la doc, et qui me poserais pas de souci si j'avais réussi a appliquer la tesselation correctement.
Ce dont je doute en revanche, c'est que ta simple translation soit plus beaucoup plus simple que l'approche objet à laquelle j'aurai tendance à penser pour un code 2D (qui consisterais à chaque affichage de l'animation à incrémenter un compteur interne avec un p'tit modulo pour éviter l'overflow, pour afficher l'image correspondante précédemment chargée dans un tableau dynamique. Pas plus de 40 lignes de code réel pour la classe entière, et une seule pour l'utiliser.)