[Temps Réel] Le topic de la demoscene & des explosions de cpu/rétines

[aliochou]

Des shaders pour le son ?

Mhhh je pense qu’ils font référence à ça. En gros utiliser le GPU pour faire des choses en général destinées au CPU, comme le son, la physique ou même le gameplay. Donc je veux pas dire de bêtise, mais cette démo peut très bien être 100% exécutée sur une carte graphique.

[nova]

Des shaders pour le son ?

Sur ce sujet: http://www.pouet.net/topic.php?which=9487&page=1

[Camarade_Chev]

Fou ! Les explosions et fumée
C’est quoi les astuces pour faire tenir ça en 4k?
Tout est sous forme d’équations, les instruments, la partition, les textures, les trajectoires, les objets 3d ?

D’une part, oui, autant de choses que possible sont procédurales.
Ensuite, le grand truc de la compression est que l’algorithme de compression lui-même n’a pas besoin d’être très compliqué tant que tu lui files des données qui compressent bien. Genre en RLE (on compresse les répétitions) 1 2 3 4 5 6 7 8 9 est incompressible mais 1 +1 +1 +1 +1 +1 +1 +1 +1 +1 va être réduit au dixième, donc tu vas changer la formulation et l’ordre des choses pour créer les répétitions. C’est vrai pour les données mais c’est vrai pour le code aussi! Enfin, à cette taille-là ça devient vraiment intéressant de quantiser, c’est à dire par exemple d’encoder un truc sur 4 bits au lieu de 16 parce que tu sais qu’il n’est jamais plus grand, etc.

Il y a une présentation meshrebelle de farbrausch sur le sujet (attenton, c’est un tantinet technique): http://www.farbrausch.de/~fg/seminars/workcompression.html
Dix ans après c’est toujours autant d’actualité.

[nova]

Une impressionnante 64k sortie ce week-end durant la Revision.

[CHAZumerou]

OK je pige même pas comment c’est possible. Y a vraiment pas une seule texture, là, même avec la maison ?

[nova]

Je pense que toutes les textures sont générées en code, ce qui explique la taille du programme.

[Lama_Himself]

Je preferes tout de meme Fermi paradox de Mercury qui est beaucoup plus propre.

[onosendai]

J’ai pas de mots.

[nova]

Demo neogeo cd, vraiment pas mal compte tenu des limitations de la machine pour ce genre d’effets:

[aliochou]

The rest of these details are mostly things I want to remind myself of later. Very technical, will not hold your hand but I will try to answer any questions if you ask in the comments.

“Frustum Culling” (the culling of chunks from the GPU renderer if they are outside the field-of-view) had to be disabled. This is because large-scale terrain deformations I do in this video make culled chunks visible to the player. I disabled frustum culling by editing the Mineshot and Minema source code (thanks to BarracudaATA for making them open source and easy to compile). Disabling frustum culling takes an insane amount of VRAM, this prompted me to upgrade from a 780 Ti to a 980 Ti.

While playing around in the Minema source code, I managed to get chunk preloading to work with Optifine (the two are normally incompatible). This means I could have potentially recorded at far+ view distances with chunk preloading. However, I chose not to do this because I was already using nearly 6 GB of VRAM with a regular far view distance.

The “Non-Euclidean Terrain Transitions”, require that frustum culling is disabled, and chunk preloading is enabled. The transitions work by having both terrain models within in the player’s view distance (in the world they are placed side-by-side), merging the terrains into the same position in a vertex shader, and then deciding which terrain is visible inside a fragment shader by constructing a second pseudo-frustum out of the cobblestone gateways. Because 2 terrain models are loaded within a single view-distance, the size of the terrain models must shrink to fit inside the view-distance. I covered this up by having the fog reduce the visibility distance whenever the player is near a transition. The terrain endpoints were stretched in the shadow-map to keep them contiguous.

For every Acid Interstate video, I sync things by recording a copy of the video with the coordinates open. I use this copy of the video as a coordinate reference. For this video I created a beatmap, and then used the coordinate reference to find the coordinates of torch-outposts and endpoints for terrain animations.

The terrain animations were controlled by the player’s world space x coordinate. This works out because the player’s camera path consists of straight linear movement towards x+ (the ascent at the beginning of the video is controlled by a vertex shader displacement). This was done because neither of the GLSL Mod’s time variables (worldTime and frameTimeCounter) can be consistently synchronized between recordings.

I ripped out the default day-night cycle and implemented my own inside the shaderpack. Doing this allowed me to adjust the length of the day to better fit with the song. This also allowed me to skip the nighttime because it didn’t really fit.

