Exporter (0) Imprimer
Développer tout

Développement de jeux Smartphone

Andy Sjostrom
businessanyplace

S'applique au logiciel :
Microsoft Smartphone 2002

Résumé

Cet article décrit le développement de jeux pour le logiciel Microsoft Smartphone 2002 et fournit des conseils s'y rapportant.

Sommaire

Présentation du marché des jeux
Développement de jeux
Portage de jeux pour Smartphone
Écriture de jeux efficaces
Accès à la mémoire et bande passante
Gestionnaire de mémoire
Système de messagerie
Gestionnaire des ressources
Proscription de l'arithmétique flottante
Proscription des divisions
Proscription des types de données fournissant uniquement la résolution suffisante pour traiter le domaine du problème
Utilisation étendue des tables de choix
Exécution de l'ensemble de votre arithmétique dans l'assembleur
Désactivation du son des touches
Captures d'écran de jeux
Conclusion

Présentation du marché des jeux

Les nouveaux Smartphones fonctionnant sous Microsoft® Windows® arrivent sur le marché avec de nouveaux jeux très attrayants et ceci n'est qu'un début. Lisez la suite de cet article pour comprendre pourquoi ces téléphones attirent des joueurs passionnés et pour obtenir les informations nécessaires pour développer des jeux réussis.

Le marché des jeux informatiques a énormément évolué depuis l'apparition des premiers jeux basés sur des caractères à la fin des années 70. D'un point de vue financier, certains analystes s'attendent à voir le marché des jeux, y compris les ventes de consoles et de logiciels PC, générer 18 milliards de dollars d'ici 2004, et ce uniquement pour les États-Unis. La valeur totale des ventes au niveau international a déjà dépassé la valeur de l'ensemble de l'industrie du film d'Hollywood. D'un point de vue technique, le marché des jeux stimule le développement de matériel destiné aux consommateurs et, au cours de ces dernières années, il a même stimulé la croissance des abonnements et de la connectivité à Internet. Ce ne sont naturellement pas les traitements de texte, les feuilles de calcul ou les applications sectorielles qui nécessitent des puces graphiques 3D plus puissantes, un stockage de masse et des processeurs plus rapides.

On s'attend à ce que la valeur de la nouvelle industrie des jeux sans fil atteigne entre 4 à 15 milliards de dollars d'ici 2006, selon les diverses sources ( Quitter le site MSDN France Site en anglais). Quelle que soit la direction choisie par l'industrie des jeux, une chose est certaine, ce sera la bonne.

Développement de jeux

Le développement de jeux pour les téléphones mobiles suit le même chemin que son équivalent basé sur les PC. Les avancées en matière de jeu sur PC incluent le passage à l'affichage graphique, la possibilité de jouer à plusieurs et de se connecter à Internet. Pendant des années, les jeux des téléphones mobiles étaient semblables aux jeux sur PC, sans affichage graphique ou avec un affichage graphique médiocre. Tandis que certains fabricants de téléphones incluent une meilleure prise en charge des graphiques, aujourd'hui encore certains téléphones sont vendus avec des jeux intégrés ne présentant quasiment aucun graphique.

Avec le Smartphone, l'industrie du téléphone mobile va connaître des avancées prodigieuses, similaires à celles déjà réalisées sur le marché des jeux sur PC, et encore peut-être même plus rapides. Les premiers jeux qui devraient voir le jour pour Smartphone existent déjà sous forme de jeux Windows et Pocket PC. Étant donné que les développeurs de jeux peuvent utiliser les mêmes outils de développement, langages de programmation et API (Interfaces de programmation d'applications), les efforts pour transposer ces jeux sur Smartphone sont minimes.

Portage de jeux pour Smartphone

Le tableau ci-dessous répertorie certaines sociétés impliquées dans le développement et le portage de jeux pour Smartphone 2002. (Liens en anglais).

Tableau 1. Sociétés impliquées dans le développement et le portage de jeux pour le Smartphone 2002.

