Posté le 06/05/2023 21:19
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 95 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
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 : G35+EII, G90+E (briquée
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 : G35+EII, G90+E (briquée
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
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 : G35+EII, G90+E (briquée
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 : G35+EII, G90+E (briquée
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).
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 : G35+EII, G90+E (briquée
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.
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 ?
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
Citer : Posté le 03/07/2023 20:20 | #
Bon, les Amigos, le temps passe vite, mais on a finalement pas trop avancé sur le sujet du projet collaboratif.
Nous voici donc aux portes des vacances d'été et son paradoxe habituel :
A ce stade la situation n'a pas changé par rapport au 23 Mai, voici les personnes intéressées avec les plus et les moins concernant les machines dispos et les langages maîtrisés :
Globalement il n'y a pas consensus global, ni au niveau des machines dispos, ni au niveau des langages maîtrisés.
Pour les machines, c'est équivalent entre les G90+E (ou fxCG50 et autres Prizm) et les monochromes, malheureusement il y aura forcément des déçus car aucune machine n'est disponible chez l'ensemble des potentiels participants.
Pour les langages, idem, Le C et le Python se démarquent, mais aucune unanimité n'apparaît. J'aurai tendance personnellement à partir sur le C qui offre un plus vaste champ des possibles, notamment grâce au support du clavier (le fameux problème du "Getkey" du Python officiel).
Si on part sur l'option C, je propose alors de partir sur la Graph Mono (G35,G75 ou G80 en SH3 et/ou SH4) comme architecture de base, ce qui permettra de faire une version de l'addin de sortie compatible Graph Couleur par la suite via le convertisseur auto. Lephe faisait aussi justement remarquer que faire un projet orienté Graph Mono serait cool car c'est une belle plateforme et lui rendre hommage serait sympa. (sans compter qu'il y a pas mal d'avantages à cette plateforme d'un point de vue performances graphiques).
Si OK pour vous, je proposerai une architecture de programme de base et on pourra regarder pour le séquencement des passages ainsi que leur durée en fonction des disponibilités de chacun.
Concernant le thème, il semble que le RPG sous un peu toutes ses formes possibles et imaginables, fasse consensus. On pourrait donc partir sur cette base.
Bien entendu cela n'est qu'une proposition pour remettre un peu d'énergie dans le système. Je vous laisse commenter.
A vous lire donc.
Citer : Posté le 03/07/2023 22:20 | #
Je me porte déja volontaire pour faire au moins une partie de la conversion, si je peux participer je vais pas attendre qu'il y ait une version traduite
Pour mes dispos ça se clarifie, déja je ne pars pas en vacances cet été, et j'aurais quelques heures (3-4) pour programmer par jour jusqu'a mi-juillet, après j'aurais en théorie toute la journée jusqu'a plus ou moins la rentrée mais je vais faire d'autres choses quand même. A noter que je fais d'autres trucs en parallèle.
Si le projet se continue dans l'année scolaire, je peux pas dire grand chose niveau dispo vu que :
1 - j'ai pas mon emploi du temps
2 - Je sais pas combien de temps les devoirs/révisions vont me laisser, et surtout si j'aurais encore l'énergie
3 - Je sais pas si il y a d'autres choses qui vont me prendre plus de temps
Ensuite je l'avais dit dans la shoutbox mais pas dans le framacalc, c'est que je peux plus emprunter une monochrome, étant donné que le gars a qui j'avais demandé à littéralement changé de pays (mais c'est une histoire pour la shout ça
Caltos : G35+EII, G90+E (briquée
Citer : Posté le 04/07/2023 11:06 | #
J'ai pas de graph mono. Le seul truc que j'ai c'est mon émulateur tout pourri. Aussi pourri que le cadavre d'un chat enterré dans du compost depuis 1 mois.
Citer : Posté le 04/07/2023 12:44 | #
Mais à priori tout ce qui manque pour faire tourner des jeux tout simples c'est le support du clavier, non ? Donc pour supporter les jeux SH4 il y a juste besoin des données de 0xA44B0000 à 0xA44B000A (?)
EDIT :
Ah oui et des syscalls
Citer : Posté le 04/07/2023 13:09 | #
le clavier est tout ce qu'il manque
Citer : Posté le 04/07/2023 19:04 | #
Si le projet part sur une Graph 35+E II je pourrai essayer de participer. Je rappelle que je ne maitrise pas très bien le C et que je ne serai donc surement pas d'une grande aide...
Sinon j'ai hate de voir ce que va donner ce projet !