Particule SDK
Posté le 10/07/2025 15:13
Ce topic est dédié au développement
Hello les gens !
Je prends un moment pour vous partager une grosse mise à jour sur ParticuleEngine, et surtout sur tout l'écosystème autour. Si vous suivez un peu le projet, vous savez que c'était jusque-là un moteur modulaire inspiré d’Unity, avec ses GameObjects, ses Components, sa logique multiplateforme…
Mais là, on passe à la vitesse supérieure : le SDK (version beta) est dispo, avec un installateur propre, une doc, des outils, et un vrai système de build.
C’est quoi le "SDK Particule" maintenant ?
C’est devenu plus qu’un simple moteur : c’est un ensemble d’outils pour créer des jeux et applis multiplateformes, avec une architecture claire, des conventions solides, et une compilation qui s’adapte à chaque cible automatiquement.
Le SDK est divisé en plusieurs modules :
ParticuleCore : la couche bas niveau qui gère le rendu, l’audio, les entrées… selon la distribution (Windows, Linux, Casio, etc.)
ParticuleEngine : le moteur de jeu haut niveau avec les GameObjects, les Composants, les Scènes, etc.
ParticuleCraft : le système de build qui fusionne les configs de chaque distribution pour générer des Makefiles adaptés.
ParticuleTools : les outils de dev intégrés (éditeur de sprites, éditeur de Makefile JSON, installateur graphique, etc.)
Et du coup, qu’est-ce qu’on peut faire avec ?
- Installer le SDK facilement avec un installateur graphique
- Utiliser ParticuleCraft en ligne de commande ou en version GUI pour créer et gérer vos projets
- Importer vos sprites depuis un petit éditeur maison
- Compiler pour différentes plateformes sans changer votre code (grâce à la séparation Core/Engine)
- Consulter une documentation intégrée en local
C’est stable ? C’est utilisable ?
Oui et non.
On peut déjà construire des applications complètes, comparables à ce qu'on ferait avec Gint, et ça fonctionne sur toutes les distributions supportées. Le cœur (ParticuleCore) est quasi terminé, il reste juste quelques petites choses à peaufiner, mais rien de bloquant.
En revanche, ParticuleEngine (la partie haut niveau avec les GameObjects/Composants/etc.) est encore en chantier. Il est prévu, les bases sont posées, mais il n’est pas encore exploitable.
Cela dit, je tenais à publier le SDK, pour ceux qui veulent déjà l’essayer ou contribuer !
Je rappelle qu'il existe un serveur Discord dédié à Particule (notamment une partie bêta-testeur) :
https://discord.gg/pQgRuEtdRA
Comment commencer ?
Tout est expliqué dans le fichier README.md du dépôt, mais en gros :
Cloner le repo :
https://github.com/leofarhi/ParticuleSDK
Lancer Setup.py (il installe tout automatiquement)
Créer un projet avec ParticuleCraft create
Lancer un build, ou utiliser l’interface graphique si vous préférez
Si vous avez des questions, bugs, suggestions ou juste envie de tester, n’hésitez pas
Citer : Posté le 10/07/2025 15:15 | #
Ça bien sûr, ma question était plutôt dans l'autre sens : est-ce que tu utilises uniquement des fonctions de gint qui existent déjà ou est-ce que tu fais du dessin compliqué direct dans la VRAM ?
Pour répondre à ton message, Lephenixnoir : oui, je fais pas mal de dessins complexes directement dans la VRAM, pour des raisons d’optimisation.
Refactoriser le code me prend plus de temps que prévu. J’ai déjà fait les trois quarts hier et avant-hier, mais je ne serai pas du tout disponible dans les prochains jours, donc ça repousse un peu la suite. Je vais voir si j’arrive à finir ce soir.
Albert Einstein
Citer : Posté le 10/07/2025 15:19 | #
Pas de pression, moi je rédige mon manuscrit, j'ai quasiment rien le temps de faire ce mois-ci...
Le dessin en question c'est des optimisations de fonctions déjà dispo (auquel cas les shaders Azur pourraient potentiellement suffire) ou des primitives à toi ? Parce que en gros le shader "triangle texturé" ça c'est facile à écrire bien mais si tu fais des trucs tordus du genre post-processing, doubles textures en sortie, etc. ça va être plus dur.
Citer : Posté le 10/07/2025 15:32 | #
des optimisations de fonctions déjà dispo
Il y a de ça, oui, notamment, mais il y a aussi quelques primitives à moi, comme le fait d’afficher une texture redimensionnée en temps réel (plus tard j’ajouterai la rotation en temps réel), des font customs, etc... .
Actuellement (et ce n’est pas prévu), il n’y a pas de post-processing (en gros, je ne lis jamais la VRAM).
Pour moi, le seul souci qui pourrait se poser avec Azur, c’est le fait de dessiner plusieurs fois le même pixel.
Par exemple, ce code doit fonctionner :
Clear();
texture1->Draw(0, 0);
texture2->Draw(0, 0);
Display()
(Dans cet exemple, texture1 et texture2 font la même taille)
Comme texture2 est dessinée après, on doit voir uniquement texture2 au rendu.
Albert Einstein
Citer : Posté le 10/07/2025 15:38 | #
Le rendu d'image avec transfo linéaire (rotation + redimensionnement) est déjà codé dans gint et j'ai plein de variations pour Azur (notamment dans Azuray), ça ne posera pas de problème.
Tu lis jamais la VRAM : PARFAIT.
Bien sûr que tu peux dessiner plusieurs fois le même pixel ? Ce serait inutilisable sinon o_O
Citer : Posté le 10/07/2025 15:46 | #
Hé bah, c’est nickel ça !
Le rendu d’image avec transfo linéaire (rotation + redimensionnement) est déjà codé dans gint
Ah mince, je ne savais pas ça !
Tu jetteras aussi un œil à la version Gint pour voir s’il n’y a pas des améliorations à faire.
Albert Einstein
Citer : Posté le 10/07/2025 15:56 | #
J'en doute, vu que je me rappelle maintenant que la raison pour laquelle je l'ai codée c'est pour faire les rotations en temps réel dans After Burner, qui tourne sous Azur : https://www.planet-casio.com/Fr/programmes/programme4238-1-after-burner-lephenixnoir-jeux-add-ins.html
Faudra voir les formats de stockage des textures par contre, parce que moi j'hésite pas à contorsionner les textures pour gratter des cycles
Citer : Posté le 19/07/2025 22:30 | #
Hello !
J'ai mis à jour et renommé le post. Comme promis, j’ai publié le nouveau code source; cette fois, le code est propre et stable! ENFIN ! APRES 6 ANS !
Je l’ai pas mal testé sur Windows, mais peu sur Linux, car là où je suis actuellement, je suis limité à WSL.
Si certaines personnes peuvent tester et me faire des retours, ce serait top.
Vous pouvez essayer de compiler les exemples qui se trouvent dans ParticuleCore/Examples.
Quant à Lephenixnoir, dis-moi si tu arrives à tout faire fonctionner pour qu’on puisse avancer sur la version pour Azur.
Albert Einstein
Citer : Posté le 19/07/2025 23:53 | #
Merci ! Pour le ping je peux voir probablement en fin de semaine prochaine ou au début de la suivante.
Citer : Posté le 21/07/2025 16:18 | #
Petit tour des fonctions de dessin que je vois :
- Pour les polices : il faudra écrire un shader, car une commande par pixel ça va complètement défoncer la file de commande et les perfs. La version actuelle serait facile à convertir en un shader car il faut juste pouvoir couper en bande horizontales et elle itère sur un rectangle. Par contre, sauf si le compilateur fait de la réduction de force out of this world la fonction telle qu'écrite est probablement très lente. Et ça laisse une commande par caractère. Honnêtement, ce serait mieux d'utiliser le format de polices de gint, qui est optimisé pour le rendu et est déjà supporté dans Azur (sans scaling par contre pour l'instant)
- DrawLine() existe (juste peu testé), DrawHLine() peut faire via line, ou rectangle, ou écrire un shader.
- Draw[Raw]Pixel[Unsafe](): possible mais trop lent, le but est de ne jamais s'en servir.
- DrawRectFilled() : existe
- DrawRectOutline() : rien à faire, 4 lignes c'est satisfaisant je pense
- Images : dimage() est déjà supporté.
- La partie Size qui redimensionne je réalise qu'il faut quand même que je recode des choses ; image_linear() génère toujours une nouvelle image et ne s'occupe donc pas de découper en morceaux. Elle saute déjà les pixels transparents par contre.
- La partie Color qui multiple les couleurs, ça pue un peu. Enfin on peut le coder mais c'est ultra-lent comme opération. Je suis pas sûr non plus de voir quel effet ça fait parce que c'est pas de l'alpha blending (?)
Note que ton world switch manuel va te créer des problèmes de maintenance, je verrai si je peux pas fournir ça dans gint directement (ça me pique un peu mais bon, la double fonction ça a toujours été lourd... vous assumez si vous vous plantez avec)
Citer : Posté le 21/07/2025 16:50 | #
Merci ! Pour le ping je peux voir probablement en fin de semaine prochaine ou au début de la suivante.
Pas de souci, ça me laissera le temps de finaliser certaines choses dans le Core.
L'objectif est d'avoir un rendu visuel identique, donc si tu parviens à obtenir le même résultat avec Azur pour le rendu des polices, ça me convient parfaitement. Il faudra simplement ajouter dans le builder une fonction qui convertit un fichier .ttf en format Azur.
À propos de Draw[Raw]Pixel[Unsafe](), ces fonctions peuvent être très rapides sur certaines machines et très lentes sur d'autres, et ce n'est pas un problème en soi. En effet, elles ne seront sans doute jamais utilisées sur les plateformes où leur performance est mauvaise.
L'idée, c'est de garantir la présence de ces fonctions pour assurer la compatibilité, même si elles ne sont pas appelées dans certaines versions du moteur.
Pour clarifier : par exemple, la version gint utilise ces fonctions pour la 3D. Mais dans la version 3D d'Azur, on utilisera probablement un shader à la place.
Donc, même si les fonctions comme Draw[Raw]Pixel[Unsafe]() ne sont pas optimisées dans Azur, elles doivent quand même exister, ne serait-ce que pour respecter l’interface attendue. Cela ne veut pas dire qu’elles seront effectivement utilisées dans cette version.
Par ailleurs, la 3D est encore dans ParticuleEngine, mais je vais la déplacer dans le Core. Donc ne touche pas à ParticuleEngine pour le moment : ce module n'est pas du tout stable et va subir de gros changements prochainement.
Concernant image_linear(), attention car Size n’est pas limité à des facteurs de mise à l’échelle entiers (comme x2 ou x3). On peut aussi faire du redimensionnement style x0.5, donc il faut garder ça en tête.
Pour Color, c’est effectivement embêtant si ce n’est pas optimisé, surtout pour les UI qui vont souvent les utiliser.
Désolé pour le world switch manuel, je n'avais pas vraiment le choix. Il est actuellement utilisé uniquement pour les appels à OpenFile si je ne me trompe pas.
Dans la documentation, je précise clairement que OpenWith est recommandé à la place de Open et Close, donc normalement ça ne posera pas trop de problèmes.
Albert Einstein
Citer : Posté le 21/07/2025 17:07 | #
Merci pour ces retours (désolé j'ai écrit un peu à l'arrache donc pas très délicatement). Effectivement j'ai lu que Core.
Ok pour les polices. Il existe déjà https://git.planet-casio.com/YuzhenQin/fontconv et je pourrais partir de là. Quand tu convertis tu extraits quels plages de glyphes ?
Pour les pixels, oui bien sûr la fonction doit être dispo dans tous les cas. Je clarifie juste que c'est pas optimal du tout. Note d'ailleurs qu'actuellement dans Azur si tu remplis la file de commande ça arrête d'enregistrer les commandes donc t'as un frame partiel. Je pourrai améliorer ça plus tard, mais ça améliorera pas les perfs sur ces gros frames.
Oui bien sûr, image_linear() fait tous les facteurs ainsi que les rotations, donc pas de souci de ce côté-là.
Peux-tu m'expliquer l'objectif de la multiplication ? Quel effet ça fait ? À quelle fréquence c'est utilisé ?
Parce que là pour te donner une idée si je prends le shader P8 sans redimensionnement le programme met 5 cycles pour dessiner chaque pixel. À vue de nez ta multiplication là elle prend genre 30 cycles. C'est même pas le même ordre de grandeur ^^"
Non non je me souviens c'est moi qui t'avais dit de faire ça. Mais là je vois que le code de world switch a changé depuis et pour des raisons subtiles. C'est pas une bonne idée de te laisser traîner ce code-là.
Mais en fait je vérifie dans le code et y'a déjà gint_world_switch_{in,out}() dans l'API. Tu devrais pouvoir utiliser ça à la place.
Citer : Posté le 21/07/2025 17:20 | #
Hello, à toutes fins utiles je rappelle juste aussi le convertisseur de fonts de KDX : https://git.planet-casio.com/kdx/gff
Je m'en suis servi plein de fois, il est cool à utiliser.
Mais en fait je vérifie dans le code et y'a déjà gint_world_switch_{in,out}() dans l'API. Tu devrais pouvoir utiliser ça à la place.
Je savais pas qu'il y avait ça. Ce sont des balises pour qui entourent un groupe de fonctions qui nécessite un World Switch ?
Citer : Posté le 21/07/2025 17:57 | #
Ah purée merci Sly, je le cherchais tout à l'heure mais je croyais que le dépôt s'appelait "gint font forge" pas juste "gff" et du coup je le trouvais pas x)
Oui c'est l'équivalent de démarrer et terminer un world switch (si tu donnes les bons paramètres)
Citer : Posté le 21/07/2025 18:40 | #
Merci pour ces retours (désolé, j’ai écrit un peu à l’arrache, donc pas très délicatement). Effectivement, j’ai lu que Core.
Ok pour les polices. Il existe déjà https://git.planet-casio.com/YuzhenQin/fontconv, et je pourrais partir de là. Quand tu convertis, tu extrais quelles plages de glyphes ?
Pas de souci ! Pour les glyphes, on les choisit manuellement depuis le Makefile, comme ça on ne prend que ceux qu’on souhaite (une liste de glyphes par défaut est proposée).
Voir : https://github.com/leofarhi/ParticuleSDK/blob/main/ParticuleCore/Distributions/Windows/MakeAppConfig.py
Peux-tu m’expliquer l’objectif de la multiplication ? Quel effet ça fait ? À quelle fréquence c’est utilisé ?
Par exemple, quand un bouton est sélectionné, il a une teinte. C’est assez typique de Unity 3D : en gros, pour la plupart des boutons UI, on utilise une seule image blanche (par exemple) qui sert de "forme" (ça sert souvent de mask), à laquelle on applique une couleur. Ça évite d’avoir une image différente pour chaque couleur de bouton.
C’est pareil pour la gestion de la lumière sur les modèles 3D : les ombres, les effets de teinte, etc.
Donc a voir s'il y a pas une autre solution
Non non, je me souviens, c’est moi qui t’avais dit de faire ça. Mais là, je vois que le code de world switch a changé depuis, et pour des raisons subtiles. Ce n’est pas une bonne idée de te laisser traîner ce code-là.
Mais en fait, je vérifie dans le code, et il y a déjà gint_world_switch_{in,out}() dans l’API. Tu devrais pouvoir utiliser ça à la place.
Okay !
Au pire, tu pourras directement modifier la version de gint si tu penses qu’il y a moyen d’optimiser certaines choses en plus.
Actuellement, j’essaye de faire en sorte que ça marche au moins, et je travaillerai l’opti un petit peu plus tard, une fois que toutes les bases sont posées.
Albert Einstein
Citer : Posté le 21/07/2025 21:28 | #
Ah purée merci Sly, je le cherchais tout à l'heure mais je croyais que le dépôt s'appelait "gint font forge" pas juste "gff" et du coup je le trouvais pas x)
You are very welcome
Citer : Posté le 21/07/2025 21:32 | #
C’est pareil pour la gestion de la lumière sur les modèles 3D : les ombres, les effets de teinte, etc.
Donc a voir s'il y a pas une autre solution
Si la couleur est uniforme gint a un filtre dynamique "dye" qui remplace tous les pixels non-transparents par une seule couleur.
Si tu veux de l'anti-aliasing sur le bord (ce qui implique que la couleur de fond est fixée, sinon faudra faire de l'alpha blending, que tu ne fais pas actuellement), alors tu peux utiliser une palette et précalculer la multiplication sur la palette, auquel cas tu paies les 30 cycles genre une dizaine/vingtaine de fois pour modifier la palette, et ensuite le dessin va vite.