SociétésJeux
Ideaworks3D Quitter le site MSDN France Site en anglais « Rebound! », ainsi que d'autres jeux, développés parfois avec des éditeurs partenaires comme Eidos Interactive Quitter le site MSDN France Site en anglais.
Hexacto Quitter le site MSDN France Site en anglais « Tennis Addict », « Full Hand Casino » et « Slurp ». D'autres jeux sont attendus d'ici peu, parmi lesquels « Lemonade Inc. », « Baseball Addict » et « Bob The Pipe Fitter ». Plusieurs de ces jeux proposeront des fonctionnalités multi-joueurs, en s'appuyant sur les capacités sans fil de Smartphone.
Incagold Quitter le site MSDN France Site en anglais « Slamtilt », un jeu de flipper en 3D
Pixel Technologies Quitter le site MSDN France Site en anglais « MobilePlay(tm) 1 », un ensemble de jeux en ligne incluant un jeu d'échec, de dames, de poker, de bridge, de backgammon et de Reversi, etc.
Xen Games Quitter le site MSDN France Site en anglais « Interstellar Flames », un jeu d'action dans lequel vous pilotez un avion de chasse pour défendre la terre.
Terra Mobile-iobox Quitter le site MSDN France Site en anglais « Defender » et d'autres jeux qui suivront plus tard avec des fonctionnalités sans fil

Le développement et la qualité des jeux développés dépendent en grande partie des capacités de la plate-forme cible et des moteurs de jeu disponibles. Outre les API du kit de développement du logiciel Smartphone, les moteurs de jeu suivants seront bientôt disponibles :

Consultez ces liens (en anglais) pour découvrir les fonctionnalités complexes proposant une expérience irrésistible aux joueurs sur Smartphone.

Écriture de jeux efficaces

Nous nous sommes adressé à Sven Myhre, Directeur général et développeur chez Amazing Games Quitter le site MSDN France Site en anglais, pour en savoir plus quant au développement de jeux efficaces.

L'une des idées reçues parmi les utilisateurs et les développeurs de portables est qu'un processeur ARM moderne peut être comparé aux processeurs Pentium d'une vitesse similaire. Toutefois, cette comparaison ne donne pas une idée fidèle du processeur ARM. Un Pentium plus ancien sera supérieur à tous les Smartphones et Pocket PC actuels basés sur ARM. Ceci est dû d'une part au processeur lui-même et d'autre part aux systèmes de prise en charge qui l'entourent.

