Motif commun pour mettre à l'échelle les «unités réelles» en pixels?

Il s'agit d'une question complémentaire à celle-ci .

Je voudrais savoir s'il existe un motif commun / typique / meilleur pour mettre à l'échelle ma représentation du monde (actuellement 160Kmx160Km) pour l'adapter à la zone de dessin (actuellement 800x600 pixels).

Je peux penser à au moins quatre approches différentes:

Un naïf (comme je l'ai fait jusqu'à présent). J'ai implémenté une fonction globale sc(vector)qui retournera simplement une copie réduite du vecteur transmis. Cela fonctionne bien sûr, mais m'oblige à écrire du code comme:

drawCircle(sc(radius), sc(position))

Fonctions d'emballage . Je pourrais définir plusieurs fonctions, chacune d'elles enveloppant celle du middleware d'origine. Par exemple, je pourrais définir myDrawCirclequi mettrait d'abord à l'échelle les arguments qui ont besoin d'être mis à l'échelle, puis appeler drawCircleavec ce dernier. Cela rendrait mon code peut-être plus lisible et plus facile à maintenir, mais je devrais écrire beaucoup de fonctions de wrapping, qui semblent idiotes.

Décorateur de fonction . Je pourrais simplement décorer les fonctions middleware existantes, fournissant une mise à l'échelle automatique pour tous les paramètres qui sont une instanciation de la classe Vector3D, mais le problème est que ces fonctions fonctionnent également avec les mêmes paramètres étant listou Vector2Daussi, et le décorateur n'aurait aucun moyen de savoir quelles listes doivent être mises à l'échelle (le rayon par exemple) et lesquelles non (les valeurs RVB).

Initialisation de surface . Lors de la définition de la surface sur laquelle je vais dessiner, je pourrais définir le facteur d'échelle (de sorte que j'utiliserais alors des mètres et non des pixels comme paramètres). Cela fonctionnerait de manière transparente pour moi et serait ma solution de choix, mais bien sûr, elle devrait être implémentée dans le middleware, donc ce n'est pas une vraie option.

... de toute façon: comme il s'agit d'un problème très courant, je me demande s'il existe un modèle établi qui résout avec élégance ce problème que je n'ai pas trouvé.

PS: Pour ce projet, j'utilise python (avec pygame ), mais - bien qu'une réponse spécifique à python / pygame soit très appréciée, je suis plus intéressé par la description générale / de haut niveau du modèle plutôt que par sa mise en œuvre concrète.

Merci d'avance pour votre temps et votre expertise.

La manière standard de procéder consiste à configurer une matrice de transformation pour effectuer la conversion pendant le rendu. Pour le rendu 3D, c'est la matrice de transformation de la vue pour la caméra qui le fait.

La plupart des API 2D ont également un moyen de spécifier une transformation de vue, en tant que matrice 2x3 ou en tant qu'échelle, translation et rotation distinctes.

Un rapide coup d'œil à la documentation de Pygame suggère que vous devrez implémenter vous-même une matrice de transformation de vue. Cela vous permet-il de dériver votre propre classe de sa classe de surface pour vous permettre d'ajouter cette fonctionnalité?

comme il s'agit d'un problème très courant, je me demande s'il existe un modèle établi qui résout avec élégance ce problème que je n'ai pas trouvé.

Habituellement, les gens n'essaient pas d'effectuer une mise à l'échelle au moment de l'exécution dans les jeux 2D. Je ne suis pas d'accord pour dire que c'est un problème courant. Si les gens veulent une mini-carte ou un autre redimensionnement fixe, il y a souvent un nouvel ensemble de graphiques fait à cet effet. Il est rare que vous ayez besoin d'une seule routine pour exécuter à 2 niveaux de zoom différents dans un jeu 2D.

Si vous utilisez une API 3D, vous pouvez obtenir cette fonctionnalité gratuitement - il suffit de modifier les paramètres de la caméra / fenêtre.

PyGame est une très ancienne API et, malheureusement, n'est vraiment adaptée à la 2D. Même si vous pouviez mettre au point des systèmes de mise à l'échelle adéquats pour les différents niveaux de zoom, les performances ne seront pas assez bonnes et l'apparence sera probablement inacceptable.

Je conseillerais que si vous voulez beaucoup zoomer et dézoomer, vous passez à une API 3D moderne dès que possible. Je recommanderais pyglet mais il y en aura probablement d'autres aussi.