#2 Codage du personnage principal

Open
opened 4 months ago by Milang · 7 comments
Milang commented 4 months ago

J’ai remarqué que les sprites du personnage principal sont en 8x12. En tant que programmeur, je pense qu c’est mon rôle de dire que ce format ne sera pas très pratique à exploiter dans le code.

Pour simplifier le code, et de l’autre coté les graphismes, je propose de mettre chaque sprite sur une image de format 16x16 (4 de marge sur les cotés) avec transparence.

De plus, je pense qu’il est possible de regrouper les sprites dans une seule image : Sur une ligne, tous les sprites d’un même etat. Sur une colonne, tous les sprites ayant la même direction.

Cela permettrait de rendre le code plus léger et plus flexible, et cela permettrait d’organiser plus simplement les images.

Qu’en pensez vous ?

J'ai remarqué que les sprites du personnage principal sont en 8x12. En tant que programmeur, je pense qu c'est mon rôle de dire que ce format ne sera pas très pratique à exploiter dans le code. Pour simplifier le code, et de l'autre coté les graphismes, je propose de mettre chaque sprite sur une image de format 16x16 (4 de marge sur les cotés) avec transparence. De plus, je pense qu'il est possible de regrouper les sprites dans une seule image : Sur une ligne, tous les sprites d'un même etat. Sur une colonne, tous les sprites ayant la même direction. Cela permettrait de rendre le code plus léger et plus flexible, et cela permettrait d'organiser plus simplement les images. Qu'en pensez vous ?
Lephenixnoir commented 4 months ago
Owner

Tout mettre sur une spritesheet, c’est clairement une bonne idée. C’est aussi plus pratique pour éditer.

Par contre je ne vois pas de raison de tout mettre en 16x16. Multiplier par 12 c’est pas difficile…

Par contre selon les actions (attaque, saut, whatever) les sprites ne feront peut-être pas tous 8x12. Prenez une marge.

Tout mettre sur une spritesheet, c'est clairement une bonne idée. C'est aussi plus pratique pour éditer. Par contre je ne vois pas de raison de tout mettre en 16x16. Multiplier par 12 c'est pas difficile... Par contre selon les actions (attaque, saut, whatever) les sprites ne feront peut-être pas tous 8x12. Prenez une marge.
Milang commented 4 months ago
Owner

J’ai une raison de tout mumtiplier par 16 : Les sprites ont une taille de 8x12, mais le côté où il y a les 4 pixels de plus varie. Donc si on souhaite afiicher le personnage qu’a un seul endroit (une seule instruction dans le code, pas de cas par cas), il faut lui mettre des marges partout où il est succeptible d’y avoir des pixels qui dépassent.

Si je propose cela, c’est pour éviter d’avoir une série d’images alternativement de 12x8, 8x12, 12x8 et 8x12 qui nécéssiteraient du cas par cas.

J'ai une raison de tout mumtiplier par 16 : Les sprites ont une taille de 8x12, mais le côté où il y a les 4 pixels de plus varie. Donc si on souhaite afiicher le personnage qu'a un seul endroit (une seule instruction dans le code, pas de cas par cas), il faut lui mettre des marges partout où il est succeptible d'y avoir des pixels qui dépassent. Si je propose cela, c'est pour éviter d'avoir une série d'images alternativement de 12x8, 8x12, 12x8 et 8x12 qui nécéssiteraient du cas par cas.
Shadow commented 4 months ago
Owner

Le perso en 8x12 est en fait la seule solution graphique respectant les autres tiles… le 8x8 rend mal (très très mal) et le 16x16 bien que beau est trop grand… >_<’

Après le fait que 4 pixels dépassent n’est pas gênant : tu affiche tout l’écran et en dernier tu place le personnage, en écrasant les pixels dessous lui, dans certains Links, ce procédé est utilisé et a deux avantages : il induit une légère perspective, et il rend bien !

Pour le tileset, on avait commencé avec les objets et les décors, ça ne devrait pas poser de problèmes pour les joueurs ^^

Le problème du changement de la taille… Ça c’est plus embêtant. Je pense que le spritesheet aura une marge avec les pixels transparent comme c’est déjà suggéré…

Le perso en 8x12 est en fait la seule solution graphique respectant les autres tiles… le 8x8 rend mal (très très mal) et le 16x16 bien que beau est trop grand… >_<' Après le fait que 4 pixels dépassent n'est pas gênant : tu affiche tout l'écran et en dernier tu place le personnage, en écrasant les pixels dessous lui, dans certains Links, ce procédé est utilisé et a deux avantages : il induit une légère perspective, et il rend bien ! Pour le tileset, on avait commencé avec les objets et les décors, ça ne devrait pas poser de problèmes pour les joueurs ^^ Le problème du changement de la taille… Ça c'est plus embêtant. Je pense que le spritesheet aura une marge avec les pixels transparent comme c'est déjà suggéré…
Lephenixnoir commented 4 months ago
Owner

