PureBasic

Dobro a écrit :ha bah oui ... vous avez raison

............ Je suis un Âne ! ...............

Faut pas exagérer, tu pensais que les événements étaient enlevés, tu as eu raison de demander une preuve !

Bonjour,

A lire et essayer de comprendre les choses de divers topic, je me suis aperçu que comme "Dobro" je faisais quelque erreur de gestion de mes programmes. A la base je faisais tout comme "Dobro" et depuis c'est quelques topic je suis en cours de modification de mes programmes.

Je comprends mieux pourquoi en faisant certain test, j'avais par moment 2 à 4 fois l'appel à la même fonction (qui ne prenne pas beaucoup de temps machine). Mais bon c'est des choses à bien comprendre et à bien utiliser.

Cordialement,
GallyHC

PS : les topic sur ce sujet son vraiment utile et vont surement être bénéfique pour beaucoup.

Ouai peut être mais la preuve en est que ce débat a été instructif.
Et puis la dernière réponse de Fred date de 2010 tout de même hein

Une petite rafraichissade ne fait pas de mal

Salut

C'est intéressant en tout cas, on apprend des trucs

.

Autre question : est-ce valable si on n'a pas de screen, ni flipbuffer(), etc ?

Si on dessine sur un canvas, et ça doit souvent être ton cas

, il faut gérer le délay de chaque bouclage soit-même, il y a eu un topic la-dessus il n'y a pas longtemps.
Mais en revanche, l'utilisation de la double boucle est toujours nécessaire.

Mais tout dépend de l'architecture de ton code. Si ta boucle principale ne fait que traiter les évènements, alors il n'y a pas besoin de la doubler.
Si en revanche elle comprend une partie, affichage / traitement de données / calculs etc... opérations qui ne concernent pas les évènements, alors il faut doubler la boucle.

Graph100 a bien répondu là : http://www.purebasic.fr/french/viewtopi ... 18#p162118

Dans un programme fenêtré normal, l'application n'est réveillée par le système d'exploitation que s'il se passe quelque chose : clic sur un gadget, déplacement de fenêtre, mouvement souris, etc. -> WaitWindowEvent()

Si l'application doit effectuer des actions régulièrement, ou des traitements très longs, elle peut demander à l'OS de la réveiller à des intervalles réguliers, avec un timer par exemple, ou gérer à part certains événements (cas de photoshop et de la gestion clavier). Des threads peuvent gérer cela sans même que le programme principal n'ait à intervenir. -> WaitWindowEvent() est normalement suffisant.

Si l'application est en plein écran synchronisé avec un FlipBuffers(), là on entre dans un autre domaine, celui de la boucle d'affichage synchronisée. Le programme tourne en continu et doit effectuer toutes les opérations en moins d'une frame. Par exemple, pour un affichage à 60Hz, la carte graphique va piocher une image complète de l'écran dans la mémoire vidéo 60 fois par seconde, donc si l'on veut afficher quelque chose de différent, on doit le faire en moins de 1/60ème de seconde.

Dans ce laps de temps, il faut traiter toutes les entrées (événements utilisateur/réseau/micro/etc.), faire les calculs de déplacements/IA/etc, faire toutes les sorties (graphique/audio/réseau/etc.). Si on n'y arrive pas, il y a lag (ralentissement).

Maintenant, du fait des différences de latence des entrées/sorties, les programmeurs de grosses applications temps-réel dissocient souvent les différentes parties. Par exemple, il n'y a rien de plus énervant de ne pouvoir quitter un jeu dont l'affichage est planté, car le programme n'a pas séparé la gestion du clavier. On s'arrange donc pour qu'un thread gère le réseau, un autre le clavier, un autre l'affichage, ...

En général, un programme PureBasic est suffisamment léger pour ne pas avoir à s'occuper de tout ça. Et puis PureBasic gère en interne certaines choses, qui sont en fait assez différentes d'un OS à l'autre. En ce qui concerne la gestion des événements, puisqu'on veut être rapide (moins de 1/60ème de sec!) il ne faut pas "bloquer" le programme avant d'être sûr d'avoir fait tout ce qu'on devait faire. Une fois qu'on en est sûr, on peut rendre la main à l'OS pour qu'il effectue ses tâches de fond : c'est normalement intégré au FlipBuffers().

