Discussion :

[Kitsune64]

Bonjour,

J'aurai voulu savoir avant de me mettre à coder un exemple, la différence entre Caméra et Viewport dans un jeu sous SDL2. (Des exemples si possible pour la 2D).

Peut-être que ces illustrations et une vidéo pourrait vous aider à m'expliquer:

Mario Kart: écran splitté


Miracle Warrior: Interface+Carte+Image de background


Scène d'intro de FFVI (voir à partir de 1:27) Mouvement de la caméra ou du Viewport? je ne sais pas bien en fait.

Un petit dernier mais en 3D ici FFVIII: La carte apparait sur la vue 3D. Quel rôle joue le(s) viewport(s) et la/les caméra(s)


Si vous savez me dire combien de caméra et de viewport (possible) pour ces exemples.
Merci pour vos réponses!

[Bousk]

La caméra c'est l'objet qui regarde (position, direction, zoom, ...), le viewport est le truc sur quoi c'est affiché (morceau d'écran).

[Kitsune64]

Donc on associe généralement 1 Viewport par Caméra?
Et si je comprends bien ce que tu dis...J'imagine que pour l'exemple de FFVIII il y a deux viewports qui se superposent, dont 1 à une opacité translucide (pour la carte dans ce cas)?

[LittleWhite]

Bonjour,

Le viewport peut être un morceau de la fenêtre/écran. Je vais sûrement répéter ce que a dit Bousk, car sa réponse est exacte. La caméra permet d'effectuer les transformations afin d'obtenir des coordonnées dans un espace normalisé (entre -1 et 1, en X et Y). Vous pourrez en avoir une explication plus détaillée dans ce tutoriel, mais en bref, cela veut dire la chose suivante :

• la caméra permet de définir une vue dans le monde virtuel. Autrement dit, c'est un point dans l'espace (position), qui regarde dans une direction (view) avec une certaine ouverture/zoom. Avec cette caractérisation, on peut transformer les points (les polygones) du monde virtuel (pouvant être en 3D, ou en 2D) dans un espace normalisé (qui est en 2D), tout en prenant en compte des déformations comme celle lié à la perspective (la profondeur). Si on déplace la caméra, les polygones se déplacent dans l'espace normalisé. Si on change la direction, les polygones "se déplacent" aussi. C'est pour ça que la caméra est utile, car cela permet de simuler... ce qui se passe avec une vraie caméra/appareil photo qui retranscrit une image sur une pellicule.
  Toutefois, la caméra n'est absolument pas obligatoire. On peut très bien imaginer faire un programme/jeu qui placent les polygones directement dans l'espace normalisé (on afficherait un sprite à la position (-0.6, 0.786)). Mais après, si on veut déplacer le sprite (ou scroller la vue), il faut déplacer tous les polygones pour que ça marche .
• une fois que nous avons nos polygones en espace normalisé, on va vouloir les afficher sur un écran (l'écran de notre PC/console). Cet écran, c'est un tableau de pixel, allant de 0 à 1920. Donc, nos polygones dans l'espace (-1, 1), il faut encore les transformé afin d'allumer les bons pixels. La transformation est beaucoup plus simple (une addition, une multiplication).
• ici, j'ai parlé d'afficher directement sur l'intégralité de l'écran (0 à 1920), mais rien n'empêche de définir un viewport plus petit, ou plus grand, permettant ainsi de faire le rendu dans une zone réduite ou plus grande. Cela n'impacte que la transformation a effectué. Du coup, on peut avoir plusieurs viewports, pour couvrir plusieurs zones de l'écran et ainsi de suite. On peut même utiliser une même caméra et faire un rendu dans plusieurs viewports.
  
• Note : en mathématiques, il existe un outil ultra surpuissant pour les transformations (changement d'espace de coordonnées) : les matrices

Pour vos exemples, c'est légèrement plus compliqué de donner la réponse exacte. En effet, la console en question n'avait pas une puissance illimitée et, par conséquent, on évite tous les calculs qui ne servent à rien. Aussi, la destination (la résolution de l'écran) est toujours la même. Par conséquent, on peut faire des simplifications et, notamment, ne pas utiliser de viewport, ou de caméra en tant que tel. Notamment, on peut directement indiquer le placement des sprites avec leur position à l'écran (et ne faire aucune transformation (pas de caméra, pas de viewport)). C'est rapide, mais cela ne marche que pour une résolution de sortie unique, non redimensionnable
FFVIII fonctionne sur une machine plus puissante (et encore, la PS1 et son absence de nombre flottant ). Celui-ci a bien une caméra (pour le rendu 3D, car c'est bien plus facile ainsi). Pour la minicarte, on peut imaginer un viewport, mais j'en doute, car autant afficher les éléments là où il faut (et pas besoin d'effectuer un rendu dans une résolution plus grande ou plus petite que ce qui sera sur l'écran à la fin). Mais en effet, on va afficher le monde 3D en premier, puis la minicarte avec un peu de transparence, par la suite. En réalité, on ne peut pas faire dans l'autre sens .

[Kitsune64]

Merci pour les explications, elles se rejoignent effectivement. Je n'ai pas vu auparavant de tutoriaux concernant le terme "espace normalisé" mais j'imagine que c'est un concepte + souvent abordé pour des environnements en 3D.

Je ne fais que de la 2D, je me demande donc si c'est vraiment utile cette distinction entre viewport et caméra pour l'instant dans les petits projets que je peux élaborer...D'après ce que vous écrivez vers la fin de votre réponse on peut s'en passer pour gagner en temps de calculs si on reste sur des résolutions prédéfinies. Mais je pense en ayant lu votre réponse que certains jeux 2D on des fois des effets de Zoom ou (Dé)zoom et dans ce cas je me dis que ces conceptes de caméra associée à un viewport me semble nécessaire mais je me trompe peux être...

...Pour illustrer ce que je viens d'écrire je prends cet exemple d'effet. Au moment 0:23 de la vidéo, il y a un effet de zoom et dézoom avant d'arriver dans un combat. Je ne vois pas bien comment programmer ce genre d'effet sans utiliser un champ de caméra.

Aussi non je pense avoir compris la distinction entre les deux termes, merci à vous.

[LittleWhite]

Pour les zooms/dézoome, il n'y a pas besoin de viewport. Le besoin de caméra est principalement utile en 3D, notamment à cause de la déformation liée à la perspective. Mais en 2D, comme je l'ai dit, c'est moins utile. Un zoom/dézoome, c'est juste un déplacement des points des sprites. Dans ce cas là, il faut des routines d'affichage de sprite permettant d'afficher le sprite sur une zone plus grande ou plus petite que la taille du sprite. Cela peut se faire avec des calculs de base (grossissement * 2, c'est afficher deux fois les mêmes pixels). Dans la SNES, ce n'était pas une caméra, juste ils avaient des routines optimisées pour afficher et redimensionner les sprites (et même déformer les sprites à l'afficher (Mode 7)).