Partir du Mesh pour obtenir les données .hgt ?

[AIME43]

value = (((buffer.w & $00FF) << 8) ) | ((buffer.w & $FF00) >> 8) -> cela donne 0
et avec les FF inversé pas la bonne valeur

[PhM]

value = (((buffer.w & $00FF) << 8) ) | ((buffer.w & $FF00) >> 8) -> cela donne 0
et avec les FF inversé pas la bonne valeur

Comment veux-tu que je fasse s'il me faut deviner de quoi il s'agit, à partir de quelques lignes sans aucun contexte ni explication ?

• Est-ce que buffer.w est un 16 bits non signé ?
• Qu'est-ce que buffer ? Quelle donnée contient-il ?
• Si il y a un buffer.w y a-t-il aussi un buffer.x ? .y ? .x ? .z ?
• Que représente buffer.w ?
• Quel langage utilises-tu ?

Pour résumer, en utilisant :

    unsigned short Zob = 0xAABB;
    unsigned short Boz = ((Zob & 0x00FF) << 8) | ((Zob & 0xFF00) >> 8);
    unsigned short Baz = (Zob << 8) | ((Zob & 0xFF00) >> 8);

Boz et Baz seront égaux à 0xBBAA, ce que l'on souhaitait obtenir. Il faut que la variable d'origine, Zob dans ce cas, soit un 16 bits non signé.

PhM

[AIME43]

Que je paramètre la variable buffer en signé ou non signé ne change rien et c'est elle qui charge la donnée lue dans le fichier raw.
PureBasic.
Et j'ai dit que pour les fichiers HGT ça marche comme indiqué plus haut.
Phm le plus simple est de me donner la solution en C je transcrirais.

[PhM]

Que je paramètre la variable buffer en signé ou non signé ne change rien ...

Attention, les décalages sur des nombres signés ou non ne fonctionnent pas de la même façon.

Phm le plus simple est de me donner la solution en C je transcrirais.

Si tu regardes bien ma réponse précédente c'est déjà fait. Regarde comment Boz et Baz sont calculés, utilise l'une ou l'autre des deux façons de faire.

PhM

[AIME43]

Les 2 formules donnent la même valeur erronée.

[PhM]

Les 2 formules donnent la même valeur erronée.

Alors c'est un cas de GIGO (garbage in, garbage out). Ce que tu donnes à convertir n'est très probablement pas ce que tu penses être.

Dis moi, précisément, d’où vient la donnée que tu utilises.

PhM

[AIME43]

fichier +45+003.txt.elevation.raw de différents .dsf dont original x-plane.

[PhM]

fichier +45+003.txt.elevation.raw de différents .dsf dont original x-plane.

Ca tombe bien j'ai utilisé +45+003 pour des tests de terrain généré sur GPU.

• Quels sont les deux premiers octets que tu as dans le raw pour +45+003 (Tel quels sans conversion, dans l'ordre lu) ?
• Quelle valeurs obtiens-tu après conversion avec les deux méthodes proposées ?
• Quelle valeur t'attendais tu à avoir, celle que tu dis être la bonne ?

PhM

[AIME43]

voila, la ligne 607 c'est juste pour connaitre la valeur des bits, et c'est la valeur des 3 premier nombres lus qu'il faudrait avoir.
les 2 dernières données sont pour les 2 différentes formules

[PhM]

voila, la ligne 607 c'est juste pour connaître la valeur des bits, et c'est la valeur des 3 premier nombres lus qu'il faudrait avoir. les 2 dernières données sont pour les 2 différentes formules

Bon, si j'ai bien compris :

• La valeur lue est : 0000 0011 1111 0110, soit 03F6 en hexa.
• L'une des conversions donne : 1111 0110 0000 0011, soit F603 en hexa, ce qui est ok.
• L'autre conversion donne : 1111 0110 0000 0011, soit F603 en hexa, ce qui est ok.
• La "valeur 607" est 0000 0010 0101 1111, soit 025F en hexa, et n'a rien à voir avec les valeurs précédentes donc.

A ce stade je constate que les conversions marchent, elle donnent un résultat correct. Si j'ai raté quelque chose dans ton image réponds moi en clair aux points suivants :

• La valeur en entrée de conversion est : __________
• La valeur en sortie de la conversion 1 est : __________
• La valeur en sortie de la conversion 2 est : __________
• La valeur que j'attends est : __________

PhM

[AIME43]

Voili voila

A ce stade je constate que les conversions marchent, elle donnent un résultat correct. Si j'ai raté quelque chose dans ton image réponds moi en clair aux points suivants :

• La valeur en entrée de conversion est : _______1014___
• La valeur en sortie de la conversion 1 est : ________62979__
• La valeur en sortie de la conversion 2 est : ________62979__
• La valeur que j'attends est : _____607_____

PhM

[PhM]

Ok, ça confirme ce que je soupçonnais.

Donc : Il n'est pas possible d'avoir 607 en sortie de conversion si 1014 est donné en entrée. Pour avoir 607 en sortie il faut avoir 24322 en entrée. Il faut que tu vois avec ton programme ou les données lues, je n'en sais pas plus.

PhM

[AIME43]

Si je paramètre value en signé j'obients -2557.

[PhM]

Si je paramètre value en signé j'obients -2557.

Tu ne peux pas utiliser de nombres signés pour les opérations de décalage (<< et >>) pour convertir l'endianness. La raison est que si le nombre est négatif c'est un décalage arithmétique qui va être utilisé au lieu du décalage logique, le bit de signe va alors être répliqué lors du >> ce qui fausse complètement le résultat.

PhM