[Index Software] Coin des développeurs :]

[Bubu]

Bonjour, en Licence on a eu des cours de dev où le prof nous montrait comment transformer un programme récursif en programme linéaire en utilisant une pile.
On remplace la pile d'appels de méthodes récursives par une pile de donnés.
Le problème, c'est que j'ai oublié, je ne sais plus comment on fait.
Quelqu'un aurait des conseils ou un lien vers un article qui en parle ?

(J'ai besoin d'implémenter le negamax sans récursivité)

[Tugdual]

À vue de nez : tu crées une structure correspondant à l'ensemble de tes variables locales, tu instancies un tableau de ces structures, et tu ajoutes en paramètre de ta fonction un index sur l'élément courant du tableau (et l'adresse du tableau et la taille maxi de ce tableau, si tu le fais sans classe).

[user6375]

Je n'avais pas vu ce message plus tôt, mais j'y répond maintenant.

Je ne suis pas sûr d'avoir bien cerné ton problème de taille de skybox

En fait c'est très simple : comment afficher à la taille réelle le système solaire avec une résolution au millimètre, en sachant que le moteur 3D de Unity ne gère pas plus de 7 digit pour les flottants ?

Seule solution, passer par des skybox qui gère les mises à l’échelle pour que, dans l’échelle relative, je n'ai pas besoin de plus de 7 digit par flottant pour dimensionner, positionner et déplacer mes objets.

problème 1 : à l’échelle 1u=1m, il m'est tout simplement impossible d'afficher une planète (valeur max 9'999'999m=9'999km, trop peu pour la Terre).
problème 2 : à l’échelle 10km, la résolution max est de l'ordre du mètre, ce qui n'est pas jouable pour simuler l'arrimage d'un vaisseau a une station (les mouvements doivent être inférieur au mètre pour avoir un affichage fluide). Mais cette echelle permet d'afficher une planète (1240u pour la Terre)
problème 3 : à l'echelle 1u=1 millions de km, il est impossible d'avoir un une résolution inférieur à 100km ... je vous explique pas les bonds que ferait un vaisseau se déplaçant a cette échelle ... mais ça permet de positionner les planètes a leur position réelle dans le système solaire (enfin jusqu'a Neptune, après c'est trop loin, j'aurais besoin d'un digit supplémentaire. Mais Neptune ça me suffit, pas besoin de Pluton )

En d'autre terme, j'ai besoin d'un système de skybox imbriquée qui me permet de stocker les coordonnées 3D des objets sous la forme 123,4567 et ce que ce soit à l’échelle 1u=1 millions de Km, 1u=10km et 1u=1.

Cela me permet d'avoir de petits objets 3D qui représentent les planètes à l’échelle du système solaire. D'avoir de gros objets 3D planète à l’échelle 10km (a cette échelle, la Terre fait 1240u = 12400km), et d'avoir des objets de taille réelle à l’échelle 1u=1m (ISS fait 400u a cette échelle). Et comme je gère tout ca sous forme de skybox, j'ai plus qu'a jouer sur les couches d'affichage pour gérer ce qui est affiché par chaque caméra.

Ça marche plutôt bien comme solution.

[Bubu]

À vue de nez : tu crées une structure correspondant à l'ensemble de tes variables locales, tu instancies un tableau de ces structures, et tu ajoutes en paramètre de ta fonction un index sur l'élément courant du tableau (et l'adresse du tableau et la taille maxi de ce tableau, si tu le fais sans classe).

Bonne idée.
C'est dérivé du Puissance 4.
Mais pour un coup on n'a besoin que d'une seule chose, la colonne dans laquelle le joueur à mis son jeton.
Quand on revient en arrière dans l'arborescence, on enlève le jeton.
Comme ça on n'a pas besoin de stocker toute la grille pour chaque possibilité.
Un simple entier suffit. Car le problème, c'est la mémoire. Stocker les grilles intermédiaires couteraient une blinde en performances.
Or j'ai besoin d'aller jusqu'à 8 en profondeur. (4 coups chacun). Et quasi instantané.
Je compte utiliser plusieurs threads pour diviser la durée de calcul de l'AI, et de stocker dans une pile juste la colonne jouée, plutôt qu'une méthode récursive et son contexte.
Merci

[Bubu]

Je n'avais pas vu ce message plus tôt, mais j'y répond maintenant.

Je ne suis pas sûr d'avoir bien cerné ton problème de taille de skybox

En fait c'est très simple : comment afficher à la taille réelle le système solaire avec une résolution au millimètre, en sachant que le moteur 3D de Unity ne gère pas plus de 7 digit pour les flottants ?

Seule solution, passer par des skybox qui gère les mises à l’échelle pour que, dans l’échelle relative, je n'ai pas besoin de plus de 7 digit par flottant pour dimensionner, positionner et déplacer mes objets.

problème 1 : à l’échelle 1u=1m, il m'est tout simplement impossible d'afficher une planète (valeur max 9'999'999m=9'999km, trop peu pour la Terre).
problème 2 : à l’échelle 10km, la résolution max est de l'ordre du mètre, ce qui n'est pas jouable pour simuler l'arrimage d'un vaisseau a une station (les mouvements doivent être inférieur au mètre pour avoir un affichage fluide). Mais cette echelle permet d'afficher une planète (1240u pour la Terre)
problème 3 : à l'echelle 1u=1 millions de km, il est impossible d'avoir un une résolution inférieur à 100km ... je vous explique pas les bonds que ferait un vaisseau se déplaçant a cette échelle ... mais ça permet de positionner les planètes a leur position réelle dans le système solaire (enfin jusqu'a Neptune, après c'est trop loin, j'aurais besoin d'un digit supplémentaire. Mais Neptune ça me suffit, pas besoin de Pluton )

En d'autre terme, j'ai besoin d'un système de skybox imbriquée qui me permet de stocker les coordonnées 3D des objets sous la forme 123,4567 et ce que ce soit à l’échelle 1u=1 millions de Km, 1u=10km et 1u=1.

Cela me permet d'avoir de petits objets 3D qui représentent les planètes à l’échelle du système solaire. D'avoir de gros objets 3D planète à l’échelle 10km (a cette échelle, la Terre fait 1240u = 12400km), et d'avoir des objets de taille réelle à l’échelle 1u=1m (ISS fait 400u a cette échelle). Et comme je gère tout ca sous forme de skybox, j'ai plus qu'a jouer sur les couches d'affichage pour gérer ce qui est affiché par chaque caméra.

Ça marche plutôt bien comme solution.

Bien sur, bonjour.
Si tu cherches à afficher des constellations, une skybox ne suffira jamais. Sauf pour le fond.
Si tu cherches à afficher des planètes, des étoiles mouvantes, il faut les gérer en 3D.
Le billboarding suffirait sans doute au niveau affichage.

Je ne connais pas Unity, mais y a il moyen de créer ses propres shaders ?
Car en plus d'afficher tes planètes toujours parallèlles à l'écran (le billborading est parfait pour afficher des formes sphériques), il est indispensable qu'elles soient affichées à la profondeur maximale.
Pour cela il faut coder le vertex shader et le pixel shader.
D'où ma question à propos d'Unity.

[Nibelheim]

Bonjour à tous,

En tant que développeur professionnel je souhaitais me présenter sur ce fil. C’est que tout comme vous il s’agit de ma passion principale depuis longtemps.
Je reprends donc la suggestion de présentation pour constituer mon emballage :

- je suis donc dev pro (ingénieur en info et maths appliquées)

- depuis que j’ai une calculatrice programmable. J’ai toujours été attiré par les machines et leur puissance. C’est de l’ordre de la fascination. Avec le recul je pense qu’on peut parler d’intérêt spécial.
J’ai démarré avec le BASIC puis le Turbo Pascal. Un poil d’asm x86, puis du Delphi. C’était au lycée. J’ai appris le C alors que j’étais en prépa, en me documentant en fond sur le fonctionnement des machines.
Je n’ai jamais supporté d’utiliser une boîte noire et de dire « je veux juste que ça marche ». Non ! J’ai « besoin » de comprendre. Gamin je souhaitais comprendre le fonctionnement de la tv, de la voiture, du frigo etc. Ces machines ne tombent pas du ciel, nous les avons conçues. Aussi ne pas chercher à comprendre comment elles fonctionnent me semble « grave ». Parfois je me dis qu’une catastrophe et bim, c’est le retour au moyen âge.
Pour cette raison j’ai une attirance particulière pour l’informatique bas niveau et l’embarqué, où compréhension et maîtrise sont nécessaires.
J’ai logiquement fait une école d’informatique.
Le seul langage pour lequel j’ose prétendre à la maîtrise est le C. Le bash également. Je connais le C++ que je n’aime pas beaucoup (ticket d’entrée élevé, du coup le code produit en entreprise est souvent une horreur), l’assembleur ARM (sur Cortex-M).

- ce que je préfère c’est le code vraiment informatique, pas métier. Je me moque complètement de coder pour une machine à laver ou un avion. Je ne suis absolument pas passionné par ces domaines. Ce qui me stimule c’est de devoir concilier performance, sécurité, maintenabilité. D’avoir des problèmes intéressants à résoudre. J’ai tout de même une appétence certaine pour le bas niveau, le code en interaction avec le matériel. En gros je n’aime pas trop le web et n’y connais rien, je suis plutôt « os », « driver », temps réel et algorithmique, et code applicatif « critique ». Tout ça de préférence en C.
Mon « fantasme » c’est le code efficace et beau, à ce sujet je pense au personnage de l’animé BPS (Battle Programmer Shirase, c’est marrant). Une sorte d’idéal à atteindre.

- J’ai travaillé sur de l’existant de taille conséquente. « Moteur de recherche » de billets d’avion pour Amadeus. A l’époque c’était du C, bourré d’algos, de structures de données recherchées, d’optimisations et autres heuristiques. J’ai adoré excepté le côté métier justement qui me rebutait mais était incontournable (qq règles du monde aérien a connaître). J’ai aussi fait du petit, firmware pour terminal de paiement. Enfin pas si petit une fois qu’on commence à y mettre de la sécurité, des capacités de mise à jour, etc.

Mon temps libre est réduit à 0 depuis plusieurs années, le dev loisir et la veille techno me manquent.
Je suis abonné à la revue Hackable, j’adore les articles de M. Denis Bodor, je trouve que c’est un régal à chaque fois (bien écrit et niveau technique au rdv tout en restant accessible pour les amateurs). J’espère que ne pas trop déborder en parlant de ça. Pour équilibrer il y a d’autres revues bien sûr, comme Linux Magazine qui est plus généraliste.

Mon projet du moment : apprendre le Rust. Ce langage me fait rêver depuis plusieurs années, malheureusement je n’ai pas assez de temps pour l’apprendre comme je le voudrais. J’ai acheté un livre que j’aurai bientôt terminé. Mon projet ensuite : m’en servir pour mon autre centre d’interêt majeur, l’IA. Je fantasme sur l’IA dite forte. Avant d’en arriver là j’aimerais déjà faire mumuse avec certaines idées que j’ai en Rust, qui est puissant efficace, sûr et productif (contrairement au C, pas besoin de repartir du sable pour faire un truc).
Si vous n’avez pas entendu parler du Rust et que vous aimez la prog système foncez ! Ce devrait être un digne descendant moderne de C/C++.

[Bubu]

Toute mon enfance, j'ai été pourri par les performances pourries de mes ordis.
Mais copieux hein. Pourri puissance 10.000. Excusez du peu.
Soit on pouvait faire ce que l'on voulait, mais à la vitesse d'un escargot, BASIC.
Soit on programmait en langage machine. Je n'avait encore aucune connaissance en informatique (primaire), donc je n'y arrivais pas.

Et puis 30 ans plus tard, j'ai réalisé que cela avait changé. Oh malheur.
Au niveau graphismes pour notre jeu pour Android, je me suis lâché. J'ai quasiment pu faire tout ce que je voulais.
Programme Java et OpenGL.
Après il y a des salopes et des connards qui vont vous dire : Oui mais Java c'est un langage qui utilise une machine virtuelle, et il n'est pas performant.
Que nenni, je suis surpris d'avoir les mêmes performances sur un smart phone Android programmé en Java, que sur mon Ordi Windows x programmé en C++.

[user6375]

Bien sur, bonjour.
Si tu cherches à afficher des constellations, une skybox ne suffira jamais. Sauf pour le fond.
Si tu cherches à afficher des planètes, des étoiles mouvantes, il faut les gérer en 3D.
Le billboarding suffirait sans doute au niveau affichage.

Bonjour Bubu,

Alors en fait ni l'un ni l'autre. Le concept derrière tout ça c'est Skybox3D, un mix de vos 2 remarques (skybox pour le fond, 3D pour le contenu).

Pas sûr que ça soit très clair mon explication.

Ce n'est pas un planétarium, je ne simule pas les mouvements des astres. Les seuls objets mobiles sont uniquement des "engins" dans le système planétaire (vaisseaux, stations).

En fait le système planétaire est statique, et c'est juste un environnement de jeu dans l'espace, comme l'est la surface d'une planète (un terrain). Et oui c'est bien en 3D. Simplement l’échelle d'un système planétaire dépasse les capacités de base de Unity. Je dois donc le bluffer.

En fait je ne cherche plus comment faire, j'ai réussi à résoudre les derniers détails.
La difficulté réside dans le basculement de l'affichage d'un objet. Il faut substituer le même objet dans une échelle par le même objet dans une autre échelle. Chaque échelle étant gérée comme une skybox 3D indépendante, je joue sur les cameras, les layers et la visibilité de chaque objet selon la distance relative entre l'objet et le joueur.

Loin de l'objet, je l'affiche à l’échelle 1/1000000km
En me rapprochant, je bascule l’affichage de l'objet à l’échelle 1/10km
Et tout proche, je bascule l'affichage de l'objet à l’échelle 1/1m

Si l'objet n'est pas affichable à l’échelle 1/1m, je le laisse afficher dans l’échelle précédente (1/10km).
Dans ce contexte, l'objet à l’échelle 1/10km est un "décors" avec lequel le joueur ne peut pas interagir directement.

Je ne connais pas Unity, mais y a il moyen de créer ses propres shaders ?

De ce que je sais oui il est possible de créer ses propres shaders. Mais ce n'est pas l'approche que j'ai suivi.

J'ai suivi cette approche
http://davenewson.com/posts/2013/unity- ... cales.html

Ca donne qqch comme ca (sans texture, sans fond).
Première image :
Au premier plan un truc qui simule l'ISS à l’échelle 1/1m
Au second plan la Terre à l’échelle 1/10km

Seconde image :
Au premier plan la Terre à l’échelle 1/1000000km
Au second plan le soleil à la même échelle et à la distance correcte.

[user6375]

Bonjour Nibelheim,

Le Turbo Pascal, ca me rappelle des souvenirs d'étudiant

Au plaisir de discuter codage

[Nibelheim]

Toute mon enfance, j'ai été pourri par les performances pourries de mes ordis.
Mais copieux hein. Pourri puissance 10.000. Excusez du peu.
Soit on pouvait faire ce que l'on voulait, mais à la vitesse d'un escargot, BASIC.
Soit on programmait en langage machine. Je n'avait encore aucune connaissance en informatique (primaire), donc je n'y arrivais pas.

Et puis 30 ans plus tard, j'ai réalisé que cela avait changé. Oh malheur.
Au niveau graphismes pour notre jeu pour Android, je me suis lâché. J'ai quasiment pu faire tout ce que je voulais.
Programme Java et OpenGL.
Après il y a des salopes et des connards qui vont vous dire : Oui mais Java c'est un langage qui utilise une machine virtuelle, et il n'est pas performant.
Que nenni, je suis surpris d'avoir les mêmes performances sur un smart phone Android programmé en Java, que sur mon Ordi Windows x programmé en C++.

Désolé si je suis à côté de la plaque, je ne sais pas trop si ton message fait écho au mien. Je ne trouve pas que Java soit mal. Je ne pense pas qu’il faille forcément coder en C pour faire quelque chose de bien.
Je pense que connaître « ce qu’il y a derrière » est important pour écrire du bon code (ça ne fait pas tout !). Après on peut écrire des choses fantastiques en Java. Je donnais simplement mes préférences.
Et chacun peut trouver dans le développement ce qu’il aime. Encore une fois en me présentant j’indiquais mes goûts. On peut aussi adorer le côté Lego (que j’aime aussi) et ne pas vouloir démonter les briques mais les assembler rapidement pour faire de grandes constructions.
J’espère ne pas rentrer dans la catégorie « connard » à tes yeux
Il est vrai aussi c’est certain que l’informatique bas niveau et en général s’est bien ouverte et est nettement plus facile d’accès qu’auparavant.

@propane
Merci ! Oui au plaisir

[Bubu]

Toute mon enfance, j'ai été pourri par les performances pourries de mes ordis.
Mais copieux hein. Pourri puissance 10.000. Excusez du peu.
Soit on pouvait faire ce que l'on voulait, mais à la vitesse d'un escargot, BASIC.
Soit on programmait en langage machine. Je n'avait encore aucune connaissance en informatique (primaire), donc je n'y arrivais pas.

Et puis 30 ans plus tard, j'ai réalisé que cela avait changé. Oh malheur.
Au niveau graphismes pour notre jeu pour Android, je me suis lâché. J'ai quasiment pu faire tout ce que je voulais.
Programme Java et OpenGL.
Après il y a des salopes et des connards qui vont vous dire : Oui mais Java c'est un langage qui utilise une machine virtuelle, et il n'est pas performant.
Que nenni, je suis surpris d'avoir les mêmes performances sur un smart phone Android programmé en Java, que sur mon Ordi Windows x programmé en C++.

Désolé si je suis à côté de la plaque, je ne sais pas trop si ton message fait écho au mien. Je ne trouve pas que Java soit mal. Je ne pense pas qu’il faille forcément coder en C pour faire quelque chose de bien.
Je pense que connaître « ce qu’il y a derrière » est important pour écrire du bon code (ça ne fait pas tout !). Après on peut écrire des choses fantastiques en Java. Je donnais simplement mes préférences.
Et chacun peut trouver dans le développement ce qu’il aime. Encore une fois en me présentant j’indiquais mes goûts. On peut aussi adorer le côté Lego (que j’aime aussi) et ne pas vouloir démonter les briques mais les assembler rapidement pour faire de grandes constructions.
J’espère ne pas rentrer dans la catégorie « connard » à tes yeux
Il est vrai aussi c’est certain que l’informatique bas niveau et en général s’est bien ouverte et est nettement plus facile d’accès qu’auparavant.

@propane
Merci ! Oui au plaisir

Merci pour ton message.
Je voulais dire le contraire. Même maintenant les langages managés qui utilisent une machine virtuelle sont aussi performants que le C ou le C++.
Et c'est sympa d'avoir un garbage collector qui fait tout le sal boulot pour nous !

[Nibelheim]

Merci pour ton message.
Je voulais dire le contraire. Même maintenant les langages managés qui utilisent une machine virtuelle sont aussi performants que le C ou le C++.
Et c'est sympa d'avoir un garbage collector qui fait tout le sal boulot pour nous !

Oui c’est vrai.
En parlant de ça en Rust justement point de libération des ressources explicitement à la main (type free ou delete) mais point de GC non plus. La mémoire est libérée quand le propriétaire d’une ressource est lui-même détruit (par ex variable qui sort du scope). C’est transitif.
La notion de propriétaire est essentielle dans ce langage. C’est sa principale contribution/avancée et ça permet au compilateur de vérifier tout un tas de choses. Le langage est type safe quand bien même il est compilé et orienté système, et laisse la maîtrise de ce qui se passe au programmeur.
Il faut dire qu’à notre époque compiler n’a plus du tout le même coût. Il est logique ainsi que des vérifications soient transférées à la charge du compilateur et que des langages plus « puissants » émergent. On peut se permettre des compilateurs très élaborés je veux dire.

[user6375]

Pour Bubu, et ceux que cela peut intéresser, voici ce que ça donne avec un peu plus de graphisme, dans un jeu de vol spatial.

Le cylindre rouge est a l’échelle 1:1m et fait 400m de haut et 400m de diamètre. Il est à une distance d'environ 1,2km. C'est l'objet avec lequel, en principe, va interagir le joueur.
Au second plan Vénus à l’échelle 1:10km avec la texture de son atmosphère, en 8k. Elle est à une distance d'environ 11000km.
Au fond le Soleil en 3D, à l’échelle 1:1 millions de km. Avec texture et effets visuel. Il est à 108,2 millions de km.
Et en fond une skybox avec les images de la Voie Lactée

La seconde image montre ce que voit la caméra de la Skybox 1:10km pour Vénus.

[rauw]

Toute mon enfance, j'ai été pourri par les performances pourries de mes ordis.
Mais copieux hein. Pourri puissance 10.000. Excusez du peu.
Soit on pouvait faire ce que l'on voulait, mais à la vitesse d'un escargot, BASIC.
Soit on programmait en langage machine. Je n'avait encore aucune connaissance en informatique (primaire), donc je n'y arrivais pas.

Et puis 30 ans plus tard, j'ai réalisé que cela avait changé. Oh malheur.
Au niveau graphismes pour notre jeu pour Android, je me suis lâché. J'ai quasiment pu faire tout ce que je voulais.
Programme Java et OpenGL.
Après il y a des salopes et des connards qui vont vous dire : Oui mais Java c'est un langage qui utilise une machine virtuelle, et il n'est pas performant.
Que nenni, je suis surpris d'avoir les mêmes performances sur un smart phone Android programmé en Java, que sur mon Ordi Windows x programmé en C++.

Les performances dépendent également du hardware ainsi que du code (donc des équipes de programmation/développement). Pour une tâche spécifique, un programme utilisant un algorithme optimisé en Java aura toutes ses chances d'être plus performant que du C++ mal codé.

La "loi de Wirth" évoque la stagnation (voire la diminution) des performances de programmes informatiques malgré l'augmentation de la puissance de calcul du matériel. Dans le web par exemple, j'ai remarqué qu'on incluait beaucoup de bibliothèques plus lourdes que nécessaire, ce qui surcharge les serveurs/clients.

[Bubu]

Toute mon enfance, j'ai été pourri par les performances pourries de mes ordis.
Mais copieux hein. Pourri puissance 10.000. Excusez du peu.
Soit on pouvait faire ce que l'on voulait, mais à la vitesse d'un escargot, BASIC.
Soit on programmait en langage machine. Je n'avait encore aucune connaissance en informatique (primaire), donc je n'y arrivais pas.

Et puis 30 ans plus tard, j'ai réalisé que cela avait changé. Oh malheur.
Au niveau graphismes pour notre jeu pour Android, je me suis lâché. J'ai quasiment pu faire tout ce que je voulais.
Programme Java et OpenGL.
Après il y a des salopes et des connards qui vont vous dire : Oui mais Java c'est un langage qui utilise une machine virtuelle, et il n'est pas performant.
Que nenni, je suis surpris d'avoir les mêmes performances sur un smart phone Android programmé en Java, que sur mon Ordi Windows x programmé en C++.

Les performances dépendent également du hardware ainsi que du code (donc des équipes de programmation/développement). Pour une tâche spécifique, un programme utilisant un algorithme optimisé en Java aura toutes ses chances d'être plus performant que du C++ mal codé.

La "loi de Wirth" évoque la stagnation (voire la diminution) des performances de programmes informatiques malgré l'augmentation de la puissance de calcul du matériel. Dans le web par exemple, j'ai remarqué qu'on incluait beaucoup de bibliothèques plus lourdes que nécessaire, ce qui surcharge les serveurs/clients.

Je ne sais pas si vous connaissez le HLSL. High Level Shader Language. Ils sont marrants. C'est le langage de programmation des GPUs pour DirectX (Microsoft).
En fait c'est pas le language qui est haut niveau, ce sont les GPUs.
C'est assez dingue ce qu'ils sont capables de calculer. (Une simple instruction pour calculer un produit scalaire, ou un produit vectoriel, une seule instruction pour multiplier un vecteur par une matrice. Et maintenant, ils ont des cœurs dédiés au lancer de rayon. C'est complètement fou)

EDIT : Le HLSL (DirectX) et le GLSL (OpenGL) sont très proches et très simples d'accès. Ils utilisent la syntaxe du C.
La seule chose en plus, c'est qu'ils ont des types en plus, pour représenter les vecteurs et les matrices. Et des instructions qui permettent de les manipuler.

Je préfère le GLSL perso, car le vertex shader et le pixel shader sont indépendants. Deux programmes indépendants. 2 fichiers textes indépendants. Le pixel shader est appelé fragment shader sous OpenGL, et c'est plus juste car on ne sait pas quand on calcule le fragment s'il sera visible ou pas. Et ensuite les vertex shaders il n'en faut pas beaucoup. (Skybox, objets statiques, et skin meshes en gros). Alors que les fragments shaders il peut y en avoir beaucoup. Plus d'une dizaine minimum.
Sous OpenGL, on compile les 2 programmes (Vertex et Fragment shaders) en temps réel et on les relie. (link). En temps réel. Et cela constitue après un seul programme que le GPU exécute.

Quelle que soit la plateforme, le vertex shader, et le pixel shader ne se suivent pas dans le pipeline graphique.
Il y a plein d'étapes intermédiaires.
Le vertex shader est là pour les transformations matricielles essentiellement. µPour placer les sommets des objets dans la scène.
Ensuite il peut y avoir le geometry shader, qui crée à la volée de la géométrie nouvelle.
Après il peut y avoir le shader de tesselation en plus. Je n'ai jamais utilisé.

Le plus important c'est l'unité de rastérisation. Elle transforme les sommets calculés par le vertex shader en surface sur l'écran.
Et la projection est déjà appliquée à cet étage du pipeline.

Pour simplifier : vertex shader -> rasterisation -> pixel shader.

L'unité de rastérisation rempli les triangles en fournissant les coefficients d'interpolations, via coordonnées barycentriques.
Le problème c'est que cela ne marche pas pour remplir les textures, il faut en plus prendre en compte la projection.
Plus un point est profond, et plus il est petit.
Mais pas de pb, les GPUs gèrent cela automatiquement depuis leur création.