REPRÉSENTATION D'UNE SPHÈRE EN 3D (FLAT SHADING)
BruNews
Messages postés
21040
Date d'inscription
jeudi 23 janvier 2003
Statut
Modérateur
Dernière intervention
21 août 2019
-
4 sept. 2006 à 18:58
cs_ManChesTer Messages postés 374 Date d'inscription vendredi 20 octobre 2000 Statut Modérateur Dernière intervention 15 janvier 2021 - 12 sept. 2006 à 17:09
cs_ManChesTer Messages postés 374 Date d'inscription vendredi 20 octobre 2000 Statut Modérateur Dernière intervention 15 janvier 2021 - 12 sept. 2006 à 17:09
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/39421-representation-d-une-sphere-en-3d-flat-shading
https://codes-sources.commentcamarche.net/source/39421-representation-d-une-sphere-en-3d-flat-shading
12 sept. 2006 à 17:09
Biensur certains compilateus permette une "bonne" obtimisation mais aucun ne vaudra jamais la maitrise des cycles machines que tu à en asm.
Certains compilateurs actuels sont memes "contre-performant", malheureusement, il n'y a pas que des bons compilos qui existent....
Mais je suis d'accord avec toi la plupart des compilos c permettent de généré un code assez obtimisé, mais il faut etre réaliste ce n'est pas le cas de tous les compilos (regarde le code que génere le compilo vb par exemple)....
Nasman,
Tu a raison les fonctions graphiques sont souvent "définies" dans des langages de haut nivau.
Prenons l'exemple de OpenGl que je connais bien, c'est bien une "boite noire" pour toi, bien que la doc détaillée du standard OpenGl se trouve sur le net et est accesible à tous mais peux de développeurs vont faire l'effort de lire les docs à se sujet, surtout qu'elle est énorme et tres réberbative.
Le principe de opengl:
le "cpu" de la carte graphique contiend des fonction opengl en interne, c'est du code 100% assembleur qui est traduit sous forme de shéma électronique et inclus dans la "partie opengl" de la puce de la carte graphique.
Ce systeme est donc hyper rapide, bien plus que nimporte quel code asm que tu pourrais pondre sur ton pc à cause notament des vitesses de transfert ram pc=>vidéo=>ram pc et de la vitesse des puces qui utilisnt des shemas "figés ou semi figés" et donc baucoups plus rapides que le code interpreté par un cpu.
Le développeur moyen utilise en fait une librairie qui définit et traduit les appels et les dialogues entre le langage dans lequel il développe et les fonctions internes de la puce.
Normalement ce code ne sert qu'au transfert de commandes et ne contiend aucune routines "low-level" puisque celles ci sont dans la puce de la carte écran.
Dans les faits les librairies contennent du code "low-level" pour garantir la compatibilité opengl de certaines cartes graphiques "non compatibles" ou ne respectant pas la norme opengl.
On parle dans ce cas d'une émulation opengl. Elle n'existe en réalité que pour garantir la compatibilité de l'application.
Il faut aussi savoir que des libs opengl existent en assembleur.
Dans tous les cas c'est au développeur de choisir la "boite noire" qu'il veut utiliser (opengl, directx &co, mmx et autres de plus haut nivau mais souvent portables et donc moins performants).
Bon Coding...
ManChesTer.
11 sept. 2006 à 16:58
Il est vrai que des fonctions de manipulation d'images bien plus sophistiquées existent et peuvent éviter de refaire ce qui existe déjà. Malheureusement c'est souvent (toujours?) utiliser une boite noire et on ne connait pas le mécanisme utilisé. D'autre part ces fonctions ont été la plupart du temps développées avec un langage de plus haut niveau et à la compilation on obtient quelque chose qui est loin d'être optimisé, même si les routines utiles (qui calculent réellement quelque chose) le sont.
C'est sans doute la rançon à payer pour avoir une plus grande compatibilité entre les différents systèmes.
11 sept. 2006 à 16:54
Il faut cesser de penser qu'un compilo C est un vulgaire crétin d'automate, on n'en est plus là du tout.
11 sept. 2006 à 16:07
Je salue ton source qui est tres didactique.
Cependant il ne faut pas oublier que des outils permettent de réalisé ce genre d'objects 3d (opengl & directx) et de gerer les effets, déformations etc... Il est conseiller de les utiliser car ces outils garantissent une compatibilité à long teme et facilitent grandement le développement et les mise à jour.
Pour un dévelopement "pro", il est donc important d'utiliser un outil de ce type.
D'autre part ces outils sont fortement étudiés et obtimisés.
Certaines librairies permettent meme une compatibilité entre différents os/cpu.
Quand à l'utilisation d'une instruction "obsolete", pas de tracas, intel garantit la compatibilité dessandante des instructions.
Il est clair que l'instruction en question n'est pas obtimisée mais le but du source n'est-il pas didactique ?
D'autre part c'est bien plus obtimisé que le code généré par la majorité des compilateurs c, pascal ou autres....
Donc bravo pour ton source et continue sur cette voie qui me semble intéressante ;)
Bon Coding...
ManChesTer.
5 sept. 2006 à 15:42
Je rextifie ce que j'ai dit plus haut:
AAM a disparu en 64 bits ET est obsolète depuis le Pentium (ça fait un bail...).
Une instruction à plus de 10 cycles (donc perte 20 instructions avec parallelisation) pour traiter 2 octets, c'est abusé. Il était temps qu'elle soit enlevée définitivement.
5 sept. 2006 à 15:15
Il manque les opcodes dans la copie du livre d'intel,les voila,
D4 0A AAM ASCII adjust AX after multiply
D4 ib (No mnemonic) Adjust AX after multiply to number base imm8
Voila,information complète.
ToutEnMasm
5 sept. 2006 à 15:06
La conversion Mnemonique - octets n'est pas faite au niveau du microprocesseur qui ne connait que des octets mais par l'assembleur. Peut-être que dans l'esprit des gens d'Intel il n'existe que Masm comme assembleur.
5 sept. 2006 à 14:47
5 sept. 2006 à 14:39
"Nasm permet également d'utiliser quelques instructions comme aam 16 (prévue par intel) que Masm n'autorise pas.
"
ça c'est une contre vérité,preuve a l'appui.
Ensuite,si nasm veut rajouter une instruction de comparaison après l'instruction,c'est en dehors de la norme et sa ne rajoute rien du tout.
ToutEnMasm
5 sept. 2006 à 14:30
Nasm permet l'instruction AAM 16 qui est assemblé en D4 10. Il n'est pas besoin de rentrer les valeurs à la main ou de faire des db 0xD4,0x10.
Cf extrait du listing généré lors de la compilation
1040 hexascii:
1041 00000BFB D410 aam 16
1042
1043 00000BFD 3C09 cmp al,0x9
A+
5 sept. 2006 à 14:21
Mieux vaut prendre la référence intel qui suit,pour savoir de quoi on cause.Une troisième explication me semble necessaire.
ToutEnMasm
AAM?ASCII Adjust AX After Multiply Description Adjusts the result of the multiplication of two unpacked BCD values to create a pair of unpacked (base 10) BCD values. The AX register is the implied source and destination operand for this instruction. The AAM instruction is only useful when it follows an MUL instruction that multiplies (binary multiplication) two unpacked BCD values and stores a word result in the AX register. The AAM instruction then adjusts the contents of the AX register to contain the correct 2-digit unpacked (base 10) BCD result.
The generalized version of this instruction allows adjustment of the contents of the AX to create two unpacked digits of any number base (see the ?Operation? section below). Here, the imm8 byte is set to the selected number base (for example, 08H for octal, 0AH for decimal, or 0CH for base 12 numbers). The AAM mnemonic is interpreted by all assemblers to mean adjust to ASCII (base 10) values. To adjust to values in another number base, the instruction must be hand
coded in machine code (D4 imm8).
5 sept. 2006 à 14:10
Faut tout de même préciser que ceci respecte le standard Intel.
Extrait du vol2, Instructions Set Reference:
The AAM mnemonic is interpreted by all assemblers to mean adjust to ASCII (base 10) values. To adjust to values in another number base, the instruction must be hand coded in machine code (D4 imm8).
5 sept. 2006 à 13:19
Je ne parlais pas de l'instruction AAM tout court (donnant les octets D4 0A soit AAM 0xA mais AAM 0x10 codé avec les deux octets D4 10. Que donne le desassembleur de Masm avec les deux opcodes D4 10 ?
Ces deux octets décomposent un octet mis dans al en deux octets
ah, quotient de al par l'opérande (qui peut être différent de dix) et al qui contient le reste de la division.
Extrait du manuel de Nasm
AAM is for use after you have multiplied two decimal digits together and left the result in AL: it divides AL by ten and stores the quotient in AH, leaving the remainder in AL. The divisor 10 can be changed by specifying an operand to the instruction: a particularly handy use of this is AAM 16, causing the two nibbles in AL to be separated into AH and AL.
Vous pouvez vérifier qu'un exécutable contenant les deux octets D4 10 effectue bien l'opération citée.
Masm permet-il réellement de compiler AAM opérande avec opérande<>10 ?
A+
5 sept. 2006 à 12:49
5 sept. 2006 à 12:44
Masm n'autorisant pas certaines instructions,c'est un scoop.
ToutEnMasm
5 sept. 2006 à 09:30
Effectivement le code est loin d'être optimisé. J'avais utilisé une stackframe pour simplifier (?) le programme et utiliser ebp au lieu de esp (et éviter de compter les registres sauvegardés sur la pile). Je préfère ne pas utiliser ecx car ce dernier est utilisé comme compteur de boucle pour mes facettes. Si je l'utilise je devrais le sauvegarder au préalable et perdrais le bénéfice d'un push et pop.
Effectivement certaines instructions peuvent occuper un certain nombre de cycles mais je ne dispose pas de doc sur le nombre de cycles employés par les microprocesseurs. Je suppose que celà dépend si on utilise un 386, pentium ou plus performant...
J'ai essayé de réduire le temps d'exécution en travaillant avec des entiers mais la précision sera peut-être insuffisante dans certains cas.
Enfin concernant Nasm, je n'utilise pas les macros permettant de définir les différentes procédures et de ce fait le code est traduit directement sans rajout de stackframe ou autres instructions. Nasm permet également d'utiliser quelques instructions comme aam 16 (prévue par intel) que Masm n'autorise pas.
A+
4 sept. 2006 à 18:58
pourquoi tu crées une stackframe pour tes fonctions ???
'enter' doit prendre 10 cycles au moins et 'leave' 4, ça fait beaucoup à chaque appel surtout que inutile, non ?
Voyons Projection():
push edi
mov ecx, [esp+8] ; adresse de A
mov edi, [esp+12] ; adresse de destination
mov eax, [ecx]
; etc
; etc...
xor eax, eax
pop edi
ret 8
hors
mov eax, -1
pop edi
ret 8
Je remplace partout (dans cette fonction) ESI par ECX (gagne PUSH POP) vu que ECX inutilisé et pas d'appel externe dans la fonction.
Je n'utilise pas nasm, tu nous diras si va bon ainsi.