[Mesh rebelle] Le topic des techniques qui décoiffent dans les jeux


#81

Un topic ma foi fort intéressant - à mon niveau, en tout cas - sur la tech et les textures de Wind Waker, décortiqué sous Dolphin.


#82

C’est proprement fabuleux. Toutes les astuces utilisées sont :hypno: et :meuh: à la fois.


#83

Pour la petite histoire, à propos de sa remarque sur les pieds qui s’ajustent à la position du sol, il a doublement tort: effectivement Uncharted n’était pas le premier mais Wind Waker n’était de loin pas le premier non plus. Le plus vieux dont je me souviens perso est Soul Reaver 2 (2001).


#84

C’est très intéressant, et le dernier post en date du topic l’est peut-être même encore plus :


#85

Pas directement lié à des jeux, mais la nouvelle technologie Paperman (en fait le nom du court-métrage dans lequel elle est utilisée pour la première fois, en fait l’outil s’appelle Meander) de Disney est assez bluffante, combinant 2D et 3D pour résoudre les problèmes habituels d’inbetweening (création auto d’images entre les images clés) des logiciels d’animation 2D. Une sorte de variante de cel shading dans lequel les modèles 3D servent juste de référence pour déformer les dessins comme il faut (dans la vidéo ils utilisent aussi la 3D pour l’éclairage mais on peut très bien tout colorier à la main).

Au-delà de l’apport aux films d’animation en général perso après avoir lu le papier je pense que ça a un gros potentiel pour être simplifié et adapté au temps réel en restant assez joli.


#86

J’ai pas tout compris, mais le résultat final est vraiment chouette.


#87

Idem, le process me semble mystérieux, et je suis pas sûr de voire la différence visuelle entre une anim avec cette techno et une anim sans…


#88

C’est parce que visuellement, il n’y en a pas vraiment. Au niveau production, par contre, le logiciel calcule toutes les images intermédiaires et tu dois dessiner beaucoup moins d’images clés pour le même résultat.

Flash et consorts permettaient de ne plus dessiner d’intervalles mais à moins de faire de l’anim “plate” (le fameux look flash) tu devais dessiner plein de clés parce que le logiciel ne pouvait pas comprendre que tes lignes entouraient des volumes dans l’espace.

Et en même temps, par rapport à la plupart des techniques cel shading, qui dessinent des bordures automatiquement et donc des bordures fadasses, ici le trait peut avoir beaucoup de personnalité puisque c’est celui de l’artiste. De plus, le modèle 3D n’a pas besoin d’être très détaillé: ils pourraient très bien décider de ne pas modeler de visage et le faire entièrement au trait tant qu’il y a un vague crâne derrière, et ça aurait quand même l’air d’être 3D. Dans la vidéo les vêtements de la fille sont très sommaires en 3D et entièrement détaillés au trait par exemple.


#89

Pour info, Disney diffuse actuellement gratuitement la version finale du court-métrage sur Youtube :

Spoiler

Ils vécurent heureux et touchèrent beaucoup d’Assedic.


#90

Apres avoir disséquer le code des jeux id, Fabien Sanglard remets ca en faisant l’analyse de Duke3D
http://fabiensanglard.net/duke3d/


#91

Merci Lama ! Toujours intéressant à lire.

Mon dieu.

My god.

Mein Gott.

Tout ça pondu par Ken Silverman, un gamin de 18 ans qui a envoyé une démo de son moteur-3D-comme-Doom à 3DRealms et a été embauché direct. Accessoirement, son 2nd moteur en voxel a été abandonné en 2005… mais fait tourner Ace of Spades en ce moment même. J’ai cherché un peu partout où est-ce qu’il travaillait actuellement avant de comprendre que créer le moteur de Duke et ses dérivés doit permettre de vivre sa vie pas trop mal en se contentant de hobbies.


#92

Moi je suis pas codeur. Ca me dirait bien que tu nous expliques pourquoi ça te fait sauter au plafond ces trois exemples ?


#93

“Mon dieu” : le mec code une partie de son bouzin en décryptant de l’assembleur hyper-optimisé et en le retranscrivant en C. Dangerous.

“My god” : un “switch case”, c’est une instruction qui te permet de regarder la valeur d’une variable, et selon, d’appliquer un bout de code différent. Normalement t’as 3 cas différents à gérer dans ton instruction avant de reprendre le cours normal de ton programme. Là, pendant 3000 lignes, le gars est dans son instruction = illisible.