Le Pentium est superscalaire (il peut exécuter plusieurs instructions par cycle d'horloge), avec cinq unités d'exécution parallèles et une unité à virgule flottante intégrée. Normalement, un cache L1 interne et un cache L2 externe généreux se trouvent également dans la plupart des PC qui en sont dotés.

Les Smartphones et Pocket PC actuels fonctionnant sous Windows et basés sur ARM sont scalaires au mieux (ils peuvent donc exécuter une instruction par cycle). Mais cette instruction est limitée et ne contient que les principales instructions de base. Les instructions plus avancées, par exemple, une division, n'existent pas et doivent être émulées dans le logiciel.

La capacité à alimenter le processeur avec des instructions et des données de façon à ce qu'il continue à fonctionner à pleine vitesse constitue un autre problème. La plupart des conceptions utilisent un bus unique de 16 bits pour récupérer les instructions du code et les données. Étant donné que toutes ces instructions sont de 32 bits, le bus devrait fonctionner deux fois plus vite que le processeur et, ce, uniquement pour alimenter le pipeline d'instructions du code. Et ce n'est pas le cas. C'est actuellement l'autre difficulté, le bus est plus lent que le processeur. Le facteur de vitesse du bus par rapport à celui du processeur varie d'un facteur 2 à 4. Un bus de 16 bits cadencé à 66 MHz peut juste fournir suffisamment d'instructions de code pour un processeur ARM cadencé à 33 MHz maximum, sans compter les données que vous souhaitez traiter. Pour résoudre ce problème, la plupart des processeurs ARM incluent un cache des instructions et un cache des données. Leur taille par défaut est de 8 Ko pour les instructions et les données du code respectivement, bien que certains atteignent 32 Ko. Tant que l'instruction du code ou les données requises sont présentes dans le cache, l'unité centrale peut les récupérer directement à partir du cache à la vitesse maximale et il est inutile de passer par l'intermédiaire du bus frontal lent. Mais, dès que vous commencez à accéder au code et aux données qui ne sont pas déjà chargés dans le cache, vous repassez en fait à une vitesse inférieure à 33 MHz (avec un bus 16 bits cadencé à 66 MHz). Il est en fait très facile de réduire la capacité d'un processeur ARM de 132 MHz à 2 MHz, uniquement en organisant vos données de façon inefficace, de sorte que le cache provoque l'effet inverse de celui escompté.

Mais cela est encore rapide comparé à ce que vous pouvez obtenir avec des types de données incorrects et un codage inefficace. Effectuez de nombreuses divisions ou utilisez de nombreux types de données à virgule flottante et l'unité centrale peinera à atteindre 0,2 millions d'instructions de code par seconde.

Accès à la mémoire et bande passante

Les Smartphones pourraient être dotés de toute une gamme de processeurs ARM, avec chacun des coûts d'accès à la mémoire différents, mais vous pouvez être quasiment certain que vous disposeriez de trop peu de cache et d'un bus de mémoire trop lent pour ne pas vous en apercevoir.

Prenons l'exemple d'un processeur fonctionnant à 132 MHz et d'un bus frontal 16 bits fonctionnant à 66 MHz. Dès que vous lisez un octet qui n'est pas déjà présent dans le cache du processeur, ce dernier doit d'abord remplir une ligne entière du cache. Une ligne de cache peut contenir 16 mots (un mot est égal à 32 bits ou 4 octets au niveau de l'architecture ARM), ce qui signifie qu'une ligne de cache est égale à 16 * 4 = 64 octets. Étant donné que votre bus frontal est de 16 bits, il sera occupé pendant 32 cycles avant que cette ligne ne soit remplie, et comme le bus fonctionne à moitié moins vite que votre processeur, celui-ci restera bloqué pendant 64 cycles avant que vous puissiez obtenir le misérable octet que vous demandez. Assurez-vous donc que le remplissage de la ligne de cache vaut la peine d'attendre. Vérifiez également que votre mémoire est compressée de la façon la plus compacte possible et vérifiez les modes d'accès à la mémoire pour voir si vous pouvez réorganiser certaines structures pour gagner en efficacité. Si vous accédez régulièrement à une seule donnée membre d'une structure et que vous traitez un grand nombre de ces structures, voyez si vous ne pouvez pas transférer cette donnée membre spécifique dans son propre tableau.

Pour les mêmes raisons, utilisez des octets (8 bits) ou des octets doubles (16 bits) à chaque fois que c'est possible, étant donné que le processeur ARM peut développer à la fois des octets et des octets doubles signés et non signés en mots au cours du chargement mémoire/registre. Toutefois, lorsque vous stockez des valeurs signées à partir de registres vers un emplacement de mémoire à octet ou à octet double, le compilateur générera deux instructions de décalages pour faire en sorte que la valeur garde son bit de signe même si la valeur de votre registre est trop volumineuse pour l'emplacement de mémoire créé. Sur les processeurs ARM, l'un des décalages peut se produire sans qu'il ne vous en coûte rien (presque toutes les instructions « normales » peuvent être associées à une instruction de décalage) selon l'efficacité du compilateur. Cette information est cruciale pour vos boucles secondaires. À chaque fois que vous utilisez une variable à un octet ou à un octet double, veillez à utiliser un type de données non signé dès que vous le pouvez.

Gestionnaire de mémoire

Ceci n'est sans doute pas une nouveauté pour vous, mais les gestionnaires de mémoire généraux et les fonctions, telles que malloc, realloc et new (généralement, juste un wrapper de malloc) sont très lents. Souvent vous feriez mieux d'affecter préalablement toute la mémoire dont vous avez besoin et d'utiliser votre propre gestionnaire de mémoire. C'est en effet le sous-système le plus important de votre projet de jeu. Pendant le développement, vous pouvez facilement incorporer des vérifications de cohérence, tester les pointeurs incorrects et vous assurer que tous vos opérateurs free et delete correspondent à vos opérateurs alloc et new.

Il est également bien plus rapide d'affecter des tableaux de structures de taille égale et d'utiliser uniquement un masque de bits (ou un autre moyen) pour traiter l'allocation et la désallocation.

Système de messagerie

