Posté le 05/04/2016 19:52
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 224 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 05/04/2016 19:58 | #
Tout est dit ici. Après, faudra sans doute optimiser : http://forums.mediabox.fr/wiki/tutoriaux/flashplatform/affichage/3d/raycasting
Ajouté le 05/04/2016 à 19:59 :
Je te conseille de tout lire, mais voici quand même la partie sur l'affichage de textures : http://forums.mediabox.fr/wiki/tutoriaux/flashplatform/affichage/3d/raycasting/theorie/06-texturer_des_murs
Citer : Posté le 05/04/2016 22:16 | #
Merci, je vais y jeter un oeil !
D'ailleurs je me suis un peu renseigné, et j'ai vu que Kelli avait codé son Wolfenstein en s'aidant de Revolution FX.
Est ce que cette librairie est toujours plus rapide à l'heure actuelle ou est ce que d'autres comme monochromelib sont mieux ? (Niveau rapidité pour un moteur raycasting) ?
Citer : Posté le 05/04/2016 22:57 | #
Purobaz s'était lancé dans ce projet il y a longtemps
Voici la page du projet avec ses sources
Citer : Posté le 05/04/2016 23:40 | #
MonochromeLib est pour le coup une de lib de graphisme les plus optimisées. La seule manière selon moi d'aller plus vite serai de la coder en ASM et d'aller chercher gint (pour peu que ça sorte un jour, hein Lephe ?
Citer : Posté le 06/04/2016 09:39 | #
D'acc merci pour vos réponses, effectivement j'ai jeté un regardé son moteur ça m'a bien aidé !
D'ailleurs, connaissez vous un moyen de convertir une image png en noir et blanc de 32*32 en tableau de char contenant des 0 et 1 ?
Edit : j'ai réussi grâce à TilesCreator à convertir mon image en hexa, mais comment faire pour le binaire?
Citer : Posté le 06/04/2016 10:31 | #
Pour l'image binaire il y a le fxSpriter de Lephénixnoir qui fait comme SpriteCoder mais avec des nombres binaire
Citer : Posté le 06/04/2016 12:47 | #
Est ce que cette librairie est toujours plus rapide à l'heure actuelle ou est ce que d'autres comme monochromelib sont mieux ? (Niveau rapidité pour un moteur raycasting) ?
Revolution-fx date du premier moteur de gris et ça c'est vieux ! Vu le boulot de PLL, mieux vaut ML ou mieux, un peu d'assembleur là où tu compiles avec le SDK... si tu veux jouer la carte de la puissance il vaut toujours mieux taper sur gcc avec -Ofast !
a seule manière selon moi d'aller plus vite serai de la coder en ASM et d'aller chercher gint (pour peu que ça sorte un jour, hein Lephe ?
Je te montrerai samedi à quoi ça ressemble les sources de gint...
fxSpriter traîne ici par ailleurs : fxSpriter – Encodage rapide d'images
Mieux vaut le compiler sous Linux, je sais jamais si les binaires Windows sont à jour (je crois pas d'ailleurs, il y a un bug sur les sets).
Citer : Posté le 06/04/2016 16:04 | #
Lephe, pour fxSpriter je l'ai essayé mais il n'a pas encodé mon image comme je le voulais, je voudrais pour une image de 16*16 par exemple un tableau de 256 octets contenant uniquement des 0 et des 1, fxSpriter me me donne un tableau de 32 octets contenant des valeurs de 0 à 255.
D'ailleurs autre question, j'ai récupéré les bouts de code de revolutionfx contenant l'overclocking, mais il ne marche que partiellement : Je peux overclocker ma calto en x2, x3 ou x4 sans problème, par conrte une fois qu'elle est overclockée, si j'essaye de modifier une fois de plus la valeur de l'overclock (ou si j'essaye de désactiver l'overclock), ma calto crash.
Y'a-t-il un moyen fiable et plus récent que revolution fx pour l'overclock ?
Edit : j'ai créé un petit programme en C qui convertit mes image hexa en binaire donc c'est bon pour ce point là
Citer : Posté le 06/04/2016 17:42 | #
Lephe, pour fxSpriter je l'ai essayé mais il n'a pas encodé mon image comme je le voulais, je voudrais pour une image de 16*16 par exemple un tableau de 256 octets contenant uniquement des 0 et des 1, fxSpriter me me donne un tableau de 32 octets contenant des valeurs de 0 à 255.
Quoi, tu voudrais multiplier la taille en mémoire par 8 ? Je sais que les textures ont besoin d'être rapides mais t'en es pas encore là...
Y'a-t-il un moyen fiable et plus récent que revolution fx pour l'overclock ?
Oui, [url=www.planet-casio.com/Fr/programmes/programme2796-1-ftune-sentaro21-add-in.html]FTune et FTune2[/url] de Sentaro21.
Edit : j'ai créé un petit programme en C qui convertit mes image hexa en binaire donc c'est bon pour ce point là
Ah, mais quelle méthode dégueulasse >_<
Citer : Posté le 06/04/2016 21:08 | #
Lephe, pour fxSpriter je l'ai essayé mais il n'a pas encodé mon image comme je le voulais, je voudrais pour une image de 16*16 par exemple un tableau de 256 octets contenant uniquement des 0 et des 1, fxSpriter me me donne un tableau de 32 octets contenant des valeurs de 0 à 255.
Là c'est carrément crade oui. ><
Franchement, en jouant sur le décalage de bit et les opérateurs unitaires, t'as moyen de gagner en place et vitesse. Et puis Wolfenstein est fluide sur SH3, alors si tu testes sur SH4 c'est pas normal que tu sois lent… Je pense que tu peux bien améliorer l'optimisation de ton code actuel.
Citer : Posté le 07/04/2016 13:35 | #
Après réflexion et vu le nombre de textures présentes dans un jeu de ce type (100, 200 maximum) il semble quand même que c'est la meilleure solution. La méthode d'affichage empêche d'itérer sur les bits donc il semble plus simple les stocker de cette manière, même si ça génère un coût plus important en mémoire.
Citer : Posté le 09/04/2016 16:32 | #
Rebonjour à tous, j'ai à nouveau un problème (vous l'aurez deviné
J'ai, suite aux conseils de Darkstorm, recodé mon jeu en remplaçant les Float par des fixed.
J'ai eu beaucoup de bugs suite à cela, mais maintenant je suis très près du but. Tout refonctionne comme avant, excepté certaines lignes de l'écran qui ne sont pas affichées correctement (voir cette photo : http://www.noelshack.com/2016-14-1460211886-capture.png ).
J'ai quand même réussi après de nombreux tests à isoler le bout de code où se trouve l'erreur (50 lignes), mais je ne vois pas où elle se trouve précisément.
Voici le pastebin du fichier avec les fixed qui présente des bugs visuels : http://pastebin.com/rdV5vSD4
Voici le fichier original qui marche parfaitement : http://pastebin.com/63pmRqNX
Tout ce que je sais c'est que les valeurs mapX et mapY ne sont pas les bonnes à la fin de ces lignes et causent ce bug visuel, mais je n'arrive pas à remonter plus loin.
Quelqu'un pour m'aider ?
Merci, Drak
Citer : Posté le 10/04/2016 01:12 | #
@Drakalex007 Ayant déjà codé plusieurs moteurs de raycasting dont un pour la HP Prime, le bug que tu obtiens avec une colonne isolée affichant n'importe quoi me dit clairement quelque chose :
Cela correspond habituellement à un cas particulier mal géré.
Normalement pour le raycasting, tu effectues nombre de calculs mathématiques, en utilisant entre autres des fonctions trigonométriques et des divisions.
Le bug visuel correspond selon moi à une combinaison (repère choisi + orientation caméra + rayon bien particulier) qui fait que le calcul tel que tu l'as codé est impossible :
- division par zéro
- fonction trigonométrique tangente non définie pour 90°+k*Pi
Il te faut donc détecter ces cas particuliers, et dans ce cas remplacer le calcul impossible qui n'a pas lieu d'être par un calcul alternatif donnant quand même la bonne réponse.
Citer : Posté le 14/04/2016 17:56 | #
Hey Critor, effectivement tu avais raison, c'est bel et bien une division par zéro qui ne passe pas.
Cependant, pourquoi avec des Int et des Float tout s'affiche normalement tandis qu'avec des Fixed il y a des bugs comme ça ? Suis-je obligé de coder quelque chose pour ce cas précis ? Ca me parait un peu "brouillon".
Ajouté le 14/04/2016 à 18:33 :
Bon au final c'est assez simple à résoudre, j'ai rajouté à la fonction fdiv la premiere ligne :
[b][blue]if[/blue][/b] (y == [maroon]0[/maroon]) y += [maroon]1[/maroon];
[b][blue]if[/blue][/b] (y>(1<<(2*DB-2))) [b][blue]return[/blue][/b] x/(y>>DB);
[b][blue]return[/blue][/b] fmul(x, ((1<<(2*DB))/y));
}
Et tout marche, merci Critor
Citer : Posté le 14/04/2016 19:26 | #
Et la question qui tue : combien de FPS sans overclock ?
Citer : Posté le 14/04/2016 20:54 | #
Alors de façon générale, on va dire :
La plupart du temps, 12-14 FPS, parfois des zones à 10-12FPS, de très très rares pics à 8 et de même des rares pics à 16
Sachant que ma version initiale faisant 6-8fps, je suis plutot content
Citer : Posté le 14/04/2016 21:02 | #
Ça devient largement jouable
Maintenant l'overclock est utile. Avant ça ne l'était pas.
Citer : Posté le 14/04/2016 22:14 | #
Super !
Tu nous publies ça bientôt ?
Citer : Posté le 14/04/2016 22:15 | #
Haha, bientôt peut être, avant ça je compte arriver à 20 fps
Et aussi créer une librairie qui transforme les pixels en couleurs grâce à une fonction quantique, mais ce sera juste après
Ajouté le 15/04/2016 à 18:13 :
Ca y est ! (plus ou moins)
J'ai atteint le cap des 21FPS on-calc !
Bon, ne croyez pas que c'est constant, parfois on a des pics à 21 FPS, comme on a des pics à 11. Sinon, en moyenne le jeu tourne dans les 14-16FPS
(Et DS: avec l'overclocking je tape dans les 42, je sais même pas si le rafraichissement de l'écran le permet