Conversion automatique des projets gint/fxSDK mono vers Prizm CG10/20/50/G90+E
Posté le 13/03/2023 11:05
Yo,
un petit développement cool est en cours, c'est à ce stade à l'état de PoC (Proof of Concept), mais sera bientôt intégré à
fxSDK et
gint, les deux briques étant nécessaires :
la conversion en (quasi-)automatique des projets fxSDK pour fx9860G/G35+EII vers l'architecture prizm (f-CG10/20/50/G90+E).
Vous pourrez ainsi jouer aux jeux développés sur mono sur votre graphique couleur (à la condition bien entendu qu'il soit développé avec gint/fxSDK et que vous disposiez des sources du projet).
Une image valant plus que 1000 mots, voici le projet
Builder de
Mb88 converti pour fonctionner sur Graph 90+E.
Le but de la manip consiste à créer une nouvelle cible de
build pour
fxSDK afin de compiler les sources prévues pour les graph mono vers une architecture de type graph couleur (prizm). Beaucoup de choses sont communes, mais il y a aussi des différences à gérer, en particulier l'écran et sa résolution. Il faut donc faire une conversion de la VRAM "mono" (128x64 pixels en 1bit) vers une VRAM "couleur" (396x224 pixels en 16bits RGB565). On laisse donc l'addin travailler avec une VRAM virtuelle comme sur la graph mono et lors d'un call à
dupdate(), on intercepte cet appel pour faire un traitement avant le blit final vers l'écran de la CG. On procède donc à une réécriture de
dupdate() pour faire un upscale x3, un centrage de l'écran, une conversion des couleurs puis on envoie le tout vers l'écran couleur.
A ce stade, le moteur de niveaux de gris n'est pas pris en compte, mais cela viendra, c'est là prochaine grosse étape.
Je vous joins une copie de Builder pour CG50 afin que vous puissiez tester par vous même. Je suis très agréablement surpris par la vitesse de fonctionnement, compte tenu de la non optimisation du code (j'en suis à l'étape, on fait comme un bourrin pour voir si c'est jouable ou pas). On va désormais optimiser, maintenant que la faisabilité est démontrée.
A terme, quand cela sera en production, un
fxsdk new project générera tout en automatique. Ensuite un projet pour FX pourra être automatiquement converti pour fonctionner sur CG via une build avec
fxsdk build-fx-as-cg. Cela aura pour effet de générer le g3a qui pourra tourner sur votre prizm, sans rien toucher à votre projet FX initial. Bien entendu, la version mono "de base), donc le g1a, sera toujours généré via un
fxsdk build-fx comme à l'accoutumée.
Il reste pas mal de choses à faire (ayant commencé le zinzin milieu de semaine dernière) :
- tester sur plus de projets
- supporter le moteur de niveau de gris de gint
- mettre un entourage de screen mono un peu plus joli, là on a le "bleu-vert" usuel du
dupdate() sans
dclear()
- tester, tester, tester, ...
- optimiser, optimiser, optimiser, ...
Attention tout de même, si votre addin FX tripote les syscalls ou autre joyeusetés de bas-niveau, il n'y a vraiment aucune garantie que la conversion soit possible. Le projet vise seulement à rediriger les calls aux primitives/méthodes de gint vers la bonne architecture matériel.
Suite soon ... stay tuned.
Fichier joint
Citer : Posté le 14/06/2023 13:01 | #
Ah non, j'ai confondu avec la 35eii. Ce qui m'intéresserait c'est de pouvoir compiler KhiCAS avec le SDK de gint, sur la 35 et sur la 90. Mais c'est loin d'être trivial, à commencer par la résolution d'écran de la 90.
Citer : Posté le 14/06/2023 13:08 | # |
Fichier joint
Donc prendre des sources écrites pour le fx-9860G SDK ou le Prizm SDK, et les compiler avec gint... en principe c'est possible, la difficulté principale résidant surtout côté Prizm dans la diversité des syscalls (qui n'ont pas tous un équivalent côté gint)
edit: photo a posteriori
Citer : Posté le 19/03/2024 10:31 | # |
Fichier joint
Je m'attaque à ce sujet. Perspective d'émulateur Graph mono pour Graph 90+E à part, je vais proposer cette fonctionnalité dans gint. A priori ce n'est pas un gros changement structurel et ce utile à avoir pour casser certains aspects monolithiques de gint.
edit: photo a posteriori
Citer : Posté le 19/03/2024 10:56 | #
Cool. La pause "ray-golade" est finie on dirait
Blagues mises à part, c'est je pense un sujet qui semble gagner en intérêt ces derniers temps, j'ai eu 2/3 fois la question de sa disponibilité ces 2 derniers mois. Je pense en effet que décloisonner les 2 machines sera un bon boost pour gint/fxSDK, pas mal de personnes ont seulement une G35, savoir que leurs projets peuvent être aussi rendus disponibles pour G90 sera un gros plus.
En plus, techniquement, ça se fait bien...
C'est une victoire facile (un vrai "low hanging fruit" comme on aime bien de temps en temps).
Citer : Posté le 23/03/2024 12:17 | # |
Fichier joint
Premiers résultats : après fusion de la partie fxSDK (presque inchangée) et réorganisation dans gint pour permettre de compiler pour Graph 90+E avec le système de rendu de la Graph mono, je peux lancer l'add-in de test.
Note : c'est une régression par rapport à ce que Slyvtt a codé parce que je vais l'implémenter un peu différemment.
La clé de l'affaire c'est que je vais me arrêter d'utiliser dans le code de gint et des outils les macrosFX9860G et FXCG50, qui ont toujours été très arbitraires, et à la place fournir dans gint des macros plus fines décrivant quels combinaisons de drivers et systèmes de rendu on utilise. Plus tard, je changerai également la relation entre les fonctions de rendu et les drivers pour améliorer la structure.
En réalité j'ai plus que la photo ci-dessus de l'application de base parce que gintctl compile également. Par contre gintctl utilise JustUI, qui continue d'utiliser les macros FX9860G et FXCG50, et là la bonne façon de designer la lib pour l'éviter est plus subtile que juste utiliser d'autres macros.
Citer : Posté le 24/03/2024 08:51 | # |
Fichier joint
Voilà, ça n'aura pas pris très longtemps. Voici la partie moteur de gris de gintctl qui tourne sur la Graph 90+E (notez que la partie ajustement des délais n'existe pas c'est que le rendu lui-même).
Finalement le plus long et de loin le plus insupportable a été de chasser toutes les parties spécifique-fx et spécifique-cg de gintctl pour les remplacer temporairement par d'autres macros un poil plus fines. Ça m'a fait réaliser à quel point il me manque de quoi faire des interfaces graphiques plus flexibles (gintctl utilise parfois JustUI mais c'est pas non plus le graal sur ce plan).
Le temps que je teste les jeux que SlyVTT avaient pour référence, je publie ça et je considère la question comme résolue (aux bugs près qui pourraient remonter bien sûr).
Citer : Posté le 24/03/2024 08:56 | #
Superbe !! Merci Lephé.
Et hop, 2 items de la liste qui saute en one shot
Bravo, ça va permettre d'étendre largement la bibliothèque de la G90
On pourra rajouter une cible au RGB_collab afin de voir ce que ça donne.
Citer : Posté le 24/03/2024 11:06 | #
Yup ! Builder et Arena ont marché tout de suite, donc j'ai publié ça sur le topic de gint.
Une bonne chose de faite !
Citer : Posté le 24/03/2024 11:31 | #
(notez que la partie ajustement des délais n'existe pas c'est que le rendu lui-même).
Une question demeure, est ce que tu a codé tout les graphismes ou tu as simplement pris une image? Si tu as pris une image, quel couleur de gris exact faut il prendre pour que quand j'affiche l'image, (avec le niveau de gris activé) ça me donne un niveau de gris?
Merci d'avance
Tuper
tâchez de faire un émulateur de g1a pour PRIZM maintenant
Citer : Posté le 24/03/2024 11:35 | #
L'image ci-dessus est générée à partir de plein de petites fonctions, texte, lignes, images, rectangles, etc. Note que même si ça tourne sur Graph 90+E les images et les couleurs sont en mode "4 couleurs" comme si on était sur mono.
Et donc pour les assets en mono, fxconv utilise #555555 comme gris foncé et #aaaaaa comme gris clair. Mais t'es pas obligé de mettre exactement ça, il arrondit au plus proche quand tu convertis.