Quelques questions sur Genlib - Page 2

nitro
:

Pollux :
ben c ce que dit PpHd, le clipping est moche

Ce que dit PpHd c'est que le clipping simple qu'il fait actuellement est faux. Ce n'est pas parce que les 3 points sont en dehors de l'écran que le polygone n'est pas visible

faux ne me paraît pas être le terme exact. Ce qu'on veut en utilisant un moteur, ce n'est pas forcément que tous les triangles qui soient dans le demi-espace visible soient rendus à l'écran, c'est que ça soit le cas sauf dans des cas qui de toutes façons seront pathologiques (exemple : le joueur est collé à un mur alors qu'il n'y a pas de protection contre ça) et dans ce cas là le moteur ne devrait pas se mettre à ramer (par exemple en remplissant tout l'écran avec un triangle dont les coordonnées sont de toutes façons en overflow). C pour ça que je préfère le terme moche parce qu'un moteur peut très bien être "théoriquement" faux sans être moche

Pollux :
faux ne me paraît pas être le terme exact. Ce qu'on veut en utilisant un moteur, ce n'est pas forcément que tous les triangles qui soient dans le demi-espace visible soient rendus à l'écran, c'est que ça soit le cas sauf dans des cas qui de toutes façons seront pathologiques (exemple : le joueur est collé à un mur alors qu'il n'y a pas de protection contre ça) et dans ce cas là le moteur ne devrait pas se mettre à ramer (par exemple en remplissant tout l'écran avec un triangle dont les coordonnées sont de toutes façons en overflow). C pour ça que je préfère le terme moche parce qu'un moteur peut très bien être "théoriquement" faux sans être moche

Il n'y a pas que le cas pathologique que tu cites... Si le triangle se trouve par exemple en haut à gauche, avec ses trois points en dehors de l'écran, alors seule une toute petite partie de l'écran doit etre remplie (le coin supérieur gauche), et si ce n'est pas fait, on aura l'impression que la fasse la plus proche de l'objet disparait magiquement des qu'il se rapproche du coin superieur gauche de l'écran, meme si celui-ci est à une distance raisonable. Je considère ça comme un bug sérieux.

b]Si tu arrêtais d'utiliser cette librairie boguée: [/b]
Alors déjà si j'utilise cette librairie c'est pour quelque chose de bien particulier. D'ailleurs pour afficher uniquement des objet en OR, il n'y a pas besoin de Genlib qui est un peu moins rapide si on utilise uniquement des routines OR.
Sinon je ne pense pas qu'elle soit buggé. C'est vrai que si je veux faire du clipping il faut que je le face moi même : c'est bien mieux. Par contre ce que j'espère c'est que la routine ne perd pas de temps à tester si il faut clipper la ligne ou pas.
Par contre qd j'utilise le seul clipping que j'ai programmé les faces partent dans tout les sens. A priori ça ne vient pas de Genlib parce-que aucune ligne ne sort de l'écran.

Par contre c'est pour dessiner dans les buffers que je n'est pas compris... enfin pr l'instant je n'ai pas plmus chercher que ça !
Parce-qu'en faisant comme ceci :
gl_put_medium_string(DScr[0],10,10,sfps);
...on voit que ça clignote sur le shot.
Bon bah du coup je sais pas trop comment je vais faire pour résoudre ce pb de clipping.
Et puis sinon c'est possible de faire "du texte formaté" avec des variables (short par ex) avec Genlib où alors il faut utiliser sprintf() qui est terriblement lente ?

Dans une prochaine version de TIGCC, il y aura des routines rapides de itoa. Les utiliser et utiliser strcat sera peut-être plus rapide que d'utiliser sprintf, du moins jusqu'à un certain point... Si ça ne va pas et que tu veux faire plus rapide, tu peux toujours modifier les itoa et te faire un strcat approprié, TIGCC est open-source...

Ah, oui d'accord je viens de m'apercevoir que j'utilisais des unsigned int pour les vertices, enfin les sommets en 2D !

Non, finalment ça ne change rien.
il y aura des routines rapides de itoa
Ah, ok, c'est bon à savoir !

Si tu les veux tout de suite, je peux te les envoyer, puisque c'est moi qui les ai faites...

Ouais si tu veux.

Pour tes problèmes de déformations quand tu essaies de clipper tes faces, vérifie que TIGCC sort un code correct. Il m'est très souvent arrivé que TIGCC caste tes résultats de multiplications en short avant de les diviser, et ça me provoquait le genre de déformations que tu décris.

Et je précise que c'est le code qui est faux dans ce cas, pas le compilateur.
int*int=int, short*short=int, char*char=int, que ça dépasse ou non. Pour avoir un long en résultat, il faut transtyper au moins une des variables en long.

Oui, c'est vrai, en transtypant correctement tu devrais pouvoir t'en sortir, mais personnellement, j'ai toujours eu beaucoup plus de mal à trouver le transtypage correct qu'à écrire le code correct en ASM

Ouais, je sais pas. Souvent il y a des trucs bizarre et puis après plusieurs compilation ça passe. Mais là ça peut aussi venir de mon code je sais pas.
Parce-que pour clipper je ne fais rien de spécial. Juste des tests et puis des affectation de valeur à l'intérieur de la routine de remplissage. C'est très lent mais je voulais voir le résultat.