Meilleures pratiques pour la prise en charge de la touche Alt-Tab dans une application DirectX ?

Question

Lors de l'écriture d'applications DirectX, il est évidemment souhaitable de permettre à l'utilisateur de suspendre l'application par l'intermédiaire de Alt - Tab d'une manière qui est rapide et sans erreur . Quel est le meilleur ensemble de pratiques pour garantir cela ? Les éléments qui doivent être abordés sont les suivants :

1. Les meilleures méthodes pour détecter quand votre application a été quittée par un alt-tab et quand elle a été réactivée.
2. Quelles sont les ressources DirectX qui sont perdues lorsque l'utilisateur tape sur la touche Alt, et les meilleurs moyens d'y faire face.
3. Principales choses à faire et à éviter dans l'architecture des applications pour la prise en charge de la fonction alt-tab.
4. Toute différence significative entre les principales versions de DirectX, telle qu'elle s'applique à ce qui précède.

Il est également intéressant d'entendre parler d'astuces et de pièges.

Answer 1

Je supposerai que vous utilisez C++ pour les besoins de mes réponses, mais si vous pouvez vous permettre d'utiliser C#, XNA ( http://creators.xna.com/ ) est une excellente plateforme de jeu qui gère toutes ces questions pour vous.

1]

Cet article est utile pour les événements Windows dans la procédure de fenêtre pour détecter quand une fenêtre perd ou gagne le focus, vous pourriez gérer cela sur votre fenêtre principale : http://www.functionx.com/win32/Lesson05.htm . Vous pouvez également consulter le message WM_ACTIVATEAPP ici : http://msdn.microsoft.com/en-us/library/ms632614(VS.85).aspx

2]

• Le périphérique graphique est perdu lorsque l'application perd le focus du mode plein écran. Microsoft propose un article sur la manière de gérer ce problème : http://msdn.microsoft.com/en-us/library/bb174717(VS.85).aspx Cet article contient également un tutoriel sur les appareils perdus : http://www.codesampler.com/dx9src/dx9src_6.htm

• DirectInput peut également avoir un état d'erreur de périphérique perdu, voici un lien à ce sujet : http://www.toymaker.info/Games/html/directinput.html

• DirectSound peut aussi avoir un état d'erreur "device lost", cet article contient un code qui gère cela : http://www.eastcoastgames.com/directx/chapter2.html

3]

Je ferais en sorte de ne jamais désactiver Alt-Tab. Vous souhaitez probablement une charge minimale du processeur lorsque l'application n'est pas active, car l'utilisateur a probablement cliqué sur Alt-Tab parce qu'il voulait faire autre chose. Vous pouvez donc mettre l'application complètement en pause, ou réduire le nombre d'images rendues par seconde. Si l'application est réduite au minimum, vous n'avez bien sûr pas besoin d'effectuer le rendu non plus. Après avoir réfléchi à un jeu en réseau, je pense que la meilleure solution est de réduire le nombre d'images rendues par seconde ainsi que la quantité de paquets réseau traités, voire même de rejeter la plupart des paquets qui arrivent jusqu'à ce que le jeu soit réactivé.

4]

Honnêtement, je m'en tiendrais à DirectX 9.0c (ou DirectX 10 si vous voulez limiter votre système d'exploitation cible à Vista et aux versions plus récentes) si possible :)

Enfin, le sdk DirectX dispose de nombreux tutoriels et échantillons : http://www.microsoft.com/downloads/details.aspx?FamilyID=24a541d6-0486-4453-8641-1eee9e21b282&displaylang=en

Answer 2

Nous avons résolu le problème en n'utilisant pas du tout un dispositif DirectX plein écran - à la place, nous avons utilisé une fenêtre plein écran avec le drapeau le plus haut pour qu'elle cache la barre des tâches. Si vous quittez la fenêtre par Alt-Tab, vous pouvez retirer le drapeau et réduire la fenêtre. Les ressources de la texture sont maintenues en vie par la fenêtre.

Cependant, cette approche ne gère pas les événements de perte d'appareil qui se produisent en raison d'un "écran de verrouillage", de Ctrl+Alt+Suppression, de connexions de bureau à distance, de changements d'utilisateur ou autres. Mais ces événements n'ont pas besoin d'être traités de manière extrêmement rapide ou efficace (du moins, c'était le cas dans notre application).

Answer 3

Toutes les applications D3D sérieuses doivent être capables de gérer les appareils perdus, car cela peut arriver pour diverses raisons.

Dans DX10 sous Vista, il y a une nouvelle fonction "Timeout Detection and Recovery" qui fait qu'il est courant, d'après mon expérience, que les périphériques graphiques soient réinitialisés, ce qui entraînerait une perte de périphérique pour votre application. Cette situation semble s'améliorer au fur et à mesure que les pilotes évoluent, mais vous devez tout de même y faire face.

Answer 4

Dans DX8 et 9 (et 10 ?), si vous créez vos ressources (tampons de vertex et d'index et textures principalement) à l'aide de D3DPOOL_MANAGED, elles persisteront sur les périphériques perdus et n'auront pas besoin d'être rechargées. En effet, elles sont stockées dans la mémoire système et le runtime DX les copie automatiquement dans la mémoire vidéo. Cependant, il y a un coût de performance dû à la copie et ce n'est pas recommandé pour les données de vertex qui changent rapidement. Bien sûr, vous devez d'abord établir un profil pour déterminer s'il y a un problème de vitesse :-)