Posté le 09/08/2024 14:57
!
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 124 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
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
Citer : Posté le 09/08/2024 14:59 | #
Excellent ! Je les intégrerai bien tu-sais-où si jamais c'est une option.
Puisque ça en discute récemment, y'a aussi des fonctions de trigo/aléatoire pour libnum dans différents projets, e.g. https://git.planet-casio.com/Yatis-Lephe-Industries/BosonX/src/branch/main/src/util.cpp qui seront intégrées dès que j'aurai pris le temps d'évaluer la qualité des approximations et la précision.
Citer : Posté le 09/08/2024 15:01 | #
Je pense que les tiennes sont meilleures
Citer : Posté le 09/08/2024 15:02 | #
Tu peux aussi trouver qq trucs utiles ici : https://git.planet-casio.com/Slyvtt/3DEngine/src/branch/master/src/3dengine
il y a des fonctions de calculs de COS/SIN/TAN/SQRT en num16 et num32 ainsi que des fonctions de calculs matriciels en num16 aussi.
Citer : Posté le 09/08/2024 15:03 | #
En fait on a plein de trucs dans tous les coins...
Citer : Posté le 09/08/2024 18:07 | # |
Fichier joint
Le rendu est fonctionnel ! J'utilise AUCUN float
Par contre l'addin fait 8,1 Ko, ça pique.
Citer : Posté le 09/08/2024 22:06 | # |
Fichier joint
Update !
On peut maintenant bouger le vaisseau et il y a un champ d'étoiles (des points projetés en 3D, donc c'est un jeu avec 100% de la "vraie" 3D).
Citer : Posté le 09/08/2024 23:12 | # |
Fichier joint
Bon, je vais m'arrêter là pour aujourd'hui :
Je sui assez content de mon écran de titre, il prend peu de place et marche plutôt bien.
Citer : Posté le 10/08/2024 15:00 | # |
Fichier joint
Faut que j'ajoute les collisions et après tout marche
J'ai dû réduire la qualité de la vidéo cette fois ci.
Citer : Posté le 10/08/2024 16:37 | #
Salut, pour ton projet je pense que tu n'as pas besoin d'utiliser des fonctions trigonométriques à chaque frame.
Je m'explique:
Le vaisseau semble avoir 5 états:
• dirigé en face
• dirigé vers la droite
• dirigé vers la gauche
• dirigé vers le haut
• dirigé vers le bas.
Étant donné que l'état dirigé vers la droite est le symétrique de celui pour la gauche et de même pour haut et bas, on peut précalculer les positions relative des points du vaisseau vis à vis du centre de ce dernier permettant ainsi de stocker uniquement 3 états. C'est ce qui est fait par exemple dans mon jeu Dé à coudre. Si tu souhaites faire des animations plus fluides il sera nécessaire de passer par les fonctions trigonométriques.
Pour ce qui est de la caméra, si aucune rotation n'est effectuée sur elle, il est préférable d'omettre celles ci dans les formules de projection de points: on passe de
xs=((x*cos(a)-y*sin(a))/((x*sin(a)+y*cos(a))*cos(b)+z*sin(b))+0.5)*k pour la première composante de la position d'un point projeté sur l'écran soumis à deux rotations (axe x et z ici) à
xs=(x/y+0.5)*k pour un point sans rotation. (pas sûr pour les formules mais la complexité est là)
Pour les rendu en fil de fer ça rend bien mais si tu souhaites former plutôt des triangles remplis tu peux t'intéresser aux algos de rastérisations: le triangle est formé à partir d'une liste de lignes horizontales qui peuvent être combiné à des méthodes de dithering pour créer l'illusion d'afficher plusieurs couleurs. Tu peux combiner cette méthode avec du back face culling: si les points du triangles sont projetés dans le sens horaire alors cela signifie qu'on regarde la face arrière du triangle qui n'a pas lieu d'être affichée. Cette méthode à elle seule permet d'afficher correctement des formes convexes comme ici avec le tétraèdres et les pyramides à base carré.
Le soucis réside maintenant dans l'ordre d'affichage: l'approche correcte serait d'utiliser un Z buffer (un tableau qui enregistre la profondeur de chaque pixel vis à vis de la caméra ce qui permet de comparer celle du triangle que l'on souhaite dessiner avec ceux déjà dessinés afin de prendre la plus petite valeur et donc d'afficher où non le pixel s'il est derrière ceux déjà affichés) mais elle est couteuse en performance car il faut interpoler les valeurs de la profondeur en fonction de leur inverse (ce qui implique une division pour chaque pixel à afficher pour chaque triangle) et elle est aussi couteuse au niveau de la mémoire de la calculatrice (8192 * n bits de précision).
Tu peux aussi afficher chaque triangle dans l'ordre décroissant de la profondeur de leur barycentre vis à vis de la caméra mais ça peut causer certains problèmes visuels et demande un petit peu de ressource quand même. L'avantage du fil de fer c'est qu'il n'est pas nécessaire de trier quoi que ce soit car toutes les lignes sont de la même couleur donc que l'une soit dessinée avant l'autre ou inversement ça ne change strictement rien.
Pour les collisions tu peux soit prendre une approche avec des boîtes de collisions (pavé droit englobant l'élément), cette approche est moins couteuse car il suffit juste de vérifier si l'un des points de la boite l'objet 1 se situe dans les bornes de la boite de l'objet 2 pour vérifier si il y a une collision. Cette approche est néanmoins peu précise et cause beaucoup de faux positifs mais reste préférable dans des jeux qui ne base pas l'entièreté de leur gameplay dessus.
La seconde approche est plus précise mais plus couteuse et plus complexe d'un point de vue mathématique. Tu peux vérifier s'il y a une intersection entre chaque triangle du vaisseau et chaque triangle des obstacles. Dans le cas de deux triangles (T1: ABC et T2: A'B'C'), on peux trouver le point d'intersection entre les 3 droites passant par les points du triangle: (AB), (BC) et (CA) et le plan passant par T2 (pour le vecteur normal au plan passant par T2, étant donné que les droites (AB) et (AC) ne sont pas parallèles et donc que les vecteurs AB et AC sont non colinéaires en plus d'être deux vecteurs directeurs du plan, le vecteur normal peut être calculé à l'aide du produit vectoriel entre les vecteurs AB et AC mais il est préférable de le normer pour les calculs suivants et il est peut être préférable de vérifier les intersections avec aussi le vecteur opposé au vecteur normal créé mais pas sur pour ça), ensuite on vérifie si le point d'intersection appartient aux segments: (si le point d'intersection I pour le segment [AB] par exemple s'écrit sous la forme I=A+(vecteur AB)*t avec t appartenant à l'intervalle [0;1]) et on vérifie aussi si le point d'intersection appartient à T2 à l'aide des coordonnées barycentriques (ici si on prend u, v et w 3 réels tel que I=u*A'+v*B'+w*C', alors I appartient à T2 si et seulement si u, v et w appartiennent à l'intervalle [0;1] et u+v+w=1). Ensuite on fait de même mais on inverse T1 et T2 et puis on répète l'opération pour chaque triangle dont il faut vérifier les collisions ce qui peut vite bouffer toute les performances de la machine. Si les deux conditions sont remplies pour un des segments alors on peut dire qu'il y a une collision mais sinon on peut continuer à effectuer des tests. Si aucun test n'est concluant alors il n'y a pas de collision.
Ici le soucis c'est que le nombre de tests à effectuer augmente très vite donc il est préférable de combiner cette méthode avec celle de la boite de collision (s'il aucune collision n'est détectée entre les boites alors il est inutiles d'aller plus loin car il n'y aura aucune collision entre les triangles). Ici la première approche reste préférable d'un point de vue performance. Il faut tout de même faire attention à la vitesse du vaisseau: si entre deux images le vaisseau effectue un déplacement vers l'avant plus grand que la largeur du triangle alors ce dernier peut traverser le triangle sans qu'aucune collision ne soit détectée car les deux méthode vérifie les collisions entre deux objets à un unique instant t sans prendre en compte un vecteur déplacement. Il est possible d'éviter ceci à l'aide de calculs supplémentaires mais il est inutile de les effectuer quand la vitesse de rafraichissement du jeu est plus qu'assez fluide comme dans l'extrait présenté ici.
Enfin tu pourrais afficher aussi la ligne d'horizon qui sépare les étoiles du sol. Dans le cas où aucune rotation sur l'axe y n'est effectuée vis à vis de la caméra, tu peux trouver sa position y sur l'écran avec la formule (0.5-tan(b))*k avec k ton coefficient multiplicateur pour redimensionner les lignes et b l'angle de rotation sur l'axe x. Si comme ici aucune rotation sur l'axe x n'est effectuée alors il est possible de dire que la ligne d'horizon se trouve toujours au centre de l'écran: c'est à dire en y=31 ou y=32 (la calculatrice à un nombre pair de pixel sur l'axe y donc il n'y a pas de valeur au milieu).
J'espère que c'est à peu près digeste et que c'est à peu près compréhensible afin de pouvoir aider un minimum.
J'espère aussi ne pas avoir dit de bêtises (notamment sur l'histoire des collisions) si j'ai fait des erreurs n'hésitez pas à me corriger
Citer : Posté le 10/08/2024 18:23 | #
Oui, je sais que je peux les précalculer, mais les perfs sont bonnes, donc, je l'optimiserais après, là c'est la capture qui le ralentit beaucoup, on calc c'est plus fluide. Au début j'avais commencé à coder un rasterizer, mais j'ai pas envie de passer très longtemps à coder ce jeu, donc je l'ai plutôt fait en wireframe (pour ne pas faire de Z-Buffering, de triangles remplis etc.). De plus, les triangles remplis rendraient la distinction des objets plus difficile (à part avec des textures, mais ça prendrait plus de temps à coder). Je cherchais juste à faire des graphismes assez sympa en réponse au loader de lephé qui va faciliter la création de demoscenes pour calculatrices, et je voulais montrer ce dont ma libraire est capable. J'ai déjà codé les collisions, avec des AABB effectivement. Je suis en train d'ajouter des effets de particules pour rendre le jeu un peu plus esthétique.
Citer : Posté le 10/08/2024 21:57 | #
Ok, en tout cas le fil de fer c'est joli, les effets de particules aussi et c'est impressionnant la fréquence d'image. Sinon je ne sais pas si tu as modifié l'écran titre mais la rotation me semble étrange: il semblerait que le centre de rotation se situe au millieu de l'arête en bas à l'arrière du vaisseau. Je ne sais pas si c'est voulu mais celà voudrait dire que sur l'axe y et z les coordonnées sont positives. L'idéal ça serait d'avoir des coordonnées relatives au centre géométrique du solide afin d'avoir une rotation centrée au milieu de l'objet.
Citer : Posté le 10/08/2024 22:13 | #
Vu que tu utilises des géométries simples, je te conseille de prendre une approche simple. Tu peux prendre le vecteur normal aux faces et vérifier avec un produits scalaire si la faces est visible ou pas, si oui tu la garde dans ta liste. Ensuite un simple tri sur la distance devrait le faire.
Citer : Posté le 10/08/2024 23:51 | #
J'ai pas prévu de cacher les faces, mais l'idée est cool. La rotation est voulue comme ça.
Citer : Posté le 11/08/2024 14:25 | #
J'ai tout fini, mais le système de particules ne marche pas... et faut que j'ajoute des commentaires parce que là il y en a un peu peu. Donc bientôt vous pourrez y jouer. Le jeu est très simple, j'ai des idées comment le rendre mieux mais la programmation on calc est vraiment très chronophage.
Citer : Posté le 11/08/2024 16:15 | # |
Fichier joint
Le jeu est fini !
Dépôt git : https://git.planet-casio.com/mibi88/racer3d
Citer : Posté le 11/08/2024 18:43 | #
J'ai enlevé la fonction tangente car le tableau prenait beaucoup de place et je ne l'utilisais pas. J'ai aussi ajouté une TODO list de trucs qui peuvent être améliorés, mais je ne pense pas que je vais les faire, j'ai envie de passer à autre chose. J'ai aussi ajouté plein de commentaires pour que ce soit facile à comprendre ce que je fais
Au passage, j'ai mis à jour le programme : j'ai ajouté un screenshot, marqué que ce jeu n'est que compatible sh4 (kcheck n'est que compatible sh4 actuellement), j'avais oublié de le préciser et j'ai ajouté un lien vers ce topic. Au passage je vais aussi mettre à jour le post principal.
Qu'est ce que vous en pensez de ce petit jeu, quel est votre hiscore
D'ailleurs est ce que quelqu'un pourrait tester si la sauvegarde du score marche sur des calculatrices sans Fugue, je n'ai qu'une Graph 35+e II et en théorie libMicrofx devrait être en mesure de créer des fichiers etc. sur des calculatrices sans Fugue, mais je ne peux pas tester et je ne sais plus si quelqu'un l'avait testé lorque je les avait ajoutés l'année dernière (wow ça fait longtemps).
Amusez vous bien !
Citer : Posté le 11/08/2024 20:32 | # |
Fichier joint
J'en ai fait un portage cg à la va vite avec gint, ça m'a beaucoup amusé
L'add-in est en pièce jointe.
Dépôt git : https://git.planet-casio.com/mibi88/racer3d_cg
Amusez vous bien !
Citer : Posté le 12/08/2024 13:31 | #
J'ai ajouté le g3a comme deuxième fichier au programme, mais du coup quand on cherche des programmes pour cg, on ne peut pas le trouver. Est ce que c'est mieux si je fais un deuxième programme pour la version g3a, ou c'est abusé parce que c'est littéralement le même programme mais pour la CG ?
Citer : Posté le 12/08/2024 14:14 | #
Le système de programmes de la v4 est mal fait de ce point de vue, comme c'est un défaut du site c'est parfaitement autorisé de poster en double.
Citer : Posté le 12/08/2024 14:18 | #
Ok, je ne voulais pas que ce soit considéré comme du spam. Ce serait cool de rendre ça possible dans la v5