Vraiment très intéressant, merci ! J'avais toujours mis le manque de bonnes adaptations arcade sur le dos des développeurs. En te lisant je comprends beaucoup mieux.
Du coup, quand on entend dire que l'amiga et le X68000 se valent, c'est uniquement vrai si on n'y regarde pas de trop près, non ?


C'est un détail mais je ne comprends pas comment on arrive à 3 couleurs avec 3 bits. Pour moi 3 bits c'est 8 couleurs.

EDIT : ca ne serait pas plutôt 2 bits, avec une valeur reservée pour le transparent ? (et là du coup ça colle avec les 15 couleurs quand on en combine 2).

Le x68000 est une borne d'arcade avec un clavier. L'Amiga est un ordinateur avec 8 sprites hardware... Le point commun des deux machines c'est le processeur central (68000 à 7Mhz sur l'Amiga et à 10 Mhz sur le X68000). La vraie différence réside comme avec la comparaison avec les bornes d'arcade dans la gestion des sprites et des layers. Le X68000 comme les bornes d'arcade ou les consoles de jeux gère indépendamment plusieurs layers. Les sprites sont sur un layer, le fond N°1 sur un autre layer et le fond n°2 sur un autre. Et tout ça peut bouger indépendamment les un des autres. Sur un ordi classique (Amiga, Atari, Apple, PC...), la page graphique est unique et il faut soit même dessiner dans l'ordre inverse de ce qui est affiché : d'abord le fond, ensuite les sprites. On dessinant les sprites, on re-écrit par dessus le décor. Avec des layers (qu'on pourrait rapprocher de calques invisibles qui vont en final se superposer pour former l'image), chaque niveau est indépendant. On peut d'ailleurs scroller les layers contenant le fond sans avoir à tout repeindre. On se contente de décaler les coordonnées d’affichage du layer (on appelle cela un scroll hard) à la différence d'un ordi classique où il faut tout redessiner à l'écran en permanence. L'autre différence tient à la gestion des couleurs. Sur un ordi, la palette (16 couleurs sur un ST, 32 sur un Amiga, 256 sur un PC VGA) est globale à tout l'écran et chaque point peut se voir attribuer une des couleurs de la palette. Sur un X68000 ou une borne d'arcade, chaque sprite a sa propre palette (généralement 16 couleurs) et chaque layer a aussi sa propre palette. Le X68000 peut afficher sans problème 16 sprites de 16 couleurs (en fait le X68000 autorise 256 sprites à l'écran tant qu'on en met pas plus de 16 par lignes), on se retrouve ainsi avec déjà 256 couleurs à l'écran, sans compter le décor de fond qui lui aussi peut afficher X couleurs. Sur Amiga, c'est 32 couleurs à l'écran, mélangé entre les sprites et le décor.

Si le X68000 fait de l'arcade 'perfect' (tant au niveau de l'animation que du visuel) c'est justement parce qu'il partage avec ses cousines les bornes d'arcade les mêmes caractéristiques techniques (gestion hard des sprites, gestion hard des fonds, palettes définit par sprite...).

Bon, ensuite il ne faut pas oublier que les adaptations des jeux d'arcades sur le X68000 ont parfois été faite directement par les éditeurs qui avaient créé la borne (Capcom pour Street Fighter II) et donc c'est forcément plus simple de reprendre la planche graphique d’origine pour faire l'adaptation. Les conversions d'Arcade sur l'Amiga (ou sur le ST), c'était fait avec les moyens du bord et des bouts de ficelles, c'est à dire sans AUCUNE aide de la part de l'éditeur. Ni les graphiques, ni les musiques, ni rien du tout. Pour la conversion de Space Harrier sur l'Atari ST, l’éditeur européen (Elite ?) s'est contenté de signer avec Sega un accord du genre 'autorisation de porter Space Harrier sur l'Atari ST'. Comment on fait les développeurs (français en l’occurrence) ? Ils sont allé sur les champs Elysées avec un caméscope pour filmer la borne d'arcade (en cachette car c'est interdit de filmer dans les salles d'arcades) et ils ont acheté une Master System avec le jeux pour avoir une idée du déroulement des niveaux. Tout a été fait à la main (graphismes, musiques, animation, séquencement du jeu) à partir des données récoltées comme ça. Et le résultat est inespéré au vu des moyens mis en oeuvre. Donc la conversion des bornes d'arcades sur Atari et Amiga, faut clairement pas trop leur jeter la pierre aux développeurs car ça souvent été héroïque.



