[C++] GDI et panel

[picto]

Un truc me chiffone un peu.

Pour dessiner des trucs en GDI SUR le panel pour des displays,
la seule fonction qui s'offre à nous est elle le callBackDrawHUD ?

Si oui ça ne me semble pas très pratique ...
Si non, je cherche mais ne trouve pas

[DanSteph]

Tu parle des MFD de tout l'ecran ou juste du panel 2d ?

Dan

[picto]

Juste du Panel, mais en fait j'ai trouvé ...

Je me suis inspiré de l'engine indicator du ShuttleA.
En fait, j'ai l'impression que l'on peut écrire sur le GDI de n'importe ou.
Ce n'est pas comme les surfs ....

Par contre, j'ai un vrai problème.

Admettons le cas d'un Display de ce genre ( qui dessine la puissance des moteurs utilisée )
Il doit être déclaré en REDRAW ALWAYS dans le register Panel ...
Comment puis je le subordonner à une extinction du display ?
Comme par exemple sur les displays du panel du DGIV qui sont éteints en Safe Mode

Quand ton écran est noir, celà veut il dire que c'est quand même redessiné à chaque frame ?
Si oui, ça ne me parait pas très économique !

[DanSteph]

picto a écrit:
En fait, j'ai l'impression que l'on peut écrire sur le GDI de n'importe ou.
Ce n'est pas comme les surfs ....

Nan c'est même combat, il te faut un surf de destination pour les deux.
Si tu entend "depuis n'importe ou" par une fonction séparée de clbkRedraw...
tu peux aussi le faire avec un Blt...

picto a écrit:
Admettons le cas d'un Display de ce genre ( qui dessine la puissance des moteurs utilisée )
Il doit être déclaré en REDRAW ALWAYS dans le register Panel ...
Comment puis je le subordonner à une extinction du display ?
Comme par exemple sur les displays du panel du DGIV qui sont éteints en Safe Mode
Quand ton écran est noir, celà veut il dire que c'est quand même redessiné à chaque frame ?
Si oui, ça ne me parait pas très économique !

Tu a raison ce n'est pas économique du tout, il faut reserver le redraw always à des affichage
qui ont de grande chance de changer très fréquement, les moteurs eux risquent bien de ne pas
bouger pendant la plupart du temps donc il vaut mieux un "REDRAW_USER" et balancer un
triggerredrawarea quand la valeur a changé. Pour l'extinction simplement tu balance
un triggerredraw et dans la fonction redraw tu return sans riens dessiner, pour l'allumage
meme chose mais tu dessine.

Dans post step par exemple j'ai toute une section dédiée à l'affichage des barres de
niveau fuel o2 et n2 du panel du bas, ces zone sont déclarée en user quand la valeur change
je balance des trigger... j'ai eu une augmentation de 30% du framerate en faisant ca par rapport
a un always

Dan

[picto]

Pour le redraw event vi vi je sais ... la surf doit y être déclarée obligatoirement.
Mais ça fonctionne déjà hein Ma question concernait juste le type de register
et comment optimiser la fonction de dessin.

Tiens, c'est marrant, j'étais en train de me dire ça justement,
le post step avec un test pour lancer l'affichage !

Question optimisation, les exemples de la SDK sont NULS !
Si on veut faire des trucs complexes qui tournent bien, il ne s'agit
pas de copier béatement



Message modifié ( 04-08-2007 18:16 )

[DanSteph]

En passant t'a fait une structure pour garder toutes les valeurs de tes boutons
et des systèmes ?

Dan

[picto]

Meuh non

Lors de l'élaboration de mon premier système, j'ai eu besoin d'un flag FALSE
en cours de conception. Comment initialiser ensuite un système sous
structure si dès le départ on se retrouve avec des variables à intialiser
à TRUE et les autres à FALSE ?

Quelques questions sur les structures et l'imbrication des systèmes.
Admettons qu'on veuille faire un système de mise en veille ou safe
mode pour l'ensemble d'un vaisseau.

