Insérer ici le texte d'introduction de la Revue des Projets 122. Parler de la rentrée, des fleurs et des abeilles mourantes tout en inventant un lien aléatoire avec la programmation. Rajouter une blague drôle.
Rédiger le texte de présentation du premier article, de Lightmare, qui porte sur Snow Crash, un jeu aventure-énigme qui plonge le joueur dans un univers de science-fiction où il est possible d'entreprendre une vie virtuelle. Préciser que c'est un jeu éponyme du roman de Neal Stephenson.
Lightmare a écrit : Bonjour les casionautes !
Je viens de finir le chapitre 1 de mon jeu SnowCrash ! Et j'aimerais vous expliquer le fonctionnement du moteur de jeu.
Il existe d'abord plusieurs programmes :
SNOWCRSH : le programme principal qui gère les déplacements et l'interprétation des matrices qui sont au cœur du fonctionnement du programme
SNOWMAPS et SNOWMAP2 : programmes de gestion des maps et de l'initialisation des matrices pour gérer les collisions : si la case sur l'écran ou le joueur veut aller possède la valeur 1, alors le joueur ne peut pas avancer, si elle a la valeur 0, il peut. La case peut toutefois avoir une autre valeur, celles ci ont diffèrent rôles : lorsque la valeur est supérieure à 1, cela définit un dialogue ou un évent ( un dialogue se déclenche si on se trouve sur une case dont la valeur est supérieure à 1 et en appuyant sur [EXE], un event se déclenche dès qu'on arrive sur la case )
Les cases avec une valeur négative definissent un changement de map :
ex : la valeur -4 montre qu'on passe à la map d'id 4.
SNOWEVNT : stocke les évent et les déclenche selon certaines conditions ( map ou on se trouve, avancement dans le jeu... ), les évents changent ensuite une valeur dans la list 1 ( les dialogues peuvent aussi le faire la première fois qu'on l'exécute )
SNOWTEXT : stocke les dialogues et les affiche en mode graphique
et voilà ! si vous voyez des améliorations possibles, dites le moi !
Écrire un commentaire enthousiaste et encourageant sur ce projet, parce qu'il est trop cool.
Insérer ici une deuxième présentation pour le projet suivant : Warning Forever, une adaptation du jeu portant le même nom. Présenter un peu le jeu en disant que c'est un genre de space shooter, avec des boss qui évoluent de manière particulière d'une étape à l'autre. Le processus d'évolution des boss de ce jeu en fait l'un des intérêts principaux, et c'est ce par quoi Yatis a commencé.
Yatis a écrit : Warning Forever est presque "jouable"
J'ai juste quelques soucis de Fps. J'aimerais que ce dernier tourne a 64 Fps, hors quand le boss arrive à un certain stage d'évolution il tombe à 43 Fps.
Ce qui est problématique car il ne peut pas encore tirer / se déplacer (donc les Fps risquent de tomber encore plus). J'ai déjà quelque piste pour gagner quelques Fps:
----->revoir le code (ou harcoder) la gestion des dalles en fond.
----->harcoder les fonctions de dessin (ML_bmp_rota() et ML_bmp_rota_custom()) qui sont les fonctions qui me permette d'afficher des bmp en leur appliquant une rotation. (ML_bmp_rota() tourne le bmp en son centre alors que ML_bmp_rota_custom() tourne le bmp par rapport à un point quelconque).
----->revoir les algo utiliser pour la gestion des "bras".
----->pré-calculer un maximum de choses et éviter les opérations trop longues (modulo, division, etc.).
Qu'est-ce que j'ai faits depuis la RdP précédente ?
J'ai repris le code de 0 pour refaire une structure et...le jeu et passer de 40ko a 19ko donc ça a bénéfique
J'ai touché un peut au driver clavier ce qui m'a permis d'apprendre pas mal de chose sur le "comment la machine fonctionne", maintenant l'add-in est compatible SH3 et SH4.
Les collisions sont "fonctionnelles" (même si j'ai encore quelques soucis avec). J'ai aussi réfléchi sur le "système" d'évolution du boss, et il va se faire sur 3 axes:
----->Attaque: augmente la puissance et l'intelligence des armes.
----->Défense: fait pousser des membres aux endroits le joueur a tirer.
----->Déplacement: le boss réagit de plus en plus vite aux actions du joueur.
Pour l'instant j'ai implémenter seulement le système de défense (qui fonctionne très bien)
J'ai aussi implémenter une des deux caméras (celle-ci vissé sur le joueur) mais j'ai encore du mal à donner une taille de map correcte (c'est soit trop grand sois trop petit...bref il faut que je regarde vraiment parce que pour l'instant j'ai juste piffé dans le code).
Mais j'aimerai d'abord finir ce problème de Fps, seulement je peux pas encore toucher à ML_bmp_rota() et ML_bmp_rota_custom() car l'algo utiliser n'est pas précis donc il faut que je trouve autre chose.
C'est sur quoi je vais travailler la semaine qui arrive (espèrent réussir à trouver une méthode plus rapide et plus précise que celle que j'utilise).
Et pour finir, voila une petite vidéo montrant le système d'évolution (défense) en pleine action
Insérer ici un commentaire encore plus enthousiaste sur ce projet et la vidéo qui vend du rêve. Woah.
Clore l'article de manière drôle et morbide en parlant de chatons et d'explosions. Où est passée ma bouteille ?
Cette semaine, 5 programmes ont été postés !
Fifa19, pour votre Casio Graph 90+E ! Un jeu de foot simple conçu par Manolo.
Snow Crash, de Lightmare. Référez-vous à son article. Un jeu en Basic pour Calculatrices monochromes.
NASAControl, un jeu de Disperseur. Replongez-vous dans l'histoire des premiers pas de l'Homme sur la Lune ! Programme en Basic pour calculatrices monochromes.
IA de mactul.P Un programme en Basic pour calculatrices monochromes où vous discutez avec une IA.
Rocks Planets, de Disperseur. Cet Add-in (Graph 75/85/95+) vous permet de visualiser les planètes telluriques en orbite ! Disponible pour SH3 et SH4.
Bien au contraire, il faut passer par le TMU pour se faire exécuter sa fonction de frame tous les 1/64 s (si tu peux les tenir).
Pour la rotation, tu peux aussi précalculer un certain nombre de directions (10, 12 ?) pour chaque sprite au début du combat, et ensuite les réafficher à l'infini.
En effet utilise les timers c'est largement mieux. Lephé m'a converti et il avait raison
Quand tu cherches à optimiser, la meilleure piste c'est de se passer des float
J'insiste mais plus de 30 fps sur calto ça sert à rien, si très au dessus c'est suffisant, ne cherche pas à gagner 10 fps si t'es déjà à 300... ^^'
Enfin, ce n'est pas le moment d'optimiser ton code. Tu es encore en prototypage. Tu te mets des bâtons dans les roues en optimisant maintenant.
Ninestars a écrit : En effet utilise les timers c'est largement mieux. Lephé m'a converti et il avait raison
Quand tu cherches à optimiser, la meilleure piste c'est de se passer des float
J'insiste mais plus de 30 fps sur calto ça sert à rien, si très au dessus c'est suffisant, ne cherche pas à gagner 10 fps si t'es déjà à 300...
Je n'utilise aucun float et aucune libraire autre qu'un mix entre ML et usefull et j'utilise au maximum les opérations bitwise. (au grand max j'ai des multiplications)
Je cherche à optimiser pour trouver la source de cette baisse de fps qui apparaît de nulle part... puis je commençais à me perdre un peu donc un petit nettoyage ne fait pas de mal
Ninestars a écrit : Enfin, ce n'est pas le moment d'optimiser ton code. Tu es encore en prototypage. Tu te mets des bâtons dans les roues en optimisant maintenant
Oui seulement il me reste pas grand-chose pour qu'il soit jouable et si j'ai une perte aussi violente des fps ce n'est pas bon signe pour la suite du développement :/
Dans l'absolu tu as raison Ninestars, mais je pense qu'ici le point de vue est plus qu'il y a un bug dans la méthode ou l'implémentation, plutôt que simplement la fonction ne vas pas aussi vite qu'on l'aimerait.
Yatis a écrit : Je n'utilise aucun float et aucune libraire autre qu'un mix entre ML et usefull et j'utilise au maximum les opérations bitwise. (au grand max j'ai des multiplications)
Je te parie que t'as au moins des fonctions trigo. Et ça c'est lent. Très lent.
Essaie de regarder du coté des fixed, ou précalcule les sprites, ouais.
Pour le précalcul, à première vue, je dirais que 90 positions sont largement suffisantes pour tout faire. Je doute qu'un angle de moins de 4 degrés soit vraiment utile à représenter.
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Je te parie que t'as au moins des fonctions trigo. Et ça c'est lent. Très lent.
Essaie de regarder du coté des fixed, ou précalcule les sprites, ouais.
Ouais et en plus j'applique les fonctions sur tous les pixels d'une image (même si le pixel off dans l'image) donc je vais déjà essayer de régler ce problème.
Dark storm a écrit :
Pour le précalcul, à première vue, je dirais que 90 positions sont largement suffisantes pour tout faire. Je doute qu'un angle de moins de 4 degrés soit vraiment utile à représenter.
Le problème vient visiblement de setFPS() qui donne une baisse de fps violent, donc je vais essayer de passer par le TMU.
Seulement je vois pas bien comment faire:
Es-ce que j'utilise la même structure que setFPS() sauf que je regarde un Timer Counter (TCNT) à la place ?
Ou alors je gère mon jeu comme si le main(void) est une interruption (ce qui me garantira un 64fps constant et les piles seront heureuses) mais du coup, il faut que je me tape la doc de l'Interupt Controller (INTC) pour comprendre ou mettre l'address de mon main(void) (qui devra gérer, en plus, le bit UNF pour éviter que ça boucle à l'infini) ?
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
Snow Crash, de Lightmare. Référez-vous à son article. Un jeu en Basic pour Calculatrices monochromes.
Citer : Posté le 17/09/2018 20:32 | #
Bien au contraire, il faut passer par le TMU pour se faire exécuter sa fonction de frame tous les 1/64 s (si tu peux les tenir).
Pour la rotation, tu peux aussi précalculer un certain nombre de directions (10, 12 ?) pour chaque sprite au début du combat, et ensuite les réafficher à l'infini.
Citer : Posté le 18/09/2018 09:32 | #
En effet utilise les timers c'est largement mieux. Lephé m'a converti et il avait raison
Quand tu cherches à optimiser, la meilleure piste c'est de se passer des float
J'insiste mais plus de 30 fps sur calto ça sert à rien, si très au dessus c'est suffisant, ne cherche pas à gagner 10 fps si t'es déjà à 300... ^^'
Enfin, ce n'est pas le moment d'optimiser ton code. Tu es encore en prototypage. Tu te mets des bâtons dans les roues en optimisant maintenant.
Citer : Posté le 18/09/2018 11:05 | #
En effet utilise les timers c'est largement mieux. Lephé m'a converti et il avait raison
Quand tu cherches à optimiser, la meilleure piste c'est de se passer des float
J'insiste mais plus de 30 fps sur calto ça sert à rien, si très au dessus c'est suffisant, ne cherche pas à gagner 10 fps si t'es déjà à 300...
Je n'utilise aucun float et aucune libraire autre qu'un mix entre ML et usefull et j'utilise au maximum les opérations bitwise. (au grand max j'ai des multiplications)
Je cherche à optimiser pour trouver la source de cette baisse de fps qui apparaît de nulle part... puis je commençais à me perdre un peu donc un petit nettoyage ne fait pas de mal
Enfin, ce n'est pas le moment d'optimiser ton code. Tu es encore en prototypage. Tu te mets des bâtons dans les roues en optimisant maintenant
Oui seulement il me reste pas grand-chose pour qu'il soit jouable et si j'ai une perte aussi violente des fps ce n'est pas bon signe pour la suite du développement :/
Citer : Posté le 18/09/2018 20:13 | #
Dans l'absolu tu as raison Ninestars, mais je pense qu'ici le point de vue est plus qu'il y a un bug dans la méthode ou l'implémentation, plutôt que simplement la fonction ne vas pas aussi vite qu'on l'aimerait.
Citer : Posté le 21/09/2018 09:46 | #
Je n'utilise aucun float et aucune libraire autre qu'un mix entre ML et usefull et j'utilise au maximum les opérations bitwise. (au grand max j'ai des multiplications)
Je te parie que t'as au moins des fonctions trigo. Et ça c'est lent. Très lent.
Essaie de regarder du coté des fixed, ou précalcule les sprites, ouais.
Pour le précalcul, à première vue, je dirais que 90 positions sont largement suffisantes pour tout faire. Je doute qu'un angle de moins de 4 degrés soit vraiment utile à représenter.
Citer : Posté le 25/09/2018 12:22 | #
Je te parie que t'as au moins des fonctions trigo. Et ça c'est lent. Très lent.
Essaie de regarder du coté des fixed, ou précalcule les sprites, ouais.
Ouais et en plus j'applique les fonctions sur tous les pixels d'une image (même si le pixel off dans l'image) donc je vais déjà essayer de régler ce problème.
Pour le précalcul, à première vue, je dirais que 90 positions sont largement suffisantes pour tout faire. Je doute qu'un angle de moins de 4 degrés soit vraiment utile à représenter.
Le problème vient visiblement de setFPS() qui donne une baisse de fps violent, donc je vais essayer de passer par le TMU.
Seulement je vois pas bien comment faire:
Es-ce que j'utilise la même structure que setFPS() sauf que je regarde un Timer Counter (TCNT) à la place ?
Ou alors je gère mon jeu comme si le main(void) est une interruption (ce qui me garantira un 64fps constant et les piles seront heureuses) mais du coup, il faut que je me tape la doc de l'Interupt Controller (INTC) pour comprendre ou mettre l'address de mon main(void) (qui devra gérer, en plus, le bit UNF pour éviter que ça boucle à l'infini) ?
Citer : Posté le 25/09/2018 13:50 | #
Ne fais surtout pas comme setFPS() en surveillant le TCNT, utilise l'option interruption.
Si tu es sous gint, consulte la doc timer. Sinon, il y a des exemples dans ce tutoriel :
Tutoriel - La gestion du clavier en C
Le principe, en tous cas, est le même.