Le second sous-système le plus important est un système de messagerie solide comme un roc et ne se référant pas au système de pompe de message Windows. Toutes les interactions entre les objets du jeu doivent avoir lieu par l'intermédiaire de votre propre système de messagerie privé. Ceci inclut la possibilité de définir une heure de remise des messages, de sorte que vous pouvez vous envoyer des messages ou d'autres objets qui pourront être remis ultérieurement. Lorsque le caractère du jeu sélectionne un élément sous tension, vous pouvez simplement vous envoyer un message de « désactivation de la mise sous tension » de sorte qu'il vous soit remis au bout de 5 secondes, par exemple. Étant donné qu'il n'est pas certain que les objets soient encore actifs, lors de la remise du message, n'utilisez jamais de pointeurs. Les handles (id statiques) sont la solution. Avec un tel système, il est facile d'ajouter une fonctionnalité de reprise du jeu, étant donné que votre système de messagerie central ne fait que sauvegarder tous les messages dans un fichier pendant le jeu. Le système permettant de reprendre le jeu pourrait alors simplement lire tous les messages à partir du fichier de sauvegarde et les envoyer séquentiellement. C'est également parfait pour le débogage, ajoutez simplement une console ou un fichier journal où vous pouvez visualiser tous les messages en temps réel, ou bien relancez exactement le même flux de messages jusqu'à ce que vous atteigniez l'endroit où votre jeu s'est interrompu.

Même la création et la suppression d'objets doivent s'effectuer à l'aide de messages, de même que l'entrée des joueurs. La seule chose qui manque est la notion de propriété de l'objet, et vous pouvez étendre le système de messagerie pour créer un pont vers un autre ordinateur, la base d'un système multi-joueurs. Étant donné que toutes les interactions passent par le système de messagerie, la logique du jeu ne fera pas de distinction entre les messages envoyés par le joueur réel (touches matérielles), les joueurs virtuels ou les joueurs d'un réseau à distance.

Gestionnaire des ressources

Je le répète, n'accédez jamais aux objets avec des pointeurs. Toutes vos ressources doivent être liées à des handles. Pour plus d'efficacité, vous pouvez autoriser le verrouillage/déverrouillage de telles ressources dans un segment de code court, mais celles-ci ne doivent jamais rester verrouillées longtemps (ne les verrouillez pas pendant plusieurs trames). En ajoutant un compteur des utilisations, vous pouvez réutiliser les ressources en lecture seule et économiser de la mémoire. Vous n'avez également pas besoin de libérer réellement des ressources même si le compteur des utilisations est réinitialisé. En conservant les ressources en mémoire, vous pouvez procéder à l'archivage avec un temps de chargement quasiment nul la prochaine fois où vous aurez besoin de la ressource. Une autre bonne solution serait d'allouer assez de mémoire pour conserver toutes les ressources dont vous avez besoin simultanément ou d'allouer 75 % de la mémoire système libre, selon ce qui convient le mieux. Ainsi, vous pouvez utiliser des équipements plus puissants, grâce à la mémoire supplémentaire, pour mettre les ressources en cache.

Votre gestionnaire des ressources doit savoir comment recharger chaque élément de ressource. Ceci lui permet de libérer la mémoire occupée par des éléments de ressources et de les recharger sans impliquer le reste du code de votre jeu. La libération de toutes les ressources mémoire serait une réponse naturelle à la perte de focus au niveau des autres applications, de même que leur rechargement lorsque vous rétablissez le focus. Ceci devrait être exécuté automatiquement et être totalement transparent pour le reste de votre code.

Proscription de l'arithmétique flottante

