90

robinHood (./88) :
car je serais curieux de savoir ce qui se passe si tu bouge ta sourie comme un malade pour saturer d'event ton programme

Question intéressante : que peux faire un programme qui est saturé d'entrées ? Il va forcément laguer, non ?
Avec SDL, on peut réduire les évènements inutiles en les pumpant manuellement avec un masque pour éliminer d'office ceux dont on se fout, mais il reste toujours potentiellement plein d'events qui peuvent s'empiler, par exemple si je retourne mon clavier sur le bureau et que je m'assieds dessus... Il est censé se passer quoi alors ?

91

cheeky

sauf que le wait lui ne filtre pas les events

switch(SDL_PeepEvents(event, 1, SDL_GETEVENT, SDL_ALLEVENTS))

bref il va soit bouffer du cpu pour rien, soit dans le pire des cas, suivant comment tout est codé en interne, te fera qq sdl_delay pour rien (et si c'est le cas peut être même ne pas te donner l'event du timer au bout de tes 200ms qui sait ?)

pour ton exemple ce n'est pas grave, mais plus tard suivant comment tu code ta boucle principale ca pourrais delayer les event sur plusieurs frames, mieux vaut le prendre en compte.
et la le mec il le pécho par le bras et il lui dit '

92

robinHood (./91) :
pour ton exemple ce n'est pas grave, mais plus tard suivant comment tu code ta boucle principale ca pourrais delayer les event sur plusieurs frames, mieux vaut le prendre en compte.

Yep, là c'est un menu. Pour un jeu d'action, il vaut peut-être mieux récupérer les évènements à la main, c'est pas un problème.

93

robinHood (./88) :
mais petite remarque, après le wait, perso je viderais complètement la pile d’évent au lieu d'attendre que sdl te les envois un par un, car je serais curieux de savoir ce qui se passe si tu bouge ta sourie comme un malade pour saturer d'event ton programme

