Citer : Posté le 24/10/2020 22:48 | #

---

Hé dis, hé dis, est-ce qu'il y aura la musique de Touhou aussi ?

---

Citer : Posté le 27/10/2020 00:35 | # | Fichier joint

---

Bon, j'ai un peu bossé sur les dialogues ce soir, du coup je vous présente une petite démo du rendu. Le code est dispo sur la branche dialogs du dépot.

Démo en fichier joint
Et bon anniv' Tituya

Au passage Lephe, t'aurais une idée pour rendre un peu plus propre la fonction display_text ? Là c'est un one-shot pour la démo, mais ça gère pas le soft wrap, et c'est un peu moche je trouve.
Et quelques commentaires sur la manière de faire, entre autre pour les events clavier

---

Citer : Posté le 27/10/2020 09:26 | #

---

C'est vraiment stylé cette démo rien que pour un dialogue, ça donne super envie !

Pour ce qui est du code, c'est sûr qu'on va pas t'apprendre à coder... voilà ce que je peux suggérer :

• Tu dois absolument traiter tous les événements entre chaque frame. e=pollevent() ne peut pas suffire parce que s'il y a plusieurs événements dans la file tu ne vas en sortir qu'un et laisser les autres s'accumuler. C'est d'autant plus important que tu as couplé un frame graphique avec un frame d'input, et donc il faut garder en tête le fait que cette boucle peut être lente si le rendu n'arrive pas à suivre. Et c'est également très important parce que tu utilises keydown() et si la file d'événements n'est pas vide ou quasi-vide keydown() ne reflète pas l'état instantané du clavier.

Pour faire ça proprement, il y a plusieurs options. La méthode bourrine consiste à utiliser clearevents() qui fait des pollevent() jusqu'à ce qu'il n'y ait plus rien. La bonne nouvelle c'est que tu es à jour donc tu peux utiliser keydown(), la mauvaise c'est que tu peux rien faire d'autre parce que tu viens de jeter tous les événements aux ordures (d'où le nom de la fonction).

La méthode moins bourrine consiste à lire et traiter les événements un par un. La méthode fine et lag-aware consiste à traiter un par un les événements tout en tenant utilisant la valeur de e.time pour prendre en compte le fait qu'ils ne sont pas simultanés (intéressant uniquement pour un vrai bon moteur de jeu temps réel, pas un moteur de dialogues, mais qui sait ça pourrait t'arriver *cough cough*).

• Dans le jeu final je suggère d'avoir un FPS cap sous la forme d'un timer dont tu attends l'interruption entre deux frames. C'est déjà un peu le cas parce que tu arrives sur chaque dupdate() avant que le frame précédent soit fini d'envoyer, mais c'est pas hyper sérieux de s'appuyer sur le bottleneck de l'écran. Ici c'est une simple question de pas trop pomper la batterie, surtout si tu overclockes dans le moteur principal ou que tu veux ajuster la vitesse des écrans.

• Nombre de caractères par microseconde : check. Excellente unité de mesure, rien à dire.

• Tu as correctement utilisé des float pour le positionnement du texte, mais de l'autre côté tu utilises un sinus/cosinus en double précision. Non que la fonction soit longue, mais l'approximation polynomiale a moins de coefficients dans cosf() donc autant en profiter. Oublions pas que tout est en soft-fp et ça c'est catastrophiquement lent dans les cas défavorables.

• Évite de créer des copies a priori inutiles d'images, non pas que tu manquerais de mémoire, mais parce que le tas de l'OS est assez fragile et il se détériore avec le temps. Mieux vaut limiter le nombre de malloc().

• Le traitement du texte est lent, ça se voit parce que tu passes de façon très consistente de 68 FPS quand il n'y a pas de texte à 64-62 FPS quand les plus longs messages sont visibles à l'écran. Pour faire ça proprement, dsize() n'est pas tout à fait appropriée puisque tu es obligé de passer un temps quadratique à évaluer des caractères. En réalité, tu pourrais juste faire dsize() sur chaque caractère individuellement et ajouter l'espacement entre chaque pour ton calcul, mais ce serait pas robuste ni future-proof : le jour où je rajoute du kerning ou des ligatures, ça sera vite invivable (et vraiment problématique) de reproduire la logique interne de topti dans ton évaluation de taille.

De ce point de vue-là, je pense qu'il serait propice d'avoir une fonction supplémentaire dans gint pour faciliter le job. Pour ce job en particulier je pense que la fonction inverse de dsize() serait appropriée : tu spécifies la taille et il te donne le nombre max de caractères qu'il peut afficher. Si on garantit que les ligatures sont plus larges que les caractères individuels, et avec une bonne option pour prévoir les tirets en cas de coupure à l'intérieur d'un mot je pense qu'on peut gérer la plupart des situations correctement.

---

Citer : Posté le 27/10/2020 13:55 | #

---

Merci Lephe pour les retours, je ferais une màj ce soir.

Kirafi, c'est plus ou moins du legacy. En fait déjà je compte générer les différents ennemis dans un module fxconv : c'est juste un changement de chroma pour la plupart. Et oui dans ce cas passer par un tileset. Ce qui est dans dans le dépôt, c'est juste la sortie de mon script de test.

Au passage, h'en profite pour signaler que le dsubimg est efficace si tous les sprites ont la même dimension. Par exemple je ne peux pas faire ça sur les witches puisqu'elles ne sont pas toutes identiques. En soit je pourrais, mais après pour faire un affichage dynamique en fonction de la taille ça rajoute des métadonnées qui sont déjà fournies si je sépare les fichiers (img.width, img.height, etc.)

---

Citer : Posté le 27/10/2020 14:08 | #

---

Problème qui sera résolu avec le module custom fxconv qui me générera des tableaux de pointeurs tout seul comme un grand.

---