Par défaut, votre processeur ARM ne prend pas en charge l'arithmétique flottante. Toutes les arithmétiques flottantes utilisent un émulateur à virgule flottante spécial et sont très lentes. Il est courant de voir des fonctions à virgule flottante nécessitant des milliers de cycle pour être exécutées. C'est pourquoi un projet de jeu préférera normalement plutôt utiliser des formats à virgule fixe. Une virgule fixe n'est en réalité uniquement qu'un nombre entier auquel vous affectez un nombre imaginaire (mais fixe) de bits comme la fraction d'une valeur. Cela revient à considérer que les chiffres inférieurs à 1 000 sont une fraction de ce nombre. Pour exprimer le nombre 0,500, il vous suffirait simplement de multiplier par 1 000 et de terminer avec le nombre 500. L'aspect le plus difficile est de visionner mentalement cette virgule décimale invisible à chaque instant. Il n'y a pas de problème pour l'addition et la soustraction : 500 + 500 = 1 000 (ou mentalement : 0,500 + 0,500 = 1,000). Ce n'est pas aussi évident pour la multiplication et la division : considérer que 500 * 500 = 250 000 (ou mentalement : 0,500 * 0,500 = 250,000) serait incorrect. Après la multiplication de deux valeurs à virgule fixe, vous devez diviser le résultat. Si vous divisez le résultat par 1 000, vous tombez juste (250,000 / 1 000 = 0,250 est correct). Ainsi pour multiplier, vous n'avez qu'à effectuer la multiplication habituelle, puis à diviser le résultat pour le normaliser.

Ceci nous amène à un autre sujet intéressant. Qu'advient-il de la plage de données du résultat intermédiaire, avant que vous ne procédiez à sa normalisation ? Dans l'exemple ci-dessus, il est possible que vous dépassiez le nombre disponible de bits lorsque vous effectuez la multiplication, ce qui signifie que vous parvenez à un dépassement de capacité et que vous perdez ainsi la partie la plus importante du résultat. L'astuce consiste à être certain que vous utilisez un format de données en mesure de contenir le résultat le plus volumineux possible dans le résultat intermédiaire. Lorsque vous multipliez deux valeurs de 32 bits, votre valeur intermédiaire doit être de 64 bits. Après l'avoir normalisée (et rognée), le nombre de bits sera à nouveau de 32).

int Multiply16_16_by_16_16( int a16_16, int b16_16 )
 {
 __int64 tmp32_32;
 int result16_16;
 tmp32_32 = a16_16;
 tmp32_32 *= b16_16;
 // le résultat est à présent 32:32
 tmp32_32 >>= 16; // réduire aux 16 bits inférieurs
 result16_16 = ( int ) tmp32_32; // réduire aux 16 bits supérieurs.
 // le résultat est à nouveau 32:32
 return result16_16;
}

Pour diviser, faites l'inverse, commencez par multiplier, puis divisez.

Un format courant à virgule fixe serait 16:16, où les premiers 16 bits sont la partie entière et les 16 bits inférieurs la partie fractionnaire. Pour mon projet de jeu actuel, j'utilise une grande variété de formats différents afin de couvrir différentes plages de valeurs utilisées par les différentes parties du moteur du jeu. Pour résumer, j'utilise 2:30, 8:24, 16:16, 24:8, 28:4, 2:14, 8:8, 11:5, 2:8 et 4:4. La plupart sont des valeurs de 32 bits, mais certaines sont de 16, 10 ou même juste de 8 bits.

Proscription des divisions

Votre projet de jeu ne doit exécuter aucune division. Par défaut, le processeur ARM ne prend pas en charge les divisions. À chaque fois que vous exécutez une division, il vous en coûte plusieurs milliers de cycles. Un ARM de 132 MHz est théoriquement capable d'exécuter 132 millions d'instructions (ou 264 millions d'instructions si 50 % d'entre elles sont des décalages). Mais vous êtes déjà au maximum des capacités de l'unité centrale pour environ 700 000 divisions par seconde. Si votre jeu utilise 70 trames par seconde, ceci signifie que vous utilisez le processeur à sa capacité maximale en exécutant uniquement 1 000 divisions pour chaque trame créée.

Essayez plutôt de remplacer toutes les divisions par des décalages et/ou des multiplications. Les divisions par 16 peuvent être écrites sous forme de décalage de 4 vers la droite. Les divisions plus complexes peuvent être exécutées sous forme de combinaisons de décalages et/ou de multiplications.

Les divisions peuvent également être exécutées avec des tables de choix. Toutefois, avec à la fois un nominateur et un dénominateur 32 bits, vous devez disposer d'une table de choix bidimensionnelle qui dépasse largement la quantité de mémoire disponible. L'une des solutions serait alors de réduire le domaine du problème.

