[WIP] New project - Il est temps d'en parler - Un Shmup pour fx-CG50/Graph 90+E et fx-CG20/Prizm
Posté le 15/01/2023 21:55
Bon, il n'a dû échapper à personne (enfin ceux traînant du côté de la shout "projets") que je suis en cours de tripatouillage dans Azur afin de créer un Particle Engine. En effet Lephé, comme toujours, est très présent pour aider dans le lancement des projets et la résolution des problèmes techniques.
Donc en effet, je me suis donné comme objectif de créer un jeu d'un type très peu représenté sur nos chères machines : un Shmup (ou Shoot Them Up), en gros un bon gros jeux de space shooter où le but est de dégommer tout le monde.
J'en suis aux prémisses car je voulais voir ce que cela pouvait donner sur la CG50, un des problèmes attendus étant la limitation du framerate lorsque l'on doit manipuler de nombreux sprites. Et dans un shmup, des sprites, il y en a à profusion, c'est le moins que l'on puisse dire. Et très clairement, c'est le genre de jeux qui ne supporte pas trop le lag.
Je me suis donc mis en tête de comprendre comment fonctionne (du moins en surface), le moteur de rendu Azur développé par Lephé et que nous avons vu à l'oeuvre dans Afterburner.
Pour le moment nous avons un simple fond étoilé généré aléatoirement et rendu par un Shader ainsi que la possibilité de générer des explosions.
Je vous mets en PJ le g3a pour tester un peu si vous voulez regarder ce que donnent les shaders de Azur :
Au niveau des touches :
F1 à F4 permettent de montrer/cacher les infos
F6 : pour randomiser les particules de fond (étoiles défilantes)
SHIFT pour lancer un petit effet sympa d'explosion (calcul en temps réel avec le Particle Engine)
Ça tourne a quasi 100FPS sans overclock !!! Autant dire que c'est vraiment de la balle.
En Overclock F5, ça tourne à 200FPS, on frôle l'excès de vitesse, c'est une tuerie.
Je n'en dis pas plus pour le moment, c'est juste histoire de teaser un peu. Je pense que le développement se fera sur une période assez longue, n'ayant plus le même "temps libre" qu'au moment du développement de Outrun.
Donc soyez patients.
Désolé, pas de screen capture, c'est pas opérationnel avec Azur
Edit : ça correspond à ma version interne v0.1.5, donc vous voyez l'avancée du truc
Fichier joint
Citer : Posté le 18/03/2023 13:03 | #
Edit : 18/03/2023 - même si pas de MaJ (mais ça va revenir) un petit @RDP ferait pas de mal car y'a eu pas mal d'avancées
avec en prime un petit screen de la version actuelle sur ma CG50 :
J'ai maintenant un scanf() / fscanf() fonctionnel, donc je vais pouvoir développer le gestionnaire de niveaux, c'était la raison de la grosse pause de ces dernières semaines.
Citer : Posté le 19/03/2023 11:55 | #
Généralement on évite d'inclure des barres de vie dans les shmups pour des questions évidentes de lisibilité. On les garde pour les boss (et éventuellement les miniboss), mais quand on a 50 petites unités qui envahissent l'écran ça risque de surcharger graphiquement l'espace pour pas grand-chose.
Le joueur tire dans le tas, et s'appuie sur l'expérience pour savoir combien de temps un ennemi met pour mourir.
Si tu y tiens malgré tout ça serait sympa de le laisser en option !
Citer : Posté le 19/03/2023 12:03 | #
Oui oui, ne t'inquiète pas, c'est une "DEBUG feature", cela me permet :
- de voir si la gestion des hitboxes est Ok
- de calibrer la puissance des bullets et des ennemis les uns par rapport aux autres
- de voir si quand la vie atteint zéro, on déclenche bien les bons évènements (explosions, disparitions de l'ennemi des listes, apparition de bonus, ...)
Cela va bien évidemment disparaître dans les versions finales (je pourrai éventuellement laisser la possibilité de garder via une combinaison de touches ou une option dans un menu DEBUG)
Citer : Posté le 13/08/2023 17:35 | #
Bon ça faisait vraiment une paie que je n'avais pas retouché le Shmup et depuis quelques temps, l'envie de voir des boss avec plein de morceaux qui volent dans tous les sens se faisait de plus en plus pressante.
Voici donc les prémices du développement de cette feature. Bon le moteur de jeu est globalement assez souple pour supporter cela. Plutôt que de faire de longs longs discours, voici ce que ça donne pour le moment, sachant que le debuggage est pas encore passé par là et que c'est vraiment juste le début.
J'ai voulu pousser le moteur dans ses retranchement, alors il y a plein de choses affichées (c'est un peu illisible par moment), mais c'est pour tester, et ça tourne sans overclock. La vidéo prise via USB ne rend pas bien hommage à la puissance du moteur Azur, car IRL on tourne à 35fps avec qq points bas vers 30fps avec tout ce monde affiché. Via la vidéo, on est plutôt vers 20-25fps. Bref ça tourne bien.
Donc les boss pourront contenir une partie centrale sous forme de sprite(s), dans le cas illustré on a juste un sprite central et des parties animées (ici un shield rotatif composé de triangles, chacun pouvant attraper du dégât et être explosé si sa vie devient inférieure à 0). J'ai fait un cas simple, mais on peut imaginer plein de géométries complètement pétées (un crabe avec d'énormes pinces, un serpent qui ondule sur l'écran, ... ) afin de créer de la diversité (bon le plus chiant sera de programmer les comportements
Il y a quelques glitches graphiques, je pense que je sature le buffer de commande de Azur (car il y a vraiment plein de choses d'affichées en même temps), ce qui se traduit par moment par des morceaux d'image qui ne se tracent plus. Je regarderai bien entendu cela.
J'espère pouvoir faire avancer un peu plus dans les jours/semaines qui viennent.
et @RDP (j'aime bien me donner du boulot
Citer : Posté le 14/08/2023 14:20 | #
Azur est vraiment rapide : après correction de mon bug (une connerie comme d'habitude
La vidéo est prise via fxlink, on perd donc grosso modo 10ms à chaque frame, soit 10fps en moyenne. sans capture, on est à une moyenne de 34/35FPS (le plus bas que j'ai noté est 29FPS) et avec capture on est vers 20/22FPS :
J'ose même pas compter le nombre de sprites
C'est une tuerie
Citer : Posté le 16/08/2023 08:08 | # |
Fichier joint
Pour Celles et Ceux qui voudraient tester la version en cours, voici un build de la v0.4 en pièce jointe (attention l'addin est un gros patapouf
Cela correspond à ce que vous voyez dans la vidéo, ni plus ni moins, juste en désactivant le support de l'USB pour ne pas freeze le jeu si vous avez pas le fxSDK d'installé avec fxlink connecté et en attente (le mode développeur quoi
Rappel des touches (Certains choix sont pas forcément très très heureux dirons nous, mais cela pourra se changer facilement, n'hésitez pas à proposer de meilleures options si vous pensez avoir une bonne idée) :
croix directionnelle pour bouger
[F1] : tir normal (tir continu tant que la touche est maintenue)
[F2] : tir boost (tir continu tant que la touche est maintenue)
[F3] : tir laser (salve par salve, c'est le KeyPressedEvent qui compte)
[SHIFT] + [F1] à [F4] permettent de montrer/cacher les infos (Nb: la touche [F4] sera ici sans effet car j'ai désactivé la RAM étendue dans cette release)
[SHIFT] + [EXIT] pour quitter
Pour ceux que ça intéresse, j'essaye de collecter les diverses idées que j'ai pour le jeu dans ce fichier TODO.txt. Ca vous donne l'idée du chemin qui reste à parcourir pour la v1.0 ...
Citer : Posté le 22/08/2023 23:52 | #
Toujours à m'amuser avec Shmup pour voir jusqu'à quel point on peut tirer sur Azur pour pousser la fxCG50 dans ses retranchements.
Du coup voici la version Bullet Hell de Shmup.
Finalement je pourrais peut-être bien faire plaisir à Hackcell avec un Danmaku, qui sait !?! ...
Citer : Posté le 25/08/2023 11:50 | #
Yo,
quelques nouvelles du côté de Shmup (Faudra vraiment que je me mette à chercher un nom
Donc hier je me suis lancé dans les préparatifs pour un nouveau mode de jeu qui sera appelé "Asteroïd Alert" et que j'ai envie d'implémenter histoire de varier un peu le gameplay.
Pour ce faire, j'ai besoin de routines de collision un peu "chiadées". Je me suis donc mis en tête de développer quelques outils pour avoir d'une part la traditionnelle détection de type AABB et d'autre part une détection plus poussée de type Pixel Perfect.
Voici en vidéo ce que ça donne (j'ai préparé un petit addin de test pour mesurer les performances).
Comme ça pourrait servir à d'autres, j'isole cette partie dans un dépôt spécifique appelé Pixel_Perfect. N'hésitez pas à réutiliser le code si besoin. L'addin de test est inclus dans le dépôt si vous voulez tester.
Sinon, j'ai fait 2/3 petites optimisations dans Shmup en lui même, pour la gestion des trajectoires des tirs des boss. Voici ce que ça donne maintenant.
Je sais pas si c'est moi qui ferai la prochaine revue de projets, mais @RDP
Citer : Posté le 09/09/2023 13:43 | # |
Fichier joint
Cela faisait un petit moment que je n'avais pas donné de nouvelles du Shmup.
Ces derniers temps, avec la reprise du boulot, j'ai un peu (beaucoup) moins le temps de coder, les projets s'en ressentent un peu du coup.
Néanmoins, il y a quelques avancées du côté de ce projet.
La principale (et plus visible) avancée concerne l'apparition des rayons lasers dans le jeu. Il a fallu implémenter pas mal de choses qui manquaient dans le moteur de jeu, notamment la gestion des collisions entre des lignes (le laser) et des rectangles ou des triangles (pour les sprites et les boucliers des boss).
Les lasers sont directionnels comme le montre la vidéo ci-après et promettent pas mal de trucs sympas avec les ennemies et les boss. Mais je n'en dis pas plus pour le moment.
Il y a eu aussi pas mal de changements au niveau graphique (sprites qui changent, ajustement de leur taille, nouvelle fonte de caractères ...).
La prochaine grosse étape sera le séquenceur de partie. Il s'agit du module qui permettra de gérer l'apparition des vaisseaux ennemis et les éléments du décors. Cela rendra aussi possible la création de niveaux de manière moins artisanale.
Je compte aussi implémenter d'autres ennemies (dont de nouveaux boss) afin de commencer à créer du "vrai" gameplay, le moteur étant désormais suffisamment développé pour avoir un début de gameplay intéressant.
Je vous mets la version du jour en pièce attachée. Les touches restent les mêmes, avec [F4] en plus pour activer les lasers.
Ça doit bien valoir un truc dans la prochaine @RDP
Citer : Posté le 10/09/2023 10:05 | #
Bien joué pour les performances ! Les graphismes rendent vraiment bien !
Juste un truc, est ce que c'est normal qu'on puisse utiliser toutes les armes en même temps
Citer : Posté le 10/09/2023 10:55 | #
Oui pour le moment c’est en test donc tout est utilisable en parallèle pour essais. Mais dans le jeu définitif cela ne sera plus le cas. Je compte mettre en place un système d’upgrade d’arme et on aura juste une arme fonctionnelle (plus éventuellement un super tir en quantité limité, par exemple une bombe ou un truc « collectable »).
Citer : Posté le 29/04/2024 20:00 | #
Salut ! Ce projet est toujours d'actualité ?
Citer : Posté le 02/09/2024 21:05 | #
Désolé Le_masque, je n'avais pas vu ta question.
Le projet n'est pas abandonné, mais il est mis en pose en ce moment comme tous mes projets de programmations malheureusement du fait d'un gros manque de temps en ce moment.
Mais il fait clairement partie des projets que j'aimerai avancer avec Sushi Assassination et Pinball.
One Day, Soon (TM)
Citer : Posté le 25/05/2025 00:20 | #
Bon j'avance le code à un train de sénateur en ce moment, mais je voulais faire un petit mouv' sur Shmup.
J'ai donc travaillé ma page de titre. Voici un petit extrait pour teaser :
J'espère que cela vous plait.
(Bien entendu c'est calculé en temps réel)
Citer : Posté le 25/05/2025 00:29 | #
Wow c'est super classe ouais :o :o
Citer : Posté le 25/05/2025 10:53 | #
woah
faut vraiment que j'optimise mon propre moteur
Citer : Posté le 25/05/2025 11:20 | # |
Fichier joint
Si cela peut vous intéresser, voici le code source pour SDL2 avec les paramètres pour que ce soit très facilement transférable vers une calculatrice (c'est de l'arithmétique en FP 16:16).
Il faut juste modifier les fonctions de rendu et de définition de la couleur pour sortir un uint16_t dans la fonction colorFromTemperatureFixed()
int32_t t = fixedDiv(tempK - floatToFixed(3000.0f), floatToFixed(7000.0f));
int32_t t_abs = std::abs(t - (FIXED_ONE >> 1));
int32_t r = std::min(255, fixedToInt(fixedMul(FIXED_ONE * 255, std::min(FIXED_ONE, fixedMul(floatToFixed(1.5f), t)))));
int32_t g = std::min(255, fixedToInt(floatToFixed(200.0f) - fixedMul(floatToFixed(100.0f), t_abs)));
int32_t b = std::max(0, fixedToInt(fixedMul(FIXED_ONE * 255, FIXED_ONE - t)));
return {static_cast<Uint8>(r), static_cast<Uint8>(g), static_cast<Uint8>(b), 255};
}
devient
int32_t t = fixedDiv(tempK - floatToFixed(3000.0f), floatToFixed(7000.0f));
int32_t t_abs = std::abs(t - (FIXED_ONE >> 1));
uint16_t r = static_cast<uint16_t>(std::min((int) 255, (int) fixedToInt(fixedMul(FIXED_ONE * 255, std::min((int) FIXED_ONE, (int) fixedMul(floatToFixed(1.5f), t))))));
uint16_t g = static_cast<uint16_t>(std::min((int) 255, (int) fixedToInt(floatToFixed(200.0f) - fixedMul(floatToFixed(100.0f), t_abs))));
uint16_t b = static_cast<uint16_t>(std::max((int) 0, (int) fixedToInt(fixedMul(FIXED_ONE * 255, FIXED_ONE - t))));
return (((r>>3)<<11) | ((g>>2)<<5) |((b>>3)));
}
Pour ce genre de morceau de code, je travaille sur PC avec la SDL2 afin de bien caler les paramètres et quand je suis content du résultat, je bascule sur calto pour peaufiner les réglages (nombre d'étoiles, ajustement des couleurs si besoin, l'écran de la G90+E ayant un rendu un peu particulier, ...).
Pour info la version en vidéo d'hier soir contient 3200 étoiles.
Amusez vous bien, si vous voulez proposer des versions modifiées (couleurs, formes, etc.) je vous laisse revenir avec un paquet complet en zip. SI il y a une version qui me plait, je pourrais l'intégrer dans le shmup.
Citer : Posté le 31/05/2025 22:21 | #
J'ai retravaillé pas mal de parties de Shmup, et en guise de détente, j'ai mis au point une nouvelle arme :
Je suis dans la phase de tuning des paramètres, afin que :
1/ ça tourne avec des perfs correctes
2/ ça soit proche du rendu que je voudrais obtenir
Ca devrait arriver un de ces quatres.
@RdP
Citer : Posté le 01/06/2025 13:08 | #
Sympa l'effet ! C'est fait comment ? Tu prends des points plus ou moins écartés de la ligne directe et tu les relies ?
Citer : Posté le 01/06/2025 13:47 | #
yes, on tire à chaque frame un deltaX et deltaY et on vient ajuster des segments (X,Y) de la ligne directe avec (deltaX, deltaY) pour N points entre 2 bornes (point de départ et point d'arrivée).
Pour que l'effet soit mieux, on ajuste la couleur à chaque frame aussi ainsi que l'épaisseur de la ligne.
Je viens aussi de rajouter la possibilité d'avoir diverses couleurs d'arc électrique et de la changer en cours de vie de l'arc.
Pour ceux qui voudraient voir comment c'est fait, le code est là :
https://git.planet-casio.com/Slyvtt/Shmup/src/branch/dev/src/shmup/thunderstrike.cpp
et
https://git.planet-casio.com/Slyvtt/Shmup/src/branch/dev/src/shmup/thunderstrike.h