J'avais pas percuté, mais ça revient à faire un
SDL_WaitEvent (&ev);
do
{
    // events trucs et machins
} while (!SDL_PollEvent (&ev);

?
Qu'est-ce qui dit qu'on va pas traiter de l'event de manière bloquante pour le programme ?
En fait, il faudrait un thread à part pour traiter les events, à part du rendu et de "l'avancement" du programme (réglé par rapport au temps et non au framerate tongue), et essayer de traiter les évènements quand on a le temps ?
Malheureusement, j'y connais rien en multi-thread sad

94

non, n'attend pas, traite simplement ceux de dispos

SDL_WaitEvent (&ev); 
do 
{ 
    // events trucs et machins 
} while (SDL_PollEvent (&ev);





faire un thread à part sera certainement le plus propre, mais pas forcement portable sur toutes les plateformes (comme la gp32 par exemple)

moi je n'avais qu'un seul thread, et j'interpolais les déplacements pour chaque frame entre la vitesse désiré et celle de l'affichage, ce qui n'est pas forcément le mieux et le plus simple, loin de la, surtout si le framerate n'est pas constant
et la le mec il le pécho par le bras et il lui dit '

95

Oui, faut pas de ! bien sûr ^^

96

robinHood (./88) :
GoldenCrystal (./86) :
(Personnellement j'ai rien contre le Sleep pour attendre un truc (technique simpliste de flemmard trioui.gif ), m'enfin dans la boucle principale du programme, ça pue un peu, quoi...)

je ne pense pas, sleep ne veut pas dire j'attend mais plutôt "la j'ai du cpu en rab personne en à besoin ?"
Non, ça c'est la définition de yield, alors que sleep veut dire "je dors pendant au minimum x unités de temps et je laisse les autres faire leur boulot pendant que je dors"
ce n'est pas de l'embarqué, d'autre programmes tournent !
Ouais, d'autres programmes "tournent". Ça ne veut en aucun cas dire qu'ils sont actifs, ni qu'ils utilisent une quelconque quantité non strictement nulle de temps CPU.
pour moi sleep est obligatoire, au moins un sleep(0);
Fort heureusement, non.
et sous win2k (et wine) c'etais le top car sleep(1); te synchronisais à 60 fps
sick ça reste tout à fait dans le contrat de sleep pourtant, et ça collerait malgré tout très bien à la plupart des cas où tu attends un truc qui va se produire bientôt.
(PS: Quand tu utilises sleep(>0), tu indiques nécessairement que tu n'est pas trop regardant sur le temps réel qui s'écoulera pendant le sommeil)
Folco (./85) :
Et sinon, locker ta surface avant un Flip, ça sert à quoi ?
À tout sauf à quelque chose d'utile, t'en fais pas. wink
concernant le fait d'utiliser un event custom, oui, c'est de loin la chose la plus propre !
Ou pas ?
mais petite remarque, après le wait, perso je viderais complètement la pile d’évent au lieu d'attendre que sdl te les envois un par un
Car bien évidemment SDL fait un sleep avant de récupérer les messages c'es évident triso
Heureusement ça n'est pas aussi pourri que ça.
car je serais curieux de savoir ce qui se passe si tu bouge ta sourie comme un malade pour saturer d'event ton programme
Ça ça dépend juste de ton programme. Si il met trop de temps à traiter les messages, il saturera.
Dans le cas contraire, bonne chance pour arriver à le saturer.
Zerosquare (./83) :
Kevin > mais ça reste un hack crade, qui génère des context switches pour rien
tu mésestime trop le système je pense
Il mésestime que dalle. Il y a certainement très peu d'OS où sleep n'est pas implémenté avec un appel système.
quoi qu'il arrive il le fera, autant lui dire quant c'est le bon moment non ?
Oui, mais il y a des meilleures façons de faire, beaucoup plus efficace.
vous parliez de sauvegarder la batterie, c'est ce que ca fait, ca n'utilise que le nécessaire
Non, il n'y a que Zerosquare qui fait une fixation là dessus en fait.
Enfin, soyons clair, si tu fais tourner en arrière plan un programme à base de sleep() sur ton iPhone ou tel Android, tu vas ruiner la batterie en deux temps trois mouvements.
Il y a des primitives de synchronisation bien plus efficaces (mais nécessairement plus couteuses en mémoire… par rapport au cout "zéro" du sleep) qui te permettent réellement de ne rien exécuter quand tu as besoin de ne rien exécuter cheeky

J'espère que tu comprends la différence entre "attendre jusqu'à ce que x se produise" et "vérifier si x s'est produit; si non, attendre minimum x millisecondes puis recommencer" Dans le premier cas, ton thread est inactif et ne consomme pas de CPU, alors que dans l'autre il est (fréquemment) actif et consomme du cpu.
Folco (./90) :
Avec SDL, on peut réduire les évènements inutiles en les pumpant manuellement avec un masque pour éliminer d'office ceux dont on se fout, mais il reste toujours potentiellement plein d'events qui peuvent s'empiler, par exemple si je retourne mon clavier sur le bureau et que je m'assieds dessus... Il est censé se passer quoi alors ?
Si tu retournes ton clavier et que tu t'assois dessus, y'a une file qui va peut-être saturer quelque part, mais ça ne sera pas forcément celle de ton programme grin Mais avant ça, ton clavier risque de se péter cheeky
Sans compter que sur beaucoup de clavier, les touches ne sont pas toutes indépendantes les unes des autres tongue

Folco (./93) :
J'avais pas percuté, mais ça revient à faire un
SDL_WaitEvent (&ev);
do
{
    // events trucs et machins
} while (!SDL_PollEvent (&ev);
Ne fait surtout pas ça, ça sert vraiment à rien ! -_-
Contente toi de SDL_WaitEvent comme tu faisais, ça fera aussi bien…
Qu'est-ce qui dit qu'on va pas traiter de l'event de manière bloquante pour le programme ?
C'est à toi de gérer ça.
En fait, il faudrait un thread à part pour traiter les events, à part du rendu et de "l'avancement" du programme (réglé par rapport au temps et non au framerate tongue), et essayer de traiter les évènements quand on a le temps ?
Si tu voulais/avais besoin de faire un truc hautement performant, oui, mais dans ce cas tu n'utiliserais pas SDL.
Malheureusement, j'y connais rien en multi-thread sad
Contente toi donc de code simple, ça suffira très bien pour l'instant tongue
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

97

GoldenCrystal (./96) :
Qu'est-ce qui dit qu'on va pas traiter de l'event de manière bloquante pour le programme ?
C'est à toi de gérer ça.

En flushant les events qu'ont une salle gueule ? Comment faire concrètement ?

98

GoldenCrystal (./97) :
Non, il n'y a que Zerosquare qui fait une fixation là dessus en fait. Enfin, soyons clair, si tu fais tourner en arrière plan un programme à base de sleep() sur ton iPhone ou tel Android, tu vas ruiner la batterie en deux temps trois mouvements.
Donc en gros tu dis que j'ai tort mais que j'ai raison ? cheeky

La batterie d'un PC portable est plus grosse que celle d'un smartphone, mais c'est pas une excuse pour gaspiller (suffit de voir tous les programmes qui tournent arrière-plan sur un PC "de marque", codés en mode "rienàfoutre" : on connaît le résultat...)
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

99

Folco > Ben je sais pas, le côté bloquant ou non bloquant, c'est juste toi qui gère ça comme tu veux.
Typiquement, une gestion d'évènements raisonnable n'est pas sensé avoir un impact dramatique sur les performances.
Si jamais, pour une raison x ou y, tu devais t'apercevoir que le traitement d'un évènement en particulier prenait trop de CPU[, soit parce qu'il y a énormément de messages reçus, soit parce que traiter un de ces messages est long, soit pour une combinaison variable de ces deux facteurs], alors tu aurais à adapter la façon dont tu gères ces messages afin que leur traitement ne soit pas bloquant vis-à-vis des autres.
Mais tout ça est au cas par cas en fonction des besoins de ton programme.
Il faut juste retenir que le traitement d'un évènement doit être le plus court possible, et que tu dois générer le moins de messages possibles. (Windows fait par exemple de l'agrégation de messages sur certains types de messages, afin de simplifier le boulot de l'application…)
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

100

Zerosquare (./98) :
GoldenCrystal (./97) :
Non, il n'y a que Zerosquare qui fait une fixation là dessus en fait. Enfin, soyons clair, si tu fais tourner en arrière plan un programme à base de sleep() sur ton iPhone ou tel Android, tu vas ruiner la batterie en deux temps trois mouvements.
Donc en gros tu dis que j'ai tort mais que j'ai raison ? cheeky
Non, que tu as raison, mais que c'est hors propos ! tongue
(Je sais pas, sur les PC au boulot par exemple, y'a pas de batterie grin)
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

101

C'était pour citer un autre inconvénient de faire du polling + sleep (et les appareils mobiles de tous genres sont de plus en plus répandus).
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

102

robinHood (./88) :
Zerosquare (./83) :
Kevin > mais ça reste un hack crade, qui génère des context switches pour rien

tu mésestime trop le système je pense, quoi qu'il arrive il le fera, autant lui dire quant c'est le bon moment non ?vous parliez de sauvegarder la batterie, c'est ce que ca fait, ca n'utilise que le nécessaire

Bah non. Si tu utilises un syscall qui attent un certain évènement du noyau, le processus (et si aucun autre processus n'est actif, le CPU) n'est réveillé que quand cet évènement se produit, du moins sous le noyau Linux.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

103

Et c'est pareil sous Windows, ou n'importe quel autre OS décent je pense.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

104

Justement, je ne suis pas convaincu que ce soit un "OS décent". grin
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

105

On t'a déjà dit que tu étais d'une prévisibilité déprimante ?
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

106

yield ? quant je lis la def ca ressemble comme deux gouttes d'eau à un Sleep(0); sauf qu'il met le processus en dernier de la liste

en plus, il ne stoppe pas le processus si il n'y en à pas d'autre
sched_yield() causes the calling thread to relinquish the CPU. The thread is moved to the end of the queue for its static priority and a new thread gets to run.
If the calling thread is the only thread in the highest priority list at that time, it will continue to run after a call to sched_yield().


comme Sleep(0) sous xp d'ailleurs ... http://msdn.microsoft.com/en-us/library/ms686298%28VS.85%29.aspx

vive le 100% de cpu pour rien ... :- /

et d’ailleurs, je ne sait ce que ça vaut mais magnifique implémentation de yield en utilisant Sleep http://lists.puremagic.com/pipermail/phobos/2010-September/002284.html
GoldenCrystal (./96) :
Ouais, d'autres programmes "tournent". Ça ne veut en aucun cas dire qu'ils sont actifs, ni qu'ils utilisent une quelconque quantité non strictement nulle de temps CPU.

Ouais sur l'autoroute d'autre voitures "roulent". Ca ne veut en aucun cas dire quelle ne sont pas sur l'aire de repos, ou ne roulent pas à deux à l'heure sur la voie de droite.

donc roulons à fond ?
GoldenCrystal (./96) :
Fort heureusement, non.

GoldenCrystal (./96) :
Folco (./85) :
Et sinon, locker ta surface avant un Flip, ça sert à quoi ?
À tout sauf à quelque chose d'utile, t'en fais pas. wink.gif

effectivement en relisant la doc je vois que j'ai mis les fonctions dans le mauvais ordre
SDL_LockSurface sets up a surface for directly accessing the pixels. Between calls to SDL_LockSurface and SDL_UnlockSurface, you can write to and read from surface->pixels, using the pixel format stored in surface->format. Once you are done accessing the surface, you should use SDL_UnlockSurface to release it.
ma lib possède ses propres format d'images et fonctions de blit, quant elle utilise sdl elle tape direct dans le buffer de la surface, que je voulais locker proprement au flip (qui sait si le lock/unlock ne calcule pas des buffer temporaires dans divers format de blit pour accélérer les choses ?)
GoldenCrystal (./96) :
Fort heureusement, non.

donc si tes jeux utilisent le max de puissance possible, je n'en lancerais jamais aucun, cpu 100% => poubelle
GoldenCrystal (./96) :
Ou pas ?

en tout cas c'est très propre tout de même :- ) et je comprend la joie qu'à du avoir folco en utilisant cela, j'ai fait la même il y 7 jours (ok, rien à voir avec du C tongue), et j'ai trouvé ça super utile simple et propre comme système !
GoldenCrystal (./96) :
sick.gif ça reste tout à fait dans le contrat de sleep pourtant, et ça collerait malgré tout très bien à la plupart des cas où tu attends un truc qui va se produire bientôt. (PS: Quand tu utilises sleep(>0), tu indiques nécessairement que tu n'est pas trop regardant sur le temps réel qui s'écoulera pendant le sommeil)

si sdl étais fait habilement tout serais par callback pour les event, sauf que ce n'est pas le cas, bref faut lire régulièrement (ou alors dis moi quoi utiliser) sauf qu'avoir 1000000 test/seconde et 100% de cpu ben je te le laisse, très peu pour moi et mes programmes, un test de sourie ou touche n'est pas un arrêt d'urgence que je sache
GoldenCrystal (./96) :
Car bien évidemment SDL fait un sleep avant de récupérer les messages c'es évident triso.gif Heureusement ça n'est pas aussi pourri que ça.

c'est une hypothèse, sait on jamais, tu as écrit sdl ? pas moi. le fait de se reposer sur cette fonction pour dispatcher un par un les event pose des risques intérogations et connaitre son fonctionnement et éventuellement la shunter est pertinent.

en tout cas grace à cette fonction les dev de sdl nous montre comment faire une boucle avec sdl, un while 1 et un sdl delay, sdl_delay implémenté sous windows comme cela :

void SDL_Delay(Uint32 ms)
{
	Sleep(ms);
}
\o/

hérésie ! !call sdlTeam
GoldenCrystal (./96) :


de plus les procs sont rapides, mais Folco aime optimiser non ? lancer un wait qui va se while un pumpilup c'est vraiment moche et surtout inutile
GoldenCrystal (./96) :
Il mésestime que dalle. Il y a certainement très peu d'OS où sleep n'est pas implémenté avec un appel système.

mésestime == sous estime, tu as mal compris,
et si justement sleep ne fait pas des nop et appelle le système, c'est l’intérêt, qu'il fasse son job et fasse tourner le code moins vite en donnant du temps à d'autre processus éventuellement plus critique
GoldenCrystal (./96) :
Enfin, soyons clair, si tu fais tourner en arrière plan un programme à base de sleep() sur ton iPhone ou tel Android, tu vas ruiner la batterie en deux temps trois mouvements.
Il y a des primitives de synchronisation bien plus efficaces (mais nécessairement plus couteuses en mémoire… par rapport au cout "zéro" du sleep) qui te permettent réellement de ne rien exécuter quand tu as besoin de ne rien exécuter mod.gif
J'espère que tu comprends la différence entre "attendre jusqu'à ce que x se produise" et "vérifier si x s'est produit; si non, attendre minimum x millisecondes puis recommencer" Dans le premier cas, ton thread est inactif et ne consomme pas de CPU, alors que dans l'autre il est (fréquemment) actif et consomme du cpu.


pourquoi un sleep boufferais la batterie ? le proc tombe à 0% si ca bouffe la batterie, c'est vers windows qu'il faut se tourner pour des explications

ici aussi, nous parlons de code mono thread, pas de sémaphore ou autre, si tu connais un moyen de réduire la vitesse de manière simple ça m'intéresse

peut être veut tu parler sous windows de la fonction
LRESULT CALLBACK WndProc(HWND hWnd,UINT message,WPARAM wParam,LPARAM lParam) ?
quant ma lib n'utilise pas sdl elle à son point d'entrée la dedans pour la vérification des messages, les traites et éventuellement si ceux si sont définis lance les callbacks vers les fonctions onClick onMove etc
c'est très puissant et évite une vérification perpétuelle, d’ailleurs je ne comprend pas que sdl ne propose pas d'office la même chose :- /
et la le mec il le pécho par le bras et il lui dit '

107

robinHood (./107) :
pourquoi un sleep boufferais la batterie ? le proc tombe à 0% si ca bouffe la batterie, c'est vers windows qu'il faut se tourner pour des explications
C'est pas le Sleep() qui bouffe de la batterie, c'est le fait de réactiver ton thread une fois que la durée du Sleep() sera écoulée, ce qui est complètement inutile si tu n'as aucun événément à traiter.

avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

108

Ben en meme temps, tu fais comment pour ne pas faire de context switch et ne pas bouffer 100% du CPU?

Il n'y a que l'OS qui peux faire tomber le CPU en mode basse conso, pas ton soft, et meme si tu fait un wait sur un event, tu reviens a faire des context switch...
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

109

Tu fais un context switch quand tu lances ton Wait(), et un autre quand l'événement survient. Tu n'en fais pas tant qu'il ne se passe rien, contrairement au Sleep() qui va en provoquer un dès qu'il aura fini.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

110

Heu "tu n'en fait pas tant qu'il ne se passe rien" ? Heu si, si tu pars en attente d'un evenement du kernel, il va mettre ton process/thread dans la liste des taches inactive et donner la main a une autre tache, donc un joli context switch.

Apres si ton programme doit fonctionner a une fréquence précise (prendre le cas d'un émulateur par exemple) tu n'a pas 36 méthodes pour fixer la fréquence, a pars des sleep ou des boucles, autant prendre un sleep qui sera un peu moins méchant sur le CPU. Les evenements timers sont a proscrire car vraiment pas précis (déjà qu'un sleep l'est moyen..)
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

111

non, il veut dire que le wait utilise sleep lui même ...

dans mon cas perso, vu que je mettais à profit la synchro à 60fps que me proposais le sleep, mon code ne se réveillais que pour afficher la frame courante, ou traiter les event venant de windows je ne gaspille rien, mais ici avec sdl et cette vérification manuelle des touches et autres c'est loin d'être le cas.
et la le mec il le pécho par le bras et il lui dit '

112

un context switch ca bouffe tant que ca ? n'est ce pas concrètement qu'un save/load des registres ? (oui je suis un noob :- D)
et la le mec il le pécho par le bras et il lui dit '

113

Folco (./73) :
Pouah ! Une abomination pour moi, à qui un cycle perdu fend le cœur.



GT calin Folco smile
avatar
Accrochez vous ca va être Cerebral !!

114

Godzil (./110) :
Heu "tu n'en fait pas tant qu'il ne se passe rien" ? Heu si, si tu pars en attente d'un evenement du kernel, il va mettre ton process/thread dans la liste des taches inactive et donner la main a une autre tache, donc un joli context switch.
Ben je n'ai jamais dit le contraire, relis ce que j'ai écrit cheeky
Et si tous les threads utilisent ce mécanisme (ce qui est le cas pour les softs bien programmés, quand ils sont en arrière-plan ou qu'ils n'ont aucune donnée à traiter), le kernel va mettre le CPU en veille jusqu'à ce qu'il se passe quelque chose.
Godzil (./110) :
Apres si ton programme doit fonctionner a une fréquence précise (prendre le cas d'un émulateur par exemple) tu n'a pas 36 méthodes pour fixer la fréquence, a pars des sleep ou des boucles, autant prendre un sleep qui sera un peu moins méchant sur le CPU. Les evenements timers sont a proscrire car vraiment pas précis (déjà qu'un sleep l'est moyen..)
Non mais je préconise pas de faire du busy waiting sans Sleep() non plus, hein, c'est encore pire tongue
Je dis juste que si tu attends un événement, il vaut mieux utiliser une fonction prévue pour ça et qui n'utilisera pas de CPU (sous Windows, ça sera WaitForSingleObject(), GetMessage(), etc.) que de faire une boucle qui teste périodiquement avec un Sleep() ; et si SDL est pas trop mal foutue, WaitEvent() doit être un wrapper pour une ou plusieurs fonctions de ce genre.

Pour le cas d'un truc périodique, Sleep() n'est pas une si bonne idée que ça, parce que tu vas avoir un jitter aléatoire (dû au Sleep() lui même, mais aussi au temps d'exécution du code placé avant : si ton code ne prend toujours pas le même temps pour s'exécuter mais que tu as un Sleep() d'une durée fixe, ça ne sera pas périodique).

Les timers Windows de base ne sont pas ultra performants, mais au moins ils sont toujours générés à la même fréquence. Pour faire mieux, il y a les timers multimédias. Dans les programmes avec du son, on peut aussi se baser sur la fin de lecture des buffers audio (qui se produit périodiquement). Et je crois que DirectX permet aussi d'attendre un Vsync sans bouffer de CPU.

Si tu veux de la précision et de la réactivité, augmenter le niveau de priorité du processus et/ou du thread en question aide aussi.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

115

robinHood (./106) :
yield ? quant je lis la def ca ressemble comme deux gouttes d'eau à un Sleep(0); sauf qu'il met le processus en dernier de la liste
Oui, ça ressemble, mais ça n'a rien à voir. La description que tu donnais toi dans ton post est celle de "yield" et non de "sleep". "Donner du boulot aux autres" c'est yield, sleep c'est "dormir".
en plus, il ne stoppe pas le processus si il n'y en à pas d'autre
Et donc ? trifus
vive le 100% de cpu pour rien ... :- /
Gné ? trifus
et d’ailleurs, je ne sait ce que ça vaut
Rien.
mais magnifique implémentation de yield en utilisant Sleep http://lists.puremagic.com/pipermail/phobos/2010-September/002284.html
C'est pas parce que t'as un effet similaire que c'est la même chose. yield > sleep.
Sinon, sous Windows, yield s'apelle SwitchToThread…
GoldenCrystal (./96) :
Ouais, d'autres programmes "tournent". Ça ne veut en aucun cas dire qu'ils sont actifs, ni qu'ils utilisent une quelconque quantité non strictement nulle de temps CPU.
Ouais sur l'autoroute d'autre voitures "roulent". Ca ne veut en aucun cas dire quelle ne sont pas sur l'aire de repos, ou ne roulent pas à deux à l'heure sur la voie de droite.
Je veux bien croire que mon truc (bien que exact) ait été maladroitement dit, mais ta déformation est foireuse. Une voiture qui est à l'arrêt ne roule pas. Par contre tu ne me feras pas gober que dans ton esprit la fenêtre explorer minimisée qui en réalité est totalement inactive, ne "tourne" pas tongue
Bref, c'est juste pour dire qu'on est pas obligé de consommer du cpu pour "tourner". tongue
donc roulons à fond ?
J'ai absolument pas dit ça…
GoldenCrystal (./96) :
Fort heureusement, non.
donc si tes jeux utilisent le max de puissance possible, je n'en lancerais jamais aucun, cpu 100% => poubelle
Tu ne devrais jouerà aucun jeu moderne alors.
Personnellement, la plupart des jeux auxquels je joue, utilisent toute la puissance nécessaire sur le PC… Quel est l'intérêt d'avoir un bon CPU si c'est pour ne jamais l'utiliser hein ?
L'intérêt c'est de t'en servir quand t'en as besoin. Si tu résumes tout à un % d'utilisation CPU, c'est une vision assez triste des choses. T'as peut être du mal à concevoir qu'on puisse utiliser légitimement 100% du CPU ? cheeky (Hint : Suffit de concevoir son application correctement tongue)
GoldenCrystal (./96) :
Ou pas ?

en tout cas c'est très propre tout de même :- ) et je comprend la joie qu'à du avoir folco en utilisant cela, j'ai fait la même il y 7 jours (ok, rien à voir avec du C tongue), et j'ai trouvé ça super utile simple et propre comme système !
GoldenCrystal (./96) :
sick.gif ça reste tout à fait dans le contrat de sleep pourtant, et ça collerait malgré tout très bien à la plupart des cas où tu attends un truc qui va se produire bientôt. (PS: Quand tu utilises sleep(>0), tu indiques nécessairement que tu n'est pas trop regardant sur le temps réel qui s'écoulera pendant le sommeil)

si sdl étais fait habilement tout serais par callback pour les event, sauf que ce n'est pas le cas, bref faut lire régulièrement (ou alors dis moi quoi utiliser) sauf qu'avoir 1000000 test/seconde et 100% de cpu ben je te le laisse, très peu pour moi et mes programmes, un test de sourie ou touche n'est pas un arrêt d'urgence que je sache
GoldenCrystal (./96) :
Car bien évidemment SDL fait un sleep avant de récupérer les messages c'es évident triso.gif Heureusement ça n'est pas aussi pourri que ça.
c'est une hypothèse, sait on jamais, tu as écrit sdl ?
C'est pas une hypothèse, banane, le code est dans ton propre post… C'est pas la peine de poster du code si tu n'es pas capable de le lire -_-
robinHood (./84) :
int SDL_WaitEvent (SDL_Event *event)
{
	while ( 1 ) {
		SDL_PumpEvents();
		switch(SDL_PeepEvents(event, 1, SDL_GETEVENT, SDL_ALLEVENTS)) {
		    case -1: return 0;
		    case 1: return 1;
		    case 0: SDL_Delay(10);
		}
	}
}
cheeky

le fait de se reposer sur cette fonction pour dispatcher un par un les event pose des risques intérogations et connaitre son fonctionnement et éventuellement la shunter est pertinent.
Par défaut quand tu utilises une fonction, suppose qu'elle fonctionne bien… i.e. qu'elle utilise la bonne implémentation (ou bien une des meilleures s'il y a plusieurs façons de faire).
en tout cas grace à cette fonction les dev de sdl nous montre comment faire une boucle avec sdl, un while 1 et un sdl delay
Parce que t'as pas fait la même chose ? trifus
sdl_delay implémenté sous windows comme cela :

void SDL_Delay(Uint32 ms)
{
	Sleep(ms);
}
\o/
hérésie ! !call sdlTeam
Quel problème as tu en particulier avec cette implémentation ?
À part que c'est moins efficace que #define SDL_Delay(ms) Sleep(ms), c'est bien la correspondance idéale…
GoldenCrystal (./96) :
de plus les procs sont rapides, mais Folco aime optimiser non ? lancer un wait qui va se while un pumpilup c'est vraiment moche et surtout inutile
Oui, mais il cherche (aussi (surtout)) à faire les choses correctement. Enfin je vais le laisser répondre pour lui-même.
GoldenCrystal (./96) :
Il mésestime que dalle. Il y a certainement très peu d'OS où sleep n'est pas implémenté avec un appel système.
mésestime == sous estime, tu as mal compris,
Non, j'avais parfaitement compris… C'est ta réponse là que je comprends pas.
Zerosquare te dit sleep = context switch, tu dis qu'il sous-estime le système, je te dis qu'il sous-estime que dalle.
et si justement sleep ne fait pas des nop et appelle le système
Rassures-moi, tu n'en as jamais douté ? fear
fasse tourner le code moins vite
"lol"
Tu attribuais du crédit aux boucles for vides pour assurer le timing des très vieux jeux aussi ?
en donnant du temps à d'autre processus éventuellement plus critique
Les processus plus critiques ont une priorité plus haute, ils ont pas besoin de ça cheeky
GoldenCrystal (./96) :
Enfin, soyons clair, si tu fais tourner en arrière plan un programme à base de sleep() sur ton iPhone ou tel Android, tu vas ruiner la batterie en deux temps trois mouvements.
Il y a des primitives de synchronisation bien plus efficaces (mais nécessairement plus couteuses en mémoire… par rapport au cout "zéro" du sleep) qui te permettent réellement de ne rien exécuter quand tu as besoin de ne rien exécuter mod.gif
J'espère que tu comprends la différence entre "attendre jusqu'à ce que x se produise" et "vérifier si x s'est produit; si non, attendre minimum x millisecondes puis recommencer" Dans le premier cas, ton thread est inactif et ne consomme pas de CPU, alors que dans l'autre il est (fréquemment) actif et consomme du cpu.

pourquoi un sleep boufferais la batterie ? le proc tombe à 0% si ca bouffe la batterie, c'est vers windows qu'il faut se tourner pour des explications
Pourquoi "pourquoi un sleep" ?
Serait-on passé des boucles d'attente basées sur sleep à uniquement la fonction sleep ? Essaye de rester un peu sérieux stp.
La fonction sleep est très bien, elle fait boulot. Comme son boulot c'est de faire à peu près son boulot, de la manière la plus efficace possible, y'a aucune explication à demander à Windows où je ne sais quoi, parce que Sleep fait très bien son boulot.

Le fait est que Sleep, comme te l'explique Zerosquare en ./107, implique deux context switch.
On context switch, ce sont des cycles CPU perdus. Par nécessité, mais perdus quand même, c'est pour ça qu'on essaye de n'avoir recours à ces context switch que par réelle nécessité.
Si tu fais plein de Sleep(1) en boucle, ton code va idéalement (en pratique, pas forcément) cramer plein de cycles 1000 fois par seconde. Tu vas sciemment cramer des cycles pour… économiser des cycles.
Alors que tu aurais pu juste économiser des cycles.
ici aussi, nous parlons de code mono thread, pas de sémaphore ou autre, si tu connais un moyen de réduire la vitesse de manière simple ça m'intéresse
Il est bien évident que le système d'évènements de SDL est tout sauf single-threaded. D'ailleurs, tout système de passage de message est tout sauf-single threaded. L'intérêt même du passage de messages est de synchroniser et/ou coordonner différents threads entre eux. (NB : pas forcément des threads du même processus)
Comme tu l'as fait remarquer, d'autres programmes "tournent" sur le PC. Multithread ou pas, eux ont trouvé un moyen de ne rien faire du tout de manière plus efficace qu'avec un sleep. Pourquoi ne pourrais-tu pas en faire de même ?
Typiquement, s'il existe un truc que tu peux attendre, alors attend ce truc (pas avec un sleep !), sinon c'est que tu ne dois pas attendre. Si tu veux malgré tout temporiser, alors "temporise" (avec un sleep)…
Dans un jeu y'a bien un truc que tu peux attendre, c'est la synchronisation verticale… DirectX te le propose par exemple. SDL le fait (à priori) tout seul dans ton dos s'il le peut.

Sinon, typiquement, dans l'implémentation de SDL_WaitEvent, qui est le vrai problème dont on parle à la base, ce qu'il est sensé faire c'est attendre l'arrivée d'un message. Protocole qu'il respecte à peu près extérieurement, mais pas réellement quand on regarde le code utilisé.
Et pour attendre un message, il suffit d'attendre qu'un message soit inséré, ce qui ne consomme pas de CPU. Dans Windows, y'a des objets "Event" qui permettent ça pour toi.
Quand tu attends un message, tu attends sur l'objet évent.
Quand tu insères un message, tu signales l'évènement. Ce qui a pour condition de débloquer celui qui attendait. Et paf…
Dans SDL, l'équivalent a l'air d'être géré par SDL_cond, en espérant que ce ne soit pas implémenté avec Sleep sous Windows, mais quoi qu'il en soit, SQL_WaitEvent aurait pu s'en servir.
peut être veut tu parler sous windows de la fonctionLRESULT CALLBACK WndProc(HWND hWnd,UINT message,WPARAM wParam,LPARAM lParam) ?
Non, pas du tout
quant ma lib n'utilise pas sdl elle à son point d'entrée la dedans pour la vérification des messages, les traites et éventuellement si ceux si sont définis lance les callbacks vers les fonctions onClick onMove etcc'est très puissant et évite une vérification perpétuelle, d’ailleurs je ne comprend pas que sdl ne propose pas d'office la même chose :- /
Je comprends pas que tu ne comprennes pas que SDL te propose (conceptuellement) la même chose avec son système d'évènements… C'est juste que Windows est un peu plus complet / complexe à ce niveau. (Heureusement, d'un autre côté)
Si tu veux déplacer le code de gestion d'un évènement SDL (le switch) dans sa fonction propre (ce qui serait très sage) alors rien ne t'empêche de le faire cheeky
Godzil (./110) :
Heu "tu n'en fait pas tant qu'il ne se passe rien" ? Heu si, si tu pars en attente d'un evenement du kernel, il va mettre ton process/thread dans la liste des taches inactive et donner la main a une autre tache, donc un joli context switch.
Je vais préciser ce que disait Zerosquare : À part les context switch initial et final, tu ne fais pas de context switch vers ou à partir de ton programme tant qu'il ne se passe rien, contrairement au sleep où tu va faire potentiellement plein de context switch alors qu'il ne se passe rien dans ton programme.
C'est mieux ? cheeky
Apres si ton programme doit fonctionner a une fréquence précise (prendre le cas d'un émulateur par exemple) tu n'a pas 36 méthodes pour fixer la fréquence, a pars des sleep ou des boucles, autant prendre un sleep qui sera un peu moins méchant sur le CPU.
Yep, j'avais fait ça aussi cheeky
Un petit Sleep à durée variable + attente active de ~1ms pour complémenter le tout et synchroniser à 60 FPS tongue
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

116

robinHood (./106) :
si sdl étais fait habilement tout serais par callback pour les event

c'est pas le cas ??
robinHood (./106) :
mais Folco aime optimiser non

J'aime faire proprement (à la hauteur de ma compréhension...), l'"optimisation" passe après. Et puis "optimiser, c'est vague, optimiser pour la vitesse ? la taille ? la maintenance ? le nombre d'octet du code source ? Puis sur PC (C/C++) je suis trop mauvais pour optimiser en taille ou en vitesse, je n'en suis capable qu'en assembleur sur TI cheeky

117

GoldenCrystal (./115) :
Le fait est que Sleep, comme te l'explique Zerosquare en ./107, implique deux context switch.


Mais un yield ne fait pas mieux, et un "WaitForEvent" non plus, la seule chose qui change c'est la périodicité d'appel de la fonction. Si ton appli est complètement évènementielle, elle ne ferra qu'un WaitForEvent pour chaque évènement la ou si ceux-ci surviennent rarement un poll avec un sleep/yeld va consommer plus, on est d'accord, vu qu'on en ferra globalement plus..

Apres, dans le cadre d'un jeu, de toute manière, on travaille rarement en évènementiel, du moins a attendre qu'un évènement arrive. La majoritée des jeux (ce n'est pas forcement optimal) utilisent le vsync pour faire de la synchro. C'est moins vrai maintenant, et certain anciens jeux utilisaient des bouclalacon calibré sur un CPU a 10Mhz, ou avaient accès a des timers précis et utilisaient ça comme synchro.

Mais en règle général, les périphériques comme clavier/souris son, par le moteur "poll-é" et non récupéré de manière évènementiel, quitte a avoir un thread pour récupérer les évènements et dans la boucle principale du moteur aller lire des variables globales ou autres.

Zero: pour l'imprecision d'un sleep/msleep/usleep & co, oui bien sur ils ne sont pas précis, mais c'est aussi la l’intérêt de mesurer le temps du sleep et d'ajuster la pause suivant suivant le jitter. Ce n'est pas optimal, mais sur CertainsOS© il n'y a pas de mecanismes de timers fiables, donc il faut faire autrement...
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

118

ok, intéressant

ca ma permis au passage de voir comment sont géré les "drivers" de chaque plateformes dans sdl

donc si je comprend bien, je pourrais utiliser un message indiquant qu'il est temps d'afficher ma frame, event se déclenchant par exemple 60 fois par seconde ? restera le problème de génération de cet event, soit dans ma boucle winmain par un sleep, un timer, directX, ou autre ?
le code d'affichage de frame lui serais appelé la fonction winproc comme le reste de mes event ?

mais question context switch, ne serais ce pas équivalent ? pour chaque event reçu, l'os réveille le programme pour son traitement, puis le rendors à la fin de celui ci ? (sans compter ceux effectué par le sleep si je le choisi lui pour la synchro ?)

concernant sdl, elle utilise winproc aussi j’imagine ? mais au lieu de traiter les event directement par callback, elle les empile et laissera l'user les dépiler et les traiter lui même dans son code ?
GoldenCrystal (./115) :
peut être veut tu parler sous windows de la fonction LRESULT CALLBACK WndProc(HWND hWnd,UINT message,WPARAM wParam,LPARAM lParam) ?
Non, pas du tout


ok, c'est la que je ne comprend pas, pourquoi non ?
cette fonction ne s’exécute t'elle pas seulement quant un message surviens ? et n'est ce pas justement le but recherché ?

au passage y à t'il des priorité d’évent ou est ce une simple pile ? puis je dire que le message d'affichage de frame doit passer devant tous les autres moins importants comme ceux clavier/sourie ?

si ce n'est pas le cas, c'est pour cela qu'il existe des "listener" ? j'en pose un spécifique à cet event dans ma boucle principale et il agira comme un sleep en mieux pour pauser mon code ?
GoldenCrystal (./115) :
"lol" Tu attribuais du crédit aux boucles for vides pour assurer le timing des très vieux jeux aussi ?

si l'hardware est fixe, branché au secteur, et que seul un programme tourne à la fois, je ne vois pas le problème (sauf si bien sur ce temps perdu aurais pu être utilisé pour précalculer autre chose)
GoldenCrystal (./115) :
Tu ne devrais jouerà aucun jeu moderne alors.
Personnellement, la plupart des jeux auxquels je joue, utilisent toute la puissance nécessaire sur le PC… Quel est l'intérêt d'avoir un bon CPU si c'est pour ne jamais l'utiliser hein ?
L'intérêt c'est de t'en servir quand t'en as besoin. Si tu résumes tout à un % d'utilisation CPU, c'est une vision assez triste des choses. T'as peut être du mal à concevoir qu'on puisse utiliser légitimement 100% du CPU ? mod.gif (Hint : Suffit de concevoir son application correctement tongue.gif )

non bien sur, mais ici nous parlons de jeux 2d qui bouffe 0.01% de la puissance possible de nos machines actuelles
et pour moi c'étais simple, pas de sleep => 100%, sleep(0) => 100% sleep(1) => 0% mon choix étais vite fait.
GoldenCrystal (./115) :
en tout cas grace à cette fonction les dev de sdl nous montre comment faire une boucle avec sdl, un while 1 et un sdl delay
Parce que t'as pas fait la même chose ? trifus.gif

si, pour justement avoir mes 60 fps, mais si c'est moi qui le fait on me jette tongue
et la le mec il le pécho par le bras et il lui dit '