C'est un truc à penser plutôt rapidement j'ai l'impression. Si ça se
passe par un flag qui va bloquer chaque système, ça risque de ne pas
être une sinécure le moment venu si tout n'a pas été conçu pour dès
le départ dans les systèmes.

J'entrevois bien une solution du type variable = False que l'on
remplace par inversevariable = true, et suivre le fil des choses
pour voir si ça peut fonctionner. Je n'ai pas encore essayé
de faire ça sur un système .... inverser tout ce qui ne collerait
pas avec une initialisation en paquet d'une structure.

[DanSteph]

picto a écrit:
Lors de l'élaboration de mon premier système, j'ai eu besoin d'un flag FALSE
en cours de conception. Comment initialiser ensuite un système sous
structure si dès le départ on se retrouve avec des variables à intialiser
à TRUE et les autres à FALSE ?

comprend pas le problème ? tu initialise la structure d'un bloc a zero (false) et après tu met celle que tu veux à true...

memset(MesBoutons,0,sizeof(MesBouton));
MesBoutons.SurLaFigure=TRUE;
MesBoutons.SurLeBras=TRUE;

Mais du coup pas besoin de delcarer les 520 autres qui sont sur false

MesBoutons.SurLaJoue=FALSE; // inutile, deja fais avec memset...

Dan

[picto]

Oki, le truc c'était juste de bien concevoir
les systèmes pour qu'il n'y ait pas besoin
des

MesBoutons.SurLaFigure=TRUE;
MesBoutons.SurLeBras=TRUE;

Pour avoir à en écrire le moins possible quoi

Bon sinon ça rentre bien, je viens enfin de comprendre l'utilité
de réinitialiser certaines variables dans post step au lieu de
class cap .... par exemple si on fait des trucs qui bidouillent les
MFDs ..... zou un chtit

Dans clbkPostStep

   if(FIRST_STEP_INIT_DONE==FALSE)
   {
oapiGetMFDMode = blabla
if blabla, Ngolo = true
if pasblabla, Ngolo = false

      FIRST_STEP_INIT_DONE=TRUE;
   }


En y réfléchissant un peu, on pourrait presque se passer
d'une lecture et écriture sur scénario grâce à ça en étant
un peu malin ....



Message modifié ( 04-08-2007 19:51 )

[picto]

J'en ai marre de ces :fu: SURFANDLES

Sur le modèle du ShuttleA
La zone est définie en PANEL_REDRAW_ALWAYS  PANEL_MAP_BACKGROUND
Et la fonction qui redessine dynamiquement est de ce type

Code: [Select]

bool Irridium::RedrawPanel_EngineIndicator (SURFHANDLE surf)
{
HDC hDC = oapiGetDC (surf);


// Blabla pour dessiner avec les outils Windows


oapiReleaseDC (surf, hDC);
return true;
}Je me dis donc, qu'à celà ne tienne je vais la mettre en REDRAW_USER et l'appeller dans
post step comme ceci ...

Code: [Select]

for (int i = 0; i < 2; i++)
{
if (GetThrusterLevel (th_main[i]) != 0 || GetThrusterLevel (th_hover[i]) != 0 )
oapiTriggerPanelRedrawArea (0, AID_TOPDISPLAY);

}En REDRAW USER le rafraichissement se fait mal ... ça donne ça
Tous les états de l'image restent .... il n'y a aucun nettoyage entre deux frames
alors que tout fonctionne bien en REDRAW ALWAYS sans tripoter quoi que ce soit
dans la fonction de dessin !
Et pourtant, avec mon appel dans post step c'est bien un redessinage complet
de la zone qui est demandé à chaque frame par oapiTriggerPanelRedrawArea



C'est peut être ça qui fout la merde

Code: [Select]

case AID_TOPDISPLAY:  
            if (bTopDisplayStatus == TRUE)
            {
            return RedrawPanel_EngineIndicator (surf);
            }
            else if (bTopDisplayStatus == FALSE)
            {
            oapiBlt (surf, srf[1], 0, 0, 101, 101, 100, 100); // display eteint sur le bitmap
            }
         return true;J'ai un rafraichissement quand je tripote le bouton qui dit
