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


#201

Ah ben tu vois, je l’avais jamais utilisé comme “effet secondaire”, mais toujours pour dire “effets aux limites”.

Et toi pouah, non mais.

Accessoirement, apprends ta langue : en français on met toujours un espace avant un point d’exclamation.


#202

Ahaha, l’arroseur arrosé :smiley:
Mais je vais continuer à le faire à l’anglaise vu qu’il n’y a pas d’espace insécable en BBCode.

Bon, comme offrande de paix, vu qu’on parlait du merveilleux éditeur de niveaux de Frogatto dans le sujet PC, celui de Rayman Legends n’est pas mal non plus, dans un style sans cases:


https://www.youtube.com/watch?v=y-chi097uV4

je recommande en particulier le bout entre 2:30 et 2:40 de la première vidéo, avec les graphismes qui s’adaptent suivant l’angle de la surface.


#203

J’ai pas tout compris, mais si j’ai bien compris, ils ironisent sur le fait qu’il reste des bugs dans certains langages de programmation ?

Et par curiosité il code dans quoi ? Il peut passer d’un langage à l’autre aussi facilement ?


#204

C’est des langages interprétés (c’est-à-dire exécutés au fur et à mesure du code par la machine, et non compilés comme Java ou C++), qui sont réputés pour être ultra-permissifs au niveau des déclarations de variables, pour des raisons d’accessibilités. En gros, tu déclares une variable, mais tu ne spécifies pas son type, c’est en fonction de ce que tu mettras comme valeur dedans et des opérations que tu lui fera subir que l’interpréteur décidera dynamiquement son type.
C’est pratique, mais c’est parfois casse-gueule, surtout quand on va chercher la petite bête (comme dans la vidéo) en effectuant des opérations bizarres pas prévues par l’interpréteur. C’est malheureusement une faiblesse pour ces langages.


#205

Oui, le truc est qu’à moins d’être vraiment avancé dans la connaissance de ces langages, même pour un programmeur la plupart des résultats n’ont aucun sens et sont carrément contre-intuitifs, et c’est ça qui est très amusant. Il y en a certains qui arriveraient aussi dans des langages non interprétés (comme le + qui ne donne pas le même résultat dans les deux sens, bonjour C++).


#206

Pourquoi ça n’est pas corrigeable à la source ? Qui s’occupe de développer Rubi et Javascript par exemple ?


#207

Ruby et JavaScript ont bien des équipes de développement qui sortent régulièrement de nouvelles versions, mais qui ne s’attaqueront sans doute pas de sitôt à des bugs aussi pervers. Sans compter que ces résultats sont aberrants sans doute parce qu’ils sont le résultat un peu aléatoire d’un ensemble de fonctions extrêmement complexe : ça ferait beaucoup trop de boulot pour un résultat négligeable face aux autres trilliards de bugs plus gênants.


#208

Ono> En général parce que c’est logique d’un point de vue strictement technique et que la bizarrerie vient purement d’une méconnaissance du fonctionnement. En ce sens ce ne sont pas des bugs et tous les intégristes du langage vont te tomber dessus si tu propose de les changer, peut-être même pour de bonnes raisons.

Par exemple le truc du + qui ne donne pas le même résultat dans les deux sens est seulement confus parce que le + est naturellement commutatif en math mais en programmation ça n’est pas une addition, ça dépend du contexte. Par exemple 1+1 en javascript comme en c# est une addition parce que les paramètres sont des nombres (1+1=2), mais “1”+1 est une concaténation de texte parce que le premier “1” entre guillemets est du texte et que pour du texte le + est une concaténation et va supposer que le second paramètre est du texte aussi (“1”+1 = “11”).

Avec un truc comme ça il n’y a pas de bug, mais on peut se demander pourquoi le + a été choisi pour représenter la concaténation aussi (réponse: c’est pratique à écrire, “un” + " deux" + " trois" est bien plus lisible que concat(“un”, concat(" deux", " trois")) qui serait la manière classique). La plupart des trucs mentionnés dans la présentation sont de ce style, contre-intuitifs mais strictement logiques une fois qu’on connaît les règles. C’est magnifié par le fait que le contexte est encore plus implicite dans beaucoup de langages interprétés dans lesquels on n’a pas à formellement assigner un type à chaque variable.


