en fait, vu que j'aime pas trop l'APIWin32, je me suis dis, tien, tu vas pas faire comme tout l'monde, et ton DirectX, tu vas l'apprendre avec les MFC. ça va, je m'suis démerdé, mais y reste un pb.. et pas des moindres !
Attention, accrochez vous, j'explique:
c au niveau de l'appel de ma fonction D3DDraw (celle qui contient BeginScene, EndScene, etc...). Avec l'API Win32, on met l'appel à cette fonction dans le main, au niveau du DispatchMessage et compagnie. En MFC, g décidé de remplacer le createwindow par une CWnd (ce qui parait logique...). le pb, c au niveau des message. Apparement, dans une CWnd, y a pas de message Draw envoyé régulièrement pour redessiner le contenu de la fenêtre, bref, si on fait rien, qu'on reste sans bouger la souris ni rien, aucun message n'est envoyé ! j'imagine donc qu'il est impossible dans ce cas là d'utiliser une CWnd pour acueillir un Device D3D. Mais je dois utiliser quoi alors !? une view peut être, ms dans ce cas, je l'utilise comment ?
 
Je sais pas trop si y aura des réponses, vu que mon explication est bordelique (:D) et que g jammais vu personne utiliser les MFC avec DirectX (pourquoi d'ailleur, c très bien les MFC). Mais bon... je crois en vous !

[edtdd]--Message édité par El_Gringo--[/edtdd]

El_Gringo a écrit a écrit : en fait, vu que j'aime pas trop l'APIWin32, je me suis dis, tien, tu vas pas faire comme tout l'monde, et ton DirectX, tu vas l'apprendre avec les MFC. ça va, je m'suis démerdé, mais y reste un pb.. et pas des moindres ! Attention, accrochez vous, j'explique: c au niveau de l'appel de ma fonction D3DDraw (celle qui contient BeginScene, EndScene, etc...). Avec l'API Win32, on met l'appel à cette fonction dans le main, au niveau du DispatchMessage et compagnie. En MFC, g décidé de remplacer le createwindow par une CWnd (ce qui parait logique...). le pb, c au niveau des message. Apparement, dans une CWnd, y a pas de message Draw envoyé régulièrement pour redessiner le contenu de la fenêtre, bref, si on fait rien, qu'on reste sans bouger la souris ni rien, aucun message n'est envoyé ! j'imagine donc qu'il est impossible dans ce cas là d'utiliser une CWnd pour acueillir un Device D3D. Mais je dois utiliser quoi alors !? une view peut être, ms dans ce cas, je l'utilise comment ? Je sais pas trop si y aura des réponses, vu que mon explication est bordelique (:D) et que g jammais vu personne utiliser les MFC avec DirectX (pourquoi d'ailleur, c très bien les MFC). Mais bon... je crois en vous !

 
Et pourquoi tu voudrais qu'il la retrace automatiquement ta fenetre, windows?
La plupart des fenetres windows (arf, no pun intended)  n'ont pas besoin d'etre retracees tout le temps sinon ton proc serait en permanence occupe a 100% et ton ordi ramerait comme pas possible. Si tu veux la retracer c'est a toi de le faire.
 
Sinon aucun pb a utiliser dx avec les mfc, je vois pas pourquoi il y en aurait (sachant que MFC c'est juste une encapsulation orientee objet de l'API windows)
 
A+
LEGREG

bin je sais po, moi je suis parti de la structure des tutoriaux.....
 
mais effectivment, le draw (message paint je suppose) n'est envoyé que lorsque un surface doit être retracée.....
 
donc ta fonction qui doit retraçer l'image D3D, doit être appellée de ta boucle générale de l'app, où l'on consomme les messages....
 
en fait, ta fenêtre peut parfaitement acceuillir une surface D3D, mais fo que le traçage soit lancé d'ailleurs que le draw (et même qu'une méthode de ta classe fenêtre)

