[Index Software] Jeux vidéo (développement)

[ブノワ]

Les algos d'IA sont gérés par les CPUs.

Justement non, le CUDA est très populaire pour tout ce qui est algorithme génétique, c'est à dire petit bout de code pas compliqué plutôt indépendant à faire tourner massivement.
En tout cas, j'ai toujours eu des perfos au moins 50 fois plus rapide sur une carte (pourri) qu'avec un CPU, même multicore (de toute façon, le génétique et le multicore...)

[Bubu]

Je comprends bien, mais les algos génétiques ne sont pas ou peux utilisés dans les jeux, et vu qu'on parle de jeux dans ce sous-sujet ...

[ブノワ]

On etait passé dans le domaine de l IA.
Des jeux vidéo avec une IA qui tient la route, c est meme pas rare, c est inexistant au point que des humains décérébrés sont toujours meilleurs que çà.
Et ca n est pas une question de moteur ou de machine, a moins que les devs n attendent une librairie qui fasse tout a leur place.

[Bubu]

On etait passé dans le domaine de l IA.
Des jeux vidéo avec une IA qui tient la route, c est meme pas rare, c est inexistant au point que des humains décérébrés sont toujours meilleurs que çà.
Et ca n est pas une question de moteur ou de machine, a moins que les devs n attendent une librairie qui fasse tout a leur place.

Je suis d'accord.
D'ailleurs parler d'IA pour les bots qui contrôlent les ennemis, je trouve ça inapproprié.
Ils suivent le navmesh (un graphe superposé au niveau) selon A*, pour aller vers le joueur, et ensuite ils lancent leur attaque. Vous remarquerez que leurs lancés de projectiles en paraboles sont toujours parfaits ... Ces ennemis sont plutôt doués, ils ont réussi à résoudre une équation du second degré de tête!!! Oh les malins ! Fichtre !

Mais dans les jeux modernes les IA ne se contentent plus de ça.
Mais ça reste de vilains bourriquots.

[ブノワ]

Oui, les algos de pathfinding doivent beaucoup au A* et des variantes. Meme si souvent ca foire.

Mais tout ce qui est prise de decision, anticipation, optimisation, c est en general du niveau de l ecole primaire avec un "si" et une comparaison. Et ils expliquent sans honte que c est des algos perfectionnés.

Moi qui aime bien les trucs de stratégie, c est effarant de voir a quel point les gars n ont jamais joué a un truc collaboratif a plusieurs humains, ou s en foutent.

[Bubu]

Oui, les algos de pathfinding doivent beaucoup au A* et des variantes. Meme si souvent ca foire.

Et l'algo A* doit beaucoup à l'algo de Dijkstra.
(Qui permet de calculer le plus court chemin exactement). Mais jamais dans les jeux, on se contente d'approximations. Et pareil pour les cartographies.
A* utilise une heuristique : quand on a une bifurcation, on choisit la prochaine destination la plus proche à vol d'oiseau. Ce qui est normal dans le monde réel.
Dijkstra est plus théorique, on approfondi tous les chemins possibles.

Avec Dijkstra, pour trouver un itinéraire, aller de Paris à Munich, il vous faut la carte du monde. C'est de l'humour, mais c'est vrai. Si vous n'êtes pas à quelques années près avant d'avoir vos billets, ça peut le faire. L'algorithme de Dijkstra est théorique, mais impraticable sur de grandes cartes. Mais il est superbe, on se demande même pourquoi il n'a pas été inventé avant ...
Aujourd'hui on utilise des variantes. Genre A*, le pathfinding est une notion en plein essor.

[Bubu]

Encore sur les GPUs :
Je parlais des tests conditionnels sur des variables (non constantes) qui sont les ennemis jurés pour la cohérence des threads.
Et ben les boucles c'est pareil.
En GLSL, il y a un préfixe éventuel [unroll(x)] devant le mot clé for. Où x est le nombre d'itérations max. Et le compilateur déroule la boucle en suite d'itérations codées, sans boucle, et donc sans tests conditionnels. Quitte à zapper les itérations qui sont en trop, non atteintes.
[EDIT], le compilateur GLSL donne sur l'écran le code assembleur généré (pour GPU), mais je n'y ai jamais prêté attention. Je pense que toutes les itérations de boucles utilisant le préfixe [unroll (...)] sont exécutées, même si les dernières servent éventuellement à rien.

Car sur les GPUs, mieux vaut avoir des taches cohérentes, bien synchronisées, quitte à faire des calculs "inutiles".

Cependant, ce problème est à relativiser.
Si vous ne faites que des transformations matricielles, (en gros dans les vertex shaders, qui servent à placer les sommets de la géométrie dans la scène selon le point de vue), il n'y a rien de conditionnel, il n'y a ni boucles ni tests.
Et un vertex shader ne coute rien en temps de calcul. En général on ne les prend pas en compte pour évaluer la performance d'un shader complet. (Vertex shader + Pixel Shader).
Ce sont les fragment shaders(OpenGl), appelés Pixels Shaders aussi (Direct3D) qui coutent cher. Normal puisqu'ils calculent la couleur de chaque pixel de votre écran. Avec la résolution gigantesque des écrans modernes, on comprend pourquoi. En plus, ils sont constitués de calculs bcp plus lourds et complexes.

