VB/VB.Net Integer, Byte . . .

[anodu94]

Salut à tous Ce soir, je me suis penché sur les types de données et j'ai essayé de comprendre parfaitement le tuto de bouh2. Cependant, j'ai quelques petits problèmes de compréhension. Par exemple, je me demande, à quoi ressemble mes 4 octets ( Integer ) lorsque j'envoie la mapid via le packet 225 ( Mapid : 80217092 ), j'ai compris le fait que si on a la cellid 123 par exemple, avec D2.0 on aura un Integer : 0 0 0 123, pour une chaine de caractère on indique la taille via un short, et ainsi on sépare les caractères du integer.
J'ai fait beaucoup de tests pendant plusieurs heures avec ces sites : http://rishida.net/tools/conversion/ et http://sebastienguillon.com/test/javasc ... sseur.html mais je n'arrive pas à avoir ma mapid via l'hexa envoyé : 0x04C80404 ou par le contenu du packet : 03 85 04 04 C8 04 04

J'ai remarqué en revanche, qu'un logiciel ( Packet Reader ) fait par un membre de Cadernis il me semble, arrive a trouver la Mapid via le contenu du packet, c'est ça qui m'a poussé à chercher.

Je remercie d'avance celui/celle qui pourra me renseigner, parce que ça me stress ces histoires là

A plus !

 

[ToOnS]

04 C8 04 04 -> 04 * 256 * 256 * 256 + C8 * 256 * 256 + 04 * 256 + 04

ou (04 << 24) + (C8 << 16) + (04 << 8) + 04

tu dois pouvoir trouver dans overedge ca :
Public Overrides Function ReadUInt32() As UInteger
Return (CUInt(ReadByte()) << 24) + (CUInt(ReadByte()) << 16) + (CUInt(ReadByte()) << 8) + ReadByte()
End Function

 

[anodu94]

Merci ToOnS pour ta réponse mais je ne comprends pas encore quelques petits trucs xD, déjà n'aurais tu pas oublié un 04 :
04 04 C8 04 04 au lieu de ce que tu as mis 04 C8 04 04. Là n'est pas le problème, j'ai essayé de calculer 04 * 256 * 256 * 256 + C8 * 256 * 256 + 04 * 256 * 256 + 04. Si j'ai bien compris, je dois multiplier et additionner tous ça. Encore une petite question, C8, est bien égal à 200 ? Enfin je crois.

Le premier 04 de : 04 04 C8 04 04 est bien le short de 2 octets pour indiquer la taille ?

Pour finir, 04 est encodé sur 3 bytes, C8 sur 2 bytes, 04 sur 1 byte et 04 sur quoi ? ( Selon l'ordre de ta réponse )

Merci et à bientôt ! Ca commence à s'éclairer dans ma tête.

 

[ToOnS]

04 C8 04 04 c'est chacun un byte (un octet) en hexa , si tu as windows 7 tu peux utiliser la calculette en mode "programmeur" , tu appuis sur hexa tu tapes C8 et tu appuis sur decimal si t'as pas alors oui C8 = 200

on sait que la mapid est sur un integer (ou uinteger je sais plus) donc toujours sur 4 bytes pas besoin d'un (ou 2) byte de taille , ca c'est que pour les strings (comme elles ont une taille variable) donc ici il y'a bien que 4 bytes , j'ai pas oublié un 04

pour compter on part du byte le plus a droite 04 , comme un byte va de 0 a 255 alors avec 1 seul byte on peu pas aller au dessus de 255 mais comme c'est bien foutu y'a encore 3 byte , on prend le second (en partant de la droite) encore 04 mais * 256 comme on est en base 16 (woaw on peu compter jusque 65536) puis encore l'autre a droite C8 * 256 *256 pour les memes raisons (ca pousse au max a 16777216 mais ca suffit pas encore pour un uintger) , on prend le 4ieme 04 *256 *256 *256 , on arrive a la valeur max d'un uinteger : 4294967296

http://fr.wikipedia.org/wiki/Hexad%C3%A9cimal

 

[anodu94]

Donc si je fais le calcul : 4 * 0 + 4 * 256 + 200 * 256 * 256 + 4 * 256 * 256 * 256 = 80281600

Ce n'est pourtant pas ma MapId. A moins que je n'ai pas compris quelque chose.

 

[ToOnS]

4 + 4 * 256 + 200 * 256 * 256 + 4 * 256 * 256 * 256 = 80217092
pas 4*0 parceque *0 ca veut dire que y'a un byte qui sert a rien

et Donc si je fais le calcul : 4 * 0 + 4 * 256 + 200 * 256 * 256 + 4 * 256 * 256 * 256 = 80281600 heu change les piles de ta calculette

 

[anodu94]

Hehe Merci beaucoup ToOnS J'ai compris, je me sens libre !

 

[ToOnS]

cool alors ca veut dire aussi que t'as compris que un integer ou un uinteger ca tien sur 4 octets en memoire et que comme on a tous que 256ko de memoire (ben quoi j'ai un vieux pc) si tu veux compter jusque 100 faut pas utiliser un integer mais plutot un byte (qui va jusque 255) qui prend que un octet de memoire donc tu sauves 3 octets de ma petite ram