Concrètement, dans le premier exemple (a = b -> erreur, a = a -> nil), le truc est que justement un est une erreur et l’autre pas. Quand tu fais a = quelque chose, a qui n’existait pas jusque là est créé et prend la valeur nil (“je suis une variable vide comme toutes les variables nouvellement créées”) puis le = est exécuté. Pour a = b le = produit une erreur parce que b n’existe pas. Pour a = a il n’y a pas d’erreur (a existe et a une valeur même si cette valeur représente sa vacuité) et a se voit correctement assigner la valeur nil de a (qui a été créé juste avant).

Cela est logique, mais seulement quand on connaît le truc (“lors d’une assignation une variable qui n’existe pas encore est créée avant l’assignation”). Cette confusion n’existe pas dans un langage où on t’oblige à déclarer tes variables explicitement mais le but du mécanisme dans ruby est justement de pouvoir déclarer ces variables au pied levé.

EDIT: j’espère que c’est pas trop technique.


#209

Merci à vous deux.


#210

Wow, un énorme topic cloudbush en diable sur Reddit, bourrés d’astuces de développeur pour les jeux récents :

Fallout 3 Broken Steel expansion :

“Ron the Narrator in Fallout New Vegas” :

Encore Skyrim :


Et le plus flippant, Bioshock 2 :


#211

Une vidéo de vulgarisation plutôt cool sur les modes graphiques de vieilles machines:

https://www.youtube.com/watch?v=Tfh0ytz8S0k


#212

La suite du post précédent (toujours aussi cool et didactique) :


#213

Ah chouette, je l’attendais! Là j’ai appris un ou deux trucs!


#214

Je ne sais pas trop dans quoi foutre ça mais Microsoft vient de racheter Havok à Intel.


#215

Je découvre seulement un joli hack mathématique pour accélérer un calcul bien relou en virgule flottante : 0x5f3759df

float FastInvSqrt(float x) {
  float xhalf = 0.5f * x;
  int i = *(int*)&x;         // evil floating point bit level hacking
  i = 0x5f3759df - (i >> 1);  // what the fuck?
  x = *(float*)&i;
  x = x*(1.5f-(xhalf*x*x));
  return x;
}

Le secret étant :


#216

Notez qu’il y a aussi un article wikipédia dessus: https://en.wikipedia.org/wiki/Fast_inverse_square_root


#217

Un bonne dissection du tres impressionnant moteur de gta: http://www.adriancourreges.com/blog/2015/11/02/gta-v-graphics-study/


#218

ça fait de semaines que je suis assis dessus et ça a probablement fait le tour du net depuis, mais voici une excellente présentation de l’animation de persos dans Overwatch:

Le truc intéressant, c’est que ça n’est pas du tout une présentation technologique, en fait c’est une paraphrase des fameux douzes principes de l’animation bien connus des animateurs Disney (et des amateurs de Darkstalkers) mais que beaucoup d’animateurs de jeux élevés à la motion capture ne connaissent pas parce qu’ils ne sont pas “réalistes” (alors que justement tout le truc est que le réalisme ne suffit pas).

Si vous n’avez pas l’occasion de regarder je vous spoile directement le meilleur slide:

Un aspect à noter, c’est que certains moteurs ne permettaient simplement pas ce genre d’animation élastique (UE3 par exemple avait dû être modifié pour le permettre dans Xrd). Il faut dire qu’elles ne sont pas tout de suite venues dans la 3D, apparemment c’est le film Cloudy with a Chance of Meatballs en 2009 qui a popularisé les “noodle controls”, soit la possibilité pour les marionettes 3D de switcher à volonté entre des animations solides ou élastiques. Mais en plus ne pas permettre aux os de personnages de s’étirer permet de garantir une certaine propriété mathématique qui permet de compresser les anims plus facilement (Pour ceux qui ont leur permis ça garantit que les matrices locales sont décomposables en canaux rotation/translation/homothétie ce qui fait passer une matrice de 16 valeurs à 8 et de compresser ces canaux indépendamment).

Et ça me fait penser à Ecstatica, le Alone in the Dark médiéval tout rond. Dans une interview le programmeur se plaignait de ce que tout le monde parlait du rendu ellipsoïde alors que pour lui la vraie innovation technique est justement que son moteur permettait ce genre d’animation élastique.


#219

Le sujet est intéressant mais bordel ce que le mec est chiant ! Il met 3 plombes à accoucher d’une idée qu’on peut résumer en une phrase.


#220

Un site pour s’amuser avec les shaders.

https://www.shadertoy.com/view/XslGRr