il suffit d'utiliser un timer (pas wm_timer car pas assez précis, regarde les autres timers comme les timers multimédia), où encore d'y aller brutal à coups d'InvalidateRect() dans le OnPaint() (pas très recommandé).

 
Je voudrais qu'il retrace automatiquement ma fenêtre windows parce que pour des animations, y faut bien qu'y retrace régulièrement, même si il a pas reçu de message spécifique... y retrace tt le temps, c tout ! Dans beaucoup de cas, le contenu des frames est redessiné régulièrement. ça bouffe pas tout le temps processus... y a un truc dans les OS multi process (ma fois, plutot répandus aujourd'hui ) qui s'appel le partage du temps processeur, c génial, et ça te permet de redessiner régulièrement une fenêtre en faisant d'autre trucs en même temps, génial non ?
 
sinon, le truc qui pourrait faire que les MFC soient déconseillées pour DirectX, c que DirectX à besoin d'un maximum de ressources. Si les MFC ne ralentissent qu'un petit peu, c pas gênant pr apprendre, ms après ça peut le devenir (au moment ou on en est à écrire des bout de code en ASM pour gagner un peu de ressources) les MFC "gachent" forcément un peu de ressources... mais es ce à un degré perceptible !? j'en sais rien du tout !

 
Un timer, c une bonne idée, mais j'aurai aucune idée du Delay à mettre... c qd même un truc primordial la fréquence à laquelle est appelé le truc. Et puis ça fait un peu bricolo, non !?

El_Gringo a écrit a écrit :   Je voudrais qu'il retrace automatiquement ma fenêtre windows parce que pour des animations, y faut bien qu'y retrace régulièrement, même si il a pas reçu de message spécifique... y retrace tt le temps, c tout ! Dans beaucoup de cas, le contenu des frames est redessiné régulièrement. ça bouffe pas tout le temps processus... y a un truc dans les OS multi process (ma fois, plutot répandus aujourd'hui ) qui s'appel le partage du temps processeur, c génial, et ça te permet de redessiner régulièrement une fenêtre en faisant d'autre trucs en même temps, génial non ?:D

 
Pff tu me prends pour un neuneu ou quoi?
je sais tres bien pourquoi TU veux qu'il la retrace
je te disais juste que windows ne le fera pas parce
que c'est un besoin specifique a TON application.
 
La solution (puisqu'en encapsulant tu as perdu
l'acces a ton wndproc), c'est de passer soit
par le timer (ca peut etre genant: quel valeur mettre au timer?? je crois que tres peu de jeux fonctionnent comme ca.. c'est aussi vrai qu'ils n'utilisent pas les MFC pour le moteur du jeu lui-meme. mais MFC est souvent utilise pour les outils)
Soit de provoquer le retracage dans la partie OnIdle de ton CWinApp. (mais il faudra passer par une gestion du temps, si tu veux avoir une animation fluide et reguliere quoiqu'il arrive)
 

 
Attends! il y a incompatibilite et incompatibilite.
Il y a de nombreuses personnes qui utilisent les MFC
avec toutes sortes de choses et des gens qui y sont
allergiques. ca peut etre une incompatibilite de personne
ou un probleme religieux (mais DX = microsoft aussi).
Pour les performances, la perte des MFC c'est principalement
au niveau memoire et taille de l'appli
(l'encapsulation a un cout), pour l'affichage, tu ne vas
pas utiliser les widgets standards et GDI pour ton appli temps reel de la mort qui tue.. enfin c'est toi qui vois.
 
A+
LEGREG

Donc personne à jammais tenté DirectX avec les MFC... pourquoi vous avez pas essayé ?
Le truc qui m'interre surtout, c de savoir comment afficher un Device D3D dans une vue (CView), parce que les vue, elle ont ce message Draw qui redessine le contenu de la vue régulièrement... et là, c géré correctement... je vais pas refaire toute la gestion du temps...

[edtdd]--Message édité par El_Gringo--[/edtdd]

le plus simple : pourquoi ne fais-tu pas une thread qui s'occupe de tout le temps rafraîchir ta fenêtre ?

 
Sisi ca marche
 
LEGREG

Le plus simple c'est de rafraîchir l'affichage sur l'événement OnIdle de l'appli principale.
 
Edit : ça a déjà été dit, désolé

[edtdd]--Message édité par z51--[/edtdd]

 
Parce que j'en ai jammais fait, que ça m'fait un peu peur. Et que g tjs entendu dire que le multi threading est lourd à gérer, donc à éviter autant que possible... c faux !?

Un thread c'est une solution
mais ce n'est pas la seule  
et puis se pose le probleme de la gestion
des acces concurrents a la memoire:
ajouter des mutex et verrous.
et surtout si tu utilises les librairies
de thread tu n'as pas trop de controle sur le scheduler
(temps passe a faire des calculs et de l'affichage).
Comme l'a deja ete dit pour la troisieme fois:
Overrider OnIdle dans la CWinApp c'est une solution
simple, la gestion du temps dans ce cas peut etre simple rassure toi. (consiste a calculer le temps ecoule depuis le dernier trace par exemple)
 
LEGREG

N'y a-t-il pas un probleme vis-a-vis des librairies graphiques en multi-threading ? En generales celles-ci doivent etre utilisees uniquement depuis la thread principale, non ?

 
de gérer avec OnIdle ou avec un thread, sans vouloir vs vexer, ça m'parait pas un peu du bricolage. En fait c parce que g lu un truc sur internet. ils rentraient pas dans les détails, mais ils disaient que pour utiliser DirectX avec les MFC, ils disaient d'afficher le rendu D3C dans une CViewForm. enfin, je pense que dans une CView quelconque, ça peut fonctionner pareil. Et en fait, c plutot ça qui m'interresse (à défaut de ça, je garde qd même le "OnIdle" en tête, mulit-threading--> trop complex pour si peut)

dans l'app sur laquelle je bosse en ce moment, le rendu est fait dans un thread. il communique par messages avec la thread gui. ce n'est pas moi qui me suis occupé de ce bout de code, mais je crois me souvenir qu'il n'y a aucun code spécifique mutex/critical sections/etc. on peut très bien faire du multithreading 'simple' : ici, les deux threads ne partagent jamais les mêmes données, l'un alloue, l'autre désalloue. bref, c'est un cas 'particulier' de multithreading mais ça marche bien.
 
il n'y a pas de problèmes de multithreading venant de directx, la preuve, ça marche ça marche également très bien dans un contrôle activex, aucun problème.
 
le OnIdle(), on avait essayé, le framerate était erratique car wm_idle est envoyé un peu n'importe quand.
 
je maintiens qu'un InvalidateRect() marche très bien (même si c'est trèèès crade. en attendant mieux ...)

et pourquoi donc ? ça permet d'avoir la gui qui répond tout le temps, le rendu qui ne bloque rien. pour prendre un parallèle connu, c'est ce qui se passe dans photoshop : tu as une thread gui, et une thread qui calcule les effets (genre gaussian blur) et qui balance le résultat à la thread gui pour qu'elle update les fenêtres.

 
Nope il n'y a pas de problemes... Si tu geres ca bien .
Exemple de mauvaise gestion:
un thread balance des polygones tandis qu'un deuxieme
alloue des textures.. Resultat non garanti.
Exemple de bonne gestion:
Un thread se charge de gerer les acces reseau (c'est ce que
fait DirectPlay, si je ne m'abuse) ou de jouer la musique et les effets sonores, un autre de l'affichage.
Pour limiter les effets d'acces concurrent a la memoire et aux ressources, tu ne permets qu'a un type de thread d'acceder a un type de ressource et tu bases ton appli sur un modele client- serveur(une thread qui gere la logique du jeu est client d'un serveur qui gere l'affichage).
Pour ce qui est de l'acces au variables partagees, il faut toujours les proteger par mutex meme si tu n'as pas encore eu de problemes ca ne veut pas dire qu'il n'y en aura pas
(tu pars du principe que certaines actions sont atomiques alors
qu'elles ne le sont pas). Eventuellement pour une gestion plus fine tu implantes un Read/Write Lock ou les autres modeles.. cf cours de programmation systeme pour plus de details.
 
MAIS
C'est beaucoup se compliquer la vie, en general  
reprogrammer la boucle de gestion des evenements
(ou le OnIdle si tu n'y a pas acces) suffit amplement pour une appli temps reel simple.
 
LEGREG

youdontcare a écrit a écrit : dans l'app sur laquelle je bosse en ce moment, le rendu est fait dans un thread. il communique par messages avec la thread gui. ce n'est pas moi qui me suis occupé de ce bout de code, mais je crois me souvenir qu'il n'y a aucun code spécifique mutex/critical sections/etc. on peut très bien faire du multithreading 'simple' : ici, les deux threads ne partagent jamais les mêmes données, l'un alloue, l'autre désalloue. bref, c'est un cas 'particulier' de multithreading mais ça marche bien.   il n'y a pas de problèmes de multithreading venant de directx, la preuve, ça marche ça marche également très bien dans un contrôle activex, aucun problème.   le OnIdle(), on avait essayé, le framerate était erratique car wm_idle est envoyé un peu n'importe quand.   je maintiens qu'un InvalidateRect() marche très bien (même si c'est trèèès crade. en attendant mieux ...)

 
à mon avis, ton argument qui te fais me déconseiller le OnIdle est bon, en tout cas, g aucun mal à le croire... c pas fait pour ça le OnIdle. Faire un autre thread, ça m'parait trop compliqué. Alors maintenant (ouais, je sais, je suis tétu ), si qqn peut me dire qqch sur: comment afficher un rendu D3D dans une CView, je suis prenneur...

El_Gringo a écrit a écrit : à mon avis, ton argument qui te fais me déconseiller le OnIdle est bon, en tout cas, g aucun mal à le croire... c pas fait pour ça le OnIdle. Faire un autre thread, ça m'parait trop compliqué. Alors maintenant (ouais, je sais, je suis tétu ), si qqn peut me dire qqch sur: comment afficher un rendu D3D dans une CView, je suis prenneur...

je ne connais pas CView ... mais c'est une classe qui encapsule une fenêtre, non ? tu as une fenêtre ... tu as une classe que tu peux dériver ... dx ne demande qu'un hwnd pour être initialisé ... où est le problème ? où es tu bloqué ?

haaa, merde, j'avais même pas fait gaffe que CView hérite de CWnd. Je sais pas pourquoi, j'étais persuadé du contraire... d'ailleur, g failli te répondre que "non" sans vérifier !
Bah du coup j'imagine qu'y a pas de problème !
J'pourrais pas essayer avant ce soir. Mais je verrai, vous aurez de mes nouvelles de toute façon !
Merci...

 
Ton interpretation de la doc me semble bizarre
 
Voici le vrai extrait MSDN:
 
Run cycles through a message loop, checking the message queue for available messages. If a message is available, Run dispatches it for action. If no messages are available ? often the case ? Run calls OnIdle to do any idle-time processing that you or the framework may need done. If there are no messages and no idle processing to do, the application waits until something happens. When the application terminates, Run calls ExitInstance. The figure The Message Loop in OnIdle Member Function shows the sequence of actions in the message loop.
 
A+
LEGREG

LEGREG > je connais le multi threading
je pense qu'il n'etait inutile de mettre le point sur le fait que une seule thread doit dessiner a un instant donne, et en general il est preferable que ce soit la thread principale...

je peux t'en sortir un autre :
 
"OnIdle function   Idle events can occur at times you do not expect, such as between WM_KEYDOWN and WM_KEYUP events. Timers may be a more efficient way to trigger your desired behavior. Also, you should not force OnIdle to be called repetitively by generating false messages or by always returning TRUE from an override of OnIdle because this will never allow your thread to sleep. Again, a timer or a separate thread might be more appropriate. "
 
http://msdn.microsoft.com/library/ [...] l_code.asp
 
par "un peu n'importe quand", j'entends que l'envoi du onidle dépend de facteurs qui ne permettent pas un framerate stable. c'est tout

youdontcare a écrit a écrit : je peux t'en sortir un autre : "OnIdle function   Idle events can occur at times you do not expect, such as between WM_KEYDOWN and WM_KEYUP events. Timers may be a more efficient way to trigger your desired behavior. Also, you should not force OnIdle to be called repetitively by generating false messages or by always returning TRUE from an override of OnIdle because this will never allow your thread to sleep. Again, a timer or a separate thread might be more appropriate. " http://msdn.microsoft.com/library/ [...] l_code.asp par "un peu n'importe quand", j'entends que l'envoi du onidle dépend de facteurs qui ne permettent pas un framerate stable. c'est tout

 
Bon OK faut que je sois super clair ,  
tu n'as pas compris ma critique: il ne s'agit pas de dire qu'un thread ou un timer ne permet pas de faire la tache mais
ton affirmation qu'un evenement "WM_IDLE" etait poste de maniere erratique et donc entrainait un affichage du meme acabit etait errone et la doc effectivement te contredit: il n'y a pas d'evenement WM_IDLE.
Demande a ElGringo comment il aurait fait s'il n'avait pas utilise les MFC's et bien il aurait fait comme avec OnIdle:
il aurait traite les messages comme ils arrivent et la plupart du temps il l'aurait passe dans une fonction qui se charge de mettre a jour son monde.
L'avantage des threads c'est que tu ne dois pas penser "temps reel" lorsque tu programmes parce que tu as un scheduler qui s'en charge de repartir le temps processeur pour toi mais en contrepartie tu la paies en temps de debuguage et de pose des verrous (qui peut aussi creer des blocages).
 
Je n'ai pas trouve ta citation sur la page en lien par contre j'ai trouve ca :
Threads
When you need a background task, threads may not be your best solution. Effective idle handling of the event may be a better solution. It?s easier to understand the locality of reference of your program with one thread than with two or more.
 
A good rule of thumb is that you should only use a thread if an operating system notification that you need to block on is at the root of the background work. Threads are best in such a case because it is not practical to block a main thread on an event.
 
Threads also present communication problems. You will have to manage the communication link between your threads, whether it be with a list of messages or by allocating and using shared memory. Managing your communication link will likely require synchronization to avoid race conditions and deadlock problems. Such complexity can easily turn into  bugs and performance problems.
 
Ce qui resume ce que je viens de dire en quelques dizaines de posts.
 
A+
LEGREG
Ps: si je programmais en java j'utiliserais
des threads. Mais tu n'as pas plus de garanties sur la stabilite
des frames en java qu'en C++ avec MFC, ONIDLE et threads..
La seule garantie que tu peux avoir c'est quand tu auras tout fait dans ta maniere de programmer (ca peut etre lourd suivant tes contraintes par exemples sur les acces reseau par internet ou autre) pour que l'affichage soit le plus smooth possible mais parfois la seule solution c'est de revenir a du tres bas niveau (Play station2 par ex).

[edtdd]--Message édité par legreg--[/edtdd]

El_Gringo>
 
Ta boucle avec le dispatch message etc..., tu la mets dans la méthode virtuelle CWinApp::Run() et dans le cas où tu n'as plus de message à traiter, tu envoies une invalidation (InvalidateRect) ce qui va provoquer l'appel de CView::OnDraw(CDC* pDC) dans lequel tu dessines tes objets.
 
Je trouve que c'est la méthode la moins "magouillatoire" avec les MFC. Les perfs ne seront pâs au top mais c'est pas le but.

ahala ces smiley débiles...

 
mais... OnDraw() d'une CView, t sur qu'elle est pas appelée régulièrement, sans qu'il y ai à faire quoi que ce soit !? (invalidateRect ou autre...)

 
Ah ben non ! Le OnDraw est appelé à chaque fois qu'il y a à redessiner la fenêtre (resize, minimisation/maximisation, perte de focus, fenêtre qui passe devant etc...)  mais si il n'y a rien à faire, la méthode n'est pas appelée (encore heureux sinon on réinvente le monotache )

[edtdd]--Message édité par n0mad--[/edtdd]

Moi j'ai fais un éditeur d'animation avec les MFC et direct3D. Et tout marchait très bien.
 
Lorsque j'étais en mode édition je ne reaffichait la fenêtre que lorsque windows m'envoyait un message WM_PAINT ou alors lorsque l'utilisateur avait modifié le squelette de mon personnage.
 
Et lorsque je voulais "jouer" une animation, j'activait le timer windows (WM_TIMER) en lui demandant de m'envoyer 60 messages par secondes. C'est largement suffisant pour visualiser une animation ou n'importe quel moteur 3D dans un éditeur.
Et si mon PC ramait trop pour afficher 60 images par secondes, ce n'était pas grave car windows effaçait les messages WM_TIMER en retard.
 
A mon avis, c'est la solution la plus simple pour un éditeur.
 
Leander

BENB a écrit a écrit : LEGREG > je connais le multi threading

Je ne m'adressais pas forcement a toi
mais je voulais dissiper le semblant
de FUD que pouvait soulever ton
"N'y a-t-il pas un probleme vis-a-vis des librairies graphiques en multi-threading"
 
A+
LEGREG