Windows Utilisation de l'interface native pour un programme - Page 3

(c'est pour ça que ta Freebox a cramé, quand elle a vu passer ton code ? )

Wow ça merite un point ça

Oui mais il n'y a pas encore de point pour ça... et le point Folco ne convient pas ^^

Un point Brice peut=etre ?

Zeph (./58) :
en évitant de faire tourner des boucles qui tournent à vide 99% du temps

Ben oui, c'est justement là où je ne suis pas votre entêtement, cette boucle ne tournera jamais à vide

pour que ce gain puisse profiter au rendu (entre autres).

Bah ouais c'est pour ça que quand il y a pas de messages à traiter (d'où l'utilité de PeekMessage) on utilise le temps CPU pur faire le rendu. (Qui sera éventuellement synchronisé sur la fréquence de rafraîchissement de l'écran si le développeur er/ou l'utilisateur le désirent…)

Et ce n'est bien sûr pas indispensable, comme toujours, c'est "juste" mieux

Oui, j'ai donné des raisons pour laquelle c'est mieux, mais tu ne peux pas honnêtement dire que ces raisons s'appliquent à tous les cas.

Bah... relis ton post ./18, c'est bien toi qui a expliqué au départ que c'était inutile de séparer le rendu de la pompe des messages

Je n'ai jamais dit que c'était inutile. Mais dans le contexte c'est en réponse à Zerosquare (./17) qui dit que le polling c'est mal

à part pour des applications DirectX11

En fait je parlais de la procédure de rendu (possibilité d'utiliser plusieurs threads en même temps) mais c'est vrai que ce n'était pas clair.

Et c'est avec ça que je ne suis pas d'accord.

Ben du coup moi non plus vu que ce n'est pas vraiment ce que j'ai voulu dire

Zerosquare (./59) :
--- Call : Bearbecue appelé(e) sur ce topic ...

Wow, tu veux un commentaire de quelqu'un qui obfusque son code en appelant ses variables monGrosTrouDuCul ? ()

Et si on enlevait un 't" au titre du topic?

"interface naive"

J'ai remarqué qu'en faisant du polling, une simple application avec SDL me prend un coeur à fond. Ce code suffit :

SDL_Event ev;

while (!SDL_PollEvent (&ev));
 
// On traite l'évènement
...

Alors que SDL a une super fonction : SDL_PushEvent, un un super type d'évènement : SDL_USEREVENT.
Il suffit, quand un évènement se produit dans un jeu (un truc qui tombe, un timer qui expire, whatever) de faire un SDL_PushEvent (&MyEvent), pour relancer ce qu'on veut faire, alors qu'on attendait confortablement avec un SDL_WaitEvent (&ev);
C'est magique, ça consomme rien en CPU, c'est parfait.

Bien évidemment, les boucles vides c'est le mal
L'intérêt du polling c'est de pouvoir utiliser le reste du temps CPU pour faire autre chose selon tes besoins (genre un rendu graphique, un rendu audio, …). Si tu ne le fais pas, c'est contreproductif.

Euh... oui. C'est le principe d'une boucle d'événements, et ce n'est pas spécifique à SDL. Mais c'est bien, tu découvres

EDIT : cross

Ah. Désolé de vous avoir dérangé

En fait, vu comme ça, oui je connais déjà, mais appliqué à un jeu par exemple, ça prend une autre gueule, et j'avais pas fait le rapprochement avec n'importe quelle boucle d'évènement. #tribalèze en info#

Et hop, j'étais tombé sur le code d'un pauvre abruti qui faisait du polling comme un con pour afficher un à un les caractères d'une chaine :
Fichier joint : code de merde.c

On voit bien le merdouillage à base de différence de timer, en tirant à fond dans le CPU. Pouah ! Une abomination pour moi, à qui un cycle perdu fend le cœur.
Je l'ai donc réécrit proprement, en tant que programmeur chevronné qui sait résoudre les problèmes soumis à son expertise :
Fichier joint : code state of the art.c

Et voilà. C'est clair, net, précis. Je vais envoyer mon code à l'autre abruti pour le chambrer méchamment, quand on pond des merdes pareilles on mérite pas mieux !!! PUTAIN !!! RAS-LE-CUL-DES-NOOOOBS !!!!!!!!!!!!!!!

Folco qui spam des ? J'ai du mal à savoir si c'est sérieux ou si c'est de l'ironie

(c'est de l'autodérision, c'est mon code initial le premier )

Il n'est plus très utilisé
Ni d'ailleurs.

SDL_Event ev; 
 
while (!SDL_PollEvent (&ev)) Sleep(1);
  
// On traite l'évènement 
...

et comme cela ?

Pour introduire du lag en plus de bouffer du CPU pour rien ? Super

Je faisais pareil au début, sans le sleep(1).
Le sleep, il va faire laguer au premier évènement venu, quand au pollevent, il bouffe un CPU à lui tout seul, pleine balle

Le sleep a quand-même le mérite de réduire l'abus de CPU.

En traitant l'évènement après sa pause café ? C'est pas une solution propre amha...

Par contre, si mon code posté plus haut n'est pas bon, je suis preneur. Il marche, ne bouffe pas de CPU, mais si il y a mieux je prends.

Kevin > mais ça reste un hack crade, qui génère des context switches pour rien (et gaspille de l'énergie sur les portables sur batterie) et qui introduit une latence inutile.

Folco > ce que tu as fait est très bien, rien à redire.

pour le lag, c'est pas moi qui attendais un event en while hein c'est ./69 , mais ta changé le sens dans ton autre source :- )

et pour des jeux à 60 fps, du lag, lol

moi je faisais ca :

http://procvor.free.fr/download/src/dstar.x86.src.rar /Gdl/output/graphic/fbuffer/fbuffer.cpp

	#ifdef useSdl
		SDL_LockSurface(screen);
		SDL_Flip(screen);
		SDL_UnlockSurface(screen);
		while (SDL_PollEvent (&event))
		{ ...
		};
		if(letMeUseSomePower){
			#ifdef sleepWhenNoFocus
				SDL_Delay(10*(!isAppActive));
			#else
				SDL_Delay(0);
			#endif
		} else SDL_Delay(10);
	#endif

sinon, c'est propre oui, enfin c'est ce que tu pense,

http://www.libsdl.org/release/SDL-1.2.15.tar.gz /SDL-1.2.15/src/events/SDL_events.c

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);
		}
	}
}