bTopDisplayStatus = TRUE ou bTopDisplayStatus = FALSE
Et pourtant, c'est pas logique vu que bTopDisplayStatus
reste égal à true tant que j'ai rien tripoté



Message modifié ( 05-08-2007 04:32 )

[DanSteph]

non c'est probablement ca: PANEL_MAP_BACKGROUND
Ce troisieme parametre indique à Orbiter si il doit recopier
l'ancien background avant le redraw ou si il ne doit pas y toucher etc etc...

Dans ton cas visiblement il n'y touche pas essaie un autre regarde la doc.

En passant , deja expliqué, ceci est inutile voir faux:

Code: [Select]

return RedrawPanel_EngineIndicator (surf);
clbkredraw attend toujours que tu return true, tu n'a pas besoin d'un retour d'information
de cette fonction met la en void et return true dans tous les cas de AID_TOPDISPLAY

A propos, ce serais une très bonne idée de proteger le code
d'un surfhandle qui serait non valide ci-dessous:

Code: [Select]

void Irridium::RedrawPanel_EngineIndicator (SURFHANDLE surf)
{
if(!surf)
    return;

HDC hDC = oapiGetDC (surf);

// Blabla pour dessiner avec les outils Windows

oapiReleaseDC (surf, hDC);
}
En dernier je ne pense pas que tu doive recopier le background quand éteint,
regarde le troisieme parametre PANEL_MAP_BACKGROUND dans la doc...

A++

Dan

[picto]

Bravo ! Merci

Jamais je n'aurais cherché de ce côté là !
Il suffisait de rajouter ce MAP_BACKGROUND !
Je regarderais demain pour voir si d'autres paramètres peuvent convenir
Sachant qu'il est noir sur ce display.
Ca fonctionne nickel !

Le graphisme n'est pas fait mais le principe fonctionne !
Bouton sur OFF Display vert ( éteint ), bouton sur ON ça dessine
bien un truc avec retour d'infos des thrusters.

J'ai rajouté le fusible à handle et mis la fonction  en void
Mais sur le shuttleA elles sont toutes en bool, le nez dans le
guidon, je ne fais pas forcément gaffe, désolé





Message modifié ( 05-08-2007 06:16 )

[picto]

Je sèche sur un truc complètement con
Des heures que je cherche une solution mais ça ne vient pas

Le problème viens de l'arrêt des moteurs principaux.
On peut le faire soit sur le panel soit par * soit par un SetThrusterLevel (th_main[0], 0);
à la fin d'un burn auto par exemple ... tout fonctionne nickel quand j'arrête les moteurs
avec le slider sur le panel. Mais impossible d'effacer le dernier état si c'est un arrêt auto par SetThrusterLevel



La fonction dessine pourtant avec les outils du GDI en tranparence sur le background.
avec des variables de ce type Data.dMaxThrustMainOne  =GetThrusterMax   (th_main[0]);   
directement basées sur GetThruster ... quand c'est à zéro c'est à zéro quoi

J'ai essayé ce genre de flag ( initialisé dans post step à la fin d'un autopilote )
dans le redraw event ...
           if (bFlagPourEffacerEnginePowerSurTopDisplayFinDuBurnAuto == TRUE)
         {
         RedrawPanel_EngineIndicator (surf);
            bFlagPourEffacerEnginePowerSurTopDisplayFinDuBurnAuto = FALSE;
            }   

des oapitriggermachin à tous les coins de rue   

Je ne peux pas l'appeller directement de poststep, les surfs n'y sont pas connues

Bref ça veut pas !
Par contre, dès que je retripote les Hovers, ça redémarre, si les moteurs sont à zéro,
le compteur passe à zéro.

J'ai bien pensé à une solution, , mais ce serait complètement naze, c'est de reconstruire une surf d'après un
bitmap identique et le recoller par dessus ... mais faut pas exagérer quand mêm