Mais surtout. Pensez à vous protégez.
Pensez au préservatif avant tout.

Développez protégé.

Et c'est le seigneur Bubu qui vous le dit.
Il ne faut jamais utiliser de la vaseline sur les préservatifs en latex, ça l'est rend poreux. Merci à Bubu.

[Bubu]

Les algos d'IA sont gérés par les CPUs.

Justement non, le CUDA est très populaire pour tout ce qui est algorithme génétique, c'est à dire petit bout de code pas compliqué plutôt indépendant à faire tourner massivement.
En tout cas, j'ai toujours eu des perfos au moins 50 fois plus rapide sur une carte (pourri) qu'avec un CPU, même multicore (de toute façon, le génétique et le multicore...)

Pour te répondre, oui, les GPUs sont très utilisés pour autre chose que le rendu graphique. Notamment pour les calculs matriciels, ils sont phénoménaux. On parle de GPGPUs. (General purpose ...)
Les réseaux neuronaux me semble un meilleur exemple, car c'est essentiellement des transformations matricielles qui sont utilisées.(à part pour la fonction non linéaire entre couches).
Je ne connais pas le gain en performance, mais Ixy aurait pu répondre. Ça doit être énorme.

Pour les jeux, on consacre en général entièrement le GPU au rendu graphique.

[Bubu]

Le pipeline graphique dans un GPU est assez complexe.
Déjà, il n'y a pas que les shaders, il y a les rasterizers.
Les rasterizers servent à convertir la géométrie d'un triangle (3 points 3D), en une zone de pixels à colorier sur l'écran. Evidemment, cela peut être inutile si un nouveau pixel est à afficher au même endroit, mais plus proche (en profondeur).
Les rasterizers sont entre les vertex shaders et les pixels shaders.
Dans un vertex shader, on ne donne que les sommets, les normales (vecteurs orthogonaux aux surfaces), l'uv de la (ou des) texture(s).
Pour les skin meshes, personnages animés, c'est un peu plus compliqué car on fait l'interpolation de plusieurs calculs matriciels, pour donner le sommet à la suite du pipeline.
Les rasterizers, de manière invisible même bas niveau (c'est carrément géré par le materiel), interpolent ces données pour qu'elles soient utilisées par le pixel shader.
Le pixel shader rempli les triangles en couleurs. Car les GPUs ne fonctionnent qu'avec des triangles. (Normal, on peut tout faire avec des triangles)
Donc pour faire simple : Vertex Shader -> Rasterizer -> Pixel Shader.
Après c'est encore plus complexe, il y a d'autres shaders intermédiaires. Les geometry shaders et les domain shaders.
J'ai utilisé les geometry shaders pour gérer les ombres (mauvais usage il faut le dire)
Les géometry shaders génèrent de la géometrie à la volée. (ils génèrent des triangles)
Quant aux domain shaders, je n'y connais rien.

Evidemment, quand on utilise le concept de GPGPU, les rasteriseurs ne servent à rien. D'où certaines cartes de Nvidia qui n'en ont pas, et qui n'ont même pas de port video. Mais elles sont féroces en performance. Uniquement conçues pour le calcul massivement parallèle. (via CUDA, ou OpenCl)

Les shaders sont unifiés depuis longtemps, c'est à dire que tous les shaders sont exécutables par les mêmes unités de calcul.
Les unités de calcul d'un GPU sont des monstres. Elles ont des registres de 128 bits. Soit 4 float, (voire 2 double mais c'est jamais utilisé dans les jeux), donc un registre, c'est un vecteur de 4 flottants.
Ensuite elles gèrent les matrices (4x4) sous forme de palettes locales, donc vous imaginez un peu le potentiel de calcul de ces unités. Ensuite, elles sont par centaines, voire par milliers.
Et ces unités de calcul gèrent absolument toutes les fonctions. (addition, soustraction, multiplication, division, logarithme, exponentielle, cosinus, sinus, tangente, etc). En plus des "intrinsic" qui permettent de calculer la réflexion d'un vecteur ou sa réfraction, la normalisation d'un vecteur (essentiel), etc... Mais je pense que c'est, au niveau assembleur, une suite d'instructions les "intrinsics".
A vérifier.
Donc les CPUs, peuvent aller se coucher malgré leur gestion de SIMD, ils ne font pas le poids face à la puissance de calcul phénoménale des GPUs. Normal, sinon on en aurait pas besoin.

Je crois que mes blabla méritent bien une petite croquette à la choucroute gratinée.

[Bubu]

Le repère géométrique 3D n'est pas le même qu'en maths.
En maths, x et y font le plan horizontal, et z la hauteur.

