Quel système de coordonnées utiliser pour gérer l'interface utilisateur 2D?

Suite à la question des ratios d'aspect , je suis intéressé d'entendre ce que les autres utilisent lorsqu'ils travaillent sur des systèmes d'interface utilisateur 2D (probablement leurs propres solutions maison). Plus précisément, comment gérez-vous les systèmes de coordonnées. À mon avis, il existe trois options:

1. Coordonnées codées en dur (par exemple: 0 -> 720, 0 -> 576)
2. Coordonnées normalisées (0,0 -> 1,0, 0,0 -> 1,0), mappées en coordonnées réelles avant le rendu
3. Coordonnées virtuelles (par exemple: 0 -> 1600, 0 -> 1000), mappées en coordonnées réelles avant le rendu

Le codage en dur n'est évidemment utile que si vous êtes sur une plate-forme fixe et que vous savez à l'avance quelles sont les coordonnées de votre espace d'écran, ou si vous êtes prêt à créer des dispositions d'écran pour chaque ensemble possible de dimensions d'écran.

Les coordonnées normalisées sont agréables, mais souffrent d'ambiguïté lorsque le rapport d'aspect de l'écran n'est pas fixe (par exemple, 0,75 correspond à une coordonnée physique différente lors de l'exécution en écran large qu'en 4: 3). De plus, pour les auteurs, il est vraiment contre-intuitif de déclarer un élément d'interface utilisateur comme étant (0,2 x 0,2), seulement pour constater qu'il n'est pas réellement carré lors du rendu.

Les coordonnées virtuelles ne sont pas ambiguës, mais souffrent des mêmes problèmes que les coordonnées normalisées au stade du remappage: une minuscule différence décimale peut entraîner des erreurs de coupure, ce qui signifie que les éléments d'interface utilisateur qui devraient carreler ont maintenant une couture entre eux.

De même, lorsque vous avez un écran à résolution fixe, les coordonnées normalisées et virtuelles signifient qu'il est très difficile de garantir un mappage 1: 1 entre les pixels finement conçus de votre artiste dans l'image de l'interface utilisateur et les pixels à l'écran, ce qui signifie que vous courez le risque de artefacts de mise à l'échelle désagréables (en supposant que vous effectuez un rendu sous forme de quadrillage texturé à l'écran).

Nous avons opté pour l'approche des coordonnées virtuelles, en particulier pour éviter toute ambiguïté sur les proportions. Ainsi, lors du rendu sur un écran 16:10, l'espace d'interface utilisateur est (0,0) -> (1600,1000), mais lors du rendu en 4: 3, l'espace d'interface utilisateur utilisable est en fait (133,0) -> (1467 , 0).

Y a-t-il de meilleures solutions que je ne connais pas? Existe-t-il de bonnes stratégies pour minimiser les problèmes rencontrés par ces 3 approches?

Je pense que je suis d'accord que les coordonnées normalisées ne correspondent pas vraiment bien aux choses de l'interface utilisateur.

Ce que je fais généralement pour les dispositions 2D, c'est essentiellement votre espace de coordonnées "virtuel", mais je choisis un espace qui correspond à 1: 1 avec ma résolution cible préférée (1280x720, par exemple). Ce n'est pas fixe, mais c'est intuitif à gérer et je sais que dans 90% des cas, cela aura l'air parfait. Évidemment, il est important de ne pas faire preuve de complaisance et de vérifier souvent les différentes résolutions.

Pour plus de netteté lors du remappage des résolutions, j'emprunterais quelques conseils de rendu de police et fournirais des informations sur les indices. Assurez-vous donc que les éléments qui doivent être continus sont étiquetés d'une manière ou d'une autre, tout en effectuant un arrondi aux pixels exacts où un alignement net est nécessaire.

Peut-être aussi envisager de rendre les choses plus relatives. Ainsi, au lieu que tout soit "positionner l'objet 1 à X, Y" absolu, vous pouvez spécifier "positionner en bas à gauche de l'objet 2 à un certain décalage par rapport à la partie inférieure droite de l'objet 1". Il est alors plus facile de redimensionner et / ou de déplacer des éléments sans perdre de relations importantes.

Le système de coordonnées de CEGUI semble vraiment bien pensé. Son système de coordonnées unifié mélange le positionnement absolu avec le positionnement relatif. Vous pouvez spécifier des emplacements comme:

• au milieu de l'écran
  UDim(0.5,0)
• cinq pixels à gauche du bord droit
  UDim(1.0,-5)
• deux widgets au milieu mais séparés de 10 pixels
  HA_RIGHT,UDim(0.5,-5) HA_LEFT,UDim(0.5,5)

En cas de doute, pourquoi ne pas opter pour le modèle CSS box, ou une simplification de celui-ci?

Vous pouvez spécifier des positions en pourcentages ou en pixels. Vous pouvez positionner des conteneurs avec des pourcentages mais positionner les éléments à l'intérieur en pixels, par exemple.

J'aime utiliser des coordonnées virtuelles, mais basées sur une résolution cible commune (de préférence l'une des résolutions les plus élevées auxquelles vous vous attendez à ce que le jeu s'exécute).

De nos jours, un bon choix peut être 1920x1080.

Toutes les illustrations et maquettes d'écran peuvent être créées à cette résolution, ce qui facilite la mesure des positions / distances en pixels.

Si vous utilisez un rapport d'aspect différent des coordonnées virtuelles, vous pouvez choisir comment l'adapter à l'écran (letterboxing, recadrer les côtés ou un peu des deux)

Lors du codage, je trouve que «penser en pixels» est beaucoup plus facile que de penser en coordonnées normalisées! - Je veux que le texte ait «50 pixels (virtuels) de hauteur» plutôt que «0,0463 unités de haut»

Cela dépend totalement du type d'interface graphique que vous avez, mais souvent les jeux ont des éléments ancrés le long des bords de l'écran et dans les coins, puis ils peuvent avoir une boîte au milieu de l'écran pour une boîte de dialogue modale ou quelque chose.

Si c'est le cas pour vous, puis-je suggérer d'utiliser un schéma dans lequel vous spécifiez une ancre et un décalage (x, y)? Ce serait similaire à BorderLayout de Java (mais peut-être avec les quatre coins, quatre milieux d'arêtes et un centre d'écran). Ainsi, par exemple, vous pouvez spécifier un décalage de (0,0) à partir du coin supérieur gauche; alors l'élément serait ancré exactement dans le coin de l'écran. Et puis, peu importe la résolution, le rapport hauteur / largeur, etc., vous auriez l'indicateur de santé dans le coin de l'écran. Mais ensuite, si vous ancrez un élément dans le coin supérieur droit, l'élément serait naturellement ancré par rapport à son point supérieur droit (au lieu du coin supérieur gauche), donc encore une fois, il serait automatiquement ancré au coin de l'écran, quelle que soit la résolution.

Je recommande vraiment contre les coordonnées normalisées 0,0-1,0; ceux-ci peuvent varier en fonction de la précision en virgule flottante. Les interfaces graphiques doivent être mappées en pixels, sauf si vous disposez d'une interface graphique 3D.

Cela dépend beaucoup du type de jeu et de la situation. Pour les prototypes rapides et sales, je préfère planifier l'interface utilisateur sur du papier millimétré, écrire une liste de coordonnées numériques pour une taille de fenêtre fixe et tout coder en dur - c'est plus facile et plus rapide pour moi. Mais pour un "vrai" projet où vous voudriez des fenêtres redimensionnables ou des résolutions d'écran alternatives, ce ne serait évidemment pas idéal, et une sorte de solution qui permet une mise à l'échelle dans les deux directions serait mieux.