Bonj'
Voici une évolution du player de "MOD" le plus rapide du monde, maintenant disponible pour Linux et Mac
https://github.com/arnaud-carre/LSPlayer
ou trouver des mod
c'est utilisé dans la scene demo, encore aujourd'hui..
ici c'est le groupe "Oxygene" du membre "Leonard" qui à crée le player
# bel exploit
Posté par jseb . Évalué à 2 (+0/-0).
Merci pour le lien, ça fait toujours plaisir de voir ce genre d'exploit (n'ayons pas peur des mots, c'est un exploit et surement plus que la présentation de la dernière brique javascript).
Sauf erreur de ma part (j'ai vérifié bien sûr), seul le convertisseur de modules peut s'exécuter sous Linux.
Le module est converti dans un format adapté au player, qui lui reste uniquement disponible pour les archis 68k (Amiga & Atari, au moins).
Discussions en français sur la création de jeux videos : IRC freenode / #gamedev-fr
# vitesse
Posté par Psychofox (Mastodon) . Évalué à 4 (+2/-1).
La vitesse est-elle un critère pertinent quand on parle de musique, avec donc un tempo dépendant de l'œuvre et non du lecteur?
Ne veut-on pas plutôt parler d'usage cpu à la place?
# Détails techniques
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10 (+11/-0).
Un résumé rapide du principe de ce player.
Les fichiers MOD sont basés sur deux choses: des "samples" (échantillons sonores, qui peuvent être rejoués à différentes fréquences pour jouer des notes différentes), et des "patterns" (qui indiquent quel sample jouer à quel moment, à quelle fréquence, à quel volume, etc).
Sur Amiga, la partie "sample" est gérée par le matériel: on dispose de 4 canaux (2 à droite et 2 à gauche sur la sortie stéréo) alimentés par des DMA, avec un réglage du volume et de la fréquence.
Toute la difficulté est donc la gestion des "patterns". Les fichiers MOD ont un format simple sous forme d'une liste de notes, chacune associée à un numéro de sample, un volume et un effet spécial. Un lecteur de musique MOD classique va directement lire ce format (ou une variante simplifiée ou compressée) et calculer en temps réel les fréquences, volumes, etc correspondants (les "effets" pouvant modifier les valeurs par rapport à ce qui est indiqué dans la liste de départ du pattern).
Ce que fait LSPlayer, c'est de précalculer à l'avance tout ça. Les patterns sont donc remplacés par une liste d'évènements de type:
Ainsi, le player proprement dit n'a plus aucun calcul à faire, seulement à programmer ces valeurs directement dans les canaux DMA et la puce son.
Le compromis est qu'une telle liste va peut-être occuper plus de mémoire que le fichier original. Mais, en pratique, le format MOD n'est déjà pas très compact, et en plus, de toutes façons, la plus grande partie de la mémoire nécessaire est occupée par les samples. C'est donc un tr`s bon compromis finalement.
Leonard n'en est pas à son coup d'essai sur le sujet: cette technique est en fait assez directement inspirée de ce qu'il avait déjà fait il y a plusieurs dizaines d'années avec les fichiers YM permettant de faire la même chose, mais avec la puce son de l'Atari ST: stocker directement la liste des valeurs à programmer dans la puce, plutôt que de les calculer en temps réel à partir de données plus haut niveau.
Reste un dernier problème: la version pour Atari ST du player doit s'adapter à un matériel complètement différent, pas du tout pensé pour jouer des fichiers MOD (ou plutôt, l'inverse: les fichiers MOD ont été conçus en accord avec les spécificités de l'Amiga). Là, je n'ai pas regardé quelles astuces et tours de magie sont exploités pour y parvenir. En principe il faut faire logiciellement le mixage, car il n'y a que 2 canaux DMA au lieu de 4, et si je me souviens bien, en plus, leur fréquence n'est pas configurable (ça c'est pour l'Atari STe et Falcon, pour les machines précédentes, c'est encore pire).
# Scene demo
Posté par Marotte ⛧ . Évalué à 3 (+0/-0).
Tu donnerais quelle définition de "scene demo", de la scene demo actuelle si le terme a pris un cens différent ?
J’en ai une certaine idée depuis longtemps et je n’ai pas encore souhaiter demander à Google. Et comme tu emplois le terme j’espère avoir les moyens de te faire parler.
[^] # Re: Scene demo
Posté par bunam . Évalué à 3 (+2/-0).
https://fr.wikipedia.org/wiki/Scène_démo
Je suis assez d'accord sur la définition du site ;)
Leonard est un performeur, j'ai eu l'occasion de le connaître IRL…
Il a été un des premiers à faire du scrolling hardware + fullscreen sur Atari ST (alors que ce n'est pas possible, il n'y a rien dans le hard qui permet de le faire, a contrario du hardware de l'Amiga). Il passait pas mal de temps à optimiser son code.
[^] # Re: Scene demo
Posté par Marotte ⛧ . Évalué à 3 (+0/-0). Dernière modification le 29 février 2024 à 22:17.
Donc on ne peut pas dire par exemple que certains logiciel de « visualization » de musique qui affichent des espèces de formes psychédélique (ou pas) qui suivent la musique peuvent être issus de la scene demo ?
C’est donc un domaine plutôt distinct, qui n’a pas trop de rapport avec le VJing ? Malgré que des demos puissent être drivées par de la musique. L’aspect optimisation du code étant central dans le délire.
C’est vrai qu’aujourd’hui, sur du matos moderne, qu’est-ce que tu pourrais afficher qui témoignerait d’une optimisation astucieuse des capacités du matériel… ^^
[^] # Re: Scene demo
Posté par Psychofox (Mastodon) . Évalué à 4 (+1/-0). Dernière modification le 01 mars 2024 à 08:51.
Si c'est du VJing, mais sous forme de concours à qui peut le faire mieux avec des contraintes très strictes, et donc via une programmation informatique optimisée.
Même avec le matos actuel ce n'est pas si facile car ton intro doit tenir dans 4KBytes. Idem pour les demos 64KB. Moins d'optimisation CPU, + d'optimisation GPU.
[^] # Re: Scene demo
Posté par Marotte ⛧ . Évalué à 3 (+0/-0).
Ah oui, avec ce genre de contrainte en effet, peu importe la puissance du matériel dans ce cas. Ça me fait penser au Code golf dans le même genre, sauf que là c’est la taille du code source qu’il s’agit de minimiser.
Je suis absolument admiratif des personnes capables de ce genre d’exploit.
En tous cas merci pour vos réponses j’ai une idée plus clair de ce qu’est la demo scene et content de constater qu’elle existe toujours bel et bien.
[^] # Re: Scene demo
Posté par Toufou (site web personnel) . Évalué à 3 (+2/-0).
pouet.net est la porte d'entrée et permet de se tenir au courant de ce qui sort (et des parties). Il y a de belles choses récentes y compris sur vielles machines :)
[^] # Re: Scene demo
Posté par cg . Évalué à 4 (+2/-0). Dernière modification le 01 mars 2024 à 12:14.
Je trouve aussi que le live coding est un intermédiaire intéressant entre le VJing et la scène démo.
En libre, il y a des outils comme Fluxus (visuel), Supercollider (audio) ou Pure Data (audio et visuel).
[^] # Re: Scene demo
Posté par Toufou (site web personnel) . Évalué à 2 (+1/-0).
Heu comment faire un scroll hardware+fullscreen sur ST si ce n'est pas possible ? :D A coup de fer a souder ?
Tu veux probablement dire : "alors que ce n'est pas fait pour", ce qui correspond plus aux joies de la démo :D Quoique…
[^] # Re: Scene demo
Posté par bunam . Évalué à 3 (+2/-0). Dernière modification le 04 mars 2024 à 14:23.
En bricolant à mort les interruptions du CPU provoquant de nombreux changements (de résolutions je crois) par secondes dans la puce GFX, je n'ai pas plus de détails… Je ne suis pas équipé avec le bon CPU pour comprendre vraiment ;)
[^] # Re: Scene demo
Posté par bunam . Évalué à 3 (+2/-0).
je pense avoir trouvé une discussion sur le sujet : https://www.atari-forum.com/viewtopic.php?sid=7823ecb41f1d7437caf166e2c112b3b6&t=4357
[^] # Re: Scene demo
Posté par Toufou (site web personnel) . Évalué à 1 (+0/-0).
L'explication de Léonard est claire, mais j'ignorais que hardscrolling et syncscroll étaient synonymes pour certains et bon, pourquoi pas après tout on joue avec un aspect matériel (le timing avec la hbl).
Bêtement je fais la distinction a cause du STE qui permet le hardscroll sur le simple tripotage d'un registre du shifter alors que sur ST sans syncscroll point de salut :o)
[^] # Re: Scene demo
Posté par BAud (site web personnel) . Évalué à 3 (+1/-0).
hmmmm
HBL ?
STE Atari STe ? et ST c'est pour Atari ST j'imagine…
[^] # Re: Scene demo
Posté par bunam . Évalué à 1 (+0/-0).
ici ça parle de HBL https://nguillaumin.github.io/perihelion-m68k-tutorials/_of_revealing_the_unseen_and_expanding_our_consciousness_without_the_use_of_illegal_drugs.html
"Timer B is also called HBL, Horizontal BLank."
Toujours pas ma tasse de thé tout ça ;p
[^] # Re: Scene demo
Posté par Toufou (site web personnel) . Évalué à 1 (+0/-0).
HBL : Horizontal Blank Line => la fin du tracé d'une ligne, la VBL (Vertical Blank Line) c'est la même chose pour l'affichage de la dernière ligne de l'écran. Une interruption est associée par défaut d'ailleurs à chacun de ces évènements.
ST = l'atari ST oui dont le chipset vidéo (shifter) ne supporte pas le scrolling hardware (d'où les techniques de sioux pour y arriver), c'est une des amélioration arrivée avec le STE (ça, la palette étendue, le blitter…)
Désolé, j'aurais du développer :)
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.