Reprise du message précédent :

C'est super trop beau...!  

Good job    
 
 
Sinon après un petit nettoyage du rad et remplacement de pâte thermique.
Je suis paré pour l'été    

Je vais faire mon casse pied, mais on ne voit pas l'échelle pour les abscisses... donc on ne sait pas si le graphe couvre 1 minutes, 1heure, ou plus... (d'ailleurs, un ascenseur horizontal pour accéder à des mesures antérieurs à ce qui est affiché, ca pourrait plaire, peut-être...)
 
Sinon, ca me parait vraiment pas mal
 
Un dernier point : le CPU charge semble dépasser les 100 % à un moment... Ce serait mieux de voir un trait horizontal à 100 % (pour mes courbes dans mes comptes rendus, je mets souvent une valeur max de 100+epsilon pour qu'on puisse voir la valeur 100)
 
Edit : je suis pas contre de tester en avance de phase sur mon core i7 (Win 7 x64)

Le graphe se construit petit a petit, c'est du temps reel, donc pas besoin d'echelle ! Idem ascenceur, y a les graphes a la fin
 
Faut pas non plus oublier que la place est limitee

Bon, ca commence à sentir bon l'alpha cette histoire.
 
D'ici une dizaine de jours vous devriez l'avoir, sauf gros souci de mon coté.
 
Y aura pas le test 3d mis à jour ni linpack, mais c'est pas dramatique au début. Ni la traduction en français.

Bah pour une alpha ca ira bien déja, intégration de linpack et de la 3d ne seront pas une révolution pour les users (j'ai pas dis que c'etait pas du taf pour toi entre autre avec Dx10 )

 
Et le temps que les gens triturent et détruisent totalement mon interface, ca me permettra d'avancer sur ces sujets là

Pour les graphes qui se construisent au fur et à mesure, c'est pas mal mais il faut faire attention à ne pas avoir un relevé de sonde qui renverrait une valeur faussée et qui rendrait tout le graph illisible (enfin mettrait l'échelle en l'air).
Bon je sais pas si ça arrive souvent sur des sondes de température, mais ça m'arrive régulièrement sur les fps par exemple.

C'est réglé pour l'écrètage
 
Pour les FPS, on verra en pratique astrojojo Je ne veux pas faire trop de traitement sur les graphes pour rester "performant".
 
Il me reste encore quelques trucs à vérifier, ce qui devrait prendre du temps.
 
Vous pouvez être certain d'avoir l'alpha d'ici la fin de la semaine prochaine.

Ptêt même avant, mais je préfère pas m'avancer là dessus

Non, les fps c'était pour l'exemple (j'en ai rien à faire dans OCCT).
Par exemple j'ai atitray tool qui fait des graphs de fps (avec l'échelle qui s'adapte automatiquement), le problème c'est que parfois il y a 1000 fps par exemple alors qu'en réalité ça dépasse pas les 50/100. Dans ce cas une seule mesure fausse toute l'échelle du graph. Je pense que ça pourrait aussi arriver avec les sondes ventilos/cpu.

Il dit que c'est réglé
 
Mais il dit aussi qu'on aura le programme toonooveautooboo pour semaine prochaine, voire avant
 
Bref, w&s !

 
Ok, j'ai cru que tu parlais des FPS dans OCCT
 
Pour les sondes, comme je ne fais pas de traitement sur la "validité" des lectures, ben voilà Prends par exemple un ventilo : si il passe en une seconde de 1000 à 6000rpm (par exemple hein !), c'est qu'il a démarré... et c'est valide. pourquoi pas 10.000 par la suite ?
 
On verra bien votre retour "pratique" sur ce coté là
 
OCCT v3 faisait un léger check à un moment, mais je l'ai désactivé car je n'ai jamais réussi à le déclencher, donc

Peut être laisser l'utilisateur paramétrer une valeur maximum ?
 
Mais bon faut déjà voir si des "artefacts" du genre se produisent en réalité avant d'ajouter des options supplémentaires .

heu bof pour le paramétrage. n'oubliez pas qu'il faut rester simple
 
J'ai bien fait d'annoncer encore une dizaine de jours, j'ai des bugs très tenaces Saloperie de DataGridView

on attend ca ....

Ca ne devrait plus être très long...

Par ailleurs, j'ai pas testé tous les plugins (voir aucun), ca risque de coincer à ce niveau là ).

Built-in fonctionne à merveille en tout cas

Et vu que je développe avec un plugin "bidon", y a pas de raisons que ca foire.

Ah si, y aura pas le démarrage auto d'everest dans l'alpha.

on pourra toujours rajouter le plugin Aida64 manuellement et la clé de registre qui va bien, pour lancer Aida64 en auto (avec OCCT)?

Certains plugins pourraient être supprimés comme motherboard monitor dont on sait qu'il ne sera plus jamais mis à jour & systool (ne sais pas pour lui)
Restent l'intégré, everest/aida et speedfan (qui ne reconnait pas grand chose de mon 'vieux' matos)
La simplicité prime souvent

 
Pour l'histoire : le démarrage du programme n'a pas été intégré aux plugins, je gérais ça directement dans OCCT v3. en passant en v4, je n'ai pas porté le code, l'idée étant, avec Fouge, de le mettre dans le plugin.
 
Je ne l'ai pas encore fait ( ), donc du coup, le démarrage n'est pas pris en compte. Ca arrivera dans une version future (je suis pressé de montrer un truc à du monde, ca fait un an que je bosse sur la v4 mine de rien).
 
la gestion des plugins, en dehors de ça, n'a, elle, pas changé.
 
le plugin aida64 sera intégré à l'alpha.  
 
 
 
Je les laisse, des fois que ca marche encore Ca peut servir à des gens. Ca me coute une dll à mettre dans le dossier OCCT, c'est pas la mort, les plugins sont déjà éprouvés

Il ne fonctionne plus très bien ce démarrage de toutes façons
Il aurait fallu que tu le retravailles...

Je vais le faire, pas d'inquiétude.
 
Je serai plus rapide à le faire en C#, mais je sais pas si fouge va apprécier de se retrouver avec une dépendance envers le framework .NET 2.0

Oh c'est pas pour moi
J'ai toujours une copie occt.ini de côté !

Sauf que la v4 n'a plus de fichier ini

Notre API intégrait déjà cette fonctionnalité (LaunchMonitoringProgram et CloseMonitoringProgram) et de mémoire il me semble que je les avais implémenté (je vérifierai).
De toute façon, souviens-toi Tetedeiench, on avait chacun développé la plupart des plugin :
 - pour qu'on ne se retrouve pas avec les dépendances de l'autre (mon plugin Everest dépend de Qt4)
 - si l'un de nos plugin est buggé, on a la possibilité d'utiliser celui de l'autre
Et puis chaque plugin n'est pas très long à développer.
 
Au final, il n'y avait qu'1 ou 2 plugin développé par 1 seul d'entre nous. Du coup, tu peux refaire les tiens en C# 2.0 ça ne me dérangera pas.
Et puis CSMT est en fin de vie. Je ressortirai sans doute une version avec les MAJ de WinRing0 & Qt4 et avec l'ajout du support d'AIDA64 (qui est à 99.9% identique à celui d'Everest) mais c'est tout.

Je me souviens plus trop en fait Je dois t'avouer que c'est loin tout ça.
 
CSMT en fin de vie

C'est vrai que c'est dommage pour CSMT, je l'aimais bien moi, surtout son interface que je préférais à celle d'OCCT. Il me manquera.

Le réglage sharder pour une 5770 pour que ca chauffe un max, c'est comme les HD4xx0 ?
 
Hier j'ai fait un petit test alim pour faire chauffer mon water (que j'ai un peu dépoussiéré)
52-54Max pour les core
41 pour le GPU oO
 
Eau @ 27° en idle, 34°c en test alim pour 20-21°C ambiant (mais dans le boitier il fait plus chaud )

Faut tester, mais les radeons, en général, aiment bien les bons gros shaders compliquées, et les nividias les shaders plus petits

Car 41 même pour une 5770 ca me parait pas bien chaud (shader a 0)

 
mets 8

Et là se pose la rude question : OCCT est buggué ou mon propre PC est instable ?
 

OCCT est bugué, c'est une certitude
Sinon tu peux comparer avec la V3 ^^

C'est ce que je fais.
 
Le programmeur programmé

&  
A haute dose, ça marche bien

pose des mouchards dans le code .. ca te dira ou ca coupe

C'est plus complexe que ça, mais c'est un bug de la v4

au niveau interface ou algo de detection d'erreur ?

Tu n'as qu'a simplement balancer le programme bugguer et dire que les CPU amd/intel ont un protocole de test trop light et qu'ils sont pas stable

 

 
C'est réglé Et dire que je fais ça en parrallèle d'autres trucs

Même pas peur