The video recording was split into 6 segments, each covering about 2,000 blocks. The segments were then combined in my editing software. I split the recording because Optifine does some sort of model-space refresh every ~4,000 blocks, and sometimes chunk preloading stops functioning after the refresh. Splitting the segments up into smaller chunks also allows for less recording commitment, and helps flush memory bottlenecks, however it exasperates issues if recordings are not perfectly synchronized. Splitting recordings also means I’ll have to deal with 36 video files for the VR cubemap.

[CHAZumerou]

Foutez-moi ça dans un casque VR et je vous l’achète. Car c’est Thumper en plus relax, au fond. Par contre, je n’ai pas compris si la coordination entre les blocs et la musique était manuelle (façon Star Guitar / Gondry) ou si son bidule fonctionne comme un visualisateur qui s’adapte à n’importe quel morceau (auquel cas c’est dingo).

[Camarade_Chev]

La synchro est manuelle. Le bout important pour ça est celui-là:

For every Acid Interstate video, I sync things by recording a copy of the video with the coordinates open. I use this copy of the video as a coordinate reference. For this video I created a beatmap, and then used the coordinate reference to find the coordinates of torch-outposts and endpoints for terrain animations.

Donc il a enregistré une première vidéo avec le terrain brut et un truc à l’écran qui indiquait les coordonnées, et ensuite il n’y a “plus qu’à” poser les objets aux coordonnées pertinentes pour la musique.

[aliochou]

Faisons un lecteur vidéo avec Factorio :

[aliochou]

Here is another Quill piece I created over the course of 4 days. I call it “Worlds in Worlds”. When Inigo Quilez created Quill, he claimed that it would have an infinite canvas…
Now what happens if you give an artist an infinite canvas? Of course he is going to use it right? I had to put it to the test. What if there was a world within a world within a world within a world…
By zooming in and out of the worlds I created, I blew my own mind. I could not comprehend how this was possible. This tool is just limitless! Again you have to experience this in VR to be able to fully appreciate it. But here is a little demo video of “Worlds in Worlds”! Enjoy!

[onosendai]

Explication de ce qu’il se passe : https://codingwithballs.wordpress.com/2017/02/19/makt/

[onosendai]

Bon les gars, je ne vous cache pas que je suis extrêmement frustré, j’ai envie, j’ai besoin, de coder, mais je veux le faire sur un système limité pour diverses raisons. Déjà parce que ça m’amuse, mais aussi parce que je n’ai pas envie de jongler avec des millions de librairies, et que les systèmes limités ont l’avantage d’avoir un périmètre réduit et “quantifiable”, ce qui n’est plus le cas sur PC aujourd’hui. Et puis j’aime simultanément la simplicité du basic et les défis intellectuels de l’assembleur. Les langages intermédiaires m’emmerdent.

Il y a maintenant 2 ans, je pensais projeter cette pulsion sur Smile Basic 3DS qui semblait être parfait pour canaliser cette lubie, mais ces connards de SmileBoom ne l’ont toujours pas sorti en europe (si un jour je les croise c’est mawashi gyoza DIRECT !!!).

J’avais donc décidé de me mettre à l’assembleur sur C64, et c’était bien parti mais j’ai été très vite arrêté dans mon élan à cause de l’émulateur qui ne gère pas les claviers AZERTY, sans parler des touches spéciales du C64. Je passais plus de temps à chercher les bonnes touches qu’à réfléchir au code du coup j’ai laissé tomber.

Je m’étais aussi pas mal investi dans Pico 8 mais il est un poil trop “roots”, je m’y mettrais à fond lorsqu’ils sortiront (je l’espère) Pico 16.

Je me demande maintenant si je ne vais pas tout simplement revenir à mes propres sources et apprendre l’assembleur sur Amiga, j’imagine que ça pose moins de problème dans l’émulateur.

Ca c’est pour la plateforme, pour le reste, j’ai envie de faire un pèlerinage et d’apprendre la théorie et la pratique des effets démos qui m’ont toujours fait rêver : raster, scrolling texte etc… si vous avez des ressources éducatives là dessus je prends.

[nova]

Ce site est pas mal pour commencer: http://coppershade.org/

Sa chaine youtube:

[dma]

Pour les bases de l’assembleur 68000 en termes de logique et syntaxe, et à garder sous le coude ensuite, je te conseille : http://www.mrjester.hapisan.com/04_MC68/
Après l’assembleur n’est qu’un langage pour faire interagir des composants spécifiques à chaque machine.
De ce fait il est minimaliste car il ne porte aucune logique ou structure de données fonctionnelle, spécifiques à la plateforme.
Il te faudra donc apprendre et comprendre chaque composant de la machine niveau entrées, sorties, et logique interne au composant.

[nova]

Bonne petite demo sur Megadrive sortie ce week-end à la Revision:

[aliochou]

Via GK, du 64k qui tabasse :

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

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