Vrally - Page 5

Un truc qui déchire tout

MacIntoc
a écrit : pour le passage de couleur à NVG, utilise plutot la diffusion d'erreur (error diffusion) plutot que la couleur la plus proche (nearest color). Le résultat devraient être encors plus jolies.

Autre conseil, un truc con mais qui marche bien: pour simuler des changements d'altitude, monte ou descend la ligne d'horizon (comme dans Lotus quoi).

Il me semble que ct un bresenham par segement

En asm ?

surement

Sans aucune division ?

certainement
perso, dans mon alogo de ligne, y'a pas de sivision, juste de décalages (enfin me semble)

Moi aussi dans mon algo sans traitements segmentés, il n'y a aucune division.
Mais j'avais essayé de réfléchir à un algo par traitements segmentés et je n'arrivais pas à me débarrasser d'une division...
Ce qui fait que j'ai abandonné l'idée, parce que pour des petites lignes ça ne me paraît pas intéressant vu le temps que prend la division...

pour ne pas se faire chier avec eds division, faut, je pesne, utiliser les priorités des opérateurs comme:
x + x++
et tous ces choses là

Je ne vois pas le rapport avec les divisions

tu fais une division pout ton taux d'accroissement, c bien ca ?

Pour avoir le coeff directeur, qui indique combien de pixels je dois tracer à chaque segment. Et le reste de la division me sert aussi pour calculer l'erreur, pour savoir si je dois rajouter un pixel en plus à la fin de mon segment

oué, le teux d'accroisement, c pariel

OK, je n'étais pas sûr
Bah, je n'ai pas compris comment tu fais pour l'éviter

nEUrOne a écrit :
pour ne pas se faire chier avec eds division, faut, je pesne, utiliser les priorités des opérateurs comme:
x + x++ et tous ces choses là

Non, il ne faut surtout pas faire ça, parce que ce n'est pas du C valide! Tu n'as pas le droit d'utiliser x et x++ dans le même "sequence point" (c'est-à-dire en gros dans la même expression).

Pkoi je ne pourrais pas le faire ?
Ca me parrait tout à fait logique de poivoir le faire, la priorité ds opérateur est une regle stricte !

bah moi aussi on m'a toujours parlé de priorités des opérateurs, je vois pas le problème (on en avait déjà parlé dans un autre topic mais je n'en était pas sorti plus convaincu...)

Bon, bah moi je n'ai toujours pas compris comment tu évites ta division en faisant ça.
Et puis je code en ASM.

Ximoon: la règle des opérateur fait partie des normes, que ce soit ANSI ou ISO, donc je ne vois pas pkoi ne pas l'utiliser

Jackie: bah si tu code en asm ...

Si je code en asm qu'est-ce qu'il y a ?
Tu peux m'expliquer comment tu évites la division, stp ?
Ça fait 5-6 posts que je le demande à chaque fois...

Comme c'est un taux d'accroissement, c'est une certaine fois y++ et une certaine fois x++ .. vu que tu travailles en pixel

nEUrOne a écrit :
Pkoi je ne pourrais pas le faire ? Ca me parrait tout à fait logique de poivoir le faire, la priorité ds opérateur est une regle stricte !

Tu confonds priorité d'interprétation et ordre d'évaluation.

nEUrOne a écrit :
Ximoon: la règle des opérateur fait partie des normes, que ce soit ANSI ou ISO, donc je ne vois pas pkoi ne pas l'utiliser

Parce que justement les normes ANSI et ISO interdisent explicitement de faire ça!

Je ne vois pas où c'est interdit, j'ai sous les yeux un boukin de C de O'REILLY et qui dit bien que lorsque deux opérateur ont la même priorité, c'est l'ordre d'évaluation qui va primer ...
Alors où est-ce que je ne comprends pas ?

C'est ton livre qui est faux.

>Parce que justement les normes ANSI et ISO interdisent explicitement de faire ça!
C'est pas logique dans ce cas la le compilateur devrait retourner un erreur alors.

>>Je ne vois pas où c'est interdit, j'ai sous les yeux un boukin de C de O'REILLY et qui dit bien que lorsque deux opérateur ont la même priorité, c'est l'ordre d'évaluation qui va primer ...
Alors où est-ce que je ne comprends pas ?
>C'est ton livre qui est faux.
tu est sur de toi car mon prof d'info m'avais dis la même chose que le livre de Neurone. Et la logique me dit la même chose aussi

Uther Lightbringer a écrit :
>Parce que justement les normes ANSI et ISO interdisent explicitement de faire ça! C'est pas logique dans ce cas la le compilateur devrait retourner un erreur alors.

Il ne peut pas le détecter dans tous les cas. Et les standards ne l'obligent pas à donner une erreur quelle qu'elle soit. C'est de l'undefined behavior, le compilateur peut faire absolument ce qu'il veut. Il a tout à fait le droit de sortir du code qui détruit la machine s'il a envie, le standard C le lui permet explicitement.

>>Je ne vois pas où c'est interdit, j'ai sous les yeux un boukin de C de O'REILLY et qui dit bien que lorsque deux opérateur ont la même priorité, c'est l'ordre d'évaluation qui va primer ...
Alors où est-ce que je ne comprends pas ?
>C'est ton livre qui est faux. tu est sur de toi

Oui.

car mon prof d'info m'avais dis la même chose que le livre de Neurone. Et la logique me dit la même chose aussi

Malheureusement, la confusion entre priorités d'interprétation et ordre d'exécution est très fréquente.

Je confirme ce que dit Kevin.

pour info (standard C99): section 5.1.2.3 "Program execution"
Et la liste des Sequence points dans l'annexe C.

#140: nEUrOne, tu n'es pas très explicite...

je confirme aussi ce que dit kevin.
mes sources :
bible c de K&R, ainsi que bible c++ de B stroustup.
je pense que ça devrait suffire comme references, nan ?

PS : c bien du bresenham segmenté, mais moins efficace que la routine d'ExtendeD, malheuresement

PPS :
les routines de bresenham segmentés ne sont pas adaptés aux segments courts..
faut pas l'utiliser pour eux


PPPS :
faudrait tout de meme relativiser pour la vitesse de ma routine par rapport à celle d'ExtendeD : on a pas fait de benchs sérieux sur *tous* les coeff directeurs..
il est possible que la mienne soit plus rapide dans la moitié des cas. faudrait voir sa routine.
mais bon je fais confiance à ExtendeD, il est probable qu'il ait géré ces cas là.