Voilà, j'ai trouvé le code qui me permet, très simplement, de rendre l'ombre plus sombre ou même d'en changer la teinte.
Pour cette première scène, ça donne :
Je ferai un test plus tard pour le contour au crayon.
Moi je me demandais surtout pourquoi Mizu est en pyjamas sur cette image XD Elle change de vêtements tout au long de l'aventure ?
Comme il faudrait redessiner le personnage et toutes ses animations à chaque fois qu'elle change de vêtement, cela n'arrivera qu'une fois dans le jeu.
mieux qu'un astronaute en combinaison noire, qu'il pleuve, qu'il vente ou qu'il neige...
Mais ce sont des pluies d'ammoniaque. Il est très fortement déconseillé d'ôter sa combinaison dans ces circonstances, non ?
Et puis, franchement, un astronaute en pyjama, ça fait pas sérieux !
Au passage, cela me plaît bien comment vous vous êtes déjà approprié le personnage de Mizuka. Vous en parlez comme si c'est un personnage réel. Sympa!
On l'aime beaucoup, notre petite Mizuka ! C'est un personnage auquel nous sommes attachés et qui est très amusant à mettre en scène.
Autre chose qui m'a frappé car je ne connais pas WintermuteEngine. Est-ce vraiment codé avec un langage de programmation? Pas de pseudo code ou grille d'événements?
Je ne pourrais pas te répondre : je n'y connais rien en langage de programmation.
Pour déclencher des actions, j'écris des scripts comme ceux rapportés dans les pages précédentes de cette conversation. Je crois que c'est un langage assez spécifique à Wintermute (il est adapté aux actions requises dans un point & click).
C'est superbe. Je crois que c'est la première fois que je vois un screenshot en taille réelle, et on sent vraiment la texture du papier, j'aime beaucoup. Je ne sais pas pourquoi je n'avais jamais remarqué avant. Là c'est très flagrant. Et quand je disais "superbe", ça inclut le résultat avec l'ombre. Bravo Olivier !
Je ferai un test plus tard pour le contour au crayon
Je suis persuadé que ça sera un +
Comme il faudrait redessiner le personnage et toutes ses animations à chaque fois qu'elle change de vêtement, cela n'arrivera qu'une fois dans le jeu.
C'est déjà bien. Il y a beaucoup de point & click où le héros reste le même pendant toute l'aventure. Là au moins, ça apportera de la vie, un marqueur temporel, une évolution de Mizyuka (Level up ! lol ok j'arrête).
Mais ce sont des pluies d'ammoniaque.
haha! Bien vu ! Je me demande si les autres lecteurs savent de quoi on parle
Le langage semble être extrêmement passe partout avec une syntaxe très C++, javascript, PHP... Si vous avez déjà fait le moindre langage, c'est presque de la logique algorithmique de base avec de l'objet ( objet.value = truc; objet.launch() ... ). Donc oui ça semble très accessible.
Pour ton morceau de code, j'avoue que l'algo me choque un peu. Faire une boucle infinie pour replacer l'ombre, ce n'est pas hyper gourmand pour rien ? Même avec un sleep de 10ms à chaque fois. C'est pas plus simple de faire en sorte que l'ombre soit placée en début d'arrivée aux pieds du personnage et que le joueur en plus de déplacer Mizuka, déplace également l'ombre en réalité dans la même série d'instruction que les déplacements de Mizuka ? Ca éviterait de constamment replacer l'ombre, même si immobile.
J'imagine que la boucle est de toute façon dans un bloc d'instruction en rapport avec un mouvement non ?
Merci pour ton retour sur le script.
C'est rare d'en avoir et c'est d'autant plus précieux que c'est le domaine que nous maîtrisons le moins.
Donc une boucle, c'est trop lourd pour ce genre d'opération...
En y réfléchissant, je pense avoir trouvé une idée pour déplacer l'ombre seulement quand on change de frame dans l'animation de marche.
Je fais un test aujourd'hui et je poste le code pour voir si c'est mieux.
Ca ne me choque pas plus que ça de voir une boucle s'effectuant toutes les 10ms dans un jeu vidéo. Dans Unity, par exemple, la fonction Update() des scripts s'effectue 60 fois par seconde, ce qui revient à l'effectuer toutes les 16ms. C'est à peu près le même principe avec le C# et XNA. Après, le tout, c'est de ne pas faire des opérations trop lourdes en mémoire lorsque l'on est dans ce type de fonctions.
Ca ne me choque pas plus que ça de voir une boucle s'effectuant toutes les 10ms dans un jeu vidéo.
C'est pas une histoire d'être "choqué" je pense ;).
Mais si une boucle n'a pas lieu d'être (ou du moins peut être évitée), il n'y a aucune raison qu'elle existe.
Tu me diras "osef! avec nos Intel sur-cadencés, c'est pas un problème ce genre de boucle, il y a de la ressource CPU à revendre!". Certes. Mais déjà, si tu utilises ce genre de raisonnement, si pour chaque fonction l'absence d'optimisation aura un retentissement négligeable, la somme de ces instructions superflues peut finir par grever la fluidité d'exécution d'un programme. C'est d'ailleurs typique avec les "progiciels", souvent codés avec les pieds par des types nuls (les types qui savent coder on généralement autre chose à faire que bosser sur ce genre de soft), qui sont d'une lenteur exécrable pour des tâches bidons qui auraient déjà parues triviales à l'époque des i486...
MAIS surtout, même dans un programme vraiment simple, s'efforcer à coder "proprement" et en cherchant l'optimisation n'est pas juste "pour faire joli". C'est apprendre à coder efficacement, c'est comme ça que peu à peu on enrichit ses compétences de tout un tas d'astuces algorithmiques, et que l'on acquiert la possibilité de coder beaucoup plus facilement des choses qui auparavant t'aurais parues franchement complexes. Bref, c'est comme ça que l'on apprend à coder. c'est à mon avis juste indispensable si l'on veut progresser.
Tu me diras "osef! avec nos Intel sur-cadencés, c'est pas un problème ce genre de boucle, il y a de la ressource CPU à revendre!".
Etant étudiant en Informatique industrielle, je ne dirai jamais "osef" pour ce genre de choses. J'ai eu l'occasion de toucher un peu à tout ce qui est robotique et systèmes embarqués. Et dans ces domaines, tu dois faire attention à tout, que ce soit au niveau de l'espace mémoire ou des algorithmes que tu utilises. Pour réduire les coûts dans ces domaines, il est important de travailler avec un microprocesseur le plus adapté possible, donc d'une puissance suffisante mais pas excessive pour limiter les dépenses. Enfin bref, là je m'éloigne très fort du sujet d'origine.
Sinon, je suis tout à fait d'accord avec toi en ce qui concerne l'optimisation et le fait de s'efforcer à coder proprement. Je pense avoir mal lu Seldell et je pensais que le fait qu'il soit choqué venait surtout du fait d'utiliser une boucle infinie que l'on effectue chaque 10ms.
Bref, c'est difficile de dire ici si l'algorithme est approprié ou non sans avoir une vue globale de tous les scripts qui tournent à côté. En plus, je ne connais pas du tout Wintermute et son fonctionnement.
Le problème de la boucle, c'est qu'elle implique des draw calls (rendu d'affichage) avec les SetSprite donc ce n'est pas du tout optimal.
Suivant comment est géré le rendu et l'affichage dans Wintermute, on peut se retrouver avec un Sprite qui clignote donc autant éviter.
Bah, c'était sympa quand même Mass Effect...
Voilà, j'ai trouvé le code qui me permet, très simplement, de rendre l'ombre plus sombre ou même d'en changer la teinte.
Pour cette première scène, ça donne :
Je ferai un test plus tard pour le contour au crayon.
Comme il faudrait redessiner le personnage et toutes ses animations à chaque fois qu'elle change de vêtement, cela n'arrivera qu'une fois dans le jeu.
Mais ce sont des pluies d'ammoniaque. Il est très fortement déconseillé d'ôter sa combinaison dans ces circonstances, non ?
Et puis, franchement, un astronaute en pyjama, ça fait pas sérieux !
On l'aime beaucoup, notre petite Mizuka ! C'est un personnage auquel nous sommes attachés et qui est très amusant à mettre en scène.
Je ne pourrais pas te répondre : je n'y connais rien en langage de programmation.
Pour déclencher des actions, j'écris des scripts comme ceux rapportés dans les pages précédentes de cette conversation. Je crois que c'est un langage assez spécifique à Wintermute (il est adapté aux actions requises dans un point & click).
C'est superbe. Je crois que c'est la première fois que je vois un screenshot en taille réelle, et on sent vraiment la texture du papier, j'aime beaucoup. Je ne sais pas pourquoi je n'avais jamais remarqué avant. Là c'est très flagrant. Et quand je disais "superbe", ça inclut le résultat avec l'ombre. Bravo Olivier !
Je suis persuadé que ça sera un +
C'est déjà bien. Il y a beaucoup de point & click où le héros reste le même pendant toute l'aventure. Là au moins, ça apportera de la vie, un marqueur temporel, une évolution de Mizyuka (Level up ! lol ok j'arrête).
haha! Bien vu ! Je me demande si les autres lecteurs savent de quoi on parle
http://www.theicehouse.fr
Le langage semble être extrêmement passe partout avec une syntaxe très C++, javascript, PHP... Si vous avez déjà fait le moindre langage, c'est presque de la logique algorithmique de base avec de l'objet ( objet.value = truc; objet.launch() ... ). Donc oui ça semble très accessible.
Pour ton morceau de code, j'avoue que l'algo me choque un peu. Faire une boucle infinie pour replacer l'ombre, ce n'est pas hyper gourmand pour rien ? Même avec un sleep de 10ms à chaque fois. C'est pas plus simple de faire en sorte que l'ombre soit placée en début d'arrivée aux pieds du personnage et que le joueur en plus de déplacer Mizuka, déplace également l'ombre en réalité dans la même série d'instruction que les déplacements de Mizuka ? Ca éviterait de constamment replacer l'ombre, même si immobile.
J'imagine que la boucle est de toute façon dans un bloc d'instruction en rapport avec un mouvement non ?
Trop de stress pour un si petit renard.
Merci pour ton retour sur le script.
C'est rare d'en avoir et c'est d'autant plus précieux que c'est le domaine que nous maîtrisons le moins.
Donc une boucle, c'est trop lourd pour ce genre d'opération...
En y réfléchissant, je pense avoir trouvé une idée pour déplacer l'ombre seulement quand on change de frame dans l'animation de marche.
Je fais un test aujourd'hui et je poste le code pour voir si c'est mieux.
Ca ne me choque pas plus que ça de voir une boucle s'effectuant toutes les 10ms dans un jeu vidéo. Dans Unity, par exemple, la fonction Update() des scripts s'effectue 60 fois par seconde, ce qui revient à l'effectuer toutes les 16ms. C'est à peu près le même principe avec le C# et XNA. Après, le tout, c'est de ne pas faire des opérations trop lourdes en mémoire lorsque l'on est dans ce type de fonctions.
Très beau projet ! Bonne chance !
Allez voir la chaîne de LGX (https://www.youtube.com/user/lgxabandonware) il fait des super test d'abandonware (c'pas banal
)
C'est pas une histoire d'être "choqué" je pense ;).
Mais si une boucle n'a pas lieu d'être (ou du moins peut être évitée), il n'y a aucune raison qu'elle existe.
Tu me diras "osef! avec nos Intel sur-cadencés, c'est pas un problème ce genre de boucle, il y a de la ressource CPU à revendre!". Certes. Mais déjà, si tu utilises ce genre de raisonnement, si pour chaque fonction l'absence d'optimisation aura un retentissement négligeable, la somme de ces instructions superflues peut finir par grever la fluidité d'exécution d'un programme. C'est d'ailleurs typique avec les "progiciels", souvent codés avec les pieds par des types nuls (les types qui savent coder on généralement autre chose à faire que bosser sur ce genre de soft), qui sont d'une lenteur exécrable pour des tâches bidons qui auraient déjà parues triviales à l'époque des i486...
MAIS surtout, même dans un programme vraiment simple, s'efforcer à coder "proprement" et en cherchant l'optimisation n'est pas juste "pour faire joli". C'est apprendre à coder efficacement, c'est comme ça que peu à peu on enrichit ses compétences de tout un tas d'astuces algorithmiques, et que l'on acquiert la possibilité de coder beaucoup plus facilement des choses qui auparavant t'aurais parues franchement complexes. Bref, c'est comme ça que l'on apprend à coder. c'est à mon avis juste indispensable si l'on veut progresser.
Etant étudiant en Informatique industrielle, je ne dirai jamais "osef" pour ce genre de choses. J'ai eu l'occasion de toucher un peu à tout ce qui est robotique et systèmes embarqués. Et dans ces domaines, tu dois faire attention à tout, que ce soit au niveau de l'espace mémoire ou des algorithmes que tu utilises. Pour réduire les coûts dans ces domaines, il est important de travailler avec un microprocesseur le plus adapté possible, donc d'une puissance suffisante mais pas excessive pour limiter les dépenses. Enfin bref, là je m'éloigne très fort du sujet d'origine.
Sinon, je suis tout à fait d'accord avec toi en ce qui concerne l'optimisation et le fait de s'efforcer à coder proprement. Je pense avoir mal lu Seldell et je pensais que le fait qu'il soit choqué venait surtout du fait d'utiliser une boucle infinie que l'on effectue chaque 10ms.
Bref, c'est difficile de dire ici si l'algorithme est approprié ou non sans avoir une vue globale de tous les scripts qui tournent à côté. En plus, je ne connais pas du tout Wintermute et son fonctionnement.
Le problème de la boucle, c'est qu'elle implique des draw calls (rendu d'affichage) avec les SetSprite donc ce n'est pas du tout optimal.
Suivant comment est géré le rendu et l'affichage dans Wintermute, on peut se retrouver avec un Sprite qui clignote donc autant éviter.
Conceptgame
Pages