Discussion :

[Jordinateur]

Exactement
Désolé je l'ai fais vite fais j'ai pas pensé

[fenkys]

Et utiliser un SDL_Timer ne serait pas plus pratique ?

On en regle un pour qu'il appele toutes les secondes une callback qui remet l'affichage à jour. Avantage, entre deux mises à jours de l'affichage, le processeur n'est pas du tout utilisé par la routine de gestion du temps.

[fearyourself]

Et utiliser un SDL_Timer ne serait pas plus pratique ?

On en regle un pour qu'il appele toutes les secondes une callback qui remet l'affichage à jour. Avantage, entre deux mises à jours de l'affichage, le processeur n'est pas du tout utilisé par la routine de gestion du temps.

Ce n'est pas faux MAIS : juste parce que le code n'est plus écrit par le programmeur n'est pas écrit ne veut pas dire qu'il n'utilise pas des ressources.

Un timer utilisera des ressources internes, du coup, ce n'est pas aussi évident de dire si ce sera mieux ou non. Ensuite, il est rare de vouloir cadencer le rendu, généralement on cadence les animations et on fait le rendu le plus rapidement possible...

Jc

[coyotte507]

Sinon, pour ton nombre de cartourches qui s'épuise, il y a une solution toute simple dans l'utilisation de SDL_PollEvent (et à mon c'est ça ton problème):

au lieu de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
while (...)
{
  SDL_PollEvent(&event);
  [code de gestion de l'event]
 
  ...
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
while (...)
{
  if (SDL_PollEvent(&event) != 0)
  {
    [code de gestion de l'event]
  }
 
  ...
}

[fenkys]

Je ne parlais pas de cadencer l'affichage (en me relisant si en fait, les mefaits du jus de tomate), mais d'avoir un SDL_timer qui toutes les secondes incrémente un compteur de temps. Un tel système n'aura pas la précision d'un montre à quartz, mais elle sera bien suffisante pour un jeu, avec une faible consommation de ressources. D'ailleurs, ma réponse correspond à la demande de l'auteur de l'item #18.

Je ne sais pas quel système utilise le concepteur de départ, mais sur mon ordinateur personnel, un SDL_timer en fonctionnement utilise 0% du temps processeur. De même que SDL_WaitEvent, alors que SDL_PollEvent me fait monter à 98% sans qu'aucune action ne soit effectuée. SDL_timer et SDL_WaitEvent utilisent tous deux les propriétés multitaches du système d'exploitation pour ne pas gaspiller de ressources.

[shenron666]

Je ne sais pas quel système utilise le concepteur de départ, mais sur mon ordinateur personnel, un SDL_timer en fonctionnement utilise 0% du temps processeur. De même que SDL_WaitEvent, alors que SDL_PollEvent me fait monter à 98% sans qu'aucune action ne soit effectuée. SDL_timer et SDL_WaitEvent utilisent tous deux les propriétés multitaches du système d'exploitation pour ne pas gaspiller de ressources.

ce n'est pas SDL_PollEvent qui fait que tu utilises 98% de CPU
il suffit d'un SDL_Delay pour rendre la main à l'OS de temps à autre, chose que font SDL_Timer et SDL_WaitEvent

En mettant un delai faible, genre SDL_Delay(25), je pense que tu peux avoir le même résultat, tout en réduisant l'occupation du CPU.

je plussoie sauf que 25 de delay c'est... beaucoup trop, met le minimum : 1
juste de quoi rendre la main à l'OS qui reviendra quand il aura traité sa file de messages, ce qui peut prendre beaucoup plus de 1ms, c'est vraiment histoire de rentre la main à l'OS

par exemple une boucle comme celle-ci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
while(running)
{
	// traitement des messages
	SDL_Event event;
	while (SDL_PollEvent(&event))
	{
	...
	}
 
	// dessin
 
	// gestion du temps avec SDL_GetTicks
 
	// affichage avec SDL_Flip
}

va pomper 100% de CPU et le système va ramer
ajoutes un SDL_Delay(1) dans la boucle, ton taux d'occupation CPU diminuera et le système deviendra plus réactif

[fenkys]

Tu es sûr que SDL_timer utilise un SDL_delay. Sa facon de se comporter ne me semble pas compatible avec cela.

Un SDL_delay par exemple te prend la main et passe le controle à l'OS alors que le SDL_timer te rend la main et tu peux continuer ton traitement, le SDL_timer faison son décompte de son coté.

[shenron666]

je me suis mal exprimé, je ne voulais pas dire que SDL_Timer faisait un SDL_Delay mais plutot que SDL_Timer rendait la main au système

le fonctionnement n'est pas le même comme tu dis, puisque un SDL_Timer défini une fonction qui sera appelé selon un intervalle de temps voulu

[fearyourself]

je me suis mal exprimé, je ne voulais pas dire que SDL_Timer faisait un SDL_Delay mais plutot que SDL_Timer rendait la main au système

le fonctionnement n'est pas le même comme tu dis, puisque un SDL_Timer défini une fonction qui sera appelé selon un intervalle de temps voulu

T'es sûr qu'il rend la main ? Il me semblerait qu'un simple SDL_Timer ne rendrait pas la main puisque c'est dans le coeur de la SDL qu'il y a une vérification Est-ce qu'on doit exécuter un Timer ? Et je ne vois pas pourquoi un SDL_Delay serait fait dans ce cas là.

Je peux me tromper bien sûr
Jc

[dcmo5]

T'es sûr qu'il rend la main ? Il me semblerait qu'un simple SDL_Timer ne rendrait pas la main puisque c'est dans le coeur de la SDL qu'il y a une vérification Est-ce qu'on doit exécuter un Timer ? Et je ne vois pas pourquoi un SDL_Delay serait fait dans ce cas là.

Je peux me tromper bien sûr
Jc

Il me semble que les deux fonctions rendent la main au système, c'est à dire qu'elles ne bloquent pas le processeur dans un boucle interne au programme. La différence est que le SDL_Timer permet au programme de faire autre chose en attendant un évènement envoyé par le timer, alors que le SDL_Delay ne le permet pas.

Mais que l'on attende la fin du SDL_Delay, ou que l'on attende l'évènement du Timer sans rien faire d'autre, l'occupation du processeur doit être négligeable dans les deux cas, et les autres tâches du système d'exploitation ne sont pas bloquées. Il faut préciser, dans le cas du timer, que la boucle d'attente des évènements ne doit pas monopoliser tout le CPU, elle doit donc contenir un SDL_Delay. Mais je pense que tous les programmeurs le savent.

Je crois avoir raison, mais je peux aussi me tromper bien sûr

[fearyourself]

Il me semble que les deux fonctions rendent la main au système, c'est à dire qu'elles ne bloquent pas le processeur dans un boucle interne au programme. La différence est que le SDL_Timer permet au programme de faire autre chose en attendant un évènement envoyé par le timer, alors que le SDL_Delay ne le permet pas.

Mais que l'on attende la fin du SDL_Delay, ou que l'on attende l'évènement du Timer sans rien faire d'autre, l'occupation du processeur doit être négligeable dans les deux cas, et les autres tâches du système d'exploitation ne sont pas bloquées. Il faut préciser, dans le cas du timer, que la boucle d'attente des évènements ne doit pas monopoliser tout le CPU, elle doit donc contenir un SDL_Delay. Mais je pense que tous les programmeurs le savent.

Je crois avoir raison, mais je peux aussi me tromper bien sûr

Non, comme je disais cela ne fonctionne pas comme cela. Soit le système crée un deuxième thread pour gérer le timer, ou utilise un système de type alarm. Du coup, si le thread principal ne fait pas quelque chose pour libérer le CPU, le programme global sera toujours à 100%.

Jc

[shenron666]

T'es sûr qu'il rend la main ? Il me semblerait qu'un simple SDL_Timer ne rendrait pas la main puisque c'est dans le coeur de la SDL qu'il y a une vérification Est-ce qu'on doit exécuter un Timer ? Et je ne vois pas pourquoi un SDL_Delay serait fait dans ce cas là.

Je peux me tromper bien sûr
Jc

je ne suis jamais allé voir mais je penserai qu'un SDL_Delay serait juste un "sleep"
il faudrait voir dans le code

sinon en pratique, dans une boucle du fais
temps = SDL_GetTicks();
while(running)
{
// gestion des events
// affichage
// gestion du temps
do {
SDL_Delay(1);
tmp = SDL_GetTicks();
} while(tmp - temps < 1000);
temps = SDL_GetTicks();
}
cette boucle pompe 100% du cpu si je met en commentaire le SDL_Delay, avec le SDL_Delay la conso baisse

edit : sous win32, SDL_Delay est un simple sleep, le code linux par contre est beaucoup plus compliqué, il y a 3 méthodes avec des options de compilation

[fenkys]

En tout cas j'ai vérifié dans les sources, SDL_WaitEvent n'est qu'un SDL_PollEvent avec un SDL_Delay dedans.

[fearyourself]

En tout cas j'ai vérifié dans les sources, SDL_WaitEvent n'est qu'un SDL_PollEvent avec un SDL_Delay dedans.

Et une boucle autour pour rester dedans

Jc