ou alors tu consideres qu'on a tous au moins 2Go de ram et que dans ce cas 3 octets d'economisés on s'en tape et tu utilises quand meme un integer

 

[anodu94]

En fait je me plaçais plutôt côté serveur, parce que quand j'ai relu le tuto de bouh2, je me suis dit ( sur le protocol 1.xx ), qu'il ne devait pas avoir grand monde sur les serveurs dofus/que les serveurs ( hébergeurs ) étaient des machines de guerre. Et ce côté amélioration dans le protocole D2.x ma intéressé alors je me suis dit, pourquoi pas compléter mes connaissances et je t'en remercie ToOnS.

 

[FastFrench]

cool alors ca veut dire aussi que t'as compris que un integer ou un uinteger ca tien sur 4 octets en memoire et que comme on a tous que 256ko de memoire (ben quoi j'ai un vieux pc) si tu veux compter jusque 100 faut pas utiliser un integer mais plutot un byte (qui va jusque 255) qui prend que un octet de memoire donc tu sauves 3 octets de ma petite ram

ou alors tu consideres qu'on a tous au moins 2Go de ram et que dans ce cas 3 octets d'economisés on s'en tape et tu utilises quand meme un integer

En fait, c'est même pire que ça.

Sur les processeurs actuels (32 bits et 64 bits), c'est souvent plus performant de traiter des données sur 32 bits que des données sur 8 ou 16 bits.
Ainsi, une structure du genre :
struct S1
{
char prefix; // 1 octet
int data1; // 4 octet
int data2; // 4 octet
int data3; // 4 octet
}

sera le plus souvent moins performante que :
struct S2
{
int prefix;
int data1;
int data2;
int data3;
}

car dans le premier cas, data1, data2 et data3 ne sont pas correctement alignés sur des mots de 32 bits. Ainsi pour accéder à S1.data2 par exemple, il va falloir lire deux mots de 32 bits et reconstituer la donnée requise. Alors que S2.data2 est directement accessible car correctement aligné.

C'est une des raisons pour lesquelles il est conseillé d'utiliser par défaut le type int en C / C++ / C#..., qui correspond à l'entier géré nativement par le processeur (16 bits minimum).

Ceci dit, comme on est dans la partie "VB", à priori on s'en tape un peu de l'optimisation...

 

[anodu94]

Tu critiques le VB là ;p

 

[FastFrench]

Pas vraiment, je ne fais que constater une évidence. Quand on choisit le VB ou VB.Net, c'est à priori dans une optique de simplicité, pas d'optimisation.

 

[anodu94]

J'en suis conscient, c'est un des langages de haut niveau donc ... Vraiment très simple à prendre en mains Après, par rapport au niveau de programme que la communauté de Cadernis code, on n'est pas dans la perfection de l'optimisation donc bon ^^, chaque langage a ses caractéristiques.