NintendojoFR : Le forum

Pour le moment on a quand même l'air très loin du compte, en tout cas à chaque fois que je vois un trailer de ce genre c'est une suite d'images qui bougent légèrement, mais rien de plus. Ça va probablement évoluer très vite, mais pour le moment ça me saute aux yeux à chaque fois...

Je ne dis pas le contraire (la bande annonce d'un film Mario dans le même style sur la même chaîne fait encore plus fausse). Par contre une adaptation sous cette forme, faite pour de vrai, en soit je ne dirais pas non, ça serait un angle intéressant.

Si ça permet de prototype un trailer pour un film qui n’existe pas encore, pourquoi pas. Mais je doute que quiconque ait envie de faire ça.

Et encore, un prorotype avec de l'IA, aujourd'hui ça n'a absolument aucun intérêt vu qu'il ne sera pas possible de reproduire à l'identique ce que le prototype a créé :


Encore une fois c'est quelque chose qui évoluera probablement très rapidement aussi. Mais pour le moment, il semble impossible de faire quelque chose de vraiment "professionnel".

L'autre question que je me pose derrière, c'est qu'on critique déjà le fait que la quasi totalité des blockbusters sont en fait des films d'animation avec incrustation de personnages réels (de par la magie du fond vert), est-ce qu'on veut vraiment aller encore plus loin ?
D'autant qu'on encense généralement les films d'animation qui proposent un style graphique différent de l'habitude (genre Klaus), ce qui est par définition l'antithèse de la façon dont fonctionnent les IA. (même si, oui, le marché de la nostalgie rapporte des milliards)
Je reste pour le moment vraiment très dubitatif...

Tant que la majorité de la merde d'internet reflétera la majorité de la crasse incompétence de la majorité de l'humanité et que les ia fonctionneront telle qu'actuellement nous ne pouvons nous attendre qu'à ce résultat médiocre en majorité.

Mais vu l'industrie actuelle du cinéma, j'ai bien peur que ça n'arrête pas le mouvement. Tout dépendra du public et des revenus encore une fois. :/

P@B a écrit : 03 juin 2024 11:18L'autre question que je me pose derrière, c'est qu'on critique déjà le fait que la quasi totalité des blockbusters sont en fait des films d'animation avec incrustation de personnages réels (de par la magie du fond vert), est-ce qu'on veut vraiment aller encore plus loin ?

Vraie question au passage : avec les doublures numériques et les quelques essais fructueux de deepfakes, on pourrait se passer d’acteurs dans certains cas. Mais du coup, est-ce que ça présente encore un intérêt ?

Quand je disais que je serais pas contre un film Metroid sous cet angle je parlais de l'esthétisme rétro*, pas de l'IA

*jeu de mot involontaire bienvenu

Si un jour ça se fait (ce dont je doute fortement), ce sera très certainement en animation, donc je doute que ce soit dans ce style là.

Ce n'est pas ce que je dis non plus, mais la SF de Metroid étant quand même assez générique, faut bien trouver un moyen pour un potentiel film de se démarquer. Quant à l'animation, j'aurais jamais pensé que Zelda s'aventurerait sur du live, et pourtant si.

C'est comme StarFox, si film il y a un jour, il faut que ce soit avec des marionnettes en stop motion

Putain clairement

Faut absolument confier ça au studio qui ont fait les Thunderbirds

Quand Zelinsky rend hommage à Tim Follins:

En même temps Tim Follin

Ce mec était un génie, malheureusement coincé chez Ocean

Je trouve ça fascinant de voir que des idées d'optimisation soit potentiellement contre productives.
Même si j'imagine qu'elles ont dûes été faites à l'aveugle vu la nouveauté relative du matériel sur lequel (et pour lequel) c'est codé.
Les brutes que vous êtes sur le Dojo aurez certainement plus à me dire sur le sujet, d'autant que la barrière de la langue ne m'à pas aidé à tout cerner dans la vidéo.

Genre, typiquement c'est quoi cette histoire de loterie de l'optimisation ? On ne peut déterminer à l'avance quelle fonction est optimale pour quel rendu? Pour du matériel bien identifié dont on connaît les forces et les faiblesses, y'a pas de déterminisme?

Vidéo très intéressante !

Il y a une citation connue de Donald Knuth (un pionnier de l'algorithmique) : premature optimization is the root of all evil. Le mot important est premature. N'importe quel développeur avec un minimum d'expérience te dira qu'il faut toujours mesurer avant d'optimiser. C'est vrai quel que soit le langage, mais surtout pour les langages compilés (comme c'est le cas pour Mario 64). Nous seulement pour optimiser là où c'est pertinent, mais aussi pour vérifier que ça change vraiment quelque chose. C'est encore plus vrai aujourd'hui où l'environnement est énormément complexe avec des optimisations à tous les niveaux (CPU, compilateur, ...).

Difficile de dire d'où viennent ces optimisations sans plus d'informations sur le contexte et la gestion du développement : comment étaient répartis les personnes travaillent sur le moteur et sur le level design, comment se faisait la communication, est-ce qu'il pouvait y avoir des différences entre les types de build ou entre le devkit et la vraie console, etc. Néanmoins, le fait que ça soit non seulement une nouvelle console, mais aussi une toute nouvelle approche (par rapport aux consoles 2D) n'a sûrement pas dû aider...

Toutes les "mauvaises" optimisations qui sont montrées ont du sens intuitivement. Et plusieurs d'entre elles fonctionnaient sur les consoles des générations précédentes. La vidéo le confirme pour l'inlining par exemple. Mais la proximité mémoire était aussi sûrement moins un problème sur NES/SNES.
Il aurait "suffit" de mesurer (cf. citation), mais apparemment c'était compliqué avec les outils qu'ils avaient (d'après la vidéo).
Il est aussi possible que certaines optimisations soient faites par le compilateur. Même si les compilateurs de l'époque étaient sûrement beaucoup plus basiques que ce qu'on a aujourd'hui, certains mécanismes étaient peut-être implémenter. On rappelle que le "code" de SM64 qu'on a vient de la décompilation du binaire, ça n'est pas le code tapé par les dev de Nintendo.

Genre, typiquement c'est quoi cette histoire de loterie de l'optimisation ? On ne peut déterminer à l'avance quelle fonction est optimale pour quel rendu?

C'est la première fois que je vois le terme, donc je vais me limiter à l'exemple donné par la vidéo (l'emplacement en mémoire de certaines fonctions), sans chercher à extrapoler au risque de dire des bêtises.
Le problème n'est pas lié à quelle fonction est appelée, ou à ce qu'elle fait, mais à sa position dans la mémoire. Attention, ça va être un peu technique/long.

Un programme a tendance à utiliser des données/instructions proches de celles accédées/exécutées récemment. C'est le principe de localité. Les architectures exploitent ce principe pour optimiser les accès. Par exemple, sur n'importe quel CPU pas trop simpliste, la RAM n'est pas accédée directement ; elle est d'abord copiée dans un cache, proche du CPU (et donc bien plus rapide), par petits blocs (quelques ko sur des CPU modernes) : si le CPU a besoin d'un octet dans ce petit bloc, alors il y a de grandes choses qu'il ait besoin d'autres octets de ce petit bloc bientôt, et la donnée sera déjà disponible tout près. Évidemment la taille de ce cache est limitée et y charger un nouveau bloc signifie en sortir un autre, sans forcément savoir lequel serait le meilleur choix. (Pour donner un ordre de grandeur, sur un CPU récent un accès au cache le plus près du CPU est ~100x plus rapide qu'un accès à une barette de RAM.)
Quand le code source est compilé, chaque fonction devient une suite d'instructions qui sera mise de manière contigüe dans la mémoire. Mais les fonctions étant indépendantes, elles peuvent être ordonnées un peu comme on veut dans la mémoire (et en général on s'en fiche). Le compilateur (en vrai plutôt le linker, mais on ne va pas rentrer dans ces détails) va les mettre dans un certain ordre, par exemple dans leur ordre d'apparition dans le code source.
Ce que montre la vidéo à 14:49 c'est que deux fonctions utilisées successivement sont éloignées l'une de l'autre (de plus de 1000 ko) et donc ne sont pas mises en cache ensemble. Je ne sais pas comment fonctionne ce cache, mais on imagine bien qu'il y aura des mouvements inutiles entre le cache et la RAM, qui n'auraient pas lieux si les deux fonctions étaient l'une à côté de l'autre. La vidéo insiste sur le fait que la bande passante mémoire (memory throughput) est le facteur limitant ; on veut donc au maximum éviter d'avoir à lire la RAM directement.
C'est la qu'intervient la "lotterie". Si on n'a pas de chances, parce qu'on a ajouté une fonction entre deux autres, parce qu'on a déplacé du code, ou parce que le compilateur a décidé de les ordonner différemment, des fonctions pourront ou pas se retrouver proches dans la mémoire du programme, et donc affecter les performances.

Pour du matériel bien identifié dont on connaît les forces et les faiblesses, y'a pas de déterminisme?

Il y aurait moyen de forcer deux fonctions à être côte à côte. Encore faut-il avoir identifié le problème et savoir lesquelles avant de penser à le faire (on en revient à l'importance des mesures et de l'outillage).
Il y a des mauvaises optimisations qui laissent penser que l'équipe ne connaissait pas forcément si bien les forces et faiblesses de la machine. Et c'est tout à fait normal : on a l'habitude d'avoir des jeux en fin de vie d'une console bien plus poussés que les premiers, parce que le matériel est mieux compris, et donc on peut développer de manière plus efficace.

Petite précision supplémentaire qui concerne particulièrement l’architecture de la N64 (j’ai pas encore vu la vidéo, mais ça me permet de rebondir sur cette histoire de lotterie mémoire) : la latence de la mémoire de la N64 était particulièrement élevée pour l’époque. Elle avait beaucoup de mémoire et un CPU très rapide (toujours pour l’époque), mais des temps d’accès très long.

Donc toute l’astuce pour l’optimisation de la console consistait à « nourrir » le CPU le plus vite possible. Ce qui est du coup loin d’être évident dans ces conditions. En gros, un bon programme N64 se devait de faire de l’optimisation mémoire pour maintenir le CPU à une cadence élevée.

Certains appellent ça le problème du cruise performance contre le peak performance. En gros, la N64 avait des performances de pointe très élevées (parce que très bon CPU) mais des performances de croisière moyenne (parce que mémoire lente).

Merci beaucoup Poussin, c'est assez fou (mais logique) cette histoire de disparités entre les caches processeurs et la ram.

Tu fais la différence entre code compilé ou non, c'est à dire que le compilateur désordonne parfois les instructions ? D'où l'intérêt d'utiliser directement un code bas niveau lors d'une optimisation précise/efficace ?


@Mortal: Si je ne fais pas de contresens, c'est abordé dans la vidéo ou lorsque c'est bien optimisé, l'attente mémoire provoque un "idle CPU" assez constant. (Je que je trouve paradoxalement mal opti puisqu'un des deux composants est en attente mais un détail doit m'échapper).


Ça serait passionnant d'avoir des retours de ce genre sur les vielles machines maintenant qu'elle commencent à être décortiquées.

Tu fais la différence entre code compilé ou non, c'est à dire que le compilateur désordonne parfois les instructions ?

Oui. C'est rarement le cas pour les langages interprétés (non compilés) parce que la "définition" du langage impose généralement que les instructions soient exécutées dans l'ordre d'apparition, et parce que le modèle mémoire faire que généralement, on ne pourrait pas y gagner grand chose à réarranger ou que ça coûterait trop cher (compiler avec optimisations ça prend du temps). (La réalité est plus compliquée parce que les interpréteurs très optimisés sont capables d'identifier les bouts de code souvent exécutés et de les compiler en instructions CPU à la volée pour gagner du temps.)

Pour les langages compilés, notamment le C (je vais me limiter à ce langage pour la suite), le compilateur a le droit de faire "ce qu'il veut" du moment que ce que fait le programme correspond à ce que décrit le code. Le C a plein de comportements non définis ("undefined behavior" ou "implementation defined") pour justement laisser au compilateur la possibilité de choisir ce qui l'arrange. De plus, il est en droit de supposer que le code est parfaitement conforme, ce qui n'est évidemment pas toujours le cas en cas de bug (il y a des subtilités vicieuses qui peuvent donner des résultats très surprenants... mais je m'égare).
Le compilateur C pourra par exemple supprimer complétement l'affectation d'une variable locale qui est écrite mais jamais lue ensuite, parce que ne pas l'écrire ne changera pas le comportement du programme. Il peut aussi "dérouler des boucles" ou "inliner des fonctions" (la vidéo en parle) s'il pense que ça peut faire gagner du temps. Il peut intervertir des instructions indépendantes les unes des autres pour mieux utiliser ses registres. Toujours du moment que le comportement du programme, défini et garanti par le langage, reste assuré.

D'où l'intérêt d'utiliser directement un code bas niveau lors d'une optimisation précise/efficace ?

Oui. En écrivant directement de l'assembleur on code exactement ce que le CPU devra faire. On ne pourra pas pour autant tout contrôler (l'OS décide de certaines choses, le CPU a ses propres optimisations internes, la politique de cache du CPU ne sera pas décidée au niveau assembleur, etc.) mais c'est tout de même mieux. Ça permet aussi de faire du code plus rapide, puisque le compilateur va très souvent générer du code avec des instructions qui "en trop" (à la fois parce que c'est pas un travail facile, et parce qu'il n'a pas toutes les informations à disposition pour savoir s'il peut prendre certains raccourcis).

Je que je trouve paradoxalement mal opti puisqu'un des deux composants est en attente mais un détail doit m'échapper

Ça dépend ce qu'il attend en état "idle". S'il attend la mémoire c'est effectivement un problème. S'il attend le début de la frame suivante parce la frame courante est déjà prête, c'est très bien (ça veut dire qu'il ne retarde pas l'affichage).

La géo-biologie, c'est FUN xD
(mais inquiétant car de plus en plus "imposé" dans des chantiers =_= )

MectonLaFlemme a écrit : 25 oct. 2024 15:03

La géo-biologie, c'est FUN xD
(mais inquiétant car de plus en plus "imposé" dans des chantiers =_= )

Boum le strike!

Sinon:

C'est quand internet réuni les gens malgré le temps qui passe que c'est le plus fascinant !

L’histoire de la première vidéo est très cool !

La deuxième c’est trop tech pour moi là, j’ai lâché à la moitié (ce qui est déjà pas mal ).

Retour et hommage à Chris Sawyer par Ahoy dont j'aime beaucoup les vidéos sur la musique Amstrad notamment.

J'ai appris que la musique et l'ambiance sonore de Roller Coaster Tycoon avait été faite par... Allister Brimble!
Le monde des talents du PC était tout petit en fait à l'époque.

Hâte de voir le test de Mortal

Ce reveal, ce thème, cette DA <3 <3

Le Turfu revient:



Vous n'êtes pas prêts pour 2025!

Et pour le lol: