La Revue des Projets - 193
Posté le 25/10/2020 18:49
Bonjour !
Cela fait déjà près de 2 mois que je n'ai rien posté sur le forum, vous commenciez à me manquer !
On se retrouve pour notre nouvelle Revue des Projets, avec aujourd'hui 2 articles, sans plus tarder, on commence dès maintenant par un article de l'incontournable
Lephenixnoir
En effet, il nous montre aujourd'hui une mise à jour importante à propos de son fxSDK et de gint, permettant entre autre de faire des add-ins très facilement ! Un travail incroyable que mène notre cher administrateur préféré.
Lephenixnoir a écrit :Salut à tous ! J'ai plusieurs nouvelles importantes à propos du
fxSDK et de
gint, ces outils utilisés pour développer des add-ins sous Linux.
D'abord, c'est tout récent mais j'ai pu
porter la bibliothèque mathématique OpenLibm à l'improviste hier, ce qui nous donne accès aux fonctions de
<math.h> sans avoir à utiliser newlib. newlib est sympa mais assez lourd et je suis jamais sûr de si c'est stable. OpenLibm ne donne que les fonctions de calcul et pas le
%f dans les fonctions de dessin, mais j'y travaille !
Ensuite, il est probable que les efforts de gint sur la lib standard se concentrent dans le projet
FxLibC lancé par Yatis. On a des plans pour pas mal de fonctions standard (y compris les fichiers) donc il est probable que gint se rapproche beaucoup du standard fxlib.
Enfin et c'est le plus important, comme il y a toujours beaucoup de choses à compiler et à installer avant de pouvoir travailler avec gint, j'ai réfléchi avec Darks à quelques solutions pour rendre ça plus automatique pour tous ceux qui ne veulent pas trop toucher à Linux. Actuellement Darks maintient des paquets sur l'AUR (principalement
gint-devel-git) et c'est conceptuellement ce qu'il nous faut, sauf que ça ne couvre que les utilisateurs Arch/Manjaro et pas les gens qui utilisent Debian ou Ubuntu, notamment sous WSL. Je réfléchis à une solution cross-platform qui ne vous fera exécuter que deux/trois lignes de commande pour installer GCC, le fxSDK, gint, et les libs qui vont bien.
Toutes les nouveautés sont présentées comme d'habitude sur les topics de gint et du fxSDK, vous pouvez rattraper toutes les informations en les lisant. o/
Tout cela est très intéressant ! Les mises à jour de gint son très fréquentes tout en rajoutant à chaque fois des fonctionnalités très importantes. En l’occurrence, OpenLibm rajoute énormément de possibilités pour vous add-ins ! Et ça, ce n'est pas de refus ! Je vous invite donc à aller voir tout ça si la programmation d'add ins vous intéresse.
En plus,
Dark storm a publié il y a peu un script d'installation de gcc pour Ubuntu ! Rien de plus simple pour commencer !
Compiler sous Linux avec un cross-compilateur gcc
En plus de ça, nous pouvons remarquer la présence de gint dans de plus en plus d'add-ins ces derniers temps. Des projets l'utilisant, notamment un projet dévoilé hier par notre cher
Dark storm. Je vous invite à aller voir directement là bas :
Touhou !
Sans plus de bavardage, nous passons à notre deuxième annonce, par... moi
Tituya a écrit :Salut !
Vu que je suis en vacances, je voulais commencer un nouveau petit projet rapide. Quelque chose d'assez simple pour être réalisable en 1 semaine.
Rien de bien gros bien évidemment, et c'est en utilisant
gint bien évidemment. Et comble de tout ça, j'utilise la nouvelle lib annoncée plus haut par
Lephenixnoir
Il ne s'agit pas d'un jeu mais plus d'une démo de performance en soit. J'ai voulu tout simplement créer un
raycasting 2D sur ma 90+E.
Une sorte de simulation de lumière dans un espace plat.
Grâce à cette nouvelle lib, j'ai pu réussir à produire quelque chose de fonctionnel aujourd'hui, voilà plusieurs images avec des paramètres différents :
Niveau performance, ce n'est pas très bon. Cela dépend évidemment de la quantité de murs et des paramètres. Sur ces deux photos au dessus, je dois être dans les 8 fps sur celles du haut et 3 fps sur celle du bas avec overclock. Mais il faut savoir que ces images sont des tests avec des grandes valeurs.
Je suis content du rendu final de ces tests. Qui peut d'ailleurs être le début d'un doom-like qui sait ?
Et voilà ! C'est déjà la fin de cette Revue, des annonces intéressantes, je vous invite bien évidemment à regarder les avancements des différents projets en cours !
Sur cette fin en retard, je vous souhaite de bonnes vacances et bien évidemment :
À bientôt sur Planète Casio 
Depuis la dernière RdP, 2 programmes ont été postés :
bêtes (demo) de
Pedrobzh
fourmi de langton Python de
Oskar
Lire la RdP précédente :
La revue des Projets – 191
Besoin d'aide ? Une idée ? Un projet ? Un article !
Citer : Posté le 26/10/2020 12:50 | #
Wow style ce raycasting ! Combien de rayons dans cette scène, combien de tests de collisions par rayon ?
Citer : Posté le 26/10/2020 13:30 | #
Combien de rayon : pour la scène du bas, je trace un rayon par degré. Donc 360 rayons
Combien de tests de collisions : Toujours pour cette scène, je suis obligé de tester pour chaques murs et pour tout les rayons. En comptant les bordures comme des murs, ça nous fait ici 9 murs.
Je fais donc 9 tests de collisions par rayon avant de passer à un autre.
Vu qu'il y a 360 rayons ça nous fait 3240 tests pour un affichage pour cette scène.
Voilà une petite vidéo avec des paramètres assez faibles 9 murs, un rayon tout les 6 degré. Avec et sans overclock, les performances restent assez bonnes
(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 26/10/2020 13:36 | #
Je vois, merci ! Pourquoi est-ce que tes rayons ont pas l'air espacés régulièrement sur la vidéo ?
Ça a l'air quand même pas très véloce tout ça. Tu calcules tout en point flottant ? Est-ce que tu as mesuré un peu les perfs ?
Edit : Je critique pas ton code, c'est juste un peu décevant que le point flottant et le rendu par défaut aillent pas plus vite. Je veux dire qu'un add-in peut certainement pousser plus loin pour des jeux ou d'autres applications, même sans overclock.
Citer : Posté le 26/10/2020 13:50 | # |
Fichier joint
Je pense aussi que mon code n'est pas optimisé pour ça, je pensais avoir plus de performance sur un add-in.
Je comprends pas vraiment pourquoi mes rayons ne sont pas tous espacés de la même manière, ça doit peut-être être lié au rayon que je défini autour du point d'émission ? Il faut que je fasse des tests dessus.
Et c'est là le problème, j'effectue beaucoup de calcul en flottant car j'utilise un théorème d'intersection de deux droites. Avec des calculs qui sont assez énergivore je pense.
En plus de ça, pour tracer le bon trait, je calcule avec la formule des distances dans un plan, la taille du rayon trouvé. Un autre flottant donc...
Je n'ai pas encore cherché à optimiser tout ça, je voulais déjà réussir à le produire, et c'est chose faite
Le code est pas long, j'ai mis l'archive en pièce jointe
(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 26/10/2020 13:59 | #
Ah mais il y a aussi le fait que ta méthode d'entrée est freestyle. Comme tu n'as aucun délai, le truc tourne à fond même quand il n'y a rien à faire. Si tu veux utiliser les événements à la main t'es supposé prévoir le délai (là t'es à genre 10 ms + le tems de rendu par tour de boucle, dupdate() est certainement le bottleneck).
Au passage pollevent() c'est pas assez ça ne lit qu'un événement, s'il en arrive plus d'un entre deux tours de boucle (probable) ils vont lentement s'accumuler. clearevents() est ce dont tu as besoin si tu veux prendre l'approche keydown() (c'est pareil sauf que ça les lit tous).
La division flottante est un gros red flag, je sais pas si elle est évitable mais ça te donne une idée. La racine carrée est aussi assez longue, le pow() pas tant que ça mais tu peux gagner en simplement utilisant une multiplication. Tu peux aussi gagner du temps de calcul en ne calculant pas du tout la racine carrée vu que le record sera le même et que tu as déjà les coordonnées dont tu as besoin. Si la distance importe vraiment tu peux faire la racine carrée sur le record seulement une fois que tu as tout comparé.
Citer : Posté le 26/10/2020 14:07 | #
Oui oui c'est un peu beaucoup du freestyle
J'avoue pour les événements, je n'ai pas regardé comment faire autrement, je ne connais pas vraiment les différences entre chacun.
La division flottante est par contre nécessaire si je veux utiliser cette méthode de calcul, c'est dommage je sais. Je peux essayer de faire autrement en considérant une sorte de grille, mais ça nécessite un changement complet du code.
Je n'avais pas pensé à enlever la racine carré, c'est vrai qu'elle ne sert à rien si ce n'est rajouter du temps de calcul !
Concernant les rayons qui ne sont pas à égales distance, c'est un mystère, je ne comprends pas vraiment pourquoi ça arrive, il faut que j'essaye des trucs
(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 26/10/2020 14:14 | #
À relire le code je pense que tu peux délayer la division de pas mal, déjà tu peux la faire après le if pour de pas la faire si le if est faux. Ensuite, vu que tu calcules inx et iny en ajoutant x3 et y3 avant de les retirer immédiatement pour la distance, l'objet que tu passes à sqrt() est proportionnel à den donc tu peux encore attendre après le calcul de sqrt() avant de diviser. Avantage : tu divises une seule fois, pas deux. Si tu bas le record, tu peux finaliser la valeur de u en divisant une unique fois de plus, et recalculer inx et iny.
Pour l'angle y'a aucun mystère en fait (j'aurais dû m'en douter), tu évalues des sinus et cosinus en degrés alors que tout la lib math est en radians. Donc en fait tes rayons sont complètement éparpillés sauf que grâce aux propriétés magiques de π (irrationnalité) si t'en envoies assez avec un pas fixe ça finit toujours par être à peu près équi-réparti
Citer : Posté le 26/10/2020 14:34 | #
Hmm j'ai pas tout suivi là.
Je n'ai pas vraiment compris comment tu économisais une division, il faut bien que je calcule t et u pour déterminer si il y a un point d'intersection sur la droite...
J'ai raccourci le calcul de la distance qui du coup avait des passages inutiles.
Ma fonction check_wall :
double dist;
const double den = (x1-x2)*(y3-y4) - (y1-y2)*(x3-x4);
if(den == 0) {
return 0;
} else {
//Line line intersection
double t = ((x1-x3)*(y3-y4)-(y1-y3)*(x3-x4))/den;
double u = -((x1-x2)*(y1-y3)-(y1-y2)*(x1-x3))/den;
if(t > 0.0 && t < 1.0 && u > 0.0) {
dist = pow(u*(x4-x3),2)+pow(u*(y4-y3),2); //distance player - intersection
if(dist<record) {
record = dist;
recx = x4;
recy = y4;
recu = u;
}
}
}
return 1;
}
(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 26/10/2020 14:38 | #
Oui, mais t'es pas obligé de diviser tout de suite. Tu peux écrire :
double u_den = -((x1-x2)*(y1-y3)-(y1-y2)*(x1-x3)); // =u*den
if(t_den > 0.0 && t_den < den && u_den > 0.0) {
double ux = u_den*(x4-x3);
double uy = u_den*(y3-y3);
dist = (ux*ux + uy*uy) / (den * den);
}
Citer : Posté le 26/10/2020 14:59 | #
Hmm ça ne marche pas. Les rayons ne sont pas bien stoppés. Où alors j'ai une erreur quelque part ?
double u = -((x1-x2)*(y1-y3)-(y1-y2)*(x1-x3)); // =u*den
if(t > 0.0 && t < den && u > 0.0) {
double ux = u*(x4-x3);
double uy = u*(y3-y3);
dist = (ux*ux + uy*uy) / (den * den);
if(dist<record) {
record = dist;
recx = x4;
recy = y4;
recu = u/den;
}
}
(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 26/10/2020 15:10 | #
Oui alors j'ai un peu oublié que parfois den < 0 et du coup ça change le sens des inégalités. Ça se sauve en multipliant t, u et den par -1 si den est négatif pour bien appliquer les signes même si tu ne divises pas en valeur absolue. (J'espère que c'est tout x3)
Citer : Posté le 26/10/2020 15:18 | #
Ok en effet, j'aurai dû le voir je suis débile
Bon, ça fonctionne correctement mais ça n'améliore pas de beaucoup les performances, c'est vraiment les calculs qui posent problème ici...
(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 26/10/2020 15:22 | #
Oh ça m'étonnerait beaucoup que ça n'améliore pas les performances. Mais ce serait bien plus facile de mesurer une fois ta boucle principale correctement cadencées, avec une mesure de FPS ou mieux une mesure du temps de calcul.
Citer : Posté le 27/10/2020 11:47 | #
2/3 lignes de code pour l'install des outils fxSdk/gint *touss * *tousscasio-docker
Faut vraiment que je fasse une communication de ce truc...
Quel application pour un moteur de RayCasting 2D ?
Citer : Posté le 27/10/2020 11:54 | #
Quelle application à un moteur de raycasting 2d ?
Et bien je ne sais pas vraiment :E, c'était surtout un petit challenge pour moi de réussir à en faire un !
A partir d'un moteur comme ça, je peux théoriquement faire une sorte de simulation 3D de la scène. Un peu comme doom le faisait à l'époque
(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 27/10/2020 17:08 | #
Okay je vois le genre
D'ailleurs en parlant de 3D techniquement Windmill ça devrait être compatible avec les graphs couleurs ?
Citer : Posté le 28/10/2020 09:07 | #
Techniquement, oui. D'un point de vues perfs, faut voir.
Y'a quand même un paquet de pixels en plus, donc le z-buffer est beaucoup plus gros et y'a plus de points à calculer.
Ceci dit les graphs couleur ont pas mal de RAM et une fréquence CPU plus élevée, donc ça se discute.
Citer : Posté le 28/10/2020 09:23 | #
Le problème fondamental étant que je n'ai jamais réussi à compiler Windmill avec GCC, et pour la Graph 90+E y'a pas le choix. Si on arrive à choper Ninestars assez longtemps pour une collaboration un peu poussée ça doit vaguement être tentable je pense. Je promettrais absolument aucun résultat en termes de perfs full-screen mais en 128x64 par exemple aucun problème.