nicooo a écrit 36 commentaires

Je viens de publier une détection basique pour les planches sur fond noir.
Ça marche pas mal pour Drugs & Wires ;)

C'est fait, testable sur le site de démo avec une case à cocher !

Et oui, Kumiko a été choisi à la fois pour la similitude phonétique avec "comic" prononcé à la japonaise, et avec "comic cutter" :)

Content que ça plaise !

Je n'ai pas encore rajouté d'option pour numéroter les cases de droite à gauche pour le sens de lecture japonais, mais c'est prévu.

Ce sera fait très prochainement, avec une case à cocher sur le site de démo :)

Hello, et merci pour tes encouragements !

Je pense m'atteler prochainement à la détection de la couleur de fond, ce qui est en effet nécessaire dans certains cas (même minoritaires).
J'imagine bêtement prendre, en plus du blanc, la couleur du pixel {0,0} et voir le nombre de cases détectées en la considérant comme couleur de fond (et leur organisation dans l'espace, leur taille etc. pour voir si ça a du sens).

Si tu as des exemples n'hésite pas à les poster, je pourrai m'en servir pour tester !

Oui, la lecture se fait pour l'exemple dans le navigateur, avec un simple zoom sur chaque page, sur les cases successives.
Je ne connais pas bien epub mais ça vaudrait le coup de se pencher là-dessus, voir s'il y a déjà des fonctionnalités rendant possible la lecture case par case.

Kumiko avance à son propre rythme, un peu lambin pour une ninja si tu veux mon avis. :)

Merci pour les exemples d'unsoundedcomics.

La découpe a été améliorée pour ignorer les petits éléments graphiques entre les cases, afin de pouvoir les dissocier. Mais comme noté dans pas mal d'autres commentaires, il faut aussi veiller à ne pas trop les ignorer, car ils ont parfois toute leur importance !
C'est toute la difficulté du truc.

Je t'invite à jeter un œil aux améliorations récentes sur cet aspect : voici les "diffs visuels" des dernières versions concernées : v1.1 et v1.2.1.

Pour ce qui est des cases qui se chevauchent comme dans tes exemples, je pense qu'il faudra recourir à une détection de lignes dans l'image, quand la détection de contours ne suffit pas.
Plein d'idées pour la suite :)

Yes, je pense qu'on va pas couper à cet outil d'édition ;)

Merci pour les louanges :p

Sur les idées point par point :

• nextcloud paraît en effet être une bonne base de stockage pour les BD. Je pense pas me lancer tout de suite là-dedans par contre, ça a l'air d'être du taf.
  Note que tu peux enregistrer les pages HTML produites par Kumiko, elles sont indépendantes du site de démo (+ deux fichiers js et un css qui devraient s'enregistrer avec la page). Et donc les visionner en local dans ton navigateur, voire les publier sur un site à toi. Mais tout le monde n'a pas un tel hébergement.

• Merci pour ces deux recos de lecteurs, je vais les contacter !

• Bonne idée aussi de définir un standard, ce serait canon d'ouvrir ton .cbz avec n'importe quel lecteur un peu (avancé) et d'avoir la lecture case par case intégrée !

Merci pour ton commentaire chaleureux, ravi que ça te plaise !

L'IHM est en effet très sommaire et devait juste servir à montrer les possibilités de la découpe de cases. Elle n'a pas forcément vocation à devenir un lecteur très abouti (on aura noté que le design n'est pas mon fort :p).

Je pense comme toi que Kumiko fera mieux son job si c'est un lecteur déjà bien fonctionnel qui intègre le résultat des découpes.
Tu aurais des noms de lecteurs de BD sympas à qui soumettre cette idée ?

C'est une fort bonne idée, merci !
Il faudrait alors avoir un mode d'affichage "case seule" pour éviter que le ratio de l'écran ne permette de voir un bout de case suivante, et donc de réponse :)

Bien d'accord !
On peut rêver, mais Kumiko ne saura probablement jamais tout faire parfaitement.

Cet outil de post-prod est dans la roadmap :)

Yes, j'ai vu des BD au format numérique qui incluaient du son également, quand on arrive sur une certaine case. Sky is the limit.

Kumiko a une taille max (relative) pour ce qu'elle peut exclure entre deux cases. Si l'inter-case est bien rempli, les deux cases autour sont considérées et affichées comme une seule, permettant de voir entre les deux aussi.

Génial ! En effet je vois pas de solution pour la case-trou ni pour le double sens de lecture :)

Merci pour tous ces exemples !

Ah oui chouette exemple. Effectivement ça va être compliqué :)

Merci pour l'exemple d'Imbattable, à tester !

Note que si deux cases sont reliées par un élément graphique d'une certaine taille (pas juste un filet entre deux bulles par exemple), les deux cases sont détectées comme une seule, ce qui permet de visualiser le tout correctement.

Je suis bien d'accord avec vous deux ! L'idéal reste de voir les pages une à une telles qu'elles ont été pensées et organisées. Et pour ma part, en version papier. :)
Les auteur.ices de BD ne manquent pas d'imagination pour leurs structures de pages, et on ne va pas leur en vouloir.

Pour ce qui est des marges, c'est effectivement un point d'amélioration. Pour le moment Kumiko a tendance à exclure tout ce qui n'est pas une case (lettrage en marge découpé en autant de lettres, ignorées car trop petites).

Hello,
Je ne savais pas ce qu'était l'ellipse en BD, donc j'ai jeté un œil.
Tu veux dire que parce qu'on ne lit qu'une case à la fois, on s'imagine moins bien ce qui passe entre les cases ?

Merci pour ton retour d'expérience !
Je vais tester à nouveau, c'est vrai que ce serait pratique de pouvoir juste donner un lien aux gens.
Pour la version en ligne, il faudra en effet que je voie si le fonctionnement actuel est compatible avec l'exécution dans le navigateur.

Hello,

J'ai essayé d'exporter le jeu en HTML5 aussi, mais quand j'ai vu la lenteur du résultat dans le navigateur, j'ai abandonné l'idée (temporairement ?)
J'ai supposé que le nombre de collisions à gérer par le jeu était un peu trop important.

Cependant je t'invite à tester : exporter en HTML5 depuis le menu de Godot, et voir ce que ça donne dans ton navigateur.
Tes retours sont les bienvenus !

Hello,

Godot a pas mal de fonctionnalités qui réduisent la quantité de code à écrire, et comme tu dis le code du jeu à proprement parler est dans le dossier scripts. Ça fait quand même un peu de lecture. :)

Pour les exécutables ils sont en effet créés par Godot et ensuite complètement indépendants. Je les exporte (=compile) depuis l'interface, en GUI. J'imagine qu'on peut le faire avec la ligne de commande de Godot, mais ça implique aussi d'installer ce dernier.
Une alternative reste de le compiler le jeu toi-même une fois, et ensuite de lancer ton binaire pour jouer (d'ailleurs je suis intéressé par une comparaison des fichiers qu'on obtient, voir si c'est rigoureusement le même ou pas !).

Pourquoi pas un flatpak en effet. Faudra juste tester l'accès au système de fichier, car depuis la toute dernière beta, j'enregistre le pseudo dans un fichier utilisateur (pour le mode en ligne, et ne pas devoir le retaper à chaque fois).

Tu veux bien me contacter pour en discuter ? Sur mastodon ou matrix, ou laisse-moi simplement un moyen de t'écrire dans la boîte à texte ici : https://shootingpactris.njean.me/#Contact

(Edit: Ah mais je me disais bien que je reconnaissais ZeMarmot !!)

Si tu aimes le challenge, le mode solo - clavier ou manette - où tu contrôles les deux personnages est fait pour toi !
Sinon, la coop locale et la coop en ligne rendent le jeu plus accessible. ;)

Je suis d'ailleurs dispo pour une partie en réseau ! (contact : https://shootingpactris.njean.me/#Contact )
(Pour l'instant c'est pas très fun d'attendre en espérant que quelqu'un d'autre se connecte…)

Entre un pied-de-nez (c'était plutôt de l'auto-dérision) et s'entendre dire que ce qu'on fait n'est pas cohérent ou que ce qu'on dit n'a aucun sens, je trouve qu'il y a un petit fossé. Mais chacun·e son point de vue.

Ça aurait été bien de les faire tester à d'autres personnes avant de trancher tout seul dans ton coin et de te dire qu'à ce stade ça valait le coup d'en rédiger une dépêche.

Le jeu est en version bêta et n'a aucune prétention, ni maintenant ni probablement dans le futur.
Oui, je l'ai développé tout seul dans mon coin. Peu de personnes y ont joué, et c'était le but de poster une dépêche. Certain·e·s m'ont fait des retours qui ont été discutés et pris en compte, ou pas.
Je n'ai pas tranché définitivement sur quoi que ce soit, et garde ton idée en tête.

Il a rejoint la pléiade de jeux libres ou indé que j'ai supprimé au bout de 5mn de jeu.

Tant pis.

Je ne parle pas de mouvement ou d'animation mais de positionnement donc parler de fluidité ici n'a aucun sens.

Le positionnement fait suite à un mouvement, et il précède le prochain mouvement. Ça me paraît donc avoir du sens.
Merci d'être un peu aimable dans ce que tu écris.
J'ai codé plusieurs versions du déplacement de Pacman, et celle-ci est celle qui me semble le plus ergonomique.

Niveau code il n'y a aucun intérêt à le laisser en suspend

C'est au niveau du jeu plus que du code qu'il faut évaluer l'intérêt.
S'arrêter entre deux cases permet de repartir exactement d'où tu t'es arrêté, donc sans saccade, si tu poursuis ton mouvement précédent.
C'est quand tu changes d'une direction horizontale à verticale, ou vice-versa, qu'il faut se recaler sur une ligne/colonne.

Tu as joué au jeu et ça t'a dérangé ?
Tu peux aussi me montrer un extrait de la vidéo où tu trouves que ça fait bizarre.

Je vois bien le côté flottant que tu évoques. Qu'on pourrait aussi qualifier de fluide. :D

Les fantômes ne me semblent pas concernés, car ils sont toujours en mouvement. Du coup ils ne s'arrêtent jamais entre deux cases.

Pour Pacman, quand il s'arrête, il peut être effectivement entre deux cases. Sache que quand tu changes de direction avec Pacman, il se "recale" sur la grille avant de bouger, afin d'éviter des blocages pas naturels contre des murs.
Mais je ne vois pas bien comment améliorer ça davantage. Il faudrait qu'il se recale dès qu'il s'arrête ?

Enfin pour le vaisseau, comme je disais, le contraindre à "suivre les murs" du labyrinthe implique de beaucoup modifier sa jouabilité. À réfléchir.