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.

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 ), et j'ai trouvé ça super utile simple et propre comme système !

GoldenCrystal (./96) :
ç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 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
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 :- /