Message modifié ( 06-08-2007 08:49 )

[picto]

J'ai trouvé
Comme quoi ça fait du bien de dormir de temps en temps

Deux lignes dans poststep

if (bTopDisplayStatus == TRUE)
oapiTriggerPanelRedrawArea (0, AID_TOPDISPLAY);

Mais ce n'est pas très économique
Si le gars laisse le display allumé ça fait plein d'affichages pour un truc qui bouge pas  

J'ai fait des tests ...  
MFDs, HUD et les trois displays éteints FPS 300
MFDs et HUD allumés mais trois displays éteints FPS 250
Pendant le burn auto, MFDs et HUD allumés avec des trucs qui clignotent et les displays éteints FPS 200
Pendant un burn auto avec tout allumé avec des trucs qui clignotent de partout FPS 125



Message modifié ( 06-08-2007 16:56 )

[DanSteph]

mhhhhh... je me demande si t'est parti clean sur ce coup la...
tu peut tout renvoyer steuplais ? juste le projet pas les datas...

Ce soir cinoche ce sera peut etre tard la réponse mais faut que j'examine
le truc pour voir si le principe est bon...

A pluche

Dan

[picto]

Oki, j't'envoie ça ...

C'est le bon moment avant qu'il ne soit trop tard pour revenir en arrière
de s'engager sur une voie  que si c'est pas la bonne on se rendra compte
qu'il y a eu gourrance sur le choix de la route qui mène au nirvana du fps élevé  ....
Et réciproquement selon la théorie du "doubling" (bien connue de nos amis Sumériens)
J'ai vérifié avec mon ami le professeur Pangolin ! Ca fonctionne nickel !



Message modifié ( 06-08-2007 18:17 )

[DanSteph]

Quan tu eteint en auto, tu redemande bien un redraw, le problem c'est que tu a prise tes variables

Code: [Select]

Data.dThrustMainOne      =GetThrusterLevel (th_main[0]);
Data.dThrustMainTwo      =GetThrusterLevel (th_main[1]);
Data.dThrustHoverOne     =GetThrusterLevel (th_hover[0]);
Data.dThrustHoverTwo     =GetThrusterLevel (th_hover[1]);
Data.dMaxThrustMainOne   =GetThrusterMax   (th_main[0]);
Data.dMaxThrustMainTwo   =GetThrusterMax   (th_main[1]);
Data.dMaxThrustHoverOne  =GetThrusterMax   (th_hover[0]);
Data.dMaxThrustHoverTwo  =GetThrusterMax   (th_hover[1]);
Avant l'extinction qui est plus bas... Et le redraw ce fait avant le prochain poststep et le nouveau
"grab" des variables.

Du coup quand le redraw est fait les thurster sont bien a zéro mais pas la valeur Data.dThrustMainOne...

Essaie ce genre de truc: (pseudo code)

Code: [Select]

if(DoitEteindre)
{
      SetThruster(main,0);
      Data.dThrustMainOne=0;
      oapiTriggerRedrawAID_DDISPLAY_ENGINE);
}

Sinon j'ai vu deux trois truc d'optimisation et d'ecriture...
L'indentation gaffe toi:

Fause indentation:

Code: [Select]

void mafonction()
{

       switch(salut)
       {
case HELLO:
break;
case OUAIS:
break;
       }

}

Juste:

Code: [Select]

void mafonction()
{

       switch(salut)
       {
       case HELLO:
              break;
       case OUAIS:
              break;
       }

}

Pour regler ca automatiquement fait "edit"-"select all" puis alt+F8 ca va reindenter ton code automatiquement...
a faire sur chaque listing.

Sinon tout ca c'est vachement bien pour un gars qui connaisait rien au C++ voici un mois

Dan

[picto]

Bravo et merci , Maitre, petit scarabée content

Ca fonctionne nickel dans la boucle "doit éteindre" avec ça
      Data.dThrustMainOne=0;
      Data.dThrustMainTwo=0;