Voilà, je voulais être bref, c'est raté, désolé...

Edit: grilled par graph100

oui , ben je coucherai moins bete ce soir

fais pas bon vieillir

Ouep Dobro, même deux fois papa (pour moi) on apprend et cela tout les jours. Pt1 que ces bon d'être un Dev amateur on ce couche souvent moin con qu'un jour avant .....

GallyHC

PS : avec ton nouvelle avatar on a presque la même couleur vert lolllll UN SIGNE LOLLLLLLLLLLLLLLLLLLL....

PS2: Le vert est la couleur de l'espoir, on en manque pas déjà

.

PS3 : par principe et tout ce que j'avais dit c'est quand même mieu de vider un pile avant de faire autre chose

................ dixit D'jes (en son jeune et tres tres jeune temps, mais j'ai jamais oublier).

Un petit truc j'ai hâte d’une belle confrontation de point de vue de ce style, car la, on apprend vraiment des choses. A la prochaine rixe de ce genre

.

Faut un peu d’humour quand même

.

Dobro a écrit :ha bah oui ... vous avez raison

............ Je suis un Âne ! ...............

La franchement beaucoup moin que moi et encore plus que d'autre

.

GallyHC

C'est bien vrai, moi je n'oublierai jamais le coup de la fenêtre ouverte après le alt-tab, super astuce made by Dobro, entre autres.

J'ai bien lu vos explications, et j'ai voulu tester sur un gros programme (environ 15 000 lignes de code, avec 1000 lignes rien que dans la boucle principale).
En changeant et en appliquant la double boucle + windowEvent(), le programme mouline comme pas possible et se bloque, alors qu'avec un simple WaitWindowEvent(1)/boucle simple, ça marche nickel.