Le perso en 8x12 est en fait la seule solution graphique respectant les autres tiles… le 8x8 rend mal (très très mal) et le 16x16 bien que beau est trop grand… >_<’

Milang ne parle pas de dessiner le personnage en 16x16 mais de rajouter du vide autour de l’image pour l’agrandir jusqu’à 16x16.

J’ai une raison de tout mumtiplier par 16 : Les sprites ont une taille de 8x12, mais le côté où il y a les 4 pixels de plus varie.

Legit. Sinon tu peux positionner à la main un “point central” du sprite. (Utile surtout si tu manques d’espace, plutôt sur Graph 90 en donc.)

> Le perso en 8x12 est en fait la seule solution graphique respectant les autres tiles… le 8x8 rend mal (très très mal) et le 16x16 bien que beau est trop grand… >_<’ Milang ne parle pas de dessiner le personnage en 16x16 mais de rajouter du vide autour de l'image pour l'agrandir jusqu'à 16x16. > J’ai une raison de tout mumtiplier par 16 : Les sprites ont une taille de 8x12, mais le côté où il y a les 4 pixels de plus varie. Legit. Sinon tu peux positionner à la main un "point central" du sprite. (Utile surtout si tu manques d'espace, plutôt sur Graph 90 en donc.)
KikooDX commented 2 months ago
Owner

Je pense que vous parlez de l’affichage du personnage lorqu’il attaque, une autre solution envisageable serait de créer deux objets pour les épées de dimensions différentes, appelons les sword_u, sword_d (8x4), sword_l et sword_r (4x8) pour l’exemple. Je suis conscient qu’il n’y a pas de notion d’objet en C mais c’est plus facile à expliquer comme cela. Lorsque le Héros attaque vers la gauche, l’objet sword_l devient visible, change de sprite pour correspondre à la direction du Héros aux coordonnées X_heros - 8, Y_heros - 4. Cet offset peut-être réglé avec un switch lors de l’attaque, de même pour le sprite utilisé. Je pense que dans le code tout ça pourrait être géré dans un bloc.

Ce n’est pas la meilleure solution, mais plus il y en a de proposées plus le choix est large ^^

Je pense que vous parlez de l'affichage du personnage lorqu'il attaque, une autre solution envisageable serait de créer deux objets pour les épées de dimensions différentes, appelons les sword_u, sword_d (8x4), sword_l et sword_r (4x8) pour l'exemple. *Je suis conscient qu'il n'y a pas de notion d'objet en C mais c'est plus facile à expliquer comme cela.* Lorsque le Héros attaque vers la gauche, l'objet sword_l devient visible, change de sprite pour correspondre à la direction du Héros aux coordonnées X_heros - 8, Y_heros - 4. Cet offset peut-être réglé avec un switch lors de l'attaque, de même pour le sprite utilisé. *Je pense que dans le code tout ça pourrait être géré dans un bloc.* Ce n'est pas la meilleure solution, mais plus il y en a de proposées plus le choix est large ^^
Lephenixnoir commented 2 months ago
Owner

Pas stupide. Mais si l’épée bouge par rapport à la position du personnage selon les frames d’animation, ça devient un peu casse-pieds à positionner non ?

Maintenant ça a l’avantage que ça séparer les éléments de la spritesheet.

Pas stupide. Mais si l'épée bouge par rapport à la position du personnage selon les frames d'animation, ça devient un peu casse-pieds à positionner non ? Maintenant ça a l'avantage que ça séparer les éléments de la spritesheet.
KikooDX commented 2 months ago
Owner

Je suppose que l’épée serait animée séparément à côté, ça revient au même. Au final, les objets qui s’ajoutent permettent juste “d’étendre” le sprite du joueur, ça évite d’avoir une marge énorme en permanence. C’est juste une idée jetée comme ça, la méthode sera sûrement choisi selon les besoins/contraintes.

Je suppose que l'épée serait animée séparément à côté, ça revient au même. Au final, les objets qui s'ajoutent permettent juste "d'étendre" le sprite du joueur, ça évite d'avoir une marge énorme en permanence. C'est juste une idée jetée comme ça, la méthode sera sûrement choisi selon les besoins/contraintes.
Sign in to join this conversation.
No Label
No Milestone
No Assignees
4 Participants
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
Cancel
Save
There is no content yet.