Pas besoin du SetThrust, il est fait avant ...

Il suffisait d'y penser, pas assez l'habitude, jamais je n'aurais trouvé cette explication
pour le coup de l'extinction. PPPfffouuuhhhh ..... ça pardonne rien quand même.
J'ai encore du mal à "voir" les boucles d'éxécutions se faire mentalement en lisant le code,
mais ça va venir

J'en profite pour poser une question, les touches utilisées par Orbiter genre * + - PavNum
sont elles quand même programmables ? Pas pour les changer, mais pour rajouter des trucs ?
Ou est ce que ça met la zone à coup sûr ?

Pour le coup du ALT F8, ça fait bizarre ... J'ai relu un peu après l'avoir fait; Il est vrai que
l'on voit mieux l'imbrication des if else et autres else if .... Mais ça donne des trucs cocasses
quand même. Sur le mouse event du RemoteSystem, ça part loin Bon, en même temps si
j'avais respecté cette indentation j'aurais eu moins  d'erreurs de compile à cause des {}
pendant l'élaboration de ce truc


J'imagine sur un système vraiment compliqué, c'est quatre écrans côte à côte qu'il faudrait !

C'est quoi les erreurs d'optimisation ?
Ca m'intéresse bien quand même pour ne pas en faire trop



Message modifié ( 06-08-2007 23:46 )

[DanSteph]

Les touches bidule ce dépend ce que tu entend, si c'est pour rajouter une
son no probleme par exemple... En bref si tu rajoute no problem, peut etre
peut tu pour une fois retourrner 0 au lieu de 1 ? mais ca changera pas grand chose amha...

indentation ca part jamais trop lon ca dépend aussi, a gauche je minimise le plus possible
et j'ai raremend des codes sur imbriqué. Mais une fois l'habitude prise c'est très utile
et ca améliore beaucoup la lisibilité, hors la lisibilité c'est la compréhension etc etc

Pour optimisation tracer des lignes GDI comme les thurst je me demande si un blit ne serait
pas plus éco... (pas dis hein ca dépend de ton blit)

pour quoi ne pas y faire en "femelle" par exemple ?  Le panel du fond a les lignes deja drawée
sur le fond et en fait tu fait descendre un carré couleur fond pour les masquer tu vois ?
En plus les lignes pourraient avoir un effet de lumière leger.

Tjrs pour les thrust, dès que c'est allumé ca redraw a chaque image, pas très économique... (le thrust
sur quelque milliers d'images change très peut, on général c'est plein pot ou eteint)
ils faudrais avoir une autre valeurs qui contient la derniere fois que tu a affiché et ca ne refraichirais
que quand une valeur a changée:

Code: [Select]

affiche
{
    moveto();
    LineTo(Data.dThrustMainOne);
    iOldRedrawMainOne=Data.dThrustMainOne;
}

Et dans poststep:

Code: [Select]

//reaffiche que si valeur changée
if(Data.dThrustMainOne!=iOldRedrawMainOne)
{
    oapiTriggerRedrawArea();
}

Comme tu a deux affichages tu pourrais simplifier et n'utiliser qu'une valeur:

Code: [Select]

affiche
{
    moveto();
    LineTo(Data.dThrustMainOne);
    LineTo(Data.dThrustMainTwo);
    iOldRedrawMainOne=Data.dThrustMainOne+Data.dThrustMainTwo;
}

Code: [Select]

if((Data.dThrustMainOne+Data.dThrustMainTwo)!=iOldRedrawMainOne)
{
    oapiTriggerRedrawArea();
}
Une addition par post step c'est quand même plus bandant que tout le tremblement avec GDI...
Quand tu éteint,au tout début ou quand tu rallume pour etre sure que l'affichage sera
rafraichi ne pas oublier d'initialiser la valeur "sauvegarde" sur une valeur impossible:

Code: [Select]

