Enfin ! Après 2 mois de travail, pas très efficaces en toute honnêteté, j'ai enfin un résultat montrable
!
Il ne reste plus qu'a trouver un nom !
Donc maintenant, il faut que je transforme ça en jeu.
Touches : Avant/Arrière : Dpad Haut/Bas
Gauche/Droite : Dpad Gauche/Droite
Quitter : F6
V 0.1.3
V 0.1.3
Pour le moment, tout est en float donc il y a de la marge pour optimiser. Attendez vous à <10 fps sans OC. La V 0.1.4 va sortir bientôt normalement, avec des améliorations sur ce point là.
V 0.1.4
V 0.1.4
Collision, meilleure map, petites améliorations, changement léger esthétique
Maintenant que je suis satisfait avec la base je vais optimiser.
V 0.2
V 0.2
Point fixe ! Avec désormais 25-27 fps, le "glissement" des valeurs corrigé, et une distance de rendu plus grande.
V 0.2.1
V 0.2.1
Optimisation de 4 à 7 % grâce a Slyvtt (encore ! =) ) qui a proposé gint_dvline();
V 0.2.2
V 0.2.2
Je me suis retrouvé lancé, et pas moyen de freiner l'élan !
Donc, pour aujord'hui j'ai rajouté la capture d'écran USB (0 + EXE) , le compteur de temps d'image est désormais activable/désactivable (F1 mais c'est capricieux pour le moment) et j'ai encore changé les couleurs.
V 0.3
V0.3
V 0.3 : Xoritude
Avec un peu d'huile de coude, vient les textures !
Malheuresement avec vient une baisse de FPS, de 26-29 à 13-15. Mais l'expérience reste fluide, bien qu'elle necessitera un overclock pour revenir au niveau précédents, où encore sur les CG10/20
Et j'ai falli oublier de mentioner que j'ai amélioré la réponse de la touche F1 et de la capture d'écran.
Donc j'ai sorti mon premier jeu avec ce moteur,
Maze3D, la prochaine étape est de (enfin) faire des sprites !
Citer : Posté le 09/07/2023 18:50 | #
Le truc c'est qu'écrire une ligne dans le framebuffer puis faire le calcul pour la suivante puis faire cette ligne là ect.... ça doit pas être le plus rapide en accès mémoire, en plus du fait que dline() utilise un algo pour faire des lignes diagonales alors que j'ai que besoin de faire des lignes verticales. En tout cas le dessin de la ligne est la partie la plus lente de la boucle j'ai l'impression, donc si il y a de l'opti a faire c'est là.
Caltos : G35+EII, G90+E (briquée )
Citer : Posté le 09/07/2023 18:53 | #
Oui, fais ta propre fonction où t'écris direct dans la vram
libMicrofx : https://www.planet-casio.com/Fr/forums/topic17259-2-libmicrofx-remplacez-fxlib-pour-faire-des-add-ins-tres-legers.html !
Racer3D : https://www.planet-casio.com/Fr/programmes/programme4444-1-racer3d-mb88-jeux-add-ins.html
Citer : Posté le 09/07/2023 22:04 | #
Pour info gint dispose des primitive hline (ligne horizontale) et vline (ligne verticale) qui sont optimisées pour un max de vitesse.
A utiliser de préférence par rapport à line pour les cas particuliers.
Citer : Posté le 09/07/2023 22:07 | #
Elles ne marchent pas dans mon cas, déja parceque je fais des lignes verticales donc dhline() est hors de la question, et dvline() fait une ligne de haut en bas, sans taille variable.
Caltos : G35+EII, G90+E (briquée )
Citer : Posté le 09/07/2023 22:22 | #
Oui excuse je me suis gouré de nom gint_dvline
Citer : Posté le 09/07/2023 22:25 | #
Merci. Je vais essayer ça dans 10mn, là je vais tester le tileset détaillé que je suis en train de faire pour le RPG collab
Caltos : G35+EII, G90+E (briquée )
Citer : Posté le 09/07/2023 22:50 | #
Ça a pris un peu plus que 10mn (pas a implémenter hein, je te rassure )
Et donc on passe de 25-27 fps à 26-29 !
C'est 4 à 7 % d'amélioration pour vraiment pas grand chose, merci. Ça va faire la 0.2.1 ça
Je suis en train de bosser sur les sprites, pour la 0.3 ça va envoyer du lourd (enfin pas tant que ça, mais je vais pas la sortir avant d'avoir un sprite sur la map)
Caltos : G35+EII, G90+E (briquée )
Citer : Posté le 09/07/2023 22:56 | #
Hopela, j'ai mis a jour le github et officialisé avec la 0.2.1
Caltos : G35+EII, G90+E (briquée )
Citer : Posté le 10/07/2023 00:17 | # | Fichier joint
Je me suis retrouvé lancé, et pas moyen de freiner l'élan !
La V 0.2.2 est maintenant disponible ici https://github.com/attilavs2/Raycaster_prealpha/releases/tag/Alpha-0-2-2
Donc, pour aujord'hui j'ai rajouté la capture d'écran USB (0 + EXE) , le compteur de temps d'image est désormais activable/désactivable (F1 mais c'est capricieux pour le moment) et j'ai encore changé les couleurs.
Je vais bientôt rajouter des images au post
Caltos : G35+EII, G90+E (briquée )
Citer : Posté le 16/07/2023 22:07 | # | Fichier joint
Je suis rentré, et pendant mon absence j'ai fait marcher les textures !
Je vais donc sortir une V 0.3 bientôt, et je pense que dans la semaine je vais sortir un petit jeu de labyrinthe.
J'aillais pas refaire un post, donc je modifie celui çi pour dire que c'est bon, la V 0.3 est sortie.
A voir ici https://github.com/attilavs2/Raycaster_prealpha/releases/tag/Alpha-0-3-0
Caltos : G35+EII, G90+E (briquée )
Citer : Posté le 16/07/2023 23:22 | #
Ca avance bien on dirait.
Je remarque un artefact sur le rendu, on le voit sur les deux images où le mur sur la gauche fait plus que la hauteur de l'écran (notamment avec le mur bleu). La partie de l'image qui a un mur plus haut que la hauteur de l'écran a une texture parfaitement alignée horizontalement et qui est ensuite distordue normalement quand la taille du mur ne dépasse pas l'écran.
Je pense qu'il y a un petit problème dans ton calcul de tes coordonnées de texture dans le cas d'un clipping (à mon avis tu prends la hauteur de l'écran au lieu de la hauteur "vraie" du mur dans tes calculs).
AU loin il y a un effet de moirage, tu peux essayer de contourner ce problème en faisant diverses tailles de textures (mipmapping). Les textures très géométriques aident vraiment pas pour ce genre de problème de rendu.
Bon courage.
Citer : Posté le 16/07/2023 23:27 | #
Merci !
Les effets de moirage ne m'embête pas vraiment, enfin pas au point de mettre en place des mipmaps.
Le problème de taille de la texture n'est pas un problème de mon calcul mais de image_linear, il n'y a pas de clipping donc la taille est limitée à celle de l'écran. Je pensais résoudre ça en ne prenant qu'une partie de la texture, mais je m'y suis pas encore mis.
Caltos : G35+EII, G90+E (briquée )
Citer : Posté le 17/07/2023 16:07 | #
C'est extra !
Bravo, mais peut être que tu pourrait rajouter un Back-Ground gris clair en haut et gris foncé en bas ça donnerrait surement plus de relièfe a ton programme.
Citer : Posté le 17/07/2023 16:13 | #
C'est façile a dire mais j'ai pas encore trouvé comment dessiner un rectangle sur une image bopti, où sinon il faudrait que je mette le buffer sur lequel je dessine en transparence ce qui est pas génial niveau perfs.
Caltos : G35+EII, G90+E (briquée )
Citer : Posté le 17/07/2023 16:15 | #
A ouai, je vois...
Citer : Posté le 17/07/2023 16:21 | #
C'est façile a dire mais j'ai pas encore trouvé comment dessiner un rectangle sur une image bopti, où sinon il faudrait que je mette le buffer sur lequel je dessine en transparence ce qui est pas génial niveau perfs.
Tu peux faire une double boucle et dessiner pixel par pixel, ou bien accéder directement au tableau de données. Ça ne devrait pas être trop difficile une fois que tu arrives à comprendre le format d'image
Citer : Posté le 17/07/2023 18:32 | #
Tu peux faire une double boucle et dessiner pixel par pixel, ou bien accéder directement au tableau de données. Ça ne devrait pas être trop difficile une fois que tu arrives à comprendre le format d'image
Je comprends pas vraiment le format
Et puis vu que ça doit tourner chaque frame, une boucle pixel par pixel est pas vraiment envisageable. Mais en fait c'est très raisonable la perte de fps de passer en transparent, donc c'est ce que j'ai fait.
Sinon je vais pas poster de screens/donner des infos vu que je suis en train de faire un jeu avec le moteur, qui va sortir bientôt tm , donc je garde le suspens.
PS : Ça va pas être énorme non plus, mais 15-30 mn suivant comment vous vous débrouillez, avec un potentiel de rejouabilité
Caltos : G35+EII, G90+E (briquée )
Citer : Posté le 24/07/2023 10:12 | #
J'aime beaucoup. Le raycasting c'est super pour faire des environnements fluides en 3D. Et en vrai t'as raison même à 15 FPS c'est pas mal la fluidité. Il semble y avoir quelques glitchs pour les textures des murs très proches ou alignés sur les axes. Est-ce que tu as une idée d'où ça vient ?
Citer : Posté le 24/07/2023 11:12 | #
Pour les textures proches j'ai déja une prévention, mais je pense qu'il faudrait que je fasse un celling et non et floor. Pour les axes c'est que le DDA ne marche pas avec des valeurs tendant vers 0 de vecteur de direction. La fluidité est aussi aidée par le mouvement basé sur le delta temps.
Merci en tout cas !
Caltos : G35+EII, G90+E (briquée )
Citer : Posté le 24/07/2023 11:17 | #
J'imagine une affaire de précision après une division ? Je vois fixed.h qui traîne. Enfin ça reste surprenant vu que la précision c'est 1/32768, sûrement ça devrait suffire pour représenter les petits Δx/Δy sur les vecteurs de direction ?
Citer : Posté le 24/07/2023 11:20 | #
Non c'est plus de la taille des valeurs en question, avec des valeurs inversament proportionelles, ça "avance" de beaucoup par case dans l'autre direction, et donc ça "rate" les murs ou même se retrouve en dehors de la distance de rendu au premier "pas"
Caltos : G35+EII, G90+E (briquée )