Dans l'expression a / b, vous pouvez insérer multiplier par un où vous voulez sans modifier le résultat final. Ainsi a * 1 / b donne exactement le même résultat. En outre, vous pouvez réorganiser l'ordre de vos multiplications et de vos divisions et obtenir : a * ( 1 / b ). À présent, la division est réduite à 1 / b qui ne nécessite qu'une table de choix unidimensionnelle. Vous pouvez encore réduire la table des choix, en réduisant la précision. Admettons que 16 bits de précision sont suffisants dans la plupart des cas et que vous avez uniquement besoin d'entrées de 64 K dans votre table des choix. En trouvant le MSB (bit le plus important) dans b, vous pouvez utiliser cette information pour décaler b et le résultat vers le haut ou vers le bas de sorte à atteindre la valeur de 32 bits et à conserver la résolution la plus élevée possible. Même si vous incluez le temps qu'il faut pour remplir une ligne de cache à partir d'un accès aléatoire à la table des choix des divisions, dans le pire des cas, vous finirez avec moins de 100 cycles, soit une amélioration de 20 fois par rapport à la division standard fournie par le compilateur, en contrepartie d'une petite perte de précision.

Utilisation des types de données fournissant uniquement la résolution suffisante pour traiter le domaine du problème

L'accès à la mémoire est l'aspect le plus important pour réaliser un code hautement performant. Ceci signifie que vous devez essayer d'utiliser des types de données les plus petits possible pour couvrir votre domaine de problème. Avez-vous réellement besoins d'index de 16 bits dans vos mailles ? Est-il possible de réduire le nombre de bits à 8 ? Avec un maximum de 256 contours, 256 sommets, 256 indices de lumination/ombrage, 256 polygones, 256 normales et 256 coordonnées de texture, il est possible que vous deviez diviser certaines mailles en de nombreuses autres mailles plus petites. Vous pourriez ainsi bénéficier d'un accès plus rapide à la mémoire.

Comment utilisez-vous vos vecteurs de normales ? Les utilisez-vous principalement pour des calculs d'éclairement ou des tests de visibilité ? J'utilise un format à virgule fixe de :,8 pour les composants de mes vecteurs de normales, ce qui signifie que je dispose d'une gamme allant de - 1,99609375 à + 1,99609375, avec une résolution de 0,00390625. En d'autres termes, je dispose de 8 bits de résolution fractionnaire pour couvrir 360 degrés avec une résolution de 1,4 degrés. Sur un écran minuscule, comme un écran 176 x 220, personne ne peut distinguer si un point est éclairé avec une direction incorrecte de +/- 0,7 (dans le pire des cas) par rapport à la lumière. L'avantage est que je peux stocker à la fois des composants x, y et z dans un mot unique.

Utilisation étendue des tables des choix

Créer des tables de choix pour des éléments qui peuvent être précalculés ne vous coûtera qu'un seul accès à la mémoire. En comparaison à des fonctions mathématiques complexes qui peuvent nécessiter plusieurs milliers d'instructions, cette approche est intéressante, même si vous devez céder un peu de mémoire pour stocker la table de choix.

Les candidats classiques des tables de choix sont la division inverse (1 / x), le calcul de sinus, le mélange de couleurs et l'éclairement. Dans mon projet de jeu actuel, presque toute la totalité du placage d'environnement et du pipeline d'éclairement/ombrage du convertisseur est implémentée avec quelques tables de choix précalculées.

Ce qui est agréable avec les jeux est que nous essayons simplement de convaincre les gens qu'ils font partie d'un monde vivant. Dès que l'aspect du jeu est correct et qu'une bonne impression s'en dégage, nous avons atteint notre objectif, peu importe la méthode que nous avons utilisée pour y parvenir. Notre devise en ce qui concerne l'optimisation est : Tous les moyens sont bons.

Exécution de l'ensemble de votre arithmétique dans l'assembleur

Si vous vérifiez la sortie du compilateur dans l'exemple de code précédent concernant la multiplication des nombres à virgules fixes, vous découvrirez que même la sortie du code de la version optimisée n'est pas très efficace :

