Posté le 06/05/2023 21:19
Planète Casio v42 © créé par Neuronix et Muelsaco 2004 - 2023 | Il y a 77 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 23/05/2023 11:35 | #
Petit point de la situation à ce jour 11:30 :
Il n'y a pas vraiment de consensus:
- les machines sont à égalité (il n'y a pas une machine disponible pour tout le monde)
- pour les langages idem (C et Python) ont les faveurs, mais pas forcément un consensus clair non plus.
Une option pourrait être de faire MonoChrome en C et d'utiliser le PoC pour faire la version couleur : Conversion auto fxSDK Mono vers Couleur (PoC). Par contre ça va nécessiter un peu de taf de notre côté avec Lephé pour introduire ça dans fxSDK (2.11 ?)
Une autre option est Python avec suffisamment de transversalité (un peu comme les projets de rentrée) sur Couleur et Mono. Mais là ça va nécessiter du taf.
A vous lire
Le monde est dangereux à vivre ! Non pas tant à cause de ceux qui font le mal, mais à cause de ceux qui regardent et laissent faire.
-------------------------------------------------------------------
Albert Einstein
Mathématicien, Physicien, Scientifique (1879 - 1955)
Citer : Posté le 23/05/2023 14:06 | #
IL y pas juste un moyen de "folder" le code de rendu pour les monochromes et les graphiques ? Du style un fichier "rendu-fx" et "rendu-cg" et celui qui est inclut dépend de si on fait
Caltos : G90+E, FX-92+ (x2)
Citer : Posté le 23/05/2023 14:10 | #
Dans ton CMakeLists.txt tu peux changer les fichiers source et/ou les dossiers d'en-tête en fonction de la machine ciblée. Tu peux aussi utiliser les macros TARGET_FX9860G (mono) et TARGET_FXCG50 (prizm).
Citer : Posté le 23/05/2023 14:14 | #
Voila, j'avais bien vu ça et c'est ce que a quoi je pensais !
Et puis faut juste définir quelques commandes qui vont renvoyer a des commandes de gint, vu que c'est quand même très proche (mais pas assez pour que ça soit compatible
Caltos : G90+E, FX-92+ (x2)
Citer : Posté le 23/05/2023 14:21 | #
C'est dans l'absolu possible mais pas idéal car par exemple si tu prends un pixelart en 16x16 sur Mono, il sera juste énorme (1/4 de l'écran en hauteur) tandis qu'il sera globalement petit (1/14 de la hauteur) sur la G90.
Globalement ça veut dire double de boulot sur les assets.
C'est pour ça qu'on a commencé de faire le "convertisseur auto" qui rajoute une cible "build-fx-cg" (nom qui n'est pas définitif) pour que fxSDK :
- prenne les assets FX (en 2 couleurs ou en niveau de gris)
- fasse le rendu "offscreen"
- puis upscale ce rendu à la taille écran de la G90 (en gros avec un zoom x3)
- finalement affiche ce rendu upscalé sur l'écran de la G90
Ca évite de s'embêter puisque tout est automatique.
Autre avantage, tu peux avoir 3 versions "autonomes du même programme" :
- la version niveaux de gris / N&B native sur mono (le g1a)
- une version couleur native sur G90 (le g3a)
- un autre g3a qui correspond à la version mono convertie vers la G90
Le monde est dangereux à vivre ! Non pas tant à cause de ceux qui font le mal, mais à cause de ceux qui regardent et laissent faire.
-------------------------------------------------------------------
Albert Einstein
Mathématicien, Physicien, Scientifique (1879 - 1955)
Citer : Posté le 23/05/2023 14:24 | #
Tu définis un truc du genre
Edit : Et c'est mieux d'avoir un seul code qui compile vers plusieurs platformes, parceque quand t'essayes de maintenir plusieurs trucs séparés c'est pas facile
Caltos : G90+E, FX-92+ (x2)
Citer : Posté le 23/05/2023 14:26 | #
Perso il me semble plus pertinent de viser d'abord la mono (car les graphismes mono peuvent toujours être utilisés tel quels sur la Graph 90) et ensuite d'avoir quelqu'un qui s'occupe de faire la version Graph 90 à côté. De cette façon on ne prend pas de risque. Et puis niveau méta ce serait bien aussi de faire un truc sur mono pour une fois
Citer : Posté le 23/05/2023 14:30 | #
C'est possible aussi, c'est juste que pour moi ça serait mieux niveau artistique d'avoir des trucs en plus haute résolution écrasés, plutôt que d'agrandir après, ça permet de plus facilement garder l'art original bien qu'on perde du détail
Et sinon c'est une possibilité de faire un jeu G90 noir et blanc (ou niveau de gris)
Caltos : G90+E, FX-92+ (x2)
Citer : Posté le 23/05/2023 14:42 | #
Oui mais attention au double piège de la conversion Couleur "HD" --> Mono Low "Definition"
Au mieux sur la Mono on a 4 "couleurs" si on décide de rouler pour l'utilisation du moteur de gris (donc addin en C). Si on est en Python, c'est 2 couleurs, basta. Donc il y a un sérieux taf pour partir des assets couleurs, les descendre en résolution + les convertir en 2 ou 4 couleurs, tout en gardant un truc visuellement OK.
L'option partir de base sur un programme Mono me semble, tout comme Lephé, l'option la plus raisonnable. Considérant qu'on saura au pire sans rien toucher aux assets en faire une version qui tourne sur les machines couleurs (en Python ou en C).
Le monde est dangereux à vivre ! Non pas tant à cause de ceux qui font le mal, mais à cause de ceux qui regardent et laissent faire.
-------------------------------------------------------------------
Albert Einstein
Mathématicien, Physicien, Scientifique (1879 - 1955)
Citer : Posté le 23/05/2023 14:54 | #
Moi je partais du C, et puis si on fait un ratio "carré" comme de 32x32 à 16x16 il suffit de faire la moyenne de la couleur des 4 cases en une, après passage a la moulinette du monochrome. Et oui c'est vrai que ça serait moins de boulot de faire des tuiles pour mono et après de juste agrandir sans rajouter de détail, juste histoire que ça aille sur l'écran.
Edit : Et aussi en python/basic la deuxième serait la seule option vraiment réalisable
Caltos : G90+E, FX-92+ (x2)
Citer : Posté le 23/05/2023 17:39 | #
Pour le Python, bon je vend un peu mes projets aussi, mais Asci est assez solide, et ça me semble assez réalisable sinon franchement simple de segmenter les tâches puisqu'Asci gère ça depuis des fichiers différents (e.g. la carte d'un côté, le scénario de l'autre etc)
Après le gros défaut ça va être les graphismes quoi…
Citer : Posté le 24/05/2023 15:00 | #
C'est pas une mauvaise idée Shadow si on part pour du Python.
Ton moteur a une partie graphique séparable ? On pourrait faire garder la partie non graphique et reconnecter ça avec une partie graphique différente non ASCII.
Le monde est dangereux à vivre ! Non pas tant à cause de ceux qui font le mal, mais à cause de ceux qui regardent et laissent faire.
-------------------------------------------------------------------
Albert Einstein
Mathématicien, Physicien, Scientifique (1879 - 1955)
Citer : Posté le 24/05/2023 17:07 | #
Malheureusement non, du moins pas en l'état. Les maps sont des chaînes de caratères et comme les entrées sont tous récupérées via input, ça rend impossible la gestion de map non ASCII…
Après, KikooDX, avait trouvé un trick sympa qui était de mettre les noms des items plutôt que tenter de faire des ASCII-art dans Noon. Si ça peut donner des idées…
C'est un peu le problème du Python d'avoir une partie graphique sympa, mais peu exploitable du fait de l'absence de gestion du clavier… Après, il y a toujours PythonExtra de Lephé' qui palie un certain nombre de ces problèmes.
Citer : Posté le 24/05/2023 17:09 | #
D'ailleurs tu as tenté ASCI sur PythonExtra ?
Ca passe ou pas ?
Le monde est dangereux à vivre ! Non pas tant à cause de ceux qui font le mal, mais à cause de ceux qui regardent et laissent faire.
-------------------------------------------------------------------
Albert Einstein
Mathématicien, Physicien, Scientifique (1879 - 1955)
Citer : Posté le 24/05/2023 17:12 | #
Je n'ai pas eu la curiosité d'essayer, mais le moteur devient ridiculement complexe.
Après stricto sensu, Asci marche sur tous les Python possibles et imaginable vu qu'il ne demande rien, la seule chose qui peut changer c'est la taille de l'écran, et ça c'est très bien géré…
Ce qui est un peu bête avec Asci et PythonExtra, c'est que les touches ne sont pas gérés par exemple, ce genre de tricks que j'ai été amené à faire parce que beaucoup de contraintes, mais qui perdent leurs sens si on enlève la contrainte…
Donc en conclusion, oui Asci doit très bien tourner sous PythonExtra, mais je ne pense pas qu'il soit pertinent de l'utiliser parce qu'il va forcer à compliquer l'utilisation du jeu final pour rien