if(eteintAffichage)
{
     Etteint();
     iOldRedrawMainOne=-999;
}
A l'allumage tu est certains de pas avoir de bug foireux si quand au moment de l'extinction
oldRedraw avait eu la même valeur qu'a l'allumage...


Selection d'objet GDI a ne faire QUE quand ca change... plus les boucles j'ai vu ca a un endroit:

Code: [Select]

SelectObject (hDC, g_Param.pen[3]);
for (int x = 0; x < 12; x++)
{
if (x%2==0)
{
MoveToEx (hDC, 3+x, 97 , NULL);
LineTo (hDC, 3+x, 98-Data.dThrustMainOne*73);
MoveToEx (hDC, 35+x, 97 , NULL);
LineTo (hDC, 35+x, 98-Data.dThrustMainTwo*73);
MoveToEx (hDC, 53+x, 97 , NULL);
LineTo (hDC, 53+x, 98-Data.dThrustHoverOne*73);
MoveToEx (hDC, 85+x, 97 , NULL);
LineTo (hDC, 85+x, 98-Data.dThrustHoverTwo*73);
}
}
SelectObject (hDC, g_Param.pen[3]);
for (int x = 0; x < 12; x++)
{
if (x%1==0)
{
MoveToEx (hDC, 3+x, 97 , NULL);
LineTo (hDC, 3+x, 98-Data.dThrustMainOne*73);
MoveToEx (hDC, 35+x, 97 , NULL);
LineTo (hDC, 35+x, 98-Data.dThrustMainTwo*73);
MoveToEx (hDC, 53+x, 97 , NULL);
LineTo (hDC, 53+x, 98-Data.dThrustHoverOne*73);
MoveToEx (hDC, 85+x, 97 , NULL);
LineTo (hDC, 85+x, 98-Data.dThrustHoverTwo*73);
}
}
oapiReleaseDC (surf, hDC);
Le deuxieme selectobjet est inutile, il est deja selectionné, la deuxieme boucle for() est inutile aussi
Bon la ce que tu perd ca doit ce compter en micro secondes. C'est surtout une question de
mauvaise habitude. Un jour ca peut te couter beaucoup plus que ca... donc plutot:

Code: [Select]

HDC hDC = oapiGetDC (surf);
SelectObject (hDC, g_Param.pen[3]);
for (int x = 0; x < 12; x++)
{
if (x%2==0)
{
MoveToEx (hDC, 3+x, 97 , NULL);
LineTo (hDC, 3+x, 98-Data.dThrustMainOne*73);
MoveToEx (hDC, 35+x, 97 , NULL);
LineTo (hDC, 35+x, 98-Data.dThrustMainTwo*73);
MoveToEx (hDC, 53+x, 97 , NULL);
LineTo (hDC, 53+x, 98-Data.dThrustHoverOne*73);
MoveToEx (hDC, 85+x, 97 , NULL);
LineTo (hDC, 85+x, 98-Data.dThrustHoverTwo*73);
}
if (x%1==0)
{
MoveToEx (hDC, 3+x, 97 , NULL);
LineTo (hDC, 3+x, 98-Data.dThrustMainOne*73);
MoveToEx (hDC, 35+x, 97 , NULL);
LineTo (hDC, 35+x, 98-Data.dThrustMainTwo*73);
MoveToEx (hDC, 53+x, 97 , NULL);
LineTo (hDC, 53+x, 98-Data.dThrustHoverOne*73);
MoveToEx (hDC, 85+x, 97 , NULL);
LineTo (hDC, 85+x, 98-Data.dThrustHoverTwo*73);
}
}
oapiReleaseDC (surf, hDC);

Ya peut etre d'autre truc plus foireux mais j'ai pas tout examiner, pour ce que j'ai vu si ca tourne bien c'est nickel !

A++

Dan



Message modifié ( 07-08-2007 01:11 )

[DanSteph]

sxuse pour le type:

dOldRedrawMainOne ou dOldRedrawMain si deux... pas "iRed..."

Dan

[picto]