stmdb sp!, {r11, lr} ; stmfd
 mov r11, r0
 mov r2, r1, asr #31
 mov r3, r0, asr #31
 mul r2, r11, r2
 mul r11, r3, r1
 add r3, r2, r11
 mov r11, r0
 mul r11, r3, r1
 add r0, r3, r2
 mov r3, r0, lsl #16
 orr r0, r3, r1, lsr #16
 ldmia sp!, {r11, pc} ; ldmfd

Étant donné que les codes C et C++ ne permettent pas d'exprimer l'objectif précis de notre code, le compilateur doit prendre ce que nous écrivons et traduire ces instructions sous forme de code assembleur solide.

En tant que programmeurs, nous savons parfaitement ce que vous nous souhaitons archiver et comment les microprocesseurs nous permettent d'atteindre ce but dans les meilleures conditions, le résultat est d'ailleurs souvent bien plus compact :

smull r2, r3, r0, r1
mov r0, r3, lsl #16
orr r0, r0, r2, lsr #16
mov pc, lr

Quatre multiplications sont remplacées par une seule. De nombreux transferts vers l'avant et l'arrière entre les registres peuvent être éliminés et étant donné que nous n'utilisons finalement que les quatre registres volatiles (r0-r3), nous n'avons pas besoin de configurer et de restaurer une trame de pile.

Désactivation du son des touches

Vous avez peut-être remarqué que de nombreux jeux souffrent d'une fréquence d'images « irrégulière » sur Smartphone, mais si vous désactivez le son associé aux touches, cet effet est largement diminué.

Pour des raisons obscures, l'appareil semble se figer une fraction de seconde tandis que le système d'exploitation diffuse le son associé à la touche sur laquelle vous avez appuyé.

Heureusement, chaque aspect de l'interface utilisateur peut être configuré avec XML. En définissant un petit script de configuration, vous pouvez demander au gestionnaire de configuration de modifier presque tout ce que vous voulez.

<wap-provisioningdoc> 
<characteristic type="Sounds"> 
<characteristic type="ControlPanel\Sounds\KeyPress"> 
<parm name="Mode" value="1"/> <!-- 0=aucun, 1=tonalité, 2=clic --> 
</characteristic> 
</characteristic> 
</wap-provisioningdoc>

Utilisez la fonction DMProcessConfigXML() pour intégrer les données de configuration XML ci-dessus au gestionnaire de configuration.

N'oubliez pas que vous risquez de perdre le focus en cours d'exécution, veillez donc à restaurer la configuration d'origine avant de passer à une autre application. Étant donné que l'utilisateur peut avoir modifié les paramétrages alors que votre application était inactive, vérifiez les paramétrages lorsque vous retrouvez le focus.

Captures d'écran de jeux

Voici quelques superbes captures d'écran issues des laboratoires de développement des jeux Smartphone. La figure 1 contient quelques captures d'écran de Hexacto ( Quitter le site MSDN France Site en anglais).

Jeux Hexacto en cours de développement

Figure 1. Jeux Hexacto en cours de développement.

La figure 2 contient quelques captures d'écran du jeu Rebound! de Ideaworks3D's ( Quitter le site MSDN France Site en anglais).

Jeux Ideaworks3D en cours de développement

Figure 2. Jeux Ideaworks3D en cours de développement.

La figure 3 contient des captures d'écran de jeux utilisant Fathammer's X-Forge(tm) 3D Game Engine. Celles-ci sont à la fois les versions Pocket PC et Smartphone du même jeu.

Jeux Fathammer's X-Forge 3D Game Engine en cours de développement

Figure 3. Jeux Fathammer's X-Forge3D Game Engine en cours de développement

Conclusion

Smartphone est le premier téléphone mobile disposant d'assez de puissance de traitement, de propriétés d'affichage graphique, ainsi que de connectivité pour transposer l'expérience de jeu que nous attendons d'une plate-forme PC à l'univers des téléphones mobiles. Que le jeu commence !



Dernière mise à jour le jeudi 10 avril 2003



Pour en savoir plus
Microsoft réalise une enquête en ligne pour recueillir votre opinion sur le site Web de MSDN. Si vous choisissez d’y participer, cette enquête en ligne vous sera présentée lorsque vous quitterez le site Web de MSDN.

Si vous souhaitez y participer,
Afficher:
© 2014 Microsoft