decalage de bits - Page 1

g lu le tuto de sBibi sur la 3d, tres bien fait et tout...
cependant g po compris un truc;

-> cos(roll)*cos(yaw) - sin(pitch)*sin(roll)*sin(yaw)

Mais il faut garder a l'esprit que les valeurs de nos sinus et cosinus sont multipliees par 256, donc en realite nous avons:

-> cos(roll)*256*cos(yaw)*256 - sin(pitch)*256*sin(roll)*256*sin(yaw)*256
-> cos(roll)*cos(yaw)*2^16 - sin(pitch)*sin(roll)*sin(yaw)*2^24

Et nous voulons le meme format de virgule fixe qu'au depart, soit une virgule fixe sur 8 bits, toujours dans l'exemple de la premiere case, il faudrait donc faire:

-> (cos[roll]*cos[yaw]*2^8 - sin[pitch]*sin[roll]*sin[yaw])/2^16

Soit, en utilisant les decalages de bits:
-> (cos[roll]*cos[yaw]<<8 - sin[pitch]*sin[roll]*sin[yaw])>>16

mais pour koi il passe de

-> cos(roll)*cos(yaw)*2^16 - sin(pitch)*sin(roll)*sin(yaw)*2^24
a
-> (cos[roll]*cos[yaw]*2^8 - sin[pitch]*sin[roll]*sin[yaw)/2^16

pourkoi il a divise et po multiplie???

ou alors kelkun voudrai til bien expliker komment fonctionne le principe de la virgule fixe a un debile mental??

je te dirai bien google
franchement, le principe es tpas dur :
sur les bits de poids faible, tu stocke ce qu'il y a normalement après la virgule
sur les bits de poids fort... ce qu'il y a normalement avant

ensuite, sorti de ça, c plus compliqué à expliquer
(et je connais pas suffisaùent)

bin oue le principe est po dur mais c l'application!!

avaec des sin ou des cos on obtien des chiffres du genre
0.846576 (o pif)
pour avoir des short (souci d'optimisation)
fo * par 256
ca fe donc (tjs o pif) 232.21314
comme c un short, ca fe 232

mais apres fo tout rediviser par 256??
et ca consite en koi concrteement les commandes du types <<8 ou >>16???

l'application, ma foi, g jamais utilisé
(enfin, via des fonctions qui faisaient tout toutes seules )

et ca consite en koi concrteement les commandes du types <<8 ou >>16???

décalage de 8 (respectivement 16) bits bers la gauche (droite)
soit multiplication par 2^8 (division par 2^16) (ou l'inverse, je me goure à chaque fois )

oki c ce ke je pensait, mais kan je les utilise,
tigcc me met
"right shift count >= width of type"
....c a dire???
c a dire ke je la programmation c po fait pour moi!!!

ben, tu dois fait un décalage de supérieur (ou égal) au nombre de bits de la variable

par exemple
short a;
a= ...;

a >> 16;
=> ben là, ça doit te mettre ce warning...
parce qu'un short est sur 16 bots... et que tu décale de plus (ou égal) à 16 nits... donc tu fou tout le contenu à la corbeille

aaaaaaaaaaaaaaaaaaaaaa
okokokok

mais pourtant c ce ka mis Sbib dans son tuto et il travaille avec des short

ben demande lui...
j'en sais rien moi
mais c ce que je suppose en voyant le warning

oki merci kan meme
il est connecte souvent sBibi?
ou fo ke je lui ecrive un mail???

il était connecté tout à l'heure

Il est aussi souvent sur IRC, channels #arf et #3l33t (et d'autres mais je connais pas le nom), c'est peut-être plus simple pour parler

#krypton aussi

KWT-ArpiK
a écrit : mais pourtant c ce ka mis Sbib dans son tuto et il travaille avec des short

Il utilise (ou du moins devrait utiliser) des long pour les calculs intermédiaires. On a besoin de travailler sur des long pour faire des multiplications de nombres en virgule fixe short, justement à cause du décalage à faire à la fin.

Je crois que sBibi sait très bien ce qu'il fait

squale92 a écrit :
#krypton aussi

Heu... oui mais vu le nombre d'utilisateurs sur #krypton j'ai un peu tendance à oublier son nom

Kevin Kofler a écrit :
Il utilise (ou du moins devrait utiliser) des long pour les calculs intermédiaires. On a besoin de travailler sur des long pour faire des multiplications de nombres en virgule fixe short, justement à cause du décalage à faire à la fin.

Même avis que Ximoon... Compte tenu de ce que sBibi fait et a fait, je pense qu'il sait mieux que toi comment s'y prendre

Heu... oui mais vu le nombre d'utilisateurs sur #krypton j'ai un peu tendance à oublier son nom

ben, pas étonnat qu'il y ait personne si personne le connais
(cela dit, il me sert qd je veux faire des pv à plusieurs)

squale92 a écrit :
ben, pas étonnat qu'il y ait personne si personne le connais

Boah je plaisante

erf
enfin, comme je disais, il me sert surtout pr des pv à plusieurs...

atta ... il a bien dit que son tuto comportait des erreurs de code pour que le lecteur ne recopisse pas bêtement les codes ... donc, c'est peut-être fait expres !

nEUrOne
a écrit : atta ... il a bien dit que son tuto comportait des erreurs de code pour que le lecteur ne recopisse pas bêtement les codes ... donc, c'est peut-être fait expres !

C'est une excuse ça. La vérité est qu'il a été trop paresseux pour corriger ces erreurs. Je parie qu'il n'a même pas testé le code qu'il a mis dans son tutorial. Et c'est une attitude vraiment déplorable: on écrit un tutorial avec du code pourri et bogué, et on se fout de la gueule des débutants qui essayent d'utiliser ce code. Le minimum quand on écrit un tutorial est de tester les morceaux de code qu'on y met et de corriger les éventuelles erreurs. Donc le tutorial de sBibi --> poubelle direct. Si vous voulez un tutorial 3D sérieux, cf. http://tict.ticalc.org/projects.html#ref_tutorials (series 2).

Pour un fois Kevin je suis d'accord avec toi mais il ne faut quand même pas dire que le tuto de sbibi et à mettre à la poubelle, d'ailleurs je l'ai lus et je le trouve bien détaillé et précis mais malheuresement incomplet donc il ne faut pas dire que c'est de la merde bien au contraire.

Je trouve ça extrêmement bien que le lecteur n'ait pas qu'à recopier le code du tuto pour faire son prog. Bon, c'est vrai que la méthode de sBibi est un peu vilaine, mais je suis tout de même d'accord avec ce comportement.
Et Kevin, ce n'est pas pour ce petit prétexte qu'il faut préférer le tuto de la TICT. Ne t'inquiète pas, il est bien aussi, celui de la TICT, mais ils ne parlent pas de la même chose. La TICT explique le fonctionnement d'un raycasting, et sBibi d'un Trinity-like.

lol c parti en couille
mdr moi ca me derange po tant ke ca kil y ai des "erreurs" paske ca me fait apprendre ...
mais il devrai prevenir kan meme paske g chercher pendant lontemp un truc ki pourra jamais marche...
enfin moi je critike pas paske ca prend du temps de faire un tutorial!!!

Est-ce que tu pourrais t'appliquer un peu quand tu écris, s'il te plait ?
C'est vraiment très pénible à lire...

Kevin Kofler a écrit :
C'est une excuse ça. La vérité est qu'il a été trop paresseux pour corriger ces erreurs. Je parie qu'il n'a même pas testé le code qu'il a mis dans son tutorial. Et c'est une attitude vraiment déplorable: on écrit un tutorial avec du code pourri et bogué, et on se fout de la gueule des débutants qui essayent d'utiliser ce code. Le minimum quand on écrit un tutorial est de tester les morceaux de code qu'on y met et de corriger les éventuelles erreurs. Donc le tutorial de sBibi --> poubelle direct. Si vous voulez un tutorial 3D sérieux, cf. http://tict.ticalc.org/projects.html#ref_tutorials (series 2).

Comment est-ce que tu peux cracher comme ça sur un travail que tu es completement incapable de faire ? Trop facile. Fais aussi bien, on en reparlera après.

jackiechan
a écrit : Je trouve ça extrêmement bien que le lecteur n'ait pas qu'à recopier le code du tuto pour faire son prog. Bon, c'est vrai que la méthode de sBibi est un peu vilaine, mais je suis tout de même d'accord avec ce comportement.

Moi, je ne suis pas du tout d'accord. C'est absolument inacceptable de mettre des exemples de code contenant volontairement des erreurs (ou tout simplement pas testés, ce que je pense plutôt être le cas franchement). Les exemples de code dans un tutorial doivent être utilisables tels quels. Ils peuvent être susceptibles d'adaptations selon les besoins du lecteur, mais ils doivent fonctionner!

Vertyos
a écrit : Comment est-ce que tu peux cracher comme ça sur un travail que tu es completement incapable de faire ? Trop facile. Fais aussi bien, on en reparlera après.

Ça me prend 2-3 heures maximum d'écrire un tutorial sur un sujet au hasard (y compris la 3D) avec des lignes de code totalement boguées et absolument pas testées. Si je ne le fais pas, ce n'est pas parce que je ne suis pas capable de le faire, mais parce que ça ne correspond pas du tout à mes attentes de qualité. Je préfère passer mon temps sur quelque chose qui fonctionne.

Kevin Kofler a écrit :
Moi, je ne suis pas du tout d'accord. C'est absolument inacceptable de mettre des exemples de code contenant volontairement des erreurs (ou tout simplement pas testés, ce que je pense plutôt être le cas franchement). Les exemples de code dans un tutorial doivent être utilisables tels quels. Ils peuvent être susceptibles d'adaptations selon les besoins du lecteur, mais ils doivent fonctionner!

Bon, de savoir si sBibi a des exemples de code incorrects par choix ou par flemme, ce n'est pas le sujet.
Sinon, je trouve que tu as un peu raison en fait, c'est vrai que des exemples de codes doivent fonctionner, sinon ça risque d'embrouiller encore plus le débutant...
Mais je n'aime pas l'idée qu'il suffit de recopier les exemples d'un tuto pour faire un moteur 3D, je trouve ça vraiment trop facile.

De toute façon essayer de faire de la 3D n'est pas du niveau d'un débutant en programmation, donc ceux qui lisent le tuto et qui le comprennent devraient être capables de corriger les fautes d'eux-même

Kevin Kofler
a écrit : Ça me prend 2-3 heures maximum d'écrire un tutorial sur un sujet au hasard (y compris la 3D) avec des lignes de code totalement boguées et absolument pas testées. Si je ne le fais pas, ce n'est pas parce que je ne suis pas capable de le faire, mais parce que ça ne correspond pas du tout à mes attentes de qualité. Je préfère passer mon temps sur quelque chose qui fonctionne.

Donc tu pense être capable de faire en 2~3 heures le travail de sBibi ? Je te dirais très honnêtement que je n'y crois pas une seconde, donc : "chiche".