Sur les GPUs, le vecteur x va de gauche à droite, le vecteur y va du bas vers le haut, et z va vers le fond, la profondeur.
D'où l'appellation de depth-buffer, que l'on appelle couramment z-buffer.

Le z-buffer est essentiel pour afficher correctement des surfaces opaques qui se superposent.
Le z-buffer, c'est un tableau 2D qui stocke la profondeur de chaque pixel affiché à l'écran. Il a la même résolution que votre écran.
Quand on propose un pixel, avec sa profondeur, le z-buffer rejette ou accepte immédiatement le nouveau pixel, qui sera ou non affiché selon le test.
S'il est plus proche (en profondeur) que l'existant, il le remplace, sinon, il est ignoré.
C'est fabuleux pour les surfaces opaques, mais carrément inutile pour les surfaces transparentes (à part pour le depth peeling)
Mais utiles pour tracer du transparent sur de l'opaque.

Mais les GPUs font des merveilles, car le z-buffer est entièrement géré par le materiel. Il suffit juste de le paramétrer, et de préciser le type de flottants dont il est constitué. (Car la profondeur après projection est entre 0.0 et 1.0)
Le seul problème, c'est qu'il n'est pas forcément assez précis. Très précis pour le proche, pas assez pour le lointain.
Vous avez déjà certainement expérimenté ce phénomène, où 2 surfaces lointaines quasi superposées clignotent. Tantôt on voit l'une tantôt l'autre. Souvent quand on utilise des jumelles ou un viseur dans les jeux FPS.
C'est dû à la matrice de projection. (précision logarithmique en profondeur).
D'où certains algorithmes, qui stockent la profondeur dans une texture, mais de manière linéaire, et donc se passent du z-buffer. Même précision quelque soit la profondeur. Souvent pour gérer les ombres.

[Bubu]

C'est suite au message précèdent, mais comment éviter de calculer la couleur d'un pixel, ce qui est onéreux, s'il est finalement recouvert par un autre pixel plus proche?
La solution c'est le deferred rendering. Je ne connais pas le terme français. (Rendu différé ? )
La première étape, c'est le z-pass. On remplit le z-buffer. Qui est une texture. Mais chaque pixel n'a qu'une seule composante flottante, qui est sa profondeur.
C'est un peu comme une topographie laser de la scène. On sait exactement quels pixels sont visibles dans cette scène.
Ensuite on génère la normal map (qui contient la normale de chaque pixel), et la color map (qui contient les couleurs brutes des textures).
Ensuite on combine les deux dernières (normal map + color map) pour calculer la couleur des pixels selon les éclairages(lampes et ombres).
Et on obtient l'image à afficher. Sans avoir gaspillé les ressources pour calculer les couleurs des pixels recouverts par d'autres.

Le deferred rendering n'est utilisable que pour tout ce qui est opaque.
Pour le transparent, on utilise le forward rendering, rendu classique, en triant la géometrie du lointain vers le proche, (l'inverse est utilisé pour l'opaque), ou en utilisant une technique de rendu non dépendante de l'ordre pour le transparent (OIT) comme le depth peeling.

Le depth peeling est extrêmement couteux en performances, mais donne un résultat remarquable.
Peu de jeux l'utilisent comme peu de jeux utilisent la transparence. Si c'est juste pour afficher quelques vitres, autant utiliser le forward rendering et trier les surfaces.

[Bubu]

On a envie de créer un nouveau jeu : un jeu pour s'entrainer au calcul mental.
Il serait à la fois destiné aux enfants comme aux adultes.
Il serait avant tout pédagogique.
Au début, des simples additions et soustractions, et tables de multiplication.
Au fur et à mesure, la difficulté grandirait.
Pour les divisions, on compte quand-même s'arrêter à deux pour le diviseur.

La difficulté doit être quantifiée en progression (il faut le concept de niveau).
Et des bonus que l'on gagne à chaque réussite.

Après on ne veut pas de pub, et on n'a même pas réfléchi à la rémunération possible.

Le jeu serait entièrement en 3D, et en utilisant Unity. (Histoire de pas programmer un moteur alors qu'il y a Unity)

[ブノワ]

Une raison particulière de choisir Unity plutôt qu'Unreal ?
La plateforme cible ?

[Bubu]

Une raison particulière de choisir Unity plutôt qu'Unreal ?
La plateforme cible ?

Les plateformes cibles sont Android et iOS

Sous Android, on programme en Java, voire en native code (C, C++) alors que sous iOS, on programme en Objective C. (L'horreur)
Unity se demerde tout seul avec ça, je ne sais comment d'ailleurs, ce sont des couches trop bas niveau, mais le même projet Unity est au final une application valable pour les deux plateformes.
En utilisant C# qui est une version améliorée de Java, mais pour .NET ou pour Unity !

[ブノワ]

Je comprends,commencer a developper sur Unreal pour iOS c est pas vraiment une bonne idée en ce moment, vu la guerre entre les maisons meres Epic et Apple. (qui devrait avoir un resultat positif pour les devs a terme)