Ben au moins, ça attend naturellement avec SDL_WaitEvent, mais toi tu réinventes la roue ^^

robinHood (./84) :
pour le lag, c'est pas moi qui attendais un event en while hein

Je te parlais du sleep, pas du while qui justement, n'induit aucun lag (même s'il consomme pour rien).

Et sinon, locker ta surface avant un Flip, ça sert à quoi ? Je croyais que fallait le faire avant d'écrire sur une surface, pas avant de l'afficher.

./84 > Ben heu… #SDL# quoi.
Je crois qu'il est assez sage de considérer SDL comme exemple à ne pas suivre dans pas mal de recoins, mais bon, ça n'est pas un outil professionnel destiné à créer des trucs sérieux…
Au final ça marche, et c'est ce qui compte pour ceux qui veulent s'en servir.

(Personnellement j'ai rien contre le Sleep pour attendre un truc (technique simpliste de flemmard ), m'enfin dans la boucle principale du programme, ça pue un peu, quoi…)

Folco (./82) :
En traitant l'évènement après sa pause café ? C'est pas une solution propre amha...

C'est clair, mais si l'API est pourrie (ou si le programmeur est pourri ou du moins n'a pas suffisamment d'expérience), ça peut être la solution.

Par contre, si mon code posté plus haut n'est pas bon, je suis preneur. Il marche, ne bouffe pas de CPU, mais si il y a mieux je prends.

Non, c'est clair que ta solution est la bonne. Ou du moins le serait si le code de SDL_WaitEvent n'était pas à vomir.

GoldenCrystal (./86) :
(Personnellement j'ai rien contre le Sleep pour attendre un truc (technique simpliste de flemmard ), 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 ?"
ce n'est pas de l'embarqué, d'autre programmes tournent !

pour moi sleep est obligatoire, au moins un sleep(0);
et sous win2k (et wine) c'etais le top car sleep(1); te synchronisais à 60 fps (ok, l'utiliser est très discutable et la conséquence est que sous xp mes prog tournais ensuite trop vite!)

Folco (./85) :
Je te parlais du sleep, pas du while qui justement, n'induit aucun lag (même s'il consomme pour rien).

je sais bien, mais la question etais "bordel ca me prend 100% du cpu", et c'est normal

Folco (./85) :
Et sinon, locker ta surface avant un Flip, ça sert à quoi ? Je croyais que fallait le faire avant d'écrire sur une surface, pas avant de l'afficher.

j'en sais rien, ce code à bien entre 5 et 7 ans, de plus sdl étais la pour le "fun" le vrai framebuffer utilisé est une version custom de tinyPtc, il est fort possible que ca ne compile même pas si je tentais d'activer sdl ^^"

Folco (./85) :
Ben au moins, ça attend naturellement avec SDL_WaitEvent, mais toi tu réinventes la roue ^^

bah je préférais (et préfère toujours) coder tout de A à Z, de plus l'api de sdl ne me conviens pas et à l'origine ce code est pour la gp32 ou il ne vaut mieux même pas ne serais ce que songer à utiliser sdl

bref à la fin ca me permet par exemple de coder haut niveau avec du code genre comme ca :

  /* launch song playback */
	if(!Gdl_playSong("dstar.rar|song.xm"))
	 if(!Gdl_playSong("song.xm"))
	  Gdl_playSong(cysa,cysaSize);

ou d'avoir accès à des callback sur les event standards sans justement réinventer la roue à chaque nouveau prog

void Gdl_iniCallback( void	(*onKey)	    (int key, int pushed),
					  void	(*onClick)		(int button, int clicked),
					  void	(*onExit)       (void),
					  void	(*onMove)		(void),
					  void	(*onWhell)		(int way),
					  void	(*onFocus)		(int focus),
 					  void	(*onFileDrop)	(const char*path),
					  void  (*onAfterZoom)	(void*bf,u32 w,u32 h,u32 pitch)
      );

concernant le fait d'utiliser un event custom, oui, c'est de loin la chose la plus propre !

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

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

Godzil (./65) :
Un point Brice peut=etre ?

plutôt un point Richard von Krafft-Ebing, l'inventeur du sadisme.

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 ?