Je ne comprend pas bien ça ...

Code: [Select]

if(eteintAffichage)
{
     Etteint();
     iOldRedrawMainOne=-999;
}
Veux tu dire qu'il faut :

a) réinitialiser la valeur old quand je tripote le bouton ON OFF du display ?
b) à chaque fin d'afichage d'une surf " display moteurs"  réinitialiser Oldredraw ?

Si oui à la seconde propsition, je ne comprend pas trop, les deux
lignes entre post step et fonction(affiche) se suffisent à elles même

Pour l'instant j'ai fait ça sur le redraw event du display

Code: [Select]

case AID_TOPDISPLAY:  
if (bTopDisplayStatus == TRUE)
{
RedrawPanel_EngineIndicator (surf);
}
else if (bTopDisplayStatus == FALSE)
{
oapiBlt (surf, srf[1], 0, 0, 101, 101, 100, 100);
dOldRedrawMoteurs=-999;
}
return true;
Ca fonctionne pâââââââ ...
Test : Moteurs allumés, puissance constante, display éteint ... 250 FPS
Moteurs allumés, puissance constante, display allumé .... 180 FPS
Vais faire un peu de oapidebugstring pour comprendre ce qui va pâââââââââââ^....



Message modifié ( 07-08-2007 17:04 )

[picto]

Mais pourquoi tant de Haiiiiiinnnnneeeeeeuuuuhhhhh ???
C'est encore une histoire de ou se chopent les variables dans post step ça ...
Et pourtant le réaffichage se fait quand même ...  





Message modifié ( 07-08-2007 17:54 )

[DanSteph]

>>>>>>>>>>>>

a) réinitialiser la valeur old quand je tripote le bouton ON OFF du display ?

Exeeecute mais execccute le code dans ta tete, celui la il est pourtant simple ndd

Le but c'est de ne reaficher QUE quand il y a besoin, c'est a dire quand l'affichage a changé
notre valeur old garde la deniere position de l'affichage, si elle n'est plus egale avec la nouvelle
on balance l'ordre de reafficher...

Mais quand tu eteint ou au debut du code imagine que la valeur old est à zéro
et que tes engine sont aussi a zéro tu a quoi ? oui UN EGALITE
DONC PAS DE REAFFICHAGE !!!! BUG BUG BUG !!!

Donc quand tu ETIENT et au DEBUT du code tu mest old value de telle sorte que tu est SURE
qu'il ne sera pas egal -999 ou 34875345897435 c'est egal une valeur que les engine ne peuvent
prendre en aucuns cas...., donc tu force le reaffichage dans ces cas la !!!

comprendo ?


Désolé pour la nérvosité je FSX et une telle connerie de la part de MS
ca dépasse l'entendement...

Tu prend tout ce que je t'enseigne sur l'optimisaion et tu fais exactement l'inverse
et tu aura une idée de comment FsX est programmé---

C'est hallucinant !!!!!

Dan



Message modifié ( 07-08-2007 17:22 )

[picto]

Bah t'inquiète pour le ton ....

Merci pour l'apprentissage sur l'optimisation ... je vais y arriver nom d'une pipe !

J'ai compris ce qui se passe; ça n'a fonctionné qu'une fois, tans que OLD était égal à -999
sa valeur par défaut dans setclasscap, il faut juste que je place judicieusement le grab
des moteurs dans OLD et ça va rouler ....

[picto]

Bon, en fait ça marche nickel ...

C'est juste que je m'étais gourré de boucle sur post step ...
Je conditionnais la boucle qui fait un dernier affichage après le burn
auto au lieu de conditionner celle qui affiche couramment le display

Merci encore pour la méthode, c'est génial !
Le FPS bouge un peu quand je tripote, et remonte à son niveau d'avant
tout de suite après l'arrêt du tripotage des moteurs !

YES !!!
Avec toutes les conditions, en burn auto avec tout qui
clignote de partout le FPS est remonté de 125 à 220 !



Message modifié ( 07-08-2007 18:55 )