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

Bon, disons pour le commun des mortels

Zeph (./29) :
Je rejoins 0² contre les "while (se_passe_t_il_qqchose())", surtout quand comme ici les threads pourraient se permettre d'être en pause une grande majorité du temps (même dans un jeu, on martèle rarement les touches toutes les quelques millisecondes). Si le coût pour continuer à utiliser GetMessage c'est d'avoir une pauvre queue asynchrone pour transférer les messages à l'unique thread GUI, alors ça me semble être quand même raisonnable niveau quantité de code.

Heu… Je n'ai pas l'impression que tu comprennes comment ça doit fonctionner…
Y'a des trucs que tu peux pas faire sur le thread de rendu pendant que certains se passent sur le thread d'interface, et vice-versa, y'a aucune histoire de passage de message ou autre…
Le thread UI *est* celui qui reçoit les messages de Windows (et pas l'inverse comme tu l'as écrit), c'est lui qui va éventuellement les foutre dans une file asynchrone qui sera lue par le thread de physique / mise à jour (qui n'a rien à voir avec le rendu !).

Et justement pourquoi avoir deux threads quand tu peux simplement faire…

Tant que exécution en cours
Si message reçu => Traiter message
Sinon => Rendu graphique

C'est plutôt simple. On effectue le rendu à vitesse maximum, et on fait une petite pause pour gérer les messages si jamais il y a besoin. Pas besoin de faire attention à ce qui peut être manipulé dans un cas où dans l'autre puisque les deux ne se produisent jamais en même temps…

Mais bon, il y a un réel avantage à ça, mais à vous lire j'ai vraiment l'impression que vous êtes à côté de la plaque… Justement, l'intérêt d'utiliser une boucle parallèle avec GetMessage, ce n'est pas de "faire moins" comme vous semblez argumentez, mais bien au contraire, de "faire plus"…

Pourquoi cela ?

1 - Parce que que quand la gestion des messages (négligeable) est entrelacée avec le rendu, certains messages vont bloquer le rendu : Affichage d'un menu en mode fenêtré, redimensionnement de la fenêtre, affichage d'une boîte de dialogue modale, etc.
Ce n'est certainement pas un mal, et il y a un paquet de scénarios dans lequel c'est préférable… Et un paquet de scénarios dans lequel ça l'est moins, ou pas du tout.
(Quoi qu'il en soit c'est bien pour un PC pas puissant parce que la lourdeur du processus de rendu ne ralentira pas l'interface graphique.)

2 - Parce que quand le système de rendu tourne normalement (pas mis en pause par un cas du 1)), il peut arriver qu'il bouffe trop de temps CPU et que les messages soient traités trop peu souvent… Ce qui produira de l'input lag si mal géré… (Je pense que tout le monde a déjà du avoir ce problème un jour avec certains jeux, genre au pif Counter Strike )

Donc l'intérêt, ce n'est pas que le thread "ne branle rien"… C'est justement qu'il puisse faire quelque chose tout le temps, et à n'importe quel moment… Beaucoup de jeux apprécieront de recevoir les messages "en temps réel", et beaucoup de lecteurs multimédias apprécieront de voir la vidéo continuer à tourner pendant qu'un menu ou une boite de dialogue se sera ouverte…*
Mais beaucoup d'applications n'auront pas besoin de voir la zone de rendu s'animer pendant ouverture des menus, et ne consommeront pas suffisamment de puissance CPU pour le rendu au point de nécessiter d'avoir une boucle séparée du rendu…

Ce qui compte, c'est d'utiliser au mieux les ressources dont tu disposes, pas de demander deux fois plus de ressources pour en faire deux fois moins…

* Cela étant dit, il est tout à fait possible d'avoir un rendu continu effectué par le thread UI alors même que des évènements bloquants se produisent…

GoldenCrystal (./32) :
Donc l'intérêt, ce n'est pas que le thread "ne branle rien"...

