Paramètres par défaut fxconv #3

Closed
opened 3 years ago by KikooDX · 10 comments

Les paramètres de fichiers dans fxconv peuvent être redondants : lorsque tous les fichiers doivent être encodés dans un certain profil par fxconv par exemple, il faut écrire une ligne de configuration pour chacun d'entre eux. Je propose comme solution de créer un accès à la configuration par défaut de chaque type de la façon suivante : au lieu de

IMG.player.png = profile:p4
IMG.elevator.png = profile:p4
IMG.ground.png = profile:p4
IMG.jitem_popup.png = profile:p16
IMG.jitem.png = profile:p4
IMG.spike.png = profile:p4

on aurait

IMG.DEFAULT = profile:p4
IMG.jitem_popup.png = profile:p16

Le profil d'image par défaut deviendrai p4. jitem_pop.png serait lui traité avec le profil p16.

Il y aurait donc un élément DEFAULT sans extension pour chaque type de fichier (FONT.DEFAULT...).

Les paramètres de fichiers dans fxconv peuvent être redondants : lorsque tous les fichiers doivent être encodés dans un certain profil par fxconv par exemple, il faut écrire une ligne de configuration pour chacun d'entre eux. Je propose comme solution de créer un accès à la configuration par défaut de chaque type de la façon suivante : au lieu de ``` IMG.player.png = profile:p4 IMG.elevator.png = profile:p4 IMG.ground.png = profile:p4 IMG.jitem_popup.png = profile:p16 IMG.jitem.png = profile:p4 IMG.spike.png = profile:p4 ``` on aurait ``` IMG.DEFAULT = profile:p4 IMG.jitem_popup.png = profile:p16 ``` Le profil d'image par défaut deviendrai p4. `jitem_pop.png` serait lui traité avec le profil p16. Il y aurait donc un élément DEFAULT sans extension pour chaque type de fichier (FONT.DEFAULT...).

Ça m'a l'air très bien (et facile), merci. Pour éviter les collisions avec un fichier assets-{fx,cg}/img/DEFAULT, je propose de le nommer IMG_DEFAULT. Je peux mettre la ligne vide dans le fichier de projet par défaut, histoire qu'il n'y ait pas besoin de le taper (et donc de prendre le risque de se tromper).

Je me demande si ça vaut la peine de faire quelque chose de plus puissant (ie. par sous-dossier par exemple) ou si je laisse à ça la méthode "conversion personnalisée" de fxconv où on peut utiliser un script pour choisir les paramètres. Je pense laisser ça au script, mais je veux bien avoir ton avis. ^^

Ça m'a l'air très bien (et facile), merci. Pour éviter les collisions avec un fichier `assets-{fx,cg}/img/DEFAULT`, je propose de le nommer `IMG_DEFAULT`. Je peux mettre la ligne vide dans le fichier de projet par défaut, histoire qu'il n'y ait pas besoin de le taper (et donc de prendre le risque de se tromper). Je me demande si ça vaut la peine de faire quelque chose de plus puissant (ie. par sous-dossier par exemple) ou si je laisse à ça la méthode "conversion personnalisée" de fxconv où on peut utiliser un script pour choisir les paramètres. Je pense laisser ça au script, mais je veux bien avoir ton avis. ^^
Poster

Si je comprend bien, IMG_DEFAULT me semble très bien. Je suppose que ce sera la même chose pour tous les types, avec FONT_DEFAULT et autres. La syntaxe que j'imagine après ton message :

IMG_DEFAULT = profile:p4
IMG.jitem_popup.png = profile:p16

Un système par dossier serait intéressant en plus, par simplicité d'utilisation. Peut être faire un système utilisant * pour plus de flexibilité ?

