Faire avancer un objet [RéGzorromlu?]

[falsam]

sauf que l'utilisation de WindowEvent() oblige a utiliser soit un Delay() , soit FlipBuffer()
ce qui reviens au meme que de mettre un WaitWindowEvent(xx) ..

Je vais creuser un peu mais d'avance je vais dire beurk à cette méthode.

[Mesa]

La doc dit clairement que ce sont des ms, donc le programme attends 2 ms pour rien avant de continuer à faire quelque chose.

Attention, on n'utilise pas WaitWindowEvent([Minuteur]) parce que "c'est mieux" ou "moins bien" que WindowEvent() !

On utilise WaitWindowEvent([Minuteur]) dans certaines situations, surtout les applications, et WindowEvent() dans d'autres situations surtout les jeux, les démos et tout ce qui demande une réactivité immédiate.

WaitWindowEvent([Minuteur])
Description
Attend qu'un nouvel évènement se produise.

Cette fonction est identique à WindowEvent(), mais en plus, elle bloque l'exécution du programme, ce qui est très important dans un environnement multi-tâches.

Arguments
Minuteur (optionnel) Permet de spécifier le temps maximal (en millisecondes) durant lequel la fonction sera bloquante si aucun évènement ne survient.

Si aucun délai n'est spécifié, il attend indéfiniment jusqu'à ce qu'un évènement se produise.

Une application devrait, si possible, toujours utiliser cette fonction en préférence à WindowEvent() car elle ne prend pas de temps CPU en attente d'un évènement

Resultat = WindowEvent()
Description
Teste si un évènement s'est produit sur chacune des fenêtres ouvertes.

Arguments
Aucun.

Valeur de retour
Renvoie le prochain évènement de la file d'attente ou zéro s'il n'y a plus d'évènements.

Contrairement à la fonction WaitWindowEvent(), elle n'attend pas le prochain évènement et le renvoi est donc toujours immédiat. Cela peut être utile quand un traitement doit être fait sans attendre (par exemple une transaction réseau).

M.

[G-Rom]

sauf que l'utilisation de WindowEvent() oblige a utiliser soit un Delay() , soit FlipBuffer()
ce qui reviens au meme que de mettre un WaitWindowEvent(xx) ..

sinon bonjour la monté en charge du processeur sur l'application ,a voir dans le gestionaire des taches


le truc qu'on ignore, c'est a quoi correspond le minuteur
lorsqu'on met Waitwindowevent(1) , le 1 correspond a quoi ? , une Frame par seconde ? , une milliseconde ? ,

je pense qu'il s'agit d'une Frame par seconde, ça devrai logiquement etre callé sur la VBL ...
sinon c'est dommage que ce soit calé sur une horloge ....

Quel est le but d'un microprocesseur ? de traiter des données , à quoi cela sert il de rendre la main à l'os alors que tu utilises une application plein écran ? perso , quand je lance une app fullscreen , je m'en bas les steack de savoir que les app en arrière plan tournent moins bien que celle que j'utilise à l'instant T. Ton raisonnement est correct dans le cas d'une application basique, quand je code une calculette , j'ai pas envie que mon proco tourne à fond les ballons, mais là , on est déjà plus dans le domaine du JV, je paye un processeur , je l'utilise , point.

On utilise WaitWindowEvent([Minuteur]) dans certaines situations, surtout les applications, et WindowEvent() dans d'autres situations surtout les jeux, les démos et tout ce qui demande une réactivité immédiate.

+1

ça devrai logiquement etre callé sur la VBL ...

C'est terminé les écrans avec des canons à électron , c'est la CG qui gère cela , toi , tu ne remplis qu'un buffer de mémoire que la CG envois sur l'écran. donc la VBL , on se la taille en biseau

[Zorro]

ha en Millisecondes ... alors effectivement ....

ton explication est claire Mesa


@G-rom : oui en fait je pensai que cela pouvait etre calé sur la VBL (ce qui reviens a dire sur le nombre de Frames par secondes de nos jours...)

je trouve la doc mal expliquée (ou pas assez expliqué ) sur ce sujet

[Naheulf]

à quoi cela sert il de rendre la main à l'os alors que tu utilises une application plein écran ?

Ça sert à réduire l'utilisation du CPU lorsqu'il n'y en a pas besoin. et donc réduire la consommation en électricité pour éviter que ton programme siphonne l'autonomie des ordinateurs portables... ou explose la facture d'électricité des tours/serveurs.

[G-Rom]

à quoi cela sert il de rendre la main à l'os alors que tu utilises une application plein écran ?

Ça sert à réduire l'utilisation du CPU lorsqu'il n'y en a pas besoin. et donc réduire la consommation en électricité pour éviter que ton programme siphonne l'autonomie des ordinateurs portables... ou explose la facture d'électricité des tours/serveurs.

Relis mon message plus haut, dans le cadre d'un programme qui ressemble à un jeu comme le fait SPH , ca ne sert à rien , il a besoin de tout le temps CPU possible , ca ne sert à rien de ralentir artificiellement avec des delay , et besoin ou pas le delay s'en contrefiche , il fou le programme de coté , que le programme rame ou pas.
SAUF , comme je l'ai dit plus haut et qu'un autre membre l'a aussi fait remarqué , dans le cadre d'une petite application basique.

[Naheulf]

*y compris dans un jeu. Et ça permet accessoirement à d'autres appli (Discord par exemple) de tourner en même temps pour pouvoir dialoguer avec les potos.

[G-Rom]

Mouais, tu n'as pas du souvent ouvrir des sources sur github pour affirmé cela. j'ai jamais vu un jeu avec "un ou des" delay()/sleep() pour ralentir le programme...