C'est pourtant facile à comprendre, j'ai dit une connerie
On a bien 2 bit par point du sprite, ce qui autorise 4 couleurs dont une est réservée pour définir la transparence. Merci de m'avoir corrigé. J'ai mélangé mes couleurs et mes bits !

Olivier

Et un blitter !



Pas avec les sprites de l'Amiga non. Les "calques" sont parfaitement independants, tu peux redessiner le fond quand tu veux, ou meme ne pas le redessiner du tout.


---

Petite explication sur le blitter et les sprites hardware


Sur Amiga et autres micro, contrairement a une borne d'arcade ou une console, on a un "framebuffer". C'est a dire une zone memoire qui est une sorte de tableaux de pixels que la machine va retranscrire sous forme de points de couleurs a l'ecran directement.

Par exemple, imaginons que l'on ai une palette de 2 bits avec 0 = Noir, 1 = Bleu-verdatre fluo petant, 2 = fushia vomitif, 3 = blanc. Mettons qu'on soit en mode 3*3 pixels.

Si on a la plage memoire suivante:

0 1 1 0 2 2 0 3 3

L'ordinateur sait qu'il est en mode 3*3, donc trois pixels par ligne (c'est pour ca qu'on doit specifier le mode d'affichage, les fameux "mode 0", "mode 1", etc...), et va faire un "retour chariot" a bout de trois pixels.

Autrement dit, l'ordinateur interpretera ca comme:

0 1 1
0 2 2
0 3 3

Et donc on aura l'affichage suivant:



C'est moche comme palette hein ? Heureusement qu'aucun ingenieur sain d'esprit ne la choisirais jamais.

Donc on apercoit une limite qui est que si on veut faire defiler le decor, il va falloir modifier une par une la valeur de ces points.

C'est pour ca par exemple que certaines machines sont incapable de faire du scrolling fluide (au pif, les compatibles IBM).

Il y a plusieurs manieres de s'en sortir. L'une d'entre celles consiste a dire a la machine "Non mais en fait on va changer les regles, il ne faut plus commencer a lire a partir de la premiere colonne mais de la seconde". (ce que les premieres versions de l'Atari ST ne savaient pas faire - pas assez precisement en tout cas - mais ca a ete ameliore par la suite)

Une autre solution c'est le blitter de l'Amiga qui sait deplacer des gros blocs de donnees.

Le CPU, il ne comprend que des instructions tres simple. Donc mettons qu'on veuille ajouter une colonne de blanc a la fin, un CPU ferait ca:

Remplace Y0X0 par Y0X1
Remplace Y0X1 par Y0X2
Met la valeur "3" dans "Y0X2"
Remplace Y1X0 par Y1X1
Remplace Y1X1 par Y1X2
Met la valeur "3" dans "Y1X2"
Remplace Y2X0 par Y2X1
Remplace Y2X1 par Y2X2
Met la valeur "3" dans "Y2X2"

Ce qui prend beaucoup de temps.

Le blitter lui sait faire les decalages tout seul. Le CPU doit simplement dire au blitter:

"Decalle le tableau qui va de Y0X0 a Y2X2 de 1 colonne vers la gauche"
"Met la valeur "3" dans la colonne X2"

Et la le blitter se demerde tout seul pendant que le CPU est libre d'aller s'occuper des collisions, du score, des deplacements ennemis, etc...

Du coup on arrive a faire du scrolling fluide "comme sur une borne d'arcade", tout en pouvant au besoin etre super precis sur l'affichage.



Une borne d'arcade n'a pas vraiment de framebuffer. Elle a juste une liste de tiles (en gros, ce qui ferait office de palette de couleur sur un ordinateur), et une carte des tiles.

Au lieu d'avoir comme dans l'example precedant 0 = noir et 3 = blanc, on aurait plutot 0 = Tuyau, 1 = Nuage, 2 = Brique, 3 = Buisson

Si chaque tiles fait 16 pixels de cote, pour un terrain de jeu de 48*48 pixels, une borne n'a que 9 elements a gerer la ou l'Amiga doit composer avec 2304 elements.

C'est pour ca qu'a CPU equivalent, les jeux arcade restent quand meme souvant plus beau, car le CPU a beaucoup moins de boulot. C'est aussi pour ca que les jeux d'arcade sont un peu tous les meme et souvent chiants alors que le jeu micro est bien plus varie. Un jeu comme Worms avec deformation du terrain serait parfaitement impossible sur System 16, alors qu'il n'existe pas de jeu system 16 theoriquement inadaptable sur Amiga moyennant quelques sacrifices.


