Mode7 - Page 2

les if y'en a des tonnes au dessus dans la meme boucle, c'est surement les decalages mais je comprend pas car c'est une instruction du 68k le decalage...

faut voir comment TIGCC interprète ca un TIGCC -S pourait peut être de voir si c'est vraiment le cas

Les instructions de décalages sont particulièrement lentes car tu dois compter deux cycles pour chaque décalage de un bit. (ex. a << 3 prendra 4 cycles de plus que a << 1 ...)
tu pourrais effectivement faire un btst.
avec ton & 0x80 tu testes le 8^e bit de l'octet après qu'il ait été décalé, donc en toute logique tu pourrais tester le bit (offsetmap - 8), mais par contre, il faut veiller à ce que (offsetmap - 8) soit toujours positif (ça peut se vérifier soit avec un btst, soit avec un cmp, faut voir ce qui est le plus rapide)

en fait offsetmap est egal a (bytemap & 0x7) ou a 0 donc pas de pb pour savoir si 8-offsetmap est positif
par contre un btst c'est en asm et ca s'applique sur un registre de donnée, pix0 est une variable locale donc dans la pile, il faudrait que je la charge dans un registre puis ke je fasse le btst, le pb c'est que je sais pas quels registres sont utilisés et je pense que gcc n'aimera pas que je trafique les registres avec des instructions asm("...");

Sinon ca fait quoi tigcc -s ?

Ça te sort le code assembleur généré à partir de ton code C.

Un bset peut s'appliquer à la mémoire.

bon en gros est-ce qu'il y a quelqu'un qui peut me convertir les if en C en une instruction asm("..."); (ou 2) ??

Euh, il y a fort à parier que pix0, pix1 et compagnie ne soient utilisés qu'à cet endroit-là, et donc que l'optimisation enlève une bonne partie du code... Si tu veux vraiment voir ce que ça donne, tu peux faire asm volatile(""::"g"(pix0),"g"(pix1)...); (et pareil pour les autres variables). Ca oblige le compilo à calculer qd même le contenu de ces variables.

[EDIT : ":" en trop]

-S ça te montre l'asm généré par gcc.
Pour l'asm inline, c pas la peine de charger les variables dans des registres, gcc le fait pour toi... Regarde la dans doc de TIGCC c'est a peu près expliqué (mais faut s'accrocher pour comprendre quand même) comment faire.
Sinon, si tu ne comprends rien à la doc sur l'asm inline (ça n'aurait rien d'anormal étant donné la syntaxe merdique utilisée par gcc), tu peux toujours demander à DoubleK qu'il le fasse pour toi.

[Post croisé]

En fait pollux a l'air d'avoir raison, l'optimisation de gcc doit virer les 3/4 du code et donc c'est normal que ca aille bcp plus vite
Je vais continuer a faire quelques tests pour en etre sur

Bon j'ai vu juste avant que tigen ne soit down la dernière version du moteur, c pas mal, mais les pixels sont vachement gros, et je crois que tu fais des erreurs d'arrondi (lignes droites avec des "dents"), ce qui fait que ça ne rend pas très bien avec des gros pixels. Attention aussi si tu stockes ce que tu dois rendre avec un gros bitmap : les maps de Formula0 sont tellement grandes que j'ai été obligé de faire des tiles de tiles ( ) pour éviter d'avoir une map de plus de 64k... (et encore, j'ai choisi de prendre des tiles 4x plus gros que ceux de la SNES)

Là je suis en train de faire une version "light" du moteur de Formula0, avec une résolution 2x plus faible dans les deux sens, et je commence à avoir un framerate assez honnête Si tu veux réutiliser le moteur, a priori pas de pb.

Merci de me proposer d'utiliser le moteur mais en fait je comprend rien aux sources de formula0 .
En fait j'aurais bien voulu savoir sur quoi tu te base pour afficher la perspective car moi j'ai fait plein de tests et j'ai fini par trouver cette méthode (ya aucun site sur le net qui explique l'algo du mode7). J'ai essayé de comprendre ta technique "newtech" et même en relisant des millions de fois le readme de formula 0 je ne comprend toujours pas ...
Sinon pour les erreurs d'arrondi qui génere des lignes avec des dents, c'est configurable mais en 40x25 les dents sont obligatoires.
Pour les map j'utilise des tiles de 16x16 en ndg soit 64 octets le carré et donc une map de 512x512 composée de 32x32 tiles fait 64ko d'utilisés dans la ram, vu que je prend pas une resolution de fou (40x25) je ne vais pas mettre beaucoup de details sur la map et donc je peut refaire le circuit de mutecity de snes en 27x14 -> 23.6ko de ram

Sisi j'ai déjà vu des sites qui expliquent cet algo (mais j'ai pas noté l'url, cependant en cherchant mieux ça doit se trouver )

Moi non plus, je n'en ai jamais trouvé
Il y a un autre nom pour le mode 7 ou bien c'est là-dessus qu'on doit axer notre recherche ?

lionelA :
Merci de me proposer d'utiliser le moteur mais en fait je comprend rien aux sources de formula0

J'ai un peu réorganisé pour que la boucle principale soit plus claire et que le fichier principal contienne le moins de choses possible... (et je vais aussi utiliser les niveaux de gris de TIGCC légèrement modifiés).

En fait j'aurais bien voulu savoir sur quoi tu te base pour afficher la perspective car moi j'ai fait plein de tests et j'ai fini par trouver cette méthode (ya aucun site sur le net qui explique l'algo du mode7).

