Un editeur de dbc avec Qt

Oui je sais que c'est long . Mais là ya un soucis :/

Spell.dbc s'ouvre en 1 minute environ avec celui que j'ai fait.
Et pourtant, il est en Java.

Vous devez lire n'importe comment et/ou pas optimisé du tout :/

Asedic a écrit :Oui je sais que c'est long . Mais là ya un soucis

QT, c'est super pas optimisé, mais bon, une progressBar ca bouffe le temps
Progresse 1000 par 1000 et pas 1 par 1, tu verra une différence déjà
(sinon vire la pour un compteur dans un label, ca va plus vite au refresh)

Magus a écrit :Vous devez lire n'importe comment et/ou pas optimisé du tout :/

Pour lire un dbc, ya qu'une seule méthode, nb_enregistrement*nb_colonne

Pour l'optimisation, je suis preneur si tu as du code a proposé.
Sinon mettre un hd ssd et ca va s'ouvrir en moins d'1min
(ici, vielle machine, vieux hd )

(28-05-2011 17:47)Magus a écrit :  Spell.dbc s'ouvre en 1 minute environ avec celui que j'ai fait.
Et pourtant, il est en Java.

Vous devez lire n'importe comment et/ou pas optimisé du tout :/

Avec ton truc en java moi sur mon pc j'en avais pour une demi heure x)

---

Édition :
J'ai calculé ça me fais 13milliard de choses a lire . Comme on lis 4 bits par 4 bits tu peux multiplier ça par 4 et obtenir la taille du fichier ... OMFG

---

Édition :
1000 par 1000 pour afficher c'est ... Super (pas) pratique

30 minutes avec mon DBCBrowser ?
T'as un disque dur et un processeur en carton ? Tu utilises la machine virtuelle d'IBM ?

Sinon, pourquoi lire les bits 4 par 4 ? D'ailleurs je soupçonne que tu confondes les bits et les octets. Parce que sauf erreur, lire 4 bits ( la moitié d'un octet), c'est pas possible :/
Lire les octets 4 par 4 n'est pas une super solution non plus. Certaines colonnes ne font pas 4 octets (même si c'est le cas pour la plupart).

Sinon tu peux aussi lire beaucoup plus d'octet d'un seul coup, les stocker dans une variable et ensuite traiter la variable. Si tu limites le nombre d'accès au fichier, la lecture devrait être plus rapide. Il est facile de calculer le nombre d'octet que fait une ligne avec le format du dbc, tu peux donc lire une ligne d'un seul coup et ensuite traiter ce que tu as lu pour avoir les différentes colonnes.

Assedic a écrit :1000 par 1000 pour afficher c'est ... Super (pas) pratique

lol, afficher la progress-barre tt les 1000
(pas les datas lus)

(29-05-2011 10:57)Magus a écrit :  Certaines colonnes ne font pas 4 octets (même si c'est le cas pour la plupart).

Alors, pour les DBCs (c'est un cas général), toutes les colonnes sont de taille fixe.
La valeur est donné dans l'entete du DBC ( depuis l'origine c'est 4 )
(Sauf la zone de texte bien evidement)

(29-05-2011 10:57)Magus a écrit :  Sinon tu peux aussi lire beaucoup plus d'octet d'un seul coup, les stocker dans une variable et ensuite traiter la variable. Si tu limites le nombre d'accès au fichier, la lecture devrait être plus rapide. Il est facile de calculer le nombre d'octet que fait une ligne avec le format du dbc, tu peux donc lire une ligne d'un seul coup et ensuite traiter ce que tu as lu pour avoir les différentes colonnes.

Oui tt a fait.

NB: Rappel de l'entete,
Signature: sur 4 Octets ("WDBC")
Nombre d'enregistrement: sur 4 Octets
Nombre de colonne par enregistrement: sur 4 Octets
Taille d'un enregistrement: sur 4 Octets (depuis le debut de wow = à 4 )
Taille de la zone de texte: sur 4 Octets ( Taille globale de la zone de texte )

Ma progress bar elle a comme paramètre le nombre de collonne lues donc c'est bon .

(29-05-2011 17:32)Branruz a écrit :  

Assedic a écrit :1000 par 1000 pour afficher c'est ... Super (pas) pratique

lol, afficher la progress-barre tt les 1000
(pas les datas lus)

(29-05-2011 10:57)Magus a écrit :  Certaines colonnes ne font pas 4 octets (même si c'est le cas pour la plupart).

Alors, pour les DBCs (c'est un cas général), toutes les colonnes sont de taille fixe.
La valeur est donné dans l'entete du DBC ( depuis l'origine c'est 4 )
(Sauf la zone de texte bien evidement)

(29-05-2011 10:57)Magus a écrit :  Sinon tu peux aussi lire beaucoup plus d'octet d'un seul coup, les stocker dans une variable et ensuite traiter la variable. Si tu limites le nombre d'accès au fichier, la lecture devrait être plus rapide. Il est facile de calculer le nombre d'octet que fait une ligne avec le format du dbc, tu peux donc lire une ligne d'un seul coup et ensuite traiter ce que tu as lu pour avoir les différentes colonnes.

Oui tt a fait.

NB: Rappel de l'entete,
Signature: sur 4 Octets ("WDBC")
Nombre d'enregistrement: sur 4 Octets
Nombre de colonne par enregistrement: sur 4 Octets
Taille d'un enregistrement: sur 4 Octets (depuis le debut de wow = à 4 )
Taille de la zone de texte: sur 4 Octets ( Taille globale de la zone de texte )

J'ai mal m'exprimer. Je sais que les valeurs au début du DBC sont sur 4 octets. Je parlais des colonnes elle-même.
Il arrive d'avoir des flags sur 64 bits (8 octets) au lieu de 4 octets. Après cela n'est pas dérangeant tant que c'est un flag, mais faudrait pas tomber sur un uint64 et le couper en 2 sauvagement.

(29-05-2011 19:26)Magus a écrit :  Il arrive d'avoir des flags sur 64 bits (8 octets) au lieu de 4 octets. Après cela n'est pas dérangeant tant que c'est un flag, mais faudrait pas tomber sur un uint64 et le couper en 2 sauvagement.

Oui je vois ce que tu veux dire. Si tu lis via la structure de ton dbc tu n'a pas le probleme
par exemple Nb_Enregistrement * fread(&spellinfo,sizeof(Struct Spellinfo),1,stream)
bon ca oblige à connaitre d'abord la structure du dbc

Oui je me croyais pas obligé , eh bien si Pas grave la fonction est toute prête

Bon par contre maintenant que j'ai éssayé de multithread la fonction de lecture , eh bien j'ai un beau DBCB.exe a cessé de fonctionner

Même en le remettant comme avant ...