Pas de screen, juste un canvas (c'est issu de mon soft animatoon). J'essaie donc de gérer le delay() par moi-même, mais ça ne marche plus du tout avec la double boucle.

Voici le code (simplifié) que j'avais et qui fonctionne sans problème :

Code : Tout sélectionner

  
Repeat
  
  event = WaitWindowEvent(1)
  
  If event
    
    Select event
        
      Case #PB_Event_Menu
        ; tous les event menus
        
      Case #PB_Event_Gadget
        ; tous les event gadgets
        
      Case #PB_Event_SizeWindow, #PB_Event_MaximizeWindow  
        ; les event  size
        
      Case #PB_Event_CloseWindow
        ; LEs event closewindow en fonction des window actives
        
    EndSelect
    
  Else
    
    If option\PlayAnimation <>1
      Delay (1)
    EndIf 
    
  EndIf
  
  ; le reste des updates
  PlayAnimation(framecurrent) ; for the animation player (preview on the canvas)
  StatusBarText(#statusbar,2,"Mouse : "+Str(WindowMouseX(#WinMain))+"/"+Str(WindowMouseY(#WinMain)))
  
Until quit = 1

Remplacé par ça, après vos suggestions, ça ne marche plus du tout, le programme se bloque dès le départ. Je dois le killer depuis le gestionnaire des tâches (sauf si je l'ai lancé avec le debugger, là, je l'arrête depuis l'ide de PB) :

Code : Tout sélectionner

Repeat
  
  event = WindowEvent()
  
 Repeat
    
    Select event
        
      Case #PB_Event_Menu
        ; tous les event menus
        
      Case #PB_Event_Gadget
        ; tous les event gadgets
        
      Case #PB_Event_SizeWindow, #PB_Event_MaximizeWindow  
        ; les event  size
        
      Case #PB_Event_CloseWindow
        ; event closewindow
        
    EndSelect
    
  Until event = 0
    
  Delay (1)
  
  ; le reste des updates
  PlayAnimation(framecurrent); for the animation player (preview on the canvas)
  StatusBarText(#statusbar,2,"Mouse : "+Str(WindowMouseX(#WinMain))+"/"+Str(WindowMouseY(#WinMain)))
  
Until quit = 1

J'ai changé event = WindowEvent() par event = WaitWindowEvent(1), déplacé le delay(1), etc... j'ai toujours le blocage du programme, qui n'affiche même pas les boutons, ni le reste de l'interface (à part le menu et le canvas central).

Maintenant, il y a peut-être quelque chose que je n'ai pas saisi ^^, mais si j'utilise un double repeat, mon programme se bloque immédiatement.
D'où ma question : comment utiliser votre technique sur un gros programme pour que ça fonctionne correctement (sans passer par les threads pour le moment bien sûr, car avec simple boucle ça fonctionne sans thread

) ?

Merci pour vos réponses.

je pense que la double boucle (vidage de la liste) , n'est valable QUE sur prg basé sur un Screen ou windowedScree()

le Canvas, est un gadget ... donc dans ce cas , c'est une application "Standard" un seul Repeat avec un WaitWindowEvent(x)
devrai suffire

(mais je peux me tromper hein ...

)

Une toute petite erreur de ta part, il ne faut pas faire :

Code : Tout sélectionner

Repeat
  
  event = WindowEvent()
  
 Repeat
    
    Select event
        
      Case #PB_Event_Menu
        ; tous les event menus
        
      Case #PB_Event_Gadget
        ; tous les event gadgets
        
      Case #PB_Event_SizeWindow, #PB_Event_MaximizeWindow  
        ; les event  size
        
      Case #PB_Event_CloseWindow
        ; event closewindow
        
    EndSelect
    
  Until event = 0
    
  Delay (1)
  
  ; le reste des updates
  PlayAnimation(framecurrent); for the animation player (preview on the canvas)
  StatusBarText(#statusbar,2,"Mouse : "+Str(WindowMouseX(#WinMain))+"/"+Str(WindowMouseY(#WinMain)))
  
Until quit = 1

mais

Code : Tout sélectionner

Repeat
  
  Repeat
    
   event = WindowEvent() ;<<<<<<<<<<<<<<<<<<<< DANS la boucle !

   Select event
        
      Case #PB_Event_Menu
        ; tous les event menus
        
      Case #PB_Event_Gadget
        ; tous les event gadgets
        
      Case #PB_Event_SizeWindow, #PB_Event_MaximizeWindow  
        ; les event  size
        
      Case #PB_Event_CloseWindow
        ; event closewindow
       quit = 1
        
    EndSelect
    
  Until event = 0
    
  ; le reste des updates
  PlayAnimation(framecurrent); for the animation player (preview on the canvas)
  StatusBarText(#statusbar,2,"Mouse : "+Str(WindowMouseX(#WinMain))+"/"+Str(WindowMouseY(#WinMain)))

Until quit = 1

ah oui, au temps pour moi, ça marche mieux effectivement

(quel boulet je suis là ^^).
Je vais comparer le fps pour voir si je gagne beaucoup de performance entre la simple boucle et la double.
Merci

Djes a corrigé, maintenant ça devrait fonctionner sans soucis !

Mais je ne pense pas que tu constates une différence au niveau du fps. La différence n'apparaitra que lorsque il y aura de nombreux évènements à traiter dans un laps de temps très court.
Et le fps ne devrait pas être affecté, mais la réactivité de l'interface sera améliorée.

PureBasic

OpenScreen problème étrange

Re: OpenScreen problème étrange

Re: OpenScreen problème étrange

Re: OpenScreen problème étrange

Re: OpenScreen problème étrange

Re: OpenScreen problème étrange

Re: OpenScreen problème étrange

Re: OpenScreen problème étrange

Re: OpenScreen problème étrange

Re: OpenScreen problème étrange

Re: OpenScreen problème étrange

Re: OpenScreen problème étrange

Re: OpenScreen problème étrange

Re: OpenScreen problème étrange

Re: OpenScreen problème étrange

Re: OpenScreen problème étrange