Moteur 3D asm Ti 83(+)

[florian66]

Mince pour ionfastcopy alors c'est avec out(11) c'est obligé
Sinon pour la version finale oui effectivement je veux faire de façon a ce que toues les faces soient présentes mais que les faces non visibles ne soient pas calculée et soient des 0 tout simplement.
Que veut tu dire par gérer les cubes par zone ??
Euh sinon pour le cliping si il faut je peux utiliser les angles d'Euler même si je les aime pas

[TheMachine02]

Et bien ne pas gérer le monde comme une seule entité, mais comme de multiple sous cube, avec un discard rapide des grands cubes qui ne sont pas visible (c'est un octree).
Après le cliping, faut que tu voies, ça se jouera au niveau T-States.

[florian66]

C'est vrai que niveau rendu graphique c'est mieux mais c'est plus compliqué et une question se pose: si l'on doit considérer les faces avec des textures superficielles sur une seule face des pixels cubes ou alors des pixels cube avec une couleur pour toute les faces.

Pour le clipping, je crois que les quaternions permettent de récupérer quand même les coordonnées rotationnées (pas sûre mais ça serait bien).
Je vais voir.


EDIT:
Je fais un petit récapitulatif des fonctions necessaires :
- une fonction matris pour faire tout le reste
- une fonction rotation sur x,y et z
- une fonction de projection
- une fonction de rafraichissement (ifastcopy)
- une fonction de translation (droite, gauche, en avant, en arrière)
- une fonction scale
- une fonction de torsion (pas sûre)
- une fonction pour faire un octree
- une fonction de gestion des collisions (je crois que ça existe déjà)
Je crois qu'il en manque mais c'est déjà beaucoup.

- une fonction de vision (camera)

[TheMachine02]

voilà une routine de projection que j'ai développé pour une nouvelle version de gLib - pas encore sortie, et qui est BEAUCOUP plus rapide que l'approche brute 2 mul + 1 div, bien que légérement moins précise. Elle devrait marcher dans tout les cas(et ne pas crasher) (le cube standard marche) - excepté quand le point est hors du frustrum - mais un cliping devrait être effectué dans ce cas, donc tout va bien. Le FOV est à peu près de 80° - ce qui donne de bon résultat, sans distorsion au niveau des X,Y.

La formule de base est la suivante:

Xp=X*49/Z+48
Yp=32-(Y*49/Z)

voilà le listing : http://pastebin.com/xnwDjSu5
Y'a des optimisations à faire , mais elle est déjà pas mal à environ 700 T-States.
Je veux aussi bien essayer de faire une routine de gestion d'octree, mais il me faut plus d'info sur le monde (taille,....)

EDIT : voilà la routine de projection optimisée et je suis plutôt fier de moi sur ce coup Les performances de mon engin 3D avec cette routine sont démentes.
http://pastebin.com/3890h7HF
EDIT2: la routine ci dessus à un bug : voilà la nouvelle (sans bug) : http://pastebin.com/ivcgVp9a

[florian66]

C'est vraiment bien ta routine, bravo
sinon moi j'ai avancer sur la routine de calcul de matrice certainement moins couteuse en temps que les quaternions
sources: http://pastebin.com/1LujpvX5
j'utilise ta LUT; aussi j'ai du adapter une routine de multiplication

EDIT: ça fait environ 8000 T-states

EDIT 2 : j'ai trouvé une optimisation des multiplications qui permettrait d'enveler environ 1500 T-States en gardant certains résultats de multiplication

[TheMachine02]

Alors pour des petites notes d'optimisations :

Déjà il vaudrait mieux aligner la table de sinus sur un block de 256 bytes, c'est à dire que la première adresse de la table est de forme $XX00. En utilisant ce trick, on peux alors accéder comme ceci aux valeurs :

Code: Tout sélectionner

ld h, SinLUT/256  ;l'adresse de la LUT divisée par 256 (pas de reste)

;puis plus tard:
ld l, valeur_a_recuperer   ;valeur entre 0-255
ld a, (hl)
; a est la valeur du sinus


et avec une gestion intelligente des registres, on touche pas à h, et on modifie juste l, évitant toutes les additions inutiles, et les reloads.

Deuxièmement, il me semble que t'utilise 16 multiplications - et je ne sais pas combien avec l'optimisation, mais il vaudrait mieux utiliser cette formule :
(12 mul)
http://jeux.developpez.com/faq/math/?pa ... ations#Q35

Troisièmement, il me semble que la gestion de la matrice est un peu étrange - mais tout format peut être utilisé.

[florian66]

Oui pour le 1 je le fais
Pour le 2 je viens de le faire c'est dans l'edit 2
Pour le 3 je sais que c'est étrange mais je vais faire une matrice 3*3
Je fais tout ça ce soir

EDIT: j'arrive à environ 6070 T-states ce qui est bien , je fais que 12 multiplications et le code est plus court.

EDIT2 : voilà le code pour la routine à 6087 T-states (j'avais oublié un truc: D )
http://pastebin.com/Ds1wUic3

[TheMachine02]

Bien
Juste un problème : je suis quasiment sur qu'elle ne va pas marcher
La multiplication que tu utilise multiplie deux nombres non signés, il faut cependant que les entrées soient signées.

[florian66]

Ah mince
j'avais oublier ce truc encore, c'est pour ça que tu utilise une routine bizarre dans gLib pour multiplier
mais j'ai pas trouvé de routine de multiplication signée sur le net
ah mais si je sais (je pense)
si les nombres sont positifs alors on laisse positif
si l'un des deux est négatif, on le met positif puis on passe le résultat en négatif
si les deux sont négatifs alors on les mets en positif et on garde le résultat
un autre problème c'est la troncature, je sais pas si on peut le faire sur un nombre négatif et que le résultats soit juste


EDIT: j'ai trouvé une routine plus simple une routine qui fait a*de
mais pourquoi ta routine est si bizarre ?? c'est une optimisation de mult_a_de ??

[TheMachine02]

La routine présente dans la tranformation des vecteurs est effectivement une routine de*a signée, avec a dans [-64,64] et de dans [-512,512] et optimisée par un guru de l'asm C'est pour ça qu'elle peut te paraître étrange.