Bonne nuit.


edit :

https://gamedev.stackexchange.com/quest ... on-windows
https://stackoverflow.com/questions/413 ... e-unstable
https://gamedev.net/forums/topic/434079 ... p/3884520/
https://github.com/id-Software/DOOM/blo ... 0/d_main.c
https://github.com/id-Software/wolf3d/b ... /WL_MAIN.C

Je peu continuer toute la nuit , j'en trouverais pas.

[G-Rom]

Code : Tout sélectionner

Procedure SimulationJeu()
  For j = 0 To 10
    For i = 0 To 500
      A.d = Cos(i*i/180*#PI)  
      B.d = Sin(i*i/180*#PI)  
      C.d = Sin(i*i/180*#PI) * Cos(i*i/180*#PI)  
      D   = A + B + C
    Next
  Next 
EndProcedure



run_timer = ElapsedMilliseconds() + 3000

tick_a = 0

While run_timer > ElapsedMilliseconds()
  delta_clock.i = ElapsedMilliseconds()
  
  SimulationJeu()
  
  delta_time.f = (ElapsedMilliseconds() - delta_clock) / 1000.0
  tick_a = tick_a + 1
Wend 



run_timer = ElapsedMilliseconds() + 3000

tick_b = 0

While run_timer > ElapsedMilliseconds()
  delta_clock.i = ElapsedMilliseconds()
  
  SimulationJeu()
  
  delta_time.f = (ElapsedMilliseconds() - delta_clock) / 1000.0
  tick_b = tick_b +  1
  Delay(2)
Wend 


MessageRequester("Test","Sans delay " + Str(tick_a) + " frames"+ Chr(10)+"Avec delay " + Str(tick_b) + " frames ( deltatime surement instable à cause du delay ) "+Chr(10)+"Frame perdue pour discord : " +Str(100-((tick_b * 100) / tick_a))+"%")

[Naheulf]

Mouais, tu n'as pas du souvent ouvrir des sources sur github pour affirmé cela. j'ai jamais vu un jeu avec "un ou des" delay()/sleep() pour ralentir le programme...

Bah pourtant, tous les jeux qui proposent une limitation des FPS et/ou l'option V-Sync ont cette option à un endroit ou un autre... Que ce soit directement dans le code du jeu, dans un bibliothèque, sous la forme d'une boucle d'attente active ou via l'utilisation plus ou moins direct d'un timer. Ces deux fonctionnalités nécessitent l'utilisation à un moment ou un autre de delay()/sleep() ou équivalent...

[G-Rom]

Mouais, tu n'as pas du souvent ouvrir des sources sur github pour affirmé cela. j'ai jamais vu un jeu avec "un ou des" delay()/sleep() pour ralentir le programme...

Bah pourtant, tous les jeux qui proposent une limitation des FPS et/ou l'option V-Sync ont cette option à un endroit ou un autre... Que ce soit directement dans le code du jeu, dans un bibliothèque, sous la forme d'une boucle d'attente active ou via l'utilisation plus ou moins direct d'un timer. Ces deux fonctionnalités nécessitent l'utilisation à un moment ou un autre de delay()/sleep() ou équivalent...

https://gafferongames.com/post/fix_your_timestep/

Haa, aucun delay ou slip qui traine par terre

Ces deux fonctionnalités nécessitent l'utilisation à un moment ou un autre de delay()/sleep() ou équivalent...

pas du tout. lis bien le lien du dessus.

[Naheulf]

Haa, aucun delay ou slip qui traine par terre

Normal car à aucun moment il ne propose de fixer les fps... Au contraire, il propose un algorithme qui permet justement de s’accommoder de fps variables...

Prenons un exemple de jeu extrêmement simple du genre "Pong!". Si tu implémente son algorithme et que tu désactive le V-Sync (qui à sa propre temporisation intégrée au niveau du GPU), ton jeu va facilement tourner à 600 FPS... pour au final n'afficher qu' une image sur 10 sur un écran 60Hz. Ce n'est pas ce que j'appelle réduire l'utilisation du CPU...

[G-Rom]

Normal car à aucun moment il ne propose de fixer les fps...

t'as rien compris... t'est un gland , j'ai l'impression de parlé à jb13 ou l'autre shadow...

le titre : Fix Your Timestep!

C'est applicable pour :

- la physique.
- le réseau.
- l'affichage.


je passe mon chemin, bonne soirée.

[Ollivier]

Ce qui vous brouille la tête c'est que vous vous basez sur 2 OS différents avec un fonctionnement préemptif différent.

Windows contraint ses tâches à des tranches de 16 ms. Une tâche peut outrepasser ça, mais chaque période de 16 ms maintenue non partagée accumule une pile en mémoire virtuelle. Résultat, plus une tâche s'impose, plus le freeze va être long pour vider cette pile.
Si le "freeze" est trop long, alors Windows découpe son freeze en x morceaux (ça peut être des dizaines, des centaines, voire des milliers de morceaux, donc un cirque qui dure des heures). Résultat : le "jeu" un peu trop imposant en ressources CPU, il passe en mode multi-freeze injouable.
Enfin, après le mode "freeze occasionnel", puis le mode "mini freeze" toutes les secondes pendant x heures vient le mode "buy-another-computer" : Windows fonctionne bien pendant x heures à donf sans le moindre partage de ressources offert par un jeu, puis soudain il plante nettement, clairement et simplement.

D'où une "obligation" de mettre des délais ou équivalents pour rester compatible Windows.

[G-Rom]

D'où une "obligation" de mettre des délais ou équivalents pour rester compatible Windows.

N'importe quoi...