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: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 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 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 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 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 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 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 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 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.

---