De toute façon c'est relativement simple à trouver...

J'ai essayé de comprendre ta technique "newtech" et même en relisant des millions de fois le readme de formula 0 je ne comprend toujours pas ...

Euh alors "newtech" j'ai même pas essayé de l'implémenter, c'est vraiment un truc ultra-barbare, qui pourrait être très efficace, mais qui demanderait vraiment bcp de boulot avant d'arriver à faire qqch qui marche. En gros l'idée est de pré-rotationner les tiles, de façon à ce qu'on ait juste besoin de les zoomer pour les afficher. (et zoomer un tile est bien plus efficace que faire des rotations, parce que ça limite les accès mémoire, parce que ça dépend de moins de variables, parce qu'on peut utiliser les retenues pour copier les pixels, etc...) Mais il y a plein de problèmes pour choisir le format de stockage (et le zoom correspondant) pour faire ça de manière la plus efficace possible au niveau du rendu.

En plus si tu veux avoir plein de tiles il faudrait prendre qqs 100aines de ko d'archive temporairement, mais ça c pas forcément un pb... (surtout sur V200&co, ou sous pedrom)

Donc grosso modo, si tu avais vraiment envie de faire un bon truc, il faudrait utiliser ça, mais c uniquement si tu ne penses pas pouvoir améliorer ton mode7 existant.



Et donc la méthode que j'utilise devrait être bien plus compréhensible (et assez proche de celle que tu utilises, je pense).

Pour les map j'utilise des tiles de 16x16 en ndg soit 64 octets le carré et donc une map de 512x512 composée de 32x32 tiles fait 64ko d'utilisés dans la ram, vu que je prend pas une resolution de fou (40x25) je ne vais pas mettre beaucoup de details sur la map et donc je peut refaire le circuit de mutecity de snes en 27x14 -> 23.6ko de ram

Mouais, tout dépend de la taille de tes tiles, c sûr...

Ximoon :
Sisi j'ai déjà vu des sites qui expliquent cet algo (mais j'ai pas noté l'url, cependant en cherchant mieux ça doit se trouver )

J'en ai déjà vu quelques uns également... je me souviens plus particulièrement d'un code source en assembleur ARM ultra-commenté (avec équations et schémas) qui faisait du mode 7 sur GBA, et d'un code source en C sur PC (mode 13h) pour en faire un.

il y a une bonne explication sur le mode 7 a la fin de cette page: http://www.pixelate.co.za/issues/5/articles/circle/sincos.htm

J'ai une question, je voudrais faire en sorte que la fonction qui calcule et affiche le rendu du mode7 soit appelée N fois par secondes (N etant le nb de fps voulu par exemple 20)
J'ai donc pensé a apeler cette fonction dans une interuption mais cela ne marche pas.
Je me suis dis que c'est parce que la fonction prenait + de temps a s'executer que le temps entre 2 interruptions et donc ca rapelai la fonction alor que la premiere n'était pas finie et ainsi de suite.
J'ai donc mis une variable a 1 juste avant dapeler la fonction et je la remet a 0 apres, et en testant cette variable (globale) dans l'interruption je lance ou pas l'apel de la fonction de rendu.
Bref rien ne marche pour l'instant (est ce que ca a quelque chose a voir avec les niveau de gris ?)
Quelle auto_int utiliser ? (jutilise la 5 pour l'instant)
Comment faire pour modifier la frequence de l'auto_int_5 et de la restaurer en fin de prog ?

Tu trouveras des infos pour régler l'AI5 dans le j89hw.txt.
Sinon, pour ton pb, que se passe-t-il ? Tu as l'impression que ton prog est bloqué ? Si c'est le cas, l'hypothèse que tu as supposée est peut-être vérifiée, teste avec la moins bonne résolution pour voir.

Ce n'est pas forcément une bonne idée de mettre ton code principal dans une interruption (il faut faire attention à bien autoriser les autres interruptions si tu t'en sers, etc...), en général ce qu'on fait c'est plutôt de faire une boucle principale qui *attend* que l'interruption se déclenche une fois le tracé fini. Ca a un certain nb d'avantages, en particulier tu n'es pas limité à des multiples d'1/20è de seconde pour le tps de calcul d'un frame : avec ta méthode, si un frame prend un peu plus de tps que prévu à calculer et que tu débordes un peu sur le tps maximal autorisé, ton frame va être affiché 2x trop lgtps (et si le tps en question est 1/20è de sec, ça va carrément se voir) Parmi les autres avantages, il y a par exemple le fait que tu vas pouvoir en profiter pour tester tes touches à chaque interruption (et augmenter au passage la fréquence de l'interruption, pour qu'il y en ait par exemple 4 par frame), ce qui va te permettre d'éviter de rater un appui de touche...

On m'a dit aussi qu'il y avait des différences subtiles de comportement sur VTI entre mode superviseur et mode utilisateur (par exemple, il y a un bug qui fait que move.b d0,-(a7) fait prendre à a7 une valeur impaire, ce qui n'arrive pas sur vraie TI ou en mode utilisateur), donc il faut faire aussi gaffe à ça.

Bien sûr si tu prends vraiment toutes les précautions nécessaires, que tu autorises toutes les interruptions une fois passé en mode "calcul du frame" (mais pas avant...) et que tu repasses en mode utilisateur, que tu exécutes le test des touches *avant* de vérifier si une autre interruption est en cours, alors ça sera exactement la même chose -- en un peu plus compliqué


Pour l'AI à utiliser, la 5 est une bonne idée, oui (ça te permet de redéfinir la fréquence, et aussi de zapper facilement les auto-ints 1 et 2 avec OSSetSR).

Finalement j'ai fait que la modification de la scene (position et angle camera et tout element qui doit bouger) soit appelée dans l'interruption, les frames sont calculées le reste du temps ce qui permet d'avoir un framerate variable en fonction du nombre de sprites a afficher par exemple mais que la vitesse de jeu reste constante. Ainsi les ti overclokées ou les HW1 joueront a la meme vitesse (la difference sera la fluidité des graphismes).

Demo avec sprite : Demo
update avec meilleure formule de projection des sprites (necessite la demo) : Update

J'ai une question pour pollux : Comment as tu fait pour obtenir les images du sprite de fzero ? Il existe des utilitaires qui font ca ?

bonne chance