“Mein Gott” : ses méthodes ne reçoivent rien en paramètre et ne renvoient rien de spécifique, il utilise des variables valides à travers tout son code (globales) pour faire transiter des valeurs. C’est infernalement illisible, surtout qu’il a en plus un gros problème pour donner des noms clairs à ces variables globales.

En gros, l’ami Sanglard a du pleurer du sang pour comprendre le code :smiley:
Mais il propose une version lisible et compilable qu’il a faite lui-même : Chocolate Duke Nukem 3D. Les générations futures lui seront reconnaissantes.


#94

Merci
Thanks
Danke


#95

Concernant le switch-case “menu.c” de 3000 lignes, tous les événements liés au menu ont l’air d’avoir un code assigné.

Autrement le code est juste dans l’esprit de ce qui se faisait à l’époque (et encore aujourd’hui) sur les projets de jeux “mono-codeur one shot”.
Surtout genre pas de réutilisation du code (dans son ensemble, tout du moins) pour un futur projet envisagé, sans même parler de l’idée d’une diffusion de code.
En plus il l’a débuté en tant que projet “perso”, donc loin de l’industrie (pour ce que cette notion pouvait signifier pour le jeu vidéo à l’époque).

[EDIT] D’ailleurs le “menues.c” est issu de la partie codée chez 3dRealms, so much for the industry. :wink:


#96

Hopopop, attention, le code du menu vient des pros qui auraient dû savoir mieux le faire (au moins des define pour les numéros, quoi…), pas de Silverman. Même chose pour le combo de la mort void/global.

Fake edit: ah, tu l’as ajouté.


#97

Je ne me basais surtout sur les remarques d’engine.c, style :


Autrement, Sanglard présente vraiment les choses de manière bien pédagogique, notamment ici les apports à la logique d’un moteur de rendu de scène 3D type Doom.


#98

Oui, mais alors ça c’est super commun encore maintenant, c’est souvent un joli boost niveau performances (plus cache-friendly). Et en poussant le principe plus loin on en arrive aux systèmes d’entités/composants/glomming ('tention, lien pour programmeurs) qui sont super appropriés pour les entités dans les jeux, souvent plus que les hiérarchies objets classiques (pas de problème d’héritage multiple, construction dynamique de nouvelles classes).


#99

Mhhh, j’avais lu que les structures en C étaient adressées comme des types primitifs une fois le code compilé. C’était une connerie ?
[EDIT] En fait sûrement que non et oui, car il est probable que plus d’instructions auront été générées tout de même.
[EDIT2] Et puis cela doit également dépendre de comment sont utilisées les structures dans le programme, le moment où elles sont instanciées (dynamiquement ou non dans le moteur lui même).


Intéressant les problématiques des MMO qui ressortent de l’article sur le principe d’entité, c’est vrai que ce type de jeu doit jouer sur la scalabilité (nombre de joueurs et donc d’objets) autant que la flexibilité (évolutions du jeu et donc du code).


#100

Non mais il y a plein d’effets secondaires. Le truc dont je parlais c’est le cache, et la fréquence à laquelle les données sont demandées.


Imagine qu’un monstre a un nom et des coordonnées dans l’espace. On va supposer que le nom fait douze octets et les coordonnées douze aussi. Les coordonnées sont accédées et mises à jour à chaque frame alors que le nom n’est utilisé que dans les cas particuliers où par exemple on a besoin de déterminer quel monstre s’appelle Bob.

Le principe du cache c’est que quand tu accède à un monstre le cache charge tout le bloc de données qui l’inclut et l’accès sera plus rapide tant qu’on n’a pas besoin de charger un nouveau bloc.

Maintenant imagine le mouvement de tous les monstres à chaque frame avec un cache de 120 octets: si tes monstres sont dans un tableau de structures nom/coord, alors tu pourras traiter 5 monstres avant d’avoir à recharger le cache. Si tes monstres ont les coordonnées dans un tableau et les noms dans un tableau tu pourras traiter 10 monstres parce que tu as seulement besoin des coordonnées.

Deux fois moins de rafraîchissement du cache -> tout bénef. On a des gains similaires avec les instructions parallèles du genre SIMD, SSE, etc… D’une manière générale on gagne à séparer les données “chaudes” (consultées souvent) des données “froides” (rarement utilisées) et utiliser des tableaux aide très naturellement tant qu’on peut facilement faire la correspondance entre les différents tableaux (un problème en soi).
</pour les programmeurs>