---

Le gros probleme de l'Amiga il s'appelle surtout l'Atari ST. Le ST n'a pas de sprites hardware et partage le meme CPU que l'Amiga. Du coup, si le jeu tourne "juste avec le CPU" sur sa version ST, on le reutilise tel quel sans utiliser les sprites hardware sur Amiga et basta. Deja a l'epoque, les ravages du portage au rabais.
_________________

L'Amiga ne gère que 8 sprites hardware (16 pixels de large) en 3 couleurs. L'idée de base était d'offrir un curseur de souris qu'on pouvait déplacer sans que cela n'oblige à sauvegarder / redessiner le fond de l'image. Comme l'Amiga avait 8 canaux DMA, ils ont mis 8 sprites car ca ne coûtait pas plus cher que d'en mettre 1.

Pour augmenter le nombre de sprites à l'écran (en afficher + de , il faut attendre que le sprite soit entièrement dessiné et ENSUITE seulement on peut le réutiliser. On doit même attendre 1 ligne vide pour cela. Donc si j'ai mon Sprite0 dessiné en haut à gauche de l'écran (ligne 0) et qu'il fait 16 lignes de haut (hypothèse d'un sprite 16*16), je peux le réutiliser uniquement à partir de la ligne 17. Donc à aucun moment mes deux Sprites0 ne peuvent se chevaucher. Un peu comme les deux dirigeables de l'écran de Shadow of the Beast qui sont bien l'un sous l'autre. L'Amiga n'a pas 8 sprites par ligne, le nombre de sprite dépend de la hauteur et de la position de chaque sprite.

La réinitialisation des sprites obliges ceux ci à évoluer dans des fenêtres horizontales qui ne se chevauchent pas. Et c'est finalement tout le paradoxe de l'utilisation de sprite hardware sur l'Amiga qui sont plutôt utilisés comme objets fixes ou alors se déplaçant simplement horizontalement (la plupart des jeux les utilisant sont d'ailleurs des jeux à scrolling horizontal).



Non. Ils utilisent les couleurs des 32 registres de couleurs. Mettre un sprite à l'écran n'augmente pas le nombre de couleurs (tjs 32). C'est même pire que ça car le choix des couleurs est imposé : Les Sprite 0 et 1 ne peuvent utiliser que les couleurs 17,18 et 19 (la 16 sert de couleur de transparence), les Sprites 2 et 3 les couleurs 21, 22 et 23 (la 20 sert de couleur transparente...).

En couplant deux sprites 3 couleurs (0 et 1 par exemple), les registres de couleurs utilisables vont de 17 à 31 (la 16 est la couleur transparente).

Encore une fois, les sprites sur Amiga ont comme gros problème leur faible nombre (8), leur faible taille (16 pixels de large) et leur faible coloration (3 couleurs). Ils s'utilisent en complément (nice to have) d'un moteur de rendu basé sur des bitmaps.



Ni l'un ni l'autre en fait car les deux systèmes sont quand même très différents, même si tout comme tout hardware conçu pour afficher des éléments à l'écran on puisse trouver des parties communes.



