Programmation Orientée Jeux

Les yeux permettrons au Moteur d'afficher ce qu'il a en mémoire, après traitement, et de gérer différents modes d'affichages.

1) Affichage

Cette partie concerne la communication avec l'écran (screen device). C'est en quelque sorte le lieu où seront rendus les éléments graphiques, parmi lesquels on y trouve les éléments vus précédemment, tels que les Images, les Sprites... Pour simplifier les choses, on restera dans un environnement mono-écran.

Attention à ne pas confondre Carte Graphique (GPU) et Écran (d'un point de vu de la programmation). En effet, il est 'possible' d'afficher une ressource à l'écran sans réellement utiliser la carte graphique (via la RAM). Et il est aussi 'possible' d'envoyer une image à la carte graphique sans pour autant la voir. De plus, au niveau de la synchronisation (frame rate), ce n'est pas du tout le même monde. L'écran, généralement, possède une fréquence de 60Hz (ce qui équivaut à 60i/sec). Pourtant, il est possible d'avoir un programme qui délivre plus d'images apparentes...

Nous allons voir deux notions importantes dans les méthode de rendu d'un jeu: le mode Fenêtré / Plein écran, et le mode Plein écran exclusif.

2) Mode Fenêtré / Plein écran

Ce mode d'affichage est probablement l'un des plus courant, surtout le mode Fenêtré, mais pas vraiment pour les jeux (sauf depuis l'apparition des mini-jeux). On le retrouve dans notre Système d'Exploitation pour tout ce qui est l'affichage des 'Fenêtres' justement, ou pour tout les programmes utilitaires (IDE, Dessins, ...). Dans ce type d'affichage, le rendu n'est pas synchronisé sur l'écran (Syncro Verticale, VSync). En effet, les données envoyées à la carte graphique, sur l'écran, ne sont pas synchronisées. Il n'y a pas d'attente de fin de rendu avant de commencer un nouveau rendu (c'est ce qui entraine parfois, surtout lors de défilements, comme dans les jeux, une sorte de décalage):

Ce problème n'est pas propre au mode Fenêtré, mais aussi au mode Plein écran. Cela vient surtout du fait que dans ces modes là, c'est le Système d'exploitation qui gère le fenêtrage (lui même s'affichant sur une fenêtre). Le rendu n'est donc pas pur, et peut faire abstraction des capacités matérielles de la carte graphique.

En revanche, ce type d'affichage est plus souple, puisqu'il est géré de manière interne, et il est possible d'afficher un plus grand nombre d'image par seconde. Mais il existe un autre mode d'affichage, permettant de faire abstraction du système de fenêtrage, et ainsi profiter pleinement des capacités graphiques.

3) Mode Plein écran exclusif

Dans ce mode, on communiquera directement avec le matériel graphique (GPU), évitant ainsi toutes interférence avec le rendu du Système d'exploitation. D'ailleurs, il est facilement remarquable (surtout sur un écran CRT, moins sur un LCD qui est plus discret) que le changement de résolution ne soit pas aussi rapide que dans les modes précédents (sur un CRT on peut même entendre une sorte de 'clac' au changement de résolution). Sur un écran en 1280*960, une résolution de 640*480 en Plein écran exclusif ne sera pas identique à une résolution de 640*480 en fenêtré plein écran; dans le premier cas, on peut voir que les pixels sont beaucoup plus nettes, tandis que dans le second mode, il y a un léger lissage naturel (très visible sur un vieux jeu qui est déjà pixelisé à la base).

Il faut savoir qu'en plein écran exclusif, le rendu des images est continu (contrairement à une fenêtre, ou il peut être être ponctuel; cf. programmation évènementielle). De plus, il n'y a pas de problème lié à la syncro verticale, les images étant directement envoyées à la carte graphique; mais cela implique que le frame rate est verrouillé sur la fréquence de l'écran. Un écran à 60Hz rendra 60i/sec exactement (donc bien plus précis que la méthode vue précédemment, avec les 16.66666667ms d'attente pour simuler ce frame rate). Par contre, si le programme venait à ralentir, il affichera moins de 60i/sec tout de même... pas de magie ! (mais l'extrapolation est toujours utilisable)

Nous allons voir maintenant différentes approches pour afficher notre résultat à l'écran.

4) Double Buffering

