Moteur 3D asm Ti 83(+)

[florian66]

Voila j'ai fini avec la routine signée et sa prend entre 7300 Tstates si tout les nombres sont positif et différents de 0 et 8000 environ si ils sont négatifs
voila le code : http://pastebin.com/1suaepRH
c'est un peu bizarre mais c'est simple
J'ai commencé pour la routine de calcul des coordonnées.
Sinon pour l'octree je ne sais pas comment faire

EDIT: voila une nouvelle version plus rapide http://pastebin.com/vdYXtD24
je ne pense pas que l'on puisse faire mieux niveau vitesse (pas taille) entre 7000 Tstates et 7800 selon si c'est un nombre neg ou pas

[TheMachine02]

Je vais essayer d'optimiser cette routine de multiplication, car elle me plait pas du tout
Au niveau vitesse, y'a encore deux trois truc à faire, notamment dans la récupération des sinus/cosinus.


EDIT : non testé, vitesse non calculée, mais je dirais au moins 100 TStates enlevés : http://pastebin.com/6B22pC39

[florian66]

Mais t'es vraiment une machine , un vrai guru de l'asm.
Euh pour la routine de multiplication: grand max 530

Mais pour la récupération je fais au mieux je crois, je sais pas ce que tu veux dire ??
Je viens d'en faire une mais c'est mineure ( 9 T-states)
Je viens de finir la routine de translation mais je vais essayer de l'optimiser du coup.

[TheMachine02]

Bon j'ai finalement eu un peu de temps pour bourriner sur les maths
On peut retirer TOUTES les multiplications grâce aux identités trigonométriques. Tout les éléments n'ont pas été calculés, mais y'en a déjà une partie ici : http://pastebin.com/WrCV2CB9

On ne fait plus que des mul par 2 / div par 2 qui sont très rapide, puisque tout peut se faire dans l'accumulateur.

Et sinon, non, je ne suis pas un guru de l'asm

[florian66]

Mais si je t'assure tu es au moins 10 fois meilleur que moi !!
Pour les identités, je savais qu'elles existaient mais j'avais jamais réussi à les appliquées.

Je m'y met ce soir .
Du coup faudra que je revois entièrement la routine de translation.

EDIT: voila j'ai fini la matrice que tu avais commencée : http://pastebin.com/XbX7pVry
et j'ai fais la moitié du code de calcul
EDIT2: les formules n'étaient pas bonnes: voilà les bonnes
http://pastebin.com/ieBqfzRP
EDIT3: la routine de calcul est finie et prend 1436 T-states , je pense qu'il y a des optimisations mais trop complexe à mettre en place
http://pastebin.com/BZkL4LRF
les scf/ccf sont obligatoires car les autres manières (or a) altèrent le sign flag
EDIT 4
j'ai essayé avec les or a et c'est la même chose.

[florian66]

Oui je sais que c'est un double poste mais j'allais pas faire 30 edits
J'ai bien avancé, j'ai fini la routine de rotation, de translation, de calcul de la matrice, de déformation de cubes en parallélépipèdes
et j'ai pris ta routine de multiplication.
Par contre je ne comprend pas vraiment comment fonctionne le VBO .
Comment appliquer une texture à une face sans calculer tout les points ??

[TheMachine02]

Bien
Alors en fait ce que j'appelle VBO dans gLib n'est absolument pas un VBO XD
Il faut plutôt concevoir ça comme un buffer dans lequel j’enregistre les info des vertex pour éviter des le recalculer dès que j'en ai besoin d'un.
D'ailleur cette méthode va sans doute changer dans les prochaines versions de gLib car y'a trop de bottleneck débile lors de l'adressage/copie des points. Pour ça moi je dis implémente ta propre méthode, tout dépend de ton pipeline. (Dans tout les cas, un cache pour les vertex est cependant recommandé).

Les textures sont ... compliquées Commence déjà par faire un "flat" shading (une seule couleur par triangle).
Après si tu veux plus d'info sur les textures, regarde par là : http://en.wikipedia.org/wiki/Texture_mapping , sachant que la perpective corrected ne peux définitivement pas être faite sur calculatrice (faut pas trop lui en demander non plus).

[florian66]

Ah d'accord je commence
Aujourd'hui j'ai pleins de solutions :
est ce que tu crois que 4 données par cube ça suffit ?
On a les coordonnées d'un point (x,y,z) et ensuite on à des vecteurs x,y,z avec lesquelles on peut déterminer les 7 autres sommets du cube
Je pense que ça peut etre une bonne idée pour économiser de la place mais ça prendrais un peu plus de temps en raison des calculs ( 7 additions)
Et aussi ça permettrai de gerer facilement l'octree


EDIT: Aussi on peut eviter de calculer la rotation pour 6 sommets d'un cube.
Pour le VBO, je vais faire un buffer de 384 octets permettant de stocker 64 points ou 8 cubes.
Pour les textures, je vais faire la méthode affine.

[TheMachine02]

Si tu veux réduire les données, un seul point suffit, puis un vecteur (h,w,l), soit deux données.
Après, si tout tes cubes ont la même taille, on peut jouer intelligemment et ne calculer que trois rotations par frame... mais bon après c'est le rendu graphique qui va bottlenecké XD
Je m'explique:
on rotationne trois points, correspondant à (h,0,0);(0,w,0);(0,0l) et on récupère les coordonnées rotationnées des cubes en faisant des additions entre les trois vecteurs récupérés. (Car ceux-ci forment le repère de base).
Pour les textures, vaut mieux essayer de le mettre en dernier, je suis quasi-certains que la calculatrice n'a pas les ressources suffisantes pour faire du réel-time avec des textures... Mais bon faut toujours essayer.
Pour te donner un ordre de grandeur, le z80 à 6000000 de cycles à 6MHz. En comptant sur la limite jouable +-12fps, il ne reste plus que 500000 cycles par frame, -55000 pour fastcopy, soit +-450000 cycles. Pour une texture (oui, une seule), j’atteins environ 100000 cycles pour remplir 1/4 de l'écran (bon faut optimiser), mais ça va être chaud de les avoir En comparaison, le flat-shading se tient à +-20000cycles (pour l'instant, mais j'espère atteindre 4TStates/pxl)

[florian66]

Ben pour les cubes, effectivement ils font la même taille ( n de coté en fonction de la profondeur de l'octree ) mais ils pourraient être regrouper par 8 pour former un cube plus gros ( pour l'octree )
mais pour les vecteurs, on ne peut pas les combiner pour faire un vecteur du genre (h,w,l) ??
Pour les textures faut voir.