Bonjour à tous ! Eh oui vous ne rêvez pas il s'agit bien de la 225ème édition de notre revue pseudo hebdomadaire Tout d'abord un peu de contexte. Cette revue va couvrir les 2 3 dernières semaines, sur les projets ayant été notifiés par un @RDP, n'hésitez pas à l'ajouter à vos messages si vous souhaitez apparaître dans la prochaine revue
Comme vous avez pu le constater : J'ai du travail à faire, aujourd'hui pas moins de 8 articles de 6 personnes différentes !
Vu que nous avons un peu de retard, je vous propose de traiter les projets dans l'ordre chronologique. Ne tardons pas en commençant avec Adoranda de Tituyaoui oui c'est bien moi.
Pour ceux n'étant pas au courant, Adoranda est un projet de RPG pour nos 90+E. Ces derniers temps, à l'aide des vacances scolaires j'ai enfin pu développer l'aspect technique du jeu en implémentant les combats.
En parlant des combats, je ne vais pas mentir l'interface et le style va sûrement vous rappeler un petit jeu, je vous laisse observer cette magnifique interface :
Comme j'ai pu l'expliquer dans un long message, les différentes statistiques du joueur et des monstres sont calculées en fonction du niveau et en fonction du taux de base de l'ennemi.
Je vous ai également donné les différentes formules que j'utilise afin de calculer les dégâts ou encore les coups critiques.
Mais bon, ce message date d'il y a deux semaines. Depuis j'ai pu développer quelques aspects intéressants : À présent il y a un taux de réussite aux attaques. Une précision. J'ai rajouté des attaques ayant des effets sur celui qui la lance. Permettant des buffs le temps d'un combat. Il me fallait un moyen de calculer le niveau des monstres rencontrés. C'est pour cette raison que j'ai ajouté un système de zone sur la carte. Grâce à Tiled et ses rectangles, il est très facile de mettre le niveau moyen dans une zone ainsi que de préciser l'identifiant des monstres pouvant apparaître
Un changement interne intéressant, les attaques sont à présentes stockées en JSON, il est donc plus simple d'en créer et largement plus agréable.
Et... c'est tout... Je n'ai pas vraiment pu continuer de travailler sur Adoranda cette semaine. Mes objectifs restent les mêmes : Vous fournir un jeu ou au moins être capable d'en fournir un. En espérant pouvoir réussir à fabriquer une histoire intéressante pour vous tenir dans ce jeu relativement ambitieux
Comme expliqué plus haut, si vous êtes intéressés par les différentes formules vous pouvez en apprendre plus sur le topic :
Continuons notre escalade temporelle en parlant d'un autre habitué des revues. Si je vous parle de Shadow15510 vous pensez certainement à Asci son moteur de RPG en python.
Et vous avez raison ! Shadow vient juste de publier une nouvelle mise à jour de son moteur, le passant à la version 1.8.1
Comme d'habitude, léger changelog, permettant notamment à Shadow d'avancer sur IDK (nous allons en parler plus tard). Ici, surtout des modifications sur les animations disponibles.
walk to : l'entité se déplace jusqu'à la case donnée
follow by player : comme walk to mais si le joueur est trop loin, l'entité stoppe son mouvement pour permettre au joueur de la suivre.
À noter que l'ancienne animation walk qui correspondait à une marche "en boucle" a été renommée en walk between.
Shadow précise également des petites modifications sur l'algorithme de déplacement des entités :
Shadow15510 a écrit : Et l'algorithme de déplacement a été revu : vous pouvez dès lors directement préciser les points de départ et d'arrivée, l'entité se déplacera ensuite en ligne droite et / ou en diagonale pour rejoindre sa case d'arrivée. Néanmoins, il ne s'agit pas d'un algorithme de pathfinding, donc, s’il y a un obstacle, l'entité restera coincée.
Et c'est tout pour Asci ! Comme d'habitude vous pouvez le télécharger directement sur sa page ou en suivant le développement sur le topic dédié.
Bon, vous l'aurez compris lorsque nous parlons d'Asci nous parlons forcément du jeu à l'abréviation intéressante IDK. Shadow a pu déployer deux petits changelog afin de le mettre à jour avec Asci. Le jeu est à présent dans sa version 1.0.4 :
IDK utilise maintenant la dernière version d'Asci (j'en avais parlé sans sortir la release) lorsque l'on commence la quête principale et que l'on parle à Lithy dans Migard, on revenait au début de la quête, c'est fixé. À présent vous pouvez ajouter des entités dans les DLCs, nous pouvons donc imaginer (enfin), un joueur qui vous guide pour trouver les points de passage
Avec les derniers patchs des versions d'Asci, Shadow vous conseille de mettre à jour. Si vous souhaitez découvrir ce RPG unique en python, je vous invite à aller le télécharger sur la page officielle de téléchargement !
Aucun DLC de développé pour l'instant, en tout cas Shadow garde cette idée pour plus tard, des informations supplémentaires à nous donner Shadow ?
Changeons un peu de décors en parlant d'une personnalité que nous apprenons à découvrir ces dernières semaines. Un développeur provenant de l'univers TI, plein d'idées et surtout plein de talent ! Je parle évidemment de Slyvtt
En ce moment, la 3D est à la mode. Rappelant le projet de Gladosse dont nous avons déjà parlé il y a quelques semaines, Slyvtt s'est lancé dans un OutRun pour nos 90+E. Il s'agit là d'un jeu d'arcade de course de voiture.
Comme nous avons pu le voir dans le topic du projet, c'est loin d'être terminé ! Entre chauffards ne tournant pas dans les virages, excès de vitesse et dépassement par la droite, ce prototype ne risque pas de vous apprendre à conduire !
Dans les premiers essais remontant au 20 février, Slyvtt nous montre un peu à quoi ressemble le déplacement sur le circuit :7
Il s'agit là de sa dernière vidéo. Depuis le projet a pu avancer, Slyvtt grâce à l'aide de Lephenixnoir et du merveilleux gint a récemment pu profiter de l'upscale d'image afin de réduire considérablement la taille de l'add-in.
La dernière image en date nous montre des arbres sur le bord de la route, pouvons nous espérer des décors supplémentaires dans les prochaines mises à jour ?
Fidèle au jeu original, Slyvtt a récemment publié les premières versions de virages et de montées / descentes. Comment sont-elles programmées dans le code ?
Slyvtt a également profité de son dernier message pour nous donner une version jouable avec un circuit de test. Je vous invite grandement à aller l'essayer pour voir ce qu'un jeu de course pourrait donner sur nos calculatrices !
Le framerate semble constant. Dans les alentours de 30-40ips, les optimisations et les efforts ont valu le coup !
Un jeu de course sur 90+E, il s'agit là d'une première ! Cela nous laisse l'occasion de poser plein de questions, en voici quelques-unes sorties de mon chapeau magique de rédacteur :
Quels sont tes plans pour le futur du jeu ?
Penses-tu pouvoir fournir un utilitaire de création de circuit ?
Suite à des restrictions budgétaires, certaines questions ont dû être supprimées de la liste. (En vérité Slyvtt les as juste implémentés le temps de la rédaction)
En attendant tes réponses, je suis impatient de voir ce que tu vas réussir à nous créer ! Je te souhaite bon courage pour ce projet premier dans son genre. Si vous êtes intéressé par ce projet, je vous invite à aller jeter un coup d'oeil au topic original en suivant le lien ci-dessous.
Mais... Vous ne trouvez pas qu'il manque quelque chose à cette revue ? Comme vous le savez, une bonne revue est une revue avec Lephenixnoir ! Un Lephenixnoir écossais qui plu est. Mais aujourd'hui il n'est pas seul, entouré du meilleur graphiste de Planète Casio après KikooDX bien sûr, voici enfin des nouvelles de Rogue Life, un jeu particulièrement attendu !
Après 2 mois de travail en sous-marin comme j'aime l'appeler, Lephenixnoir nous met à disposition un add-in de test ainsi que le changelog plutôt intéressant que voici :
Lephenixnoir & Masséna a écrit :
Des animations sur la map et une revue complète des animations d'attaques par Masséna ;
Un menu principal, incomplet mais décent et donnant un aperçu des niveaux et avec une jolie transition ;
Une mécanique d'XP : au début de chaque arène le joueur est niveau 1, et monte en niveau en tuant des monstres (super animation de Masséna d'ailleurs !). L'XP est déterministe pour l'instant mais ça changera plus tard.
Des IAs décentes : les slimes foncent sur le joueur, les chauves-souris attaquent et esquivent, les gunslingers attaquent à distance. Toute la variété du jeu final n'est pas encore là, mais on s'en approche.
Des items au sol ; pour l'instant juste un item qui restaure une partie des PVs apparaît au début du niveau. Je vous conseille d'aller le chercher, bouger dans la map change complètement la dynamique de l'arène.
Dans le futur, des armes/équipements apparaîtront comme items et guideront les skills disponibles.
C'est magnifique...
Des animations et dessins par Masséna, du code et les idées de Lephenixnoir, ce jeu s'annonce déjà être un must-have des 90+E !
Si vous n'êtes toujours pas convaincu, je vous invite VIVEMENT à aller tester l'add-in : Rogue Life bêta.
Cette version de test comporte deux niveaux, basez-vous sur le premier pour avoir un avant-goût intéressant du jeu final. Je me demande quand même où en est réellement le développement. Une idée / un objectif de date de sortie à nous communiquer ?
Passons à la suite en redonnant le micro à Slyvtt. Si vous suivez le développement gint, vous avez dû tomber sur ce topic mystérieux : µSTL pour Casio Graph 90+E avec fxsdk gint. Entre incantation magique et pacte avec le diable, il est de mon devoir de rédacteur de vous résumer ce topic du mieux que je le peux.
Je tiens à préciser qu'il va s'agir d'un résumé, si le sujet vous intéresse je vous invite à aller lire le topic officiel.
Bon, plus sérieusement il s'agit d'une implémentation partielle de la bibliothèque standard de C++. Implémentant entre autres des outils de programmation très intéressants qui étaient, jusqu'alors indisponibles sur calculatrice.
Pourquoi ne pas implémenter la lib standard en entier ? C'est une tâche réalisable mais assez compliquée au niveau des calculatrices, parce que la lib standard C++ utilise beaucoup de fonctionnalités avancées de l'OS qui ne sont pas disponibles.
uSTL est donc une implémentation plus légère et beaucoup plus abordable d'une partie de cette lib standard
En quelques mots : En quelques mots : Slyvtt débloque des outils que les programmeurs C++ ont l'habitude d'utiliser mais qui n'étaient pas disponibles dans nos add-ins..
Dans l'état actuel, Slyvtt a réussi à compiler et utiliser la version 2.3 de uSTL, ouvrant la possibilité d'utiliser les Lists, les Vectors, les Strings et bien d'autres fonctions que vous pouvez voir dans le github.
Et pourquoi ne pas utiliser la dernière version 3.0 ?
Parce que ce n'est pas la même affaire ! Après de nombreux tests, Slyvtt n'a pas réussi à utiliser cette version malgré une compilation correcte. La faute aux exceptions, provoquant des problèmes au linkage de la librairie.
Slyvtt, a également posté ses retours d'utilisation dans un message très intéressant pour les futurs développeurs C++ pour gint.
Il s'agit simplement d'un mini-tutoriel d'utilisation du port de la librairie. Tu es en train de voler mon travail !
En tout cas, les résultats sont là. Ils sont très encourageants pour la suite et ouvrent enfin la perspective de développement en C++ pour gint, enfin de l'objet de qualité ! (@Yatis tu aimes ce langage non ? )
Évidemment il s'agit là encore des tests, des erreurs peuvent être trouvées et je vous invite donc à partager vos impressions sur le topic du projet.
Bon, plus que 2 articles et cette revue est terminée. Parlons à présent de KikooDX qui, fidèle à lui même se lance dans un n-ième éditeur de niveau lance dans un projet très intéressant !
Tout d'abord un peu de contexte :
Il fait froid, le vent souffle dehors. Vous êtes seul chez vous et vous ne savez pas quoi faire...
Un de vos amis développe des jeux pour calculatrice, cependant vous ne possédez que des TI et êtes la risée du lycée. On vous appelle L'AUTRE ou même L'INTRU...
Mais une lueur d'espoir déteint sur votre visage quand votre ami vous annonce cette nouvelle :
Je suis d'accord avec vous, cette situation n'arrive pas souvent. Seulement 2-3 fois par semaine mais rien de bien méchant. Enfin bref, vous l'aurez compris KikooDX est en train de développer un petit framework pour avoir un support SDL2 et gint.
SDL2 est une librairie graphique utilisable entre autres sur nos ordinateurs. Cela vous permet donc de développer votre jeu et de tester directement sur votre ordinateur, plus besoin de transférer !
Vous pouvez également envoyer le jeu à des personnes ne possédant pas ce modèle de calculatrice. Problème récurant et frustrant compte tenu du temps de développement de certains projets.
Depuis la création du topic, LZY a pu obtenir plusieurs améliorations :
Support de tileset Support du texte (Police fixe dans l'état actuel) Support de l'audio (Parce que pourquoi pas ?) Des fonctions de dessin (Rectangle, Ligne, Point)
Actuellement, KikooDX estime l'API utilisable pour un projet de moyenne taille. Si vous souhaitez porter un Dumb Clicker calculatrice et ordinateur, c'est largement faisable à présent
Mais exactement quelles sont les fonctions utilisables et où puis-je trouver un code d'exemple ?
Le projet n'en est qu'au début, et la moindre des choses que nous pouvons dire : C'est très bien parti ! KikooDX nous a habitué à fournir des utilitaires de qualité, je suis sûr que LZY va s'imposer comme LA solution pour faire un support efficace entre les deux plateformes.
Bon courage pour la suite du projet, as-tu une idée de fonctions à implémenter par la suite ? As-tu un jeu en développement avec ton outil ?
Une chose est sûre, si vous souhaitez en apprendre davantage (exemple de code et changelog) sur ce projet intéressant, je vous invite à vous rendre sur le topic du projet, indiqué en gros comme d'habitude :
Et nous arrivons à notre dernier article, de notre rédacteur sans trop de rédaction : Potter360 (sans rancune, ne le prends pas de manière agressive).
Potter n'est pas un habitué des revues, aujourd'hui il arrive avec son dernier projet en date, au nom bien trouvé : RUB3R. Point bonus pour ce jeu de mot que j'apprécie beaucoup.
En quoi consiste RUB3R ? Eh bien il s'agit d'une implémentation moche selon l'auteur, d'un moteur 3D programmé en C-Basic.
Un moteur 3D programmé en Basic c'est ambitieux. Et de ce que Potter nous montre, les résultats sont encourageants !
Impressionnant, ce moteur a été programmé sans aucune vraie connaissance en 3D, cela implique donc quelques remarques sur le code que les plus ambitieux ont expliqué dans des commentaires très intéressants.
Évidemment la programmation d'un moteur 3D n'est pas une tâche simple, encore moins lorsque l'on part de presque rien. Il y a un large vocabulaire à interpréter, de nombreuses méthodes à implémenter et surtout beaucoup de temps à y consacrer. Je ne peux que te souhaiter bon courage pour la suite Potter, le rendu est très propre pour l'instant
Si vous souhaitez encourager Potter360 dans son projet ambitieux, je vous invite à aller sur la page du topic disponible ci-dessous :
Et c'est sur ce projet que nous nous quittons cette semaine / mois. Encore désolé pour le retard accumulé par le manque de temps de mon côté. Et bien sûr, le forum n'attend pas la revue pour avancer !
Merci d'être actif et productif, le forum compte sur vous pour dynamiser les échanges
Voilà qui termine cette revue mensuelle, les habitudes ne changent pas : À bientôt sur Planète Casio
Yo,
voilà une bien belle revue de projets.
Merci beaucoup Tituya.
C'est cool de voir que plein de projets avancent bien , même si du coup ça donne plein de taf aux rédacteurs.
Nota : peut-être que pour vous faciliter la tâche on pourrait demander aux programmeurs d'écrire un petit paragraphe sur leur projet. Pour ma part, pas de problème pour aider à la rédaction.
Je vais essayer de répondre à quelques points/questions sur les deux projets du moment pour moi, en commençant par le moins sexy des deux, mais il y a une raison à cet ordre, vous allez comprendre rapidement ...
µSTL pour Graph 90+E
Comme évoqué par Tituya, je viens à la base du monde TI (nSpire en l'occurrence) où le C++ est particulièrement bien supporté via la toolchain Ndless. En particulier la STL est vraiment très bien supportée et offre donc de très grandes facilités de programmation.
J'étais un peu frustré sur la Graph 90+E, car pour un certain nombre de concepts, l'absence de STL oblige à tout se "repalucher" . Par exemple pour faire une liste chainée d'entité, et bien il faut se refaire tout le code qui va gérer cette liste chainée. Faisable, mais pas le plus intéressant du monde, on est tous pareils, on préfère largement travailler sur le code du jeux qui veut faire que sur la tripaille interne nécessaire au fonctionnement (même si certains aiment bien ça )
D'où l'idée de tenter de se doter de la STL sur la Graph 90 (désolé j'ai que cette machine, donc je ne sais pas développer sur autre chose à ce jour, mais dans l'absolu ça doit être possible moyennant les bonnes options de compilation).
Aujourd'hui, ça fonctionne avec la v2.3 sachant que la v3.0 est sortie il y a peu. Le but ultime est d'avoir cette dernière version fonctionnelle, mais c'est visiblement un gros gros boulot (qui va peut être même nécessiter des modifs/ajouts dans gint/fxlibc, donc chez Lephé et les "Costauds" ...).
Pour ceux qui veulent utiliser, vous pouvez passer par giteapc, mais updater gint et fxlibc en @dev
Donc ce projet de jeu de course repose dans sa dernière mouture sur du code qui utilise la µSTL (et voilà pourquoi j'ai commencé par l'autre projet)
En particulier, le code est fait pour fonctionner avec une construction "pilotée" des circuits. Le circuit de test est par exemple construit en utilisant quelques méthodes de base :
et tout est empilé dans un std::vector<> afin de pouvoir facilement (et rapidement) piocher les éléments à afficher à l'instant 't'.
Pour répondre à la question de Tituya : oui il sera possible d'envisager un éditeur de circuit, le code est suffisamment ouvert pour ça, même si pour être tout à fait honnête j'ai pas encore réfléchit à la forme que ça prendrait, notamment si c'est via un éditeur ou dans une partie "on-game" sur la 'caltosse'
Parmi les trucs que j'ai en tête et que j'aimerai bien voir (on va dire que c'est la TODO list de mes objectifs) :
- tout d'abord ajouter le traffic avec les voitures à éviter
- bien affiner les graphismes, trouver les bons équilibres des tailles de sprites, leur nombre, leur positionnement de manière à obtenir les bons compromis entre taille d'addin/mémoire disponible/vitesse de rendu et aspect esthétique du jeu .
- créer différents environnements avec les sprites adhoc et les "color schemes" adaptés par exemple un environnement assez vert avec des arbres comme actuellement, puis un mode désertique avec des cactus et les bordures de route plutôt dans les tons de sable/ocre). D'ailleurs je suis preneur d'idées d'environnements (je sais pas, hivernal, sunset, nuit .... )
- rajouter des sprites de ciel/nuage avec parallaxe (si ca flingue pas le framerate bien sûr )
- idéalement j'aimerai aussi avoir des concurrents (qui se battent pour la "win") avec une IA un peu chiadée.
...
- et une interface propre, avec des beaux menus et des options ;D , parce que là y'a zéro interface, c'est le néant total...
Bref, pas mal d'idées, en espérant pouvoir (et surtout savoir) tout faire.
J'espère pouvoir avancer progressivement sur le projet et je ne manquerai pas de faire des MàJ dans le topic
@+
Sly
There are only 10 types of people in the world: Those who understand binary, and those who don't ...
Wow, quelle RDP. Je pense qu'on a battu un record franchement. x)
Il me fallait un moyen de calculer le niveau des monstres rencontrés. C'est pour cette raison que j'ai ajouté un système de zone sur la carte. Grâce à Tiled et ses rectangles, il est très facile de mettre le niveau moyen dans une zone ainsi que de préciser l'identifiant des monstres pouvant apparaître
Pas mal ! Je ne me souviens plus comment tu fais ta conversion. Est-ce que lis directement le CSV, utilises une lib, quelque chose du style ? Comme je me sers aussi de Tiled pour Rogue Life je me demande si y'aurait pas un "cadre général" à dégager qui pourrait être natif dans fxconv et simplifier ce genre d'intégration.
Le framerate semble constant. Dans les alentours de 30-40ips, les optimisations et les efforts ont valu le coup !
Oui c'est super fluide ! Bien joué. Le seul truc qui m'étonne c'est le fait qu'on ne tourne pas, quand il y a des virages la voiture tourne toute seule.
-
Le screen de Rogue Life que tu as utilisé est très vieux et plus vraiment représentatif du jeu, ce qui me rappelle que j'ai pas publié de vidéo depuis bien longtemps. Ça arrive, promis !
Le framerate semble constant. Dans les alentours de 30-40ips, les optimisations et les efforts ont valu le coup !
Oui c'est super fluide ! Bien joué. Le seul truc qui m'étonne c'est le fait qu'on ne tourne pas, quand il y a des virages la voiture tourne toute seule.
Oui à ce stade c'est normal, car la mécanique de décalage de la coordonnée X n'est pas implémentée. Donc la voiture reste bien gentiment en 'autopilote' au milieu de la piste. Mais ça va évoluer, notamment dans les virages où la force centrifuge va envoyer dans le décor
There are only 10 types of people in the world: Those who understand binary, and those who don't ...
Lephenixnoir a écrit : Pas mal ! Je ne me souviens plus comment tu fais ta conversion. Est-ce que lis directement le CSV, utilises une lib, quelque chose du style ? Comme je me sers aussi de Tiled pour Rogue Life je me demande si y'aurait pas un "cadre général" à dégager qui pourrait être natif dans fxconv et simplifier ce genre d'intégration.
J'exporte la carte en JSON avant de la parse de manière un peu sale. Je fixe le nom du layer afin de savoir à quel moment l'interpréter.
Je parcours la liste des layers jusqu'à trouver celle avec le nom correspondant et appliquer la conversion appropriée. (hardcodé en fonction du nom du paramètre).
for layer in objectLayers:
if layer.get("name") == DIALOG_LAYOUT:
nbDialog = len(layer["objects"])
dialogs = parseDialog(layer)
elif layer.get("name") == TELEPORTER_LAYOUT:
nbTelep = len(layer["objects"])
teleporter = parseTeleporter(layer)
elif layer.get("name") == ZONE_LAYOUT:
nbZone = len(layer["objects"])
zone = parseZone(layer)
else:
print("UNKNOWN LAYER FOUND : " + layer.get("name"))
Honnêtement, ma manière de convertir n'est pas très propre, j'ai vu qu'il existait un module tiled pour python il a peut-être moyen de faire quelque chose de sympa avec.
Lephenixnoir a écrit : Le screen de Rogue Life que tu as utilisé est très vieux et plus vraiment représentatif du jeu, ce qui me rappelle que j'ai pas publié de vidéo depuis bien longtemps. Ça arrive, promis !
En effet, j'avais prévu de prendre une capture avec fxlink. Je n'ai juste pas pris le temps en rédigeant la fin de la revue hier à 1h du matin
Concernant Adoranda, je n'ai pas continué. L'un de mes prochains objectif est d'implémenter les dialogues une bonne fois pour toutes. En effet l'algo actuel marche vraiment mal et est très peu optimisé, pas l'idéal :E.
Bretagne > Reste du globe
(Et de toute façon, vous pouvez pas dire le contraire)
Merci pour cette RDP qualitative Tituya, je sais que c'était pas évident
Et bon courage à tous les créateurs, les projets sont tous très cools !
Tituya a écrit : Bon courage pour la suite du projet, as-tu une idée de fonctions à implémenter par la suite ? As-tu un jeu en développement avec ton outil ?
Merci ! je vais sûrement continuer en implémenter ce qu'il manque au fur et à mesure, tout en restant dans le minimalisme du framework. La plupart des changements se feront sûrement sans ajouts en surface -- je suis en train de programmer les paths relatifs ce matin par exemple, aucun changement en surface mais ça permet d'exécuter le jeu de n'importe où.
Un jeu est bien en développement, je participe à la 7DRL 2022 en partenariat avec Masséna Je partagerai le build FXCG50 ici une fois la jam terminée (d'ici 4-5 jours).
Wow, cette RDP xD
Merci pour mon petit passage dans la RDP !
RUB3R est en train de vraiment changer depuis la dernière update, je suis en fait en train d’implémenter l’axe Z et un nouveau moyen d’utiliser le moteur (spoil : c’est fait. Mais je galère sur les textures.)
Sinon les autres projets sont super cool, et sur la forme cette RDP est vraiment de qualité. Merci <3
Je ne passe pas très souvent mais j'essaie de rester quand même au courant de ce qu'il se passe et ça faisait longtemps que j'avais pas été autant impressionné et par autant de projets, ils sont tous super impressionnant ! J'imagine que ça confirme aussi les progrès sur les outils et environnements à disposition pour développer des projets. Et à voir uSTL et LZY (depuis le temps qu'on veut un truc comme ça qui tienne bien la route ), ça a l'air bien parti pour ne pas s'arrêter ! Et puis Rogue Life ça a l'air d'être la classe internationale quand même !
Petite point qui a attrapé ma curiosité (il y a sans doute une réponse toute prête typée RTFM quelque part, mais je ne suis pas tout à fait au courant d'où trouver ça) :
Depuis le projet a pu avancer, Slyvtt grâce à l'aide de Lephenixnoir et du merveilleux gint a récemment pu profiter de l'upscale d'image afin de réduire considérablement la taille de l'add-in
Ça consiste en quoi l'upscale d'image ? C'est des routines qui permettent de manière assez transparente d'écrire dans une VRAM "plus petite" et qui est intelligemment agrandie au moment de l'affichage ? Ou bien c'est à l'échelle des textures du jeu qui peuvent être stockées en petit et intelligemment appliquée sur des grandes surfaces avec l'agrandissement qui va bien ?
Merci pour la RDP en tout cas, c'est trop cool de voir tout ça, et d'avoir un peu de contexte, d'introduction et tout autour des projets ! Ça aide clairement à suivre ce qu'il se passe dans la commu du coin de l'œil
Ça consiste en quoi l'upscale d'image ? C'est des routines qui permettent de manière assez transparente d'écrire dans une VRAM "plus petite" et qui est intelligemment agrandie au moment de l'affichage ? Ou bien c'est à l'échelle des textures du jeu qui peuvent être stockées en petit et intelligemment appliquée sur des grandes surfaces avec l'agrandissement qui va bien ?
Ici c'est juste une fonction qui alloue une nouvelle image dans la RAM et fait un coup de nearest-neighbor dessus (pas de mélange de couleurs vu que c'est sur une palette). C'est précalculé parce que faire cette opération à l'affichage serait assez (trop) coûteux en perfs.
Écrire dans une VRAM plus petite ça ne servirait pas à "grand-chose" parce que de base pour envoyer à l'écran (via DMA) il faut de toute façon matérialiser la surface complète. Par contre il y a des moyens (avec d'autres drivers écran) de faire un upscaling genre 2:2 ou 3:3 à la volée et de rester véritablement à une résolution plus petite ; cela dit, c'est encore expérimental.
Oh d'acc, je vois ! Effectivement, en posant la question je pensais surtout à des routines à-la DMA (ou niveau driver) qui pourraient gérer un upscale (avec les bons ratios évidemment) au moment du transfert vers l'écran.
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
À présent il y a un taux de réussite aux attaques. Une précision.
Citer : Posté le 07/03/2022 10:23 | #
Yo,
voilà une bien belle revue de projets.
Merci beaucoup Tituya.
C'est cool de voir que plein de projets avancent bien , même si du coup ça donne plein de taf aux rédacteurs.
Nota : peut-être que pour vous faciliter la tâche on pourrait demander aux programmeurs d'écrire un petit paragraphe sur leur projet. Pour ma part, pas de problème pour aider à la rédaction.
Je vais essayer de répondre à quelques points/questions sur les deux projets du moment pour moi, en commençant par le moins sexy des deux, mais il y a une raison à cet ordre, vous allez comprendre rapidement ...
µSTL pour Graph 90+E
Comme évoqué par Tituya, je viens à la base du monde TI (nSpire en l'occurrence) où le C++ est particulièrement bien supporté via la toolchain Ndless. En particulier la STL est vraiment très bien supportée et offre donc de très grandes facilités de programmation.
J'étais un peu frustré sur la Graph 90+E, car pour un certain nombre de concepts, l'absence de STL oblige à tout se "repalucher"
D'où l'idée de tenter de se doter de la STL sur la Graph 90 (désolé j'ai que cette machine, donc je ne sais pas développer sur autre chose à ce jour, mais dans l'absolu ça doit être possible moyennant les bonnes options de compilation).
Aujourd'hui, ça fonctionne avec la v2.3 sachant que la v3.0 est sortie il y a peu. Le but ultime est d'avoir cette dernière version fonctionnelle, mais c'est visiblement un gros gros boulot (qui va peut être même nécessiter des modifs/ajouts dans gint/fxlibc, donc chez Lephé et les "Costauds" ...).
Pour ceux qui veulent utiliser, vous pouvez passer par giteapc, mais updater gint et fxlibc en @dev
giteapc install -u Lephenixnoir/gint@dev Vhex-Kernel-Core/fxlic@dev SlyVTT/uSTL_2.3
C'est encore assez trappu de faire un addin avec, le mieux est de partir avec le template ad-hoc disponible ici:
Template projet C++ µSTL2.3 pour Graph 90+E
Du coup concernant le second projet :
Outrun
Donc ce projet de jeu de course repose dans sa dernière mouture sur du code qui utilise la µSTL (et voilà pourquoi j'ai commencé par l'autre projet)
En particulier, le code est fait pour fonctionner avec une construction "pilotée" des circuits. Le circuit de test est par exemple construit en utilisant quelques méthodes de base :
addStraightLine( L_VERYSHORT );
addStraightLine( L_VERYSHORT );
addCurve( L_SHORT, C_EASY, LEFT_CURVE );
addHill( L_MEDIUM, H_BIG, UP_HILL );
addCurve( L_SHORT, C_HARD, RIGHT_CURVE );
addStraightLine( L_LONG );
et tout est empilé dans un std::vector<> afin de pouvoir facilement (et rapidement) piocher les éléments à afficher à l'instant 't'.
Pour répondre à la question de Tituya : oui il sera possible d'envisager un éditeur de circuit, le code est suffisamment ouvert pour ça, même si pour être tout à fait honnête j'ai pas encore réfléchit à la forme que ça prendrait, notamment si c'est via un éditeur ou dans une partie "on-game" sur la 'caltosse'
Parmi les trucs que j'ai en tête et que j'aimerai bien voir (on va dire que c'est la TODO list de mes objectifs) :
- tout d'abord ajouter le traffic avec les voitures à éviter
- bien affiner les graphismes, trouver les bons équilibres des tailles de sprites, leur nombre, leur positionnement de manière à obtenir les bons compromis entre taille d'addin/mémoire disponible/vitesse de rendu et aspect esthétique du jeu
- créer différents environnements avec les sprites adhoc et les "color schemes" adaptés par exemple un environnement assez vert avec des arbres comme actuellement, puis un mode désertique avec des cactus et les bordures de route plutôt dans les tons de sable/ocre). D'ailleurs je suis preneur d'idées d'environnements (je sais pas, hivernal, sunset, nuit .... )
- rajouter des sprites de ciel/nuage avec parallaxe (si ca flingue pas le framerate bien sûr
- idéalement j'aimerai aussi avoir des concurrents (qui se battent pour la "win") avec une IA un peu chiadée.
...
- et une interface propre, avec des beaux menus et des options ;D , parce que là y'a zéro interface, c'est le néant total...
Bref, pas mal d'idées, en espérant pouvoir (et surtout savoir) tout faire.
J'espère pouvoir avancer progressivement sur le projet et je ne manquerai pas de faire des MàJ dans le topic
@+
Sly
Citer : Posté le 07/03/2022 11:41 | #
Wow, quelle RDP. Je pense qu'on a battu un record franchement. x)
Pas mal ! Je ne me souviens plus comment tu fais ta conversion. Est-ce que lis directement le CSV, utilises une lib, quelque chose du style ? Comme je me sers aussi de Tiled pour Rogue Life je me demande si y'aurait pas un "cadre général" à dégager qui pourrait être natif dans fxconv et simplifier ce genre d'intégration.
Oui c'est super fluide ! Bien joué. Le seul truc qui m'étonne c'est le fait qu'on ne tourne pas, quand il y a des virages la voiture tourne toute seule.
-
Le screen de Rogue Life que tu as utilisé est très vieux et plus vraiment représentatif du jeu, ce qui me rappelle que j'ai pas publié de vidéo depuis bien longtemps. Ça arrive, promis !
Citer : Posté le 07/03/2022 11:47 | #
Oui c'est super fluide ! Bien joué. Le seul truc qui m'étonne c'est le fait qu'on ne tourne pas, quand il y a des virages la voiture tourne toute seule.
Oui à ce stade c'est normal, car la mécanique de décalage de la coordonnée X n'est pas implémentée. Donc la voiture reste bien gentiment en 'autopilote' au milieu de la piste. Mais ça va évoluer, notamment dans les virages où la force centrifuge va envoyer dans le décor
Citer : Posté le 07/03/2022 12:04 | #
Pas mal ! Je ne me souviens plus comment tu fais ta conversion. Est-ce que lis directement le CSV, utilises une lib, quelque chose du style ? Comme je me sers aussi de Tiled pour Rogue Life je me demande si y'aurait pas un "cadre général" à dégager qui pourrait être natif dans fxconv et simplifier ce genre d'intégration.
J'exporte la carte en JSON avant de la parse de manière un peu sale. Je fixe le nom du layer afin de savoir à quel moment l'interpréter.
Je parcours la liste des layers jusqu'à trouver celle avec le nom correspondant et appliquer la conversion appropriée. (hardcodé en fonction du nom du paramètre).
if layer.get("name") == DIALOG_LAYOUT:
nbDialog = len(layer["objects"])
dialogs = parseDialog(layer)
elif layer.get("name") == TELEPORTER_LAYOUT:
nbTelep = len(layer["objects"])
teleporter = parseTeleporter(layer)
elif layer.get("name") == ZONE_LAYOUT:
nbZone = len(layer["objects"])
zone = parseZone(layer)
else:
print("UNKNOWN LAYER FOUND : " + layer.get("name"))
Honnêtement, ma manière de convertir n'est pas très propre, j'ai vu qu'il existait un module tiled pour python il a peut-être moyen de faire quelque chose de sympa avec.
Le screen de Rogue Life que tu as utilisé est très vieux et plus vraiment représentatif du jeu, ce qui me rappelle que j'ai pas publié de vidéo depuis bien longtemps. Ça arrive, promis !
En effet, j'avais prévu de prendre une capture avec fxlink. Je n'ai juste pas pris le temps en rédigeant la fin de la revue hier à 1h du matin
Concernant Adoranda, je n'ai pas continué. L'un de mes prochains objectif est d'implémenter les dialogues une bonne fois pour toutes. En effet l'algo actuel marche vraiment mal et est très peu optimisé, pas l'idéal :E.
(Et de toute façon, vous pouvez pas dire le contraire)
MultipliCasio
RDM Calculs
Back Mirror
A Switch To The Top C
Citer : Posté le 07/03/2022 13:01 | #
Merci pour cette RDP qualitative Tituya, je sais que c'était pas évident
Et bon courage à tous les créateurs, les projets sont tous très cools !
Bon courage pour la suite du projet, as-tu une idée de fonctions à implémenter par la suite ? As-tu un jeu en développement avec ton outil ?
Merci ! je vais sûrement continuer en implémenter ce qu'il manque au fur et à mesure, tout en restant dans le minimalisme du framework. La plupart des changements se feront sûrement sans ajouts en surface -- je suis en train de programmer les paths relatifs ce matin par exemple, aucun changement en surface mais ça permet d'exécuter le jeu de n'importe où.
Un jeu est bien en développement, je participe à la 7DRL 2022 en partenariat avec Masséna
Citer : Posté le 07/03/2022 19:00 | #
Wow, cette RDP xD
Merci pour mon petit passage dans la RDP !
RUB3R est en train de vraiment changer depuis la dernière update, je suis en fait en train d’implémenter l’axe Z et un nouveau moyen d’utiliser le moteur (spoil : c’est fait. Mais je galère sur les textures.)
Sinon les autres projets sont super cool, et sur la forme cette RDP est vraiment de qualité. Merci <3
Citer : Posté le 07/03/2022 21:57 | #
Mais c'est que ça en jette tous ces projets là :o
Je ne passe pas très souvent mais j'essaie de rester quand même au courant de ce qu'il se passe et ça faisait longtemps que j'avais pas été autant impressionné et par autant de projets, ils sont tous super impressionnant ! J'imagine que ça confirme aussi les progrès sur les outils et environnements à disposition pour développer des projets. Et à voir uSTL et LZY (depuis le temps qu'on veut un truc comme ça qui tienne bien la route
Petite point qui a attrapé ma curiosité (il y a sans doute une réponse toute prête typée RTFM quelque part, mais je ne suis pas tout à fait au courant d'où trouver ça) :
Ça consiste en quoi l'upscale d'image ? C'est des routines qui permettent de manière assez transparente d'écrire dans une VRAM "plus petite" et qui est intelligemment agrandie au moment de l'affichage ? Ou bien c'est à l'échelle des textures du jeu qui peuvent être stockées en petit et intelligemment appliquée sur des grandes surfaces avec l'agrandissement qui va bien ?
Merci pour la RDP en tout cas, c'est trop cool de voir tout ça, et d'avoir un peu de contexte, d'introduction et tout autour des projets ! Ça aide clairement à suivre ce qu'il se passe dans la commu du coin de l'œil
Citer : Posté le 07/03/2022 22:01 | #
Salut Nemh' !
Ici c'est juste une fonction qui alloue une nouvelle image dans la RAM et fait un coup de nearest-neighbor dessus (pas de mélange de couleurs vu que c'est sur une palette). C'est précalculé parce que faire cette opération à l'affichage serait assez (trop) coûteux en perfs.
Écrire dans une VRAM plus petite ça ne servirait pas à "grand-chose" parce que de base pour envoyer à l'écran (via DMA) il faut de toute façon matérialiser la surface complète. Par contre il y a des moyens (avec d'autres drivers écran) de faire un upscaling genre 2:2 ou 3:3 à la volée et de rester véritablement à une résolution plus petite ; cela dit, c'est encore expérimental.
Citer : Posté le 07/03/2022 22:13 | #
Oh d'acc, je vois ! Effectivement, en posant la question je pensais surtout à des routines à-la DMA (ou niveau driver) qui pourraient gérer un upscale (avec les bons ratios évidemment) au moment du transfert vers l'écran.