Ben si, c'est aussi pour ça. Tu as déjà codé des applis qui doivent tourner sur des machines à faibles perfs et/ou sur batteries ? Ben dans ce cas tu gères le maximum de trucs en événementiel, et le but est que tes threads restent dans l'état "attente" (qui consomme très peu de CPU et d'énergie) tant qu'ils n'ont rien d'utile à faire.

Je pense que tu pars de l'optique d'un jeu qui utilise beaucoup de CPU, mais même dans ce cas c'est pas malin de gaspiller des ressources (si ton jeu est Vsyncé et que le processeur est assez puissant pour tout gérer avec 75% de ressources, y'a pas de raison d'en utiliser 100% )

Heu ça serait sympa de ne pas sortir du contexte, on parle de Windows là… Vous, savez le truc qui fait tourner des jeux super mal optimisés comme Diablo III sur un PC branché au secteur… Je vois pas le rapport avec un autre OS qui utiliserait un autre API sur un autre type de matériel dans un autre cas d'utilisation…
Donc… Win32… sur un PC… Branché au secteur…
J'ai bien parlé d'une boucle de jeu au départ, non ?

Et si ton jeu est VSyncé, justement, ton gentil API graphique s'occupera pour toi d'attendre le VSync à la fin du rendu de chaque frame. (Enfin, c'est l'idée, en pratique c'est légèrement plus complexe…)
Si ton jeu est pas VSyncé, alors soit tu proposes au joueur une option qui lui permette de limiter le FPS artificiellement, soit tu tu fais un rendu au maximum de ta capacité de rendu. (Peut-être parce que tu sais que ton jeu ne tournera pas fluidement en dessous du maximum… ^^)

GoldenCrystal (./34) :
Donc... Win32... sur un PC... Branché au secteur...

Tu sais, même en restant dans le domaine des jeux, il existe aussi des portables... des subnotebooks ... des gens qui n'ont pas les moyens de se payer PC récent... des jeux qui ne nécessitent pas une config de malade...

Bah oui, et tu joues à quoi sur un netbook ou un vieux PC ?
J'ai un petit indice : à rien, à part au démineur et au solitaire…
Et je pense être plutôt bien placé pour en parler… Côté PC complètement dépassés, j'ai eu ma dose…

D'autant plus que le multithreading dans un jeu peut être très rapidement assez catastrophique sur une config faible, justement… Parce qu'une config faible n'a dans le meilleur des cas que deux cœurs CPU, et parfois même qu'un seul… Et surtout, en général un GPU tout pourri…

Alors oui, nous sommes d'accord, l'évènementiel, c'est bien (est-ce que j'ai d'ailleurs une fois dit le contraire), oui l'attente active, c'est mal…
Mais dans une boucle de jeu, ce qui compte c'est de faire tourner le jeu… Si t'as pas de quoi le faire tourner (point de vue développeur), de toutes façons, tu ne joues pas…

GoldenCrystal (./36) :
Bah oui, et tu joues à quoi sur un netbook ou un vieux PC ? J'ai un petit indice : à rien, à part au démineur et au solitaire...

Oui, d'ailleurs il y a quelques années, quand ton vieux PC monocore était une bonne config, il n'y avait pas de jeux c'est évident

Ah oui c'est sûr, tu peux jouer au vieux jeux qui ne sont peut être même plus compatibles avec les OS modernes… NB : C'est vrai que Windows 7 reste quand même étonnamment compatible avec de très vieux trucs.
Et tu sais comment fonctionnent les vieux jeux auquel tu peux jouer ?
Exactement comme je l'ai décrit.

Bref, arrête de partir dans tous les sens… C'est marrant d'essayer de me faire dire n'importe quoi en ajoutant sans cesse un truc qui n'a aucun rapport avec le sujet d'avant et tu as 100% de chances de réussir à me faire dire une connerie avec ça, mais j'en ai marre de jouer à ce jeu débile à chaque fois, j'arrête là…

GoldenCrystal (./27) :
./26 > T'as du oublier la mention "interface native" qui est marquée dans le titre du sujet…

wxWidgets est un wrapper autour des contrôles natifs, exactement comme MFC, sauf que wxWidgets est portable.

Alors pourquoi wxWidgets utilise-t-il GTK sous KDE ?

Parce que le portage Qt n'a jamais été complété (d'abord pour des raisons de licence et après pour des raisons d'inertie parce qu'il y a déjà le backend GTK+).

Parce que sous Linux y'a pas de contrôles vraiment natifs de toute façon #troll#

GC > tu me rappelles un collègue, qui considère tout ce qui date d'avant le Core 2 Duo comme de l'histoire médiévale, et qu'on ne peut quasiment pas faire de multithread sur un proc monocore... Bizarrement si tu relis les posts yN de (allez soyons gentils) 2004, y'avait déjà des gens qui jouaient à plein de jeux qui tournent toujours parfaitement, sans parler de tous les émulateurs...

Sérieux, sors un peu de ton .NET, de tes processeurs à plein de cores et de tes CG qui font tourner qui font tourner quarante-douze millions de shaders, on n'a pas attendu ça pour faire des jeux et des applis gourmandes sur PC. Et t'as l'air de considérer que l'optimisation en puissance consommée est marginale, mais c'est justement un point qui est activement étudié dans les nouveaux OS comme Windows 7 et 8.

GoldenCrystal (./32) :
Heu… Je n'ai pas l'impression que tu comprennes comment ça doit fonctionner…
Y'a des trucs que tu peux pas faire sur le thread de rendu pendant que certains se passent sur le thread d'interface, et vice-versa, y'a aucune histoire de passage de message ou autre…Le thread UI *est* celui qui reçoit les messages de Windows (et pas l'inverse comme tu l'as écrit), c'est lui qui va éventuellement les foutre dans une file asynchrone qui sera lue par le thread de physique / mise à jour (qui n'a rien à voir avec le rendu !).

Tu parlais de jeu (cf. fin du ./14), et dans ce cas le thread qui calcule le rendu ne sera certainement pas celui qui reçois les messages, non. Enfin libre à toi de faire comme ça et d'avoir des messages qui bloquent ton rendu (heu ... et tu vas jusqu'à prétendre que c'est ce que tu *cherches* comme comportement ? ), mais si c'est ta solution je suis pas sûr qu'il faille chercher bien loin la raison pour laquelle on est pas d'accord

(ça me rappelle vaguement un topic fixed time step vs variable time step, tiens)

[edit] quand tu fais du réseau tu fais pareil, tu poll 150 fois par seconde dans le même thread que celui qui traite tes données, en espérant aller assez vite ?

Zerosquare (./43) :
Parce que sous Linux y'a pas de contrôles vraiment natifs de toute façon #troll#
GC > tu me rappelles un collègue, qui considère tout ce qui date d'avant le Core 2 Duo comme de l'histoire médiévale, et qu'on ne peut quasiment pas faire de multithread sur un proc monocore...

Ben voyons, c'est vrai allons gâcher 500+ cycles d'un pauvre CPU à 1,5GHz pour exécuter séquentiellement dans un même processus des trucs qu'on aurait pu exécuter séquentiellement sans multitâches…
Non mais sérieusement… C'est même plus drôle là…

Bizarrement si tu relis les posts yN de (allez soyons gentils) 2004, y'avait déjà des gens qui jouaient à plein de jeux qui tournent toujours parfaitement

C'est vrai que si tu veux vivre dans le passé tu as une ludothèque quasi infinie. Ce n'est d'ailleurs pas exclu dans mon post, mais stop. Ça n'a vraiment plus rien à voir avec le sujet. C'est pas parce que tu es à court d'arguments qu'il faut partir dans tous les sens comme ça, on dirait Kevin…
Tu attaques tous les points que tu peux attaquer (même sans rapport avec le sujet original), sauf que toi tu comprends probablement tout à fait ce que j'ai voulu dire…

Sérieux, sors un peu de ton .NET

Ouais, encore un truc sans rapport, supper ! T'es en forme ce soir

de tes processeurs à plein de cores et de tes CG qui font tourner qui font tourner quarante-douze millions de shaders, on n'a pas attendu ça pour faire des jeux et des applis gourmandes sur PC.

T1 mais c'est l'hôpital qui se fout de la charité. Tu sais combien de core à mon Macbook ? Deux.
Exactement deux.
Tu sais combien de stream processors possède ce pauvre (et en même temps génial) GeForce 9400M qui n'a même pas sa propre mémoire vidéo (en 2008 !) ?
16. Exactement 16.
Wahou mais comment c'est trop trop trop ouf ! Je tourne depuis 7 ans avec la puissance graphique d'un PC de 2004 mais comment c'est trop trop ouf sérieux, lol mdr ptdr !!!11eleven!!!
…
Quand on sait pas on la ferme.

Heureusement, mon nouveaux a quatre coeurs et ne sera pas trop à la ramasse graphiquement. Qu'est-ce que c'est bien de pouvoir… Je sais pas, scroller une page web sans que ça rame… Démarrer Windows en moins de 3 minutes… Traiter une photo sans attendre 30sec entre chaque clic… Pouvoir jouer à un jeu en mode ultra…
Et même peut-être jouer à des jeux 2D en Flash sans que ça rame ? Ah ça par contre non, Flash c'est trop pourri. Qui croirait qu'un jeu 2D en flash rame autant sur un i7 4 coeur à 2,6 GHz que sur un Core 2 Duo à 2Ghz ? Et bien c'est la réalité dans laquelle nous vivons…

Et t'as l'air de considérer que l'optimisation en puissance consommée est marginale

Non absolument pas, je vois juste pas en quoi tu viens me faire chier sur un truc qui n'a aucun rapport.
Pour un jeu [moderne ou pas], le but c'est que ça tourne.

mais c'est justement un point qui est activement étudié dans les nouveaux OS comme Windows 7 et 8.

Et c'est très bien. Je n'ai jamais dit le contraire, je suis d'ailleurs content que Windows 8 consomme moins de RAM que Windows 7 et que OSX (même si sur le reste c'est une grosse bouse), mais arrête de t'éloigner sans-cesse du sujet pour attaquer sur des terrains vierges en me faisant porter des propos que je n'ai pas tenu !

Bon sérieusement, j'arrête vraiment, je ne répondrai plus à aucun de tes posts ici…

[Edit] Corrigé la citation foireuse

Bon t'as raison, je fais amendable honorable pour toutes les années où j'ai utilisé mon PC pour jouer, retoucher des photos, faire de l'édition sonore, coder du traitement de signal en temps réel et scroller des pages web, mais je savais pas qu'il fallait au moins 4 cores pour ça monsieur le juge

Revenons plutôt au sujet de Folco.

Zeph (./44) :
Tu parlais de jeu (cf. fin du ./14), et dans ce cas le thread qui calcule le rendu ne sera certainement pas celui qui reçois les messages, non.

Qu'on soit clair je parle bien juste d'un rendu, et je n'ai jamais parlé d'un quelconque calcul. Tu ne prends donc pas en compte la mise à jour des positions des objets et les calcul physiques là dedans, hein ?

Enfin libre à toi de faire comme ça et d'avoir des messages qui bloquent ton rendu

Bah si tu fais un jeu classique sans barre de menu ni fenêtre, il n'y aura pas grand chose pour bloquer quoi que ce soit…

heu ... et tu vas jusqu'à prétendre que c'est ce que tu *cherches* comme comportement ?

Non je prétends juste que c'est pas forcément anormal, ni même un défaut.
Exemple tu joues à un émulateur (qui jusqu'à preuve du contraire utilise le même genre de boucle de rendu qu'un jeu), et tu vas dans les menu. L'émulateur se met en pause. Ça te pose un problème ?

quand tu fais du réseau tu fais pareil, tu poll 150 fois par seconde dans le même thread que celui qui traite tes données, en espérant aller assez vite ?

Je vois même pas le rapport…
Encore une fois tu prends la chose à l'envers.
L'idée n'est pas de poller suffisamment vite pour ne rien rater.
L'idée c'est que le rendu est très important, mais tout message reçu avant le rendu doit être reçu avant le rendu.
L'idée c'est que la quantité de messages reçue ne sera jamais suffisante à elle seule pour bloquer le rendu.
L'idée c'est que le temps de traitement des messages est complètement négligeable par rapport au temps nécessaire au rendu. (Pour les chieurs, en fait, on considère juste que le temps de traitement des messages c'est peanuts, même si le temps de rendu est quasi nul, ça marche quand même)
L'idée c'est que si le rendu prend trop longtemps, les messages ne seront pas lu "en temps réel". (Puisque lus après le rendu, dans un temps négligeable)
L'idée c'est que sur une configuration équilibrée, pour un jeu type "plutôt ancien", c'est largement suffisant, plus efficace, et moins complexe à mettre en place.


Mais tout ça est déjà marqué dans mon autre post. Si vous ne comprenez pas quelque chose d'aussi simple, j'abdique.

Zerosquare (./46) :
retoucher des photos

Tu traites des RAW de 16 Mpix toi aussi ?

faire de l'édition sonore, coder du traitement de signal en temps réel et scroller des pages web, mais je savais pas qu'il fallait au moins 4 cores pour ça monsieur le juge

Ouais, j'ai clairement marqué que c'est totalement impossible dans mon post au dessus, ça me parait évident.

C'est pas que ce soit pas simple, c'est juste que c'est monstrueusement crade et que tu essaies de justifier ce choix de feignasse avec des arguments bidons, rien de plus

(et pour répondre à la question : oui, une appli qui se freeze quand j'ouvre un menu, je trouve ça anormal ^^)

Oui certainement que j'ai tort puisque je vous parle de la boucle de rendu la plus utilisée au monde…

Et certainement que même des experts ou des références en la matière n'y connaissent rien puisque vous avez toujours raison…

(Et qui a parlé de freeze ?)

Oui enfin si c'est pour continuer comme ça, moi aussi je peux balancer n'importe quel lien Microsoft qui explique pourquoi coller son rendu dans un thread à part ^^

Ouais, et si tu l'avais lu, tu verrais dans ton powerpoint que pour le rendu, ça ne s'applique qu'à partir de DirectX11 (le reste parle de chargement de ressources, c'est hors sujet ici), donc que ça n'a absolument rien à voi avec ce que toi ou Zerosquare essayez de défendre. (Ben tiens donc)

De plus, je l'ai mentionné très brièvement dans un de mes premiers posts

GoldenCrystal (./18) :
C'est pas parce que ton code est paralléllisé que ta procédure de rendu le sera, elle… (En pratique d'ailleurs, ce n'est pas vraiment le cas, sauf peut-être pour certains jeux très récents (et gourmands) qui utilisent DirectX11)

Donc arrête de sortir encore des choses dans tous les sens.

En plus comme je savais que le lien de Microsoft (qui vient juste d'un mec qui a participé à la construction de Managed DirectX) ne plairait pas (bien que totalement valide puisqu'il explique comment mettre en place *la boucle standard* sous WinForms) j'ai aussi inclut le lien de NeHe, mais tu n'as bizarrement rien trouvé à redire dessus. (PS: Google est ouvert à tous, cherchez juste "render loop" ou "game loop"…)
Tu 'nas bizarrement rien non plus à redire sur le fait que tu prennes mes arguments complètement à l'envers.

Bref. De ton côté, on peut utiliser des cartes graphiques surbourrin qui font du DirectX11 multithreadé même quand je parle assez clairement de technos un peu moins modernes, et moi je me fais taper dessus dès que je parle de trucs un peu plus puisant qu'une GeForce 2 MX et de programmes *intensifs* qui tournaient sur des processeurs pas massivement multicore.
Super les mecs !

Euh, et pour mes fenêtres Win32, je les fais sur combien de cores ?

Oh, environ 0,01...

./52 : c'était pas plus hors sujet que tes deux liens, en l'occurrence ils montrent comment mettre son rendu et sa pompe d'évènement dans la même boucle. Il ne me semble pas avoir lu quelque part qu'ils prétendaient faire passer ça pour une bonne idée. C'est un tuto, et ils présentent la solution la plus simple, ça me semble tout à fait cohérent. De la même façon que plein de tutos PHP sont illustrés avec des exemples qui contiennent du code HTML, c'est tout à fait valable pour un exemple ou un cas basique, ça ne veut pas pour autant dire que c'est une bonne idée. Tu as un lien qui explique que c'est une bonne idée de n'avoir qu'un thread plutôt que plusieurs ?

Alors après, c'est sûr que si pour toi "coder un jeu" c'est "coder un démineur", tu vas avoir de toutes façons du mal à tomber sur un problème, quelle que soit la solution que tu utilises, aussi pourrie qu'elle soit. Mais dans des cas un peu moins basiques il n'y a aucun intérêt à mettre tout dans le même thread, précisément pour la raison inverse de ton argument "comme ça si j'ai un truc qui bloque, l'intégralité de mon appli se met à ramer ". En grand fan de .NET, tu n'es j'imagine pas passé à côté de la migration progressive vers le "tout asynchrone" du framework, et si on s'amuse à faire des appels asynchrone j'ai une révélation : c'est pas pour tout caser dans un même thread et faire des "wait" entre chaque appel... Ça vaut aussi bien pour la pompe des messages que pour le réseau et n'importe quel autre type de boucle supposée fonctionner en arrière-plan.

Je ne suis pas passé à côté de ton exemple NeHe, c'est juste que ... bah c'est un exemple NeHe quoi, c'est précisément destiné à rester simple pour servir de tutorial, c'est même précisément le but de l'intégralité du site...

(Tiens, ça me manquait Sinon, quand j'étais à l'IUT, on nous apprenait à faire une boucle infinie pour gérer les événements au moins en Delphi - en Java je ne me souviens plus, j'avoue - mais j'ai toujours trouvé cette méthode particulièrement sale au moins sur le plan conceptuel... voilà, maintenant je vais me chercher du maïs pour faire du pop-corn, mais j'hésite entre caramel et sucre )

T1 mais t'es grave, il n'est nulle part question de mettre tout dans le même thread...
On parle de la boucle de rendu.
Évidemment que le son sera nécessairement dans un autre thread (ça n'a jamais été possible autrement, et heureusement il n'y a rien à faire manuellement pour que ça fonctionne).
Évidemment que le réseau est géré de manière asynchrone (et que absolument tous les jeux *doivent* utiliser le réseau... )

Et puis c'est sur je parle forcement du démineur, c'est typiquement le genre de jeu qui doit avoir une boucle de rendu (mon cul ouais)... Justement j'avais cité cet exemple parce que c'est exactement l'inverse...

Je dis juste que la boucle de jeu basique n'est pas débile et pas forcément moins puissante, et en tout cas plus simple à concevoir et utiliser qu'une boucle de rendu parallèle au thread d'UI.
Et la on me sort que je fais une boucle de polling infinie et que c'est mal (de toutes façons ce me paraît totalement évident que vos thread ne contiennent aucune boucle de polling... ), puis que en fait nan mais le but du multithreading c'est de ne pas utiliser le CPU. (Perdu, le but c'est d'optimiser (ce qui peut vouloir dire *maximiser...) l'utilisation CPU et l'exécution de tâches d'une manière indépendante de l'autre. Ce qui n'est pas indispensable dans tous les cas...)
Je suis moi même oblige de donner les vrais arguments qui défendent l'utilisation d'une boucle de rendu parallèle a la boucle de messages, alors que vous n'en avez pas été capable, et ce me revient dans la gueule.
Ensuite on me dit que ça ne marche pas sur des machines antiques ou qui n'ont rien a voir avec le sujet (alors qu'en réalité cd vient justement de là) dans une situation plus typique d'un client mail que n'importe quoi avec une boucle de rendu.
Et maintenant comme je dis qu'utiliser une boucle mixte message/rendu, ça veut forcement dire que je suis totalement opposé au multitâche. (C'est ballot mais bizarrement je prends mon pied à écrire du code parallèle lock-free...)
Je rapelle qu'à la base ça permet d'éviter tous les cas compliqués de gestion de la surface de rendu qui se retrouve partagée entre deux threads, et dont certaines opérations doivent être effectuées de manière bloquante sur le thread de messages, ce qui oblige à mettre en place une situation non triviale et coûteuse (alors même que toutes les applications n'en tirent pas forcément bénéfice...). Et en plus de ça, le rendu sur un thread suppose forcément l'utilisation d'une technologie de rendu basée sur DirectX ou OpenGL, qui autorisent plus ou moins bien selon les versions, d'effectuer un rendu sur un thread secondaire...

GoldenCrystal (./57) :
Je dis juste que la boucle de jeu basique n'est pas débile et pas forcément moins puissante, et en tout cas plus simple à concevoir et utiliser qu'une boucle de rendu parallèle au thread d'UI.

Jusque-là on est entièrement d'accord, cf. 1er paragraphe du ./55

Et la on me sort que je fais une boucle de polling infinie et que c'est mal (de toutes façons ce me paraît totalement évident que vos thread ne contiennent aucune boucle de polling... ), puis que en fait nan mais le but du multithreading c'est de ne pas utiliser le CPU. (Perdu, le but c'est d'optimiser (ce qui peut vouloir dire *maximiser...) l'utilisation CPU et l'exécution de tâches d'une manière indépendante de l'autre. Ce qui n'est pas indispensable dans tous les cas...)

C'est ton premier mot qui était exact. Le but n'est pas de maximiser l'utilisation du CPU, ça serait idiot, c'est bien de l'optimiser, à savoir d'économiser tout ce qu'on peut dans la gestion des évènements en évitant de faire tourner des boucles qui tournent à vide 99% du temps, pour que ce gain puisse profiter au rendu (entre autres). Et ce n'est bien sûr pas indispensable, comme toujours, c'est "juste" mieux

Et maintenant comme je dis qu'utiliser une boucle mixte message/rendu, ça veut forcement dire que je suis totalement opposé au multitâche. (C'est ballot mais bizarrement je prends mon pied à écrire du code parallèle lock-free...)

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 "à part pour des applications DirectX11". Et c'est avec ça que je ne suis pas d'accord.

Alors après, c'est sûr que si pour toi "coder un jeu" c'est "coder un démineur", tu vas avoir de toutes façons du mal à tomber sur un problème, quelle que soit la solution que tu utilises, aussi pourrie qu'elle soit.

j'ai codé mon démineur de la même manière que tous mes autres jeux, une seule boucle