Avec des bit plans de 8 KB (320*200 en 1 bit) avec une volonté d'afficher la maximum de couleurs (32), l'Amiga va de toute façon devoir gérer 5 plans * 8 KB = 40 KB de mémoire graphique. Le découpage en 5 zones distincts simplifie et complexifie à la fois (en fonction de ce que l'on veut faire), mais c'est 40 KB à gérer, là où une borne d'arcade se contente de gérer des pointeurs de pointeurs (le background est composé de Tiles, elles même composées de 16*16 points). Heureusement le blitter est là pour aider. Mais ca reste de la gestion de bitmap classique comme sur les autres ordi. La preuve, même le ST y arrive.



Ce qui a manqué aux PC, ce n'est ps tant la puissance du processeur mais le fait de ne pas avoir de registre vidéo qui donnait la position du faisceau d'électron rafraîchissant la page. En ne sachant pas quelle ligne étant en cours de traitement, on prenait le risque de modifier les objets de cette ligne et ainsi de couper le faisceau ce qui engendrait des marches d'escaliers.



Là je ne suis pas trop sur de comprendre ce dont tu parles... Tu évoques le pointeur de page graphique qui sur les ST étaient aligné sur une adresse se finissant obligatoirement par 00 (alignement sur 256 octets) ?



Worms tout comme Lemmings ont très bien été adaptés sur Megadrive, qui est quand même la System 16 du pauvre. Faudrait pas non plus prendre les programmeurs consoles pour des incapables. Ils font même de la 3D (F15 & Co) alors que la console n'est pas sensé afficher des points ni des lignes... Si les programmeurs sur micros savent bidouiller, leurs camarades d'en face aussi !



Oui en résumé : la résolution graphique, le framerate, le nombre de couleurs, la taille des sprites et la jouabilité (1 bouton sur la manette)



Je n'arrive pas à retrouver la phrase de la semaine qui disait que le gros problème de l'Amiga était ses fans boys.

Le ST a été une chance pour l'Amiga car cela lui a conféré dès le début des jeux qui n'ont pas coûté trop cher à adapter à une époque où personne ne croyait en la machine ni en Commodore (qui enchaînait les résultats financiers catastrophiques). Le ST s'est tout de suite très bien vendu, il faudra attendre l'Amiga 500 et sa baisse de prix pour que l'Amiga décolle enfin. En mutualisant les développement sur ces deux machines, les éditeurs ont permis à l'Amiga (et à l'Atari ST) de se constituer un si belle ludothèque.

L'Amiga est une super machine mais cela coûte très cher (en terme de complexité de développement) pour lui faire sortir les tripes. La plupart des programmeurs se contenteront donc du minimum syndical. D'ailleurs, les meilleurs jeux de la machines ne sont pas les plus spectaculaires visuellement. C'est même plutôt l'inverse. Un beau rendu a souvent été synonyme de pauvreté du gameplay (Shadow of the Beast, Unreal, Agony...).

Olivier

Notons cependant qu'en faisant joujou avec le Copper, on peut changer ces couleurs à chaque nouvelle ligne. C'est loin d'être idéal, mais ça permet les fameux effets de dégradés si caractéristiques de l'Amiga (cf. le compteur de points de vie de Shadow of the Beast).



A titre de comparaison, la NES gère 64 sprites (de 8x8 ou 8x16), la SNES 128 (8x8, 16x16, 32x32 ou 64x64) et la Neo Geo 380 (de tailles arbitraires allant de 1x2 à 16x512. Chose intéressante, la Neo Geo ne gère que des sprites, y compris pour les décors -- elle n'a pas de notion de background). Et j'imagine qu'il là aussi existe des bidouilles pour augmenter artificiellement ce nombre.



C'est pour pallier à ce problème qu'on a inventé le double buffering/page flipping, mais ça nécessite de stocker un deuxième framebuffer en RAM (ce qui coûte 64 KiB supplémentaires quand on travaille en VGA).

De plus, sur PC la fréquence de rafraichissement de l'écran varie d'une machine à l'autre en fonction de la qualité du hard qu'on utilise (à la grande époque du CRT, écrans pourris: 60 Hz, écrans moyens: 75 à 85 Hz, écrans haut de gamme: 100 à 120 Hz), il est donc impossible de se baser là-dessus pour synchroniser la boucle d'événements du jeu (il faut travailler avec des timers externes -- cf. mon article sur l'animation si vous voulez plus de détails).

Ironie du sort, c'est aussi le cas sur Amiga/ST (50 Hz en Europe, 60 partout ailleurs), mais les développeurs tardent à s'en rendre compte (ou s'en foutent) et on se retrouve avec les mêmes problèmes de conversion que sur consoles.



Un truc qui m'étonne, c'est que le framebuffer est stocké ligne par ligne, pas colonne par colonne: l'astuce décrite par FF_Clad permet de faire un scrolling vertical de manière très simple, mais pas un scrolling horizontal. L'Amiga et/ou le ST disposaient-ils d'astuces techniques pour simplifier le scrolling horizontal?

(la NES ne gérait en hard que le scrolling horizontal -- pour avoir du vertical ou du diagonal fluide, il fallait une puce supplémentaire dans la cartouche)



Je serais d'ailleurs très curieux de savoir comment ils y parvenaient. Tu aurais un article sous la main qui explique ça?
_________________

https://twitter.com/MaxNoelBass
https://www.youtube.com/c/TheTiberianSons

Pour précision : Le contrôleur CRTC d'une carte VGA fourni un bit qui indique si le faisceau est un train d'effectuer un retour horizontal ou non, ce qui permet en théorie de compter les lignes. Sauf qu'en pratique ce bit n'est relié a aucune IRQ, et qu'il faut procéder par scrutation. Au final, en dehors des coppers ça ne sert pas à grand chose car le processeur n'a pas le temps de faire grand chose entre 2 lignes.
Sur amiga ça se passe comment ?

@Wild_Cat : 99% du temps on emploie le KB au lieu du KiB, mais l'inverse j'avais jamais vu


En VGA il y a l'astuce qui consiste à déplacer le pointeur de mémoire vidéo, non pas dans une page vidéo de 320x200, mais dans une page virtuelle de 640x400 (en agissant sur des registres du CRTC pour faire "dépasser" l'image de l'écran). Ça règle le problème des pixels du bord gauche qui reviennent à droite et inversement. Mais du coup on perd le double buffer.


Est-il possible sur ces machines d’accéder directement à la mémoire vidéo ?

Oups!



C'est justement tout le problème: oui, mais la mémoire vidéo est une tilemap (+ une liste de sprites), pas un framebuffer. L'image finale n'est jamais stockée nulle part. C'est la raison pour laquelle la NES est capable d'afficher du 256x240 en 25 couleurs avec seulement 2 KiB de RAM vidéo (en comparaison, un framebuffer de 256x240 en 16 couleurs nécessite 30720 octets).
_________________

https://twitter.com/MaxNoelBass
https://www.youtube.com/c/TheTiberianSons

Ca veut dire que ces machines composent chaque pixel de la frame au fur et à mesure du balayage de l'écran, à partir du tilemap et de l’emplacement des sprites ??
C'est... étonnant, pour quelqu'un qui a toujours travaillé avec une mémoire vidéo

En gros oui, c'est comme ça que ça fonctionne. C'est comme un mode texte sous stéroïdes, et ça permet d'obtenir de jolis graphismes avec un CPU ridicule et peu de RAM vidéo (donc pour pas cher ).

Une excellente explication de la manière dont l'affichage de la NES fonctionne (avec plein de captures d'écran!) peut se trouver dans ce thread: http://theshizz.org/forum/index.php/topic/31758-how-the-nes-could-have-made-snes-level-of-graphics/


_________________

https://twitter.com/MaxNoelBass
https://www.youtube.com/c/TheTiberianSons

Un grand merci à Torben Larsen et Martin Pedersen dont la phrase de la semaine a permis d'engendrer cette passionnante discussion technique.
Mais pour en revenir à la phrase elle même, je pense qu'elle est exacte si on la remet dans son contexte. En 1987, je pense qu'il ne devait pas être aisé pour 2 ados Danois (ils sont danois ? je sais plus) d'accéder à du hardware permettant de développer pour des bornes d'arcade ou des consoles japonaises, voire même d'en connaitre les spécificités techniques.
Parmi toutes les machines sur lesquelles ils pouvaient développer librement, à savoir les micro-ordinateurs occidentaux, l'Amiga était en effet la machine dont les capacités graphiques et sonores permettaient de reproduire le plus fidèlement possible un jeu d'arcade de la même époque. Quand ils disent "spécifications techniques", à mon avis ils doivent parler uniquement de certains aspects évidents comme la palette de couleurs, ou le nombre de voix sonores.

"J'ai participé à une convention en Ecosse il y a un an ou deux. Il y avait 200 lycéens dans la salle. Je me suis présenté, je leur ai fait la liste des jeux sur lesquels j'avais travaillé, et ils m'ont tous acclamé lorsque j'ai cité GTA. J'ai demandé à tous ceux qui y avaient joué de lever la main. Tout le monde ou presque l'a levée. J'ai alors demandé à tous ceux qui avaient plus de 18 ans de garder la main en l'air. Toutes les mains se sont baissées. J'ai pris mon portable en leur disant que le jeu était interdit aux moins de 18 ans, qu'ils avaient violé la loi, et que donc j'allais 'appeler la police'. Texto. Il a fallu une demi-heure pour que les profs parviennent à calmer les gamins et à leur assurer qu'ils n'allaient pas être arrêtés. Curieusement, on ne m'a jamais demandé de revenir." (Brian Baglow, chargé des relations publiques chez Rockstar)

Génial, cette citation me fait rire à chaque fois que je viens sur le site ! C'est vraiment des cas chez Rockstar !
_________________

Dans la vie, il y a 3 catégorie des personnes : ceux qui savent compter et ceux qui ne savent pas compter. (Anonyme)

C'est intéressant d'avoir cet avis d'un compositeur reconnu, mais je ne suis absolument pas d'accord. Sur la centaine de jeux auxquels j'ai joué sur cette génération, il y en a seulement une poignée dont je serais capable de fredonner un air, en dehors des vraies chansons (c'est plus facile) et des remix : le thème sous-marin de Rayman Legends, l'air sifflé de Deadly Premonition, quelques thèmes de Sonic Unleashed et de HotD Overkill, et c'est bien tout.

Ah si, il y a aussi le "Poin Poin Poinnnnnnn" de Gears of War.

Je pourrais certainement en reconnaître (notamment ceux de De Blob, par exemple, ou Little Kings Story), mais la musique de jeux vidéo est de plus en plus calquée sur celle du cinéma, et si effectivement elle réussit souvent à faire naître une belle ambiance, les mélodies sont aux abonnés absents.

Alors qu'il y a beaucoup de titres sur MD, Saturn ou Dreamcast sur lesquels j'ai passé beaucoup moins de temps que des jeux actuels, et dont les mélodies m'ont bien plus marquées. J'ai fait Shining Force 2 une fois il y a 15 ans, je me souviens du thème de la map.
_________________

Ils sont tous méchants (sauf Sega, qui est juste con).

En même temps, on ne peut pas lutter, là.


_________________

Le Blog de Batbad - Simbabbad sur Steam - Compte Twitter

Le jour on fera ici le top 10 de la Gen, je pense que ce jeu en fera partie.
_________________

Ils sont tous méchants (sauf Sega, qui est juste con).

top 10 musical ou jeu ?

Pour les themes musicaux je suis d'accord j'accroche et je retiens moins les airs récents. trop d'orchestral, d'opera tout ca.
Heureusement que y'a Duke et son bon vieux rock
_________________

Tu veux dire qu'il sera dans le tien, non?

Perso, j'aimerais lui redonner une chance, mais je crois que pour ça, il faudrait peut-être que je passe par une grande première dans ma "carrière" de gamer et opte pour quelque chose que je n'ai jamais cautionné: en visionner un playthrough. Car en y jouant, y a rien à faire, je rentre pas dedans comme je l'espérais, et j'ai peur de ne jamais y parvenir, d'autant plus que le jeu ne me donne clairement pas envie de me faire violence.
_________________

Pour ma part, j'ai une explication beaucoup plus simple: plus jeunes, nous avions nettement moins de jeux, donc nous y passions beaucoup plus de temps. D'où le fait que nous ayons assimilés plus aisément les mélodies de ces jeux que celles des titres actuels que nous avons, hélas, un peu trop tendance à enchaîner.

Il y a aussi notre façon de jouer qui a pas mal évolué, à commencer par le jeu en ligne qui parasite les bandes-son, mais aussi les multiples sollicitations de toutes natures qui nous font décrocher, ou du moins nous éloignent de notre capacité à nous investir pleinement dans un titre. C'est, pour schématiser, la différence qu'il y a entre regarder un film au cinéma dans le calme et regarder un film en famille avec les gamins qui vadrouillent, le téléphone qui sonne, le chien du voisin qui gueule et compagnie. On perd le fil de sa concentration et, de fait, on devient moins sensible aux différents éléments de l'objet qui nous intéresse.
_________________

"Il n'est pas de lutte plus violente et déterminée que celle d'un homme face à son envie d'aller aux toilettes" - Karate Boy

Oui oui, je me suis mal exprimée.

@Odysseus : ça dépend de la façon de jouer de chacun, personnellement je pense que je joue dans de meilleures conditions aujourd'hui que lorsque j'étais plus jeune, et pourtant beaucoup de jeux rétro que je n'ai faits qu'une seule fois m'ont bien plus marqué que les jeux actuels musicalement.
_________________

Ils sont tous méchants (sauf Sega, qui est juste con).

A mon avis il y a aussi le fait que le hardware audio plus primitif et le stockage plus réduits ne permettaient pas d'atteindre la "qualité CD" qu'on a aujourd'hui dans les jeux.
Avec seulement certains sons FM, difficile de rendre correctement les instruments classiques et leurs subtilités, qu'utilisent presque toutes les BO de films genre "ambient".
Autrement dit, on n'avait pas tellement le choix. Du coup on ne jouait pas tant sur la nature des sons que sur leur hauteur et le rythme => plutôt "mélodie" qu'ambiance sonore.

Disons plutot qu'a l'époque j'etais fan de musiques electroniques et de rock, et que les musiques de jv se rapprochaient pas mal de ces 2 genres.

Maintenant y'a un peu de tout
_________________