Le Double Buffering est une technique visant à uniformiser le rendu graphique, et aussi à l'accélérer. Avant (bien que cela existe toujours), on affichait à l'écran directement, de manière séquentielle, sans préparer le rendu global (un peu comme la peinture sur un tableau, qui se colore progressivement). Maintenant (ce n'est pas nouveau non plus...) on utilise de manière plus courante le Double Buffering, à savoir que le rendu est d'abord préparé avant d'être rendu (on va d'abord peindre le tableau en entier avant de le montrer).

En plus d'avoir un rendu uniforme (et non progressif), le traitement est plus rapide, puisqu'il est fait en mémoire et non sur l'écran. Cela permet entre autre d'éviter des rendus comme celui-ci:

Le rendu dans de buffer se passera comme pour le rendu de l'écran, à la seule différence qu'il faudra écrire dans le buffer et non directement sur l'écran. Lorsque le rendu est terminé, on envoie le buffer sur l'écran (un seul rendu finalement). Il existe une autre approche plus ou moins équivalente au Double Buffering (moins spécifique). Nous allons voir la notion de Back Buffer.

5) Page Flipping / Back Buffer

Précédemment, nous avons vu qu'il était possible de préparer le rendu dans un buffer, et de passer le buffer complet à l'écran. Nous allons voir comment généraliser ce procédé, ce qui permettra de travailler avec plus d'un buffer. Voyez plutôt la source graphique comme une adresse, sur laquelle va pointer l'écran (tout comme pour une variable, ayant une adresse et un contenu). Pendant que l'on écrit dans un buffer, on fait pointer l'écran sur un autre buffer qui a terminé le rendu. Lorsque l'on a terminé d'écrire sur ce buffer, on fait pointer l'écran sur le dernier buffer prêt, ainsi, le précédant devient alors accessible pour un remplissage en fond (Back Buffer), et ainsi de suite. Ce changement s'appelle le Page Flipping, qui n'est autre qu'un changement d'adresse de source graphique, affichable à l'écran.

En procédant de la sorte, on peut aisément utiliser un Triple Buffer (qui est un Double Buffer amélioré, puisqu'il réduit le temps d'attente entre le moment ou l'on passe le buffer à l'écran, et le moment ou le buffer devient prêt), afin d'améliorer les performances du rendu, toujours dans un soucis de fluidité et de fidélité. Pour aller plus loin, il existe le Quad Buffering, qui permet l'utilisation de buffers pour la Stéréoscopie. En fait c'est deux Double Buffer; un pour chaque oeil (deux rendus traités en même temps, pour un effet 3D).

Mais où se trouve ces buffers ?

6) RAM vs VRAM

Un buffer est une zone mémoire, qui est sensé avoir un accès rapide (pas sur un disque dur par exemple...). On pense donc tout de suite à la RAM (Random-Access Memory) qui semble être le candidat idéal pour y mettre les buffers. Pas de chance, il en existe un autre; là encore ce n'est pas nouveau, mais ca reste assez récent tout de même. Il s'agit ni plus ni moins de la VRAM (Video Random-Access Memory), l'équivalent de la RAM... en beaucoup plus rapide, car directement située sur la carte graphique(proche du chip). Cette mémoire présente un énorme inconvénient: sa fiabilité. En effet, la VRAM est constamment en mouvement (et généralement possède une capacité plus limitée que la RAM), ce qui rend son contenu instable. On parle alors de mémoire volatile. Très efficace pour un rendu direct, mais à manipuler avec précaution pour toute modification comme on ferait sur la RAM. Il faut, avant chaque opération, vérifier que le contenu n'est pas perdu; si il ne l'est pas, alors tout se passe bien, sinon, il faut recharger la ressource ! Bien utilisé, les performances sont normalement au rendez-vous. C'est donc un point d'entré intéressant pour les grosses optimisations.

7) Conclusion

Nous avons qu'il existait plusieurs méthodes pour afficher quelque chose à l'écran, et plusieurs optimisations pour améliorer le rendu et la vitesse de traitement. Le mode Fenêtré / Plein écran (autrement dit Window / Full-Window) qui sont en partie gérés par le système d'exploitation (Software), et non le matériel (Hardware); le mode Plein écran exclusif (autrement dit Full-Screen), qui permet de communiquer directement avec la partie Hardware, et différentes techniques de préparation du rendu (Buffers), ainsi que deux type de mémoires pour le traitement des ressources graphiques, la RAM et la VRAM.

Lire la suite: Moteur de jeu - Les Oreilles