IMG.repertoire/* = profile:p4
IMG.un_autre/* = profile:p16
IMG.*_16.png = profile:p16
Si je comprend bien, IMG_DEFAULT me semble très bien. Je suppose que ce sera la même chose pour tous les types, avec FONT_DEFAULT et autres. La syntaxe que j'imagine après ton message : ``` IMG_DEFAULT = profile:p4 IMG.jitem_popup.png = profile:p16 ``` Un système par dossier serait intéressant en plus, par simplicité d'utilisation. Peut être faire un système utilisant `*` pour plus de flexibilité ? ``` IMG.repertoire/* = profile:p4 IMG.un_autre/* = profile:p16 IMG.*_16.png = profile:p16 ```

Oui c'est bien la syntaxe à laquelle je pense.

Le problème pour le système à dossiers c'est que la syntaxe que tu proposes n'est pas possible. Le fichier de projet est un bout de Makefile. Et tu ne peux clairement pas faire ça avec un Makefile (il faut voir chaque ligne comme un assignement de variable, il n'y a aucun mécanisme caché derrière).

D'où un certain doute... :s

Oui c'est bien la syntaxe à laquelle je pense. Le problème pour le système à dossiers c'est que la syntaxe que tu proposes n'est pas possible. Le fichier de projet est un bout de Makefile. Et tu ne peux clairement pas faire ça avec un Makefile (il faut voir chaque ligne comme un assignement de variable, il n'y a aucun mécanisme caché derrière). D'où un certain doute... :s
Poster

Hum dommage. Serait-il possible de passer de diviser ce fichier de projets en plusieurs fichiers ? Ça rendrait le scripting côté utilisateur plus sûr (pas de risque de supprimer la conf principale par erreur), et ça répondrait en partie à la demande.

Sinon le faire fonctionner par dossier uniquement comme suggéré par toi-même plus haut serait puissant et ne changerait pas grand chose à la syntaxe étoilée en pratique.

Est-ce que fxconv serait capable de détecter lui-même le nombre de couleurs utilisées par l'image ? Si je comprend bien, utiliser une palette plus petite n'a que des avantages (mémoire et vitesse), ce serait donc entièrement automatisé, en échange d'un plus long temps de processus. Si c'est bien possible en faire une option en conséquence ?

Hum dommage. Serait-il possible de passer de diviser ce fichier de projets en plusieurs fichiers ? Ça rendrait le scripting côté utilisateur plus sûr (pas de risque de supprimer la conf principale par erreur), et ça répondrait en partie à la demande. Sinon le faire fonctionner par dossier uniquement comme suggéré par toi-même plus haut serait puissant et ne changerait pas grand chose à la syntaxe étoilée en pratique. Est-ce que fxconv serait capable de détecter lui-même le nombre de couleurs utilisées par l'image ? Si je comprend bien, utiliser une palette plus petite n'a que des avantages (mémoire et vitesse), ce serait donc entièrement automatisé, en échange d'un plus long temps de processus. Si c'est bien possible en faire une option en conséquence ?

Hum dommage. Serait-il possible de passer de diviser ce fichier de projets en plusieurs fichiers ? Ça rendrait le scripting côté utilisateur plus sûr (pas de risque de supprimer la conf principale par erreur) (...)

Je suis pas sûr qu'on soit sur la même longueur d'onde avec scripting utilisateur. fxconv est prévu pour permettre au développeur de définir ses propres formats et jeux de paramètres tout en profitant des fonctions déjà implémentées, typiquement l'export vers un fichier objet avec les bons noms de variables.

Le coeur de fxconv est un module Python, et l'exécutable fxconv ne fait que lire la ligne de commande puis appeler le module. La partie scripting utilisateur dont je parle, c'est quand les petits sous-dossiers img, fonts, etc. ce n'est plus assez puissant pour toi, et :

  • Tu modifies le Makefile pour ne plus compiler tes ressources avec ces règles primitives ;
  • Tu oublies les IMG. et les FONT. dans le project.cfg ;
  • Et tu utilises un script Python pour invoquer fxconv avec les bons paramètres.

Dans ce cas, tu peux faire des choses comme ça les mains dans les poches:

params = { "type": "image", "profile": "p4" }

if path.startswith("some_folder/"):
    params["profile"] = "p8"

fxconv.convert(path, params, {"model": "cg"})

Donc ultimement pour les projets compliqués c'est comme ça que ça doit se passer. Le système de base est vraiment là pour commencer rapidement, c'est pas fait pour être super puissant. D'où le besoin de choisir une limite où on dit "ok, plus compliqué que ça, faut scripter".


Serait-il possible de passer de diviser ce fichier de projets en plusieurs fichiers ? Ça rendrait le scripting côté utilisateur plus sûr (pas de risque de supprimer la conf principale par erreur)

Donc pour en revenir à ça, tu n'est pas supposé générer le fichier de projet automatiquement. On peut couper le fichier en morceaux, mais je vois pas d'usage vraiment légitime ; chaque cas qui me vient à l'esprit devrait vraiment passer sur du scripting.

Est-ce que fxconv serait capable de détecter lui-même le nombre de couleurs utilisées par l’image ? Si je comprend bien, utiliser une palette plus petite n’a que des avantages (mémoire et vitesse), ce serait donc entièrement automatisé, en échange d’un plus long temps de processus. Si c’est bien possible en faire une option en conséquence ?

C'est déjà le comportement par défaut si tu ne spécifies pas de profil.

Mais je réalise qu'une partie du code est encore en local sur mon autre PC, donc je te confirme ça ce soir quand je l'aurai poussé... (ce qui explique aussi pourquoi ton g3a ne changeait pas : il ne convertissait pas... x_x)

> Hum dommage. Serait-il possible de passer de diviser ce fichier de projets en plusieurs fichiers ? Ça rendrait le scripting côté utilisateur plus sûr (pas de risque de supprimer la conf principale par erreur) (...) Je suis pas sûr qu'on soit sur la même longueur d'onde avec *scripting utilisateur*. fxconv est prévu pour permettre au développeur de définir ses propres formats et jeux de paramètres tout en profitant des fonctions déjà implémentées, typiquement l'export vers un fichier objet avec les bons noms de variables. Le coeur de fxconv est un module Python, et l'exécutable fxconv ne fait que lire la ligne de commande puis appeler le module. La partie *scripting utilisateur* dont je parle, c'est quand les petits sous-dossiers `img`, `fonts`, etc. ce n'est plus assez puissant pour toi, et : * Tu modifies le Makefile pour ne plus compiler tes ressources avec ces règles primitives ; * Tu oublies les `IMG.` et les `FONT.` dans le `project.cfg` ; * Et tu utilises un script Python pour invoquer fxconv avec les bons paramètres. Dans ce cas, tu peux faire des choses comme ça les mains dans les poches: ```python params = { "type": "image", "profile": "p4" } if path.startswith("some_folder/"): params["profile"] = "p8" fxconv.convert(path, params, {"model": "cg"}) ``` Donc ultimement pour les projets compliqués c'est comme ça que ça doit se passer. Le système de base est vraiment là pour commencer rapidement, c'est pas fait pour être super puissant. D'où le besoin de choisir une limite où on dit "ok, plus compliqué que ça, faut scripter". --- > Serait-il possible de passer de diviser ce fichier de projets en plusieurs fichiers ? Ça rendrait le scripting côté utilisateur plus sûr (pas de risque de supprimer la conf principale par erreur) Donc pour en revenir à ça, tu n'est pas supposé générer le fichier de projet automatiquement. On peut couper le fichier en morceaux, mais je vois pas d'usage vraiment légitime ; chaque cas qui me vient à l'esprit devrait vraiment passer sur du scripting. > Est-ce que fxconv serait capable de détecter lui-même le nombre de couleurs utilisées par l’image ? Si je comprend bien, utiliser une palette plus petite n’a que des avantages (mémoire et vitesse), ce serait donc entièrement automatisé, en échange d’un plus long temps de processus. Si c’est bien possible en faire une option en conséquence ? C'est déjà le comportement par défaut si tu ne spécifies pas de profil. Mais je réalise qu'une partie du code est encore en local sur mon autre PC, donc je te confirme ça ce soir quand je l'aurai poussé... (ce qui explique aussi pourquoi ton g3a ne changeait pas : il ne convertissait pas... x_x)
Poster

OK, je ne savais pas que fxconv pouvait être utilisé de cette manière. Je suppose que ça suffit du coup, à part le défaut le reste peut-être scripté comme tu l'as dit. Je ne savais pas que c'était possible (je ne m'étais pas trop posé la question non plus).

AH MAIS. C'est peut-être de là d'où vient l'erreur que j'ai signalé sur PC 😧

OK, je ne savais pas que fxconv pouvait être utilisé de cette manière. Je suppose que ça suffit du coup, à part le défaut le reste peut-être scripté comme tu l'as dit. Je ne savais pas que c'était possible (je ne m'étais pas trop posé la question non plus). AH MAIS. C'est peut-être de là d'où vient l'erreur que j'ai signalé sur PC :anguished:

AH MAIS. C’est peut-être de là d’où vient l’erreur que j’ai signalé sur PC 😧

C'est ça. J'ai un peu oublié de pousser Vendredi dernier aussi ; c'est maintenant fait. Pulle sur master pour récupérer le code des profils p4 et p8 de fxconv.

> AH MAIS. C’est peut-être de là d’où vient l’erreur que j’ai signalé sur PC :anguished: C'est ça. J'ai un peu oublié de pousser Vendredi dernier aussi ; c'est maintenant fait. Pulle sur master pour récupérer le code des profils `p4` et `p8` de fxconv.

J'ai une idée un peu plus sérieuse pour permettre de gérer facilement les paramètres de fxconv sans sortir les scripts Python. Je peux faire ce que tu proposes avec les wildcards en implémentant un convertisseur dans fxsdk qui serait appelé automatiquement par le Makefile. Mais du coup les paramètres de fxconv seraient dans un autre fichier... ce qui est pas forcément plus mal.

Ça donnerait :

  • project.cfg reste à sa place et n'a plus les paramètres de fxconv
  • assets-{fx,cg}/fxconv.cfg contiennent les paramètres
  • build-{fx,cg}/fxconv.cfg contiendront une version lisible par Makefile

Le dernier serait généré à partir du second à la volée, ce qui permet totalement de rajouter des wildcards et des trucs pétés. Par contre il sera régénéré à chaque fois que quelque chose change dans le dossier d'assets.

Pour la syntaxe, le plus simple est de partir par dossiers :

img = type:bopti_image
img/maps = profile:p4
img/bgs = profile:p8
img/bgs/intro.png = profile:r5g6b5

La version avec wildcards peut marcher aussi, le truc un peu chiant c'est qu'il faut donner une priorité aux directives en cas de conflit, et c'est plus simple avec les dossiers (il suffit de prendre la longueur). Comme on peut donner des ordres au cas par cas, je pense implémenter ça. Le plus important est que ce soit déployé et pas dans deux mois 😄

J'ai une idée un peu plus sérieuse pour permettre de gérer facilement les paramètres de fxconv sans sortir les scripts Python. Je peux faire ce que tu proposes avec les wildcards en implémentant un convertisseur dans `fxsdk` qui serait appelé automatiquement par le Makefile. Mais du coup les paramètres de fxconv seraient dans un autre fichier... ce qui est pas forcément plus mal. Ça donnerait : * `project.cfg` reste à sa place et n'a plus les paramètres de fxconv * `assets-{fx,cg}/fxconv.cfg` contiennent les paramètres * `build-{fx,cg}/fxconv.cfg` contiendront une version lisible par Makefile Le dernier serait généré à partir du second à la volée, ce qui permet totalement de rajouter des wildcards et des trucs pétés. Par contre il sera régénéré à chaque fois que quelque chose change dans le dossier d'assets. Pour la syntaxe, le plus simple est de partir par dossiers : ``` img = type:bopti_image img/maps = profile:p4 img/bgs = profile:p8 img/bgs/intro.png = profile:r5g6b5 ``` La version avec wildcards peut marcher aussi, le truc un peu chiant c'est qu'il faut donner une priorité aux directives en cas de conflit, et c'est plus simple avec les dossiers (il suffit de prendre la longueur). Comme on peut donner des ordres au cas par cas, je pense implémenter ça. Le plus important est que ce soit déployé et pas dans deux mois :smile:

Ça devrait être bon avec le fxSDK 2.3, plus spécifiquement ce changement sur le format des paramètres de fxconv (42f2b5c175).

Ce nouveau format couvre ce qui a été suggéré, à part le fait qu'il opère dans un seul dossier à la fois. Pour reprendre les exemples :

IMG.DEFAULT = profile:p4
IMG.jitem_popup.png = profile:p16

Le cas des paramètres par défaut se spécifie aisément avec * (p16 n'est pas un profil par contre) :

*:
  type: bopti-image
  profile: p4

jitem_popup.png:
  profile: p16

Un système par dossier serait intéressant en plus, par simplicité d'utilisation. Peut être faire un système utilisant * pour plus de flexibilité ?

IMG.repertoire/* = profile:p4
IMG.un_autre/* = profile:p16
IMG.*_16.png = profile:p16

Pour ça il faut créer un fxconv-metadata.txt dans chaque répertoire. Le nouveau système retire la nécessité de grouper par type, donc le programmeur est libre d'organiser les assets dans une hiérarchie qui correspond vaguement aux paramètres utilisés si besoin.

Si c'est vraiment de l'optimisation très fine sur chaque image où la palette est toujours choisie de façon minimale, la bonne solution est d'ajouter un profile: auto à fxconv pour choisir la bonne. Je pense que ce serait intéressant.

Le plus important est que ce soit déployé et pas dans deux mois 😄

Better luck next time je suppose...

Ça devrait être bon avec le [fxSDK 2.3](https://www.planet-casio.com/Fr/forums/topic13164-27-fxsdk-un-sdk-alternatif-pour-ecrire-des-add-ins.html#180997), plus spécifiquement [ce changement sur le format des paramètres de fxconv](https://www.planet-casio.com/Fr/forums/topic13164-27-fxsdk-un-sdk-alternatif-pour-ecrire-des-add-ins.html#180989) (https://gitea.planet-casio.com/Lephenixnoir/fxsdk/commit/42f2b5c175d7b7aa098fba000051227d81038634). Ce nouveau format couvre ce qui a été suggéré, à part le fait qu'il opère dans un seul dossier à la fois. Pour reprendre les exemples : > ``` > IMG.DEFAULT = profile:p4 > IMG.jitem_popup.png = profile:p16 > ``` Le cas des paramètres par défaut se spécifie aisément avec `*` (`p16` n'est pas un profil par contre) : ``` *: type: bopti-image profile: p4 jitem_popup.png: profile: p16 ``` > Un système par dossier serait intéressant en plus, par simplicité d'utilisation. Peut être faire un système utilisant * pour plus de flexibilité ? > > ``` > IMG.repertoire/* = profile:p4 > IMG.un_autre/* = profile:p16 > IMG.*_16.png = profile:p16 > ``` Pour ça il faut créer un `fxconv-metadata.txt` dans chaque répertoire. Le nouveau système retire la nécessité de grouper par type, donc le programmeur est libre d'organiser les assets dans une hiérarchie qui correspond vaguement aux paramètres utilisés si besoin. Si c'est vraiment de l'optimisation très fine sur chaque image où la palette est toujours choisie de façon minimale, la bonne solution est d'ajouter un `profile: auto` à fxconv pour choisir la bonne. Je pense que ce serait intéressant. > Le plus important est que ce soit déployé et pas dans deux mois 😄 Better luck next time je suppose...

Je ferme avec cette modification, s'il reste des problèmes ou d'autres demandes je pense qu'il serait plus pertinent d'ouvrir un autre ticket. Merci pour la suggestion 😃

Je ferme avec cette modification, s'il reste des problèmes ou d'autres demandes je pense qu'il serait plus pertinent d'ouvrir un autre ticket. Merci pour la suggestion :smiley:
Lephenixnoir closed this issue 2 years ago
Sign in to join this conversation.
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Lephenixnoir/fxsdk#3
Loading…
There is no content yet.