Hardcore Retrogaming

[upsilandre]

De toute facon faut pas se mentir, pour des raisons de limitation technique trop forte,  a cette epoque les jeux c'etait soit tres mauvais soit avec une dimension ludique mais qui se limitait a t'occuper 30mn voir 1 heure et ensuite tu ranges définitivement le jeu dans ton placard.
J'ai pas mal joué a la VCS, c'etait la console de mon enfance, mais j'en ai aucun souvenir passionné, c'est le souvenir d'un jouet parmis d'autre.

A cette epoque les cartouches etaient tellement petites que c'est le code lui meme qui prenait deja trop de place, on parle plus alors seulement de contrainte sur les data et les assets et les consequences que ca peut avoir sur la répétitivité du jeu (comme un jeu NES par exemple) mais de contrainte sur le code lui meme et la ca touche directement au gameplay.
Dans ta video on le voit raller par exemple quand il entre dans une piece et qu'un serpent apparait exactement au meme endroit et donc le tue sans qu'il puisse réagir mais eviter ce mauvais random implique d'ajouter des conditions dans la boucle de gameplay et chaque condition c'est du code qui prend de la place, une vingtaine d'instruction pour ajouter une condition c'est 40 octets c'est 1% de la cartouche.
Aujourd'hui le code d'un jeu moderne c'est 0.01% de la taille d'un jeu et donc 99.99% de data/assets alors que a cette epoque le code du jeu aussi minimaliste soit-il ca pouvait facilement monter a +50%, le moindre bout de code economisé (au détriment du gameplay) etait une veritable economie.

[upsilandre]

Intéressant. :laporte:

Je vois rien sur ton image, j'en déduis que ce n'est pas un screen du glitch en question?

non ca c'est juste l'ecran de depart, le chateau jaune c'est ton chateau (toi t'es le carré) et le bute du jeu c'est juste de trouver le calice et de le ramener dans ce chateau (qu'il faut ouvrir avec la clé jaune)

La piece secrete c'est celle la

[JiHaisse]

:jap:

[upsilandre]

Une autre date qui ressort de mes fouilles c'est fin 1979.
Le meme mois sort l'Intellivision, l'Atari 400/800 et le TI 99/4 (qui sera remplacé plus tard par le TI 99/4A) et elles confirment toutes une rupture technologique.

L'Intellivision est une console dont j'ai deja longuement parlé et vraiment intéressante technologiquement.
L'Atari 400/800 et le TI 99/4 sont des micro "familiaux" mais tres proche d'une console comme souvent a l'epoque, la frontiere est flou. Ce sont des machines qui se branche sur un televiseur, qui n'ont qu'un port cartouche de serie (lecteur cassette et disquette en option) et donc certain jeux en cartouche, elles ont des ports manettes (4 port manettes sur l'Atari chose assez exceptionnel pour le signaler car on revera ca que sur N64 il me semble), et des capacités audio/video avancé. Tout ce qu'on attend d'une console.

La ou ces machines se distingue des consoles c'est en général par le prix (bien plus chère qu'une console), la presence d'un clavier integré (quoique la console Odyssey2/Videopack en avait un aussi ce qui est assez drole etant donné que c'est aussi la console technologiquement la moins capable d'afficher du texte de toute l'histoire et donc un clavier inutile, une drole d'idée. Une console développé avec Intel et validé par Ralph Bae), la proposition d'une initiation a la programmation (a peu pret la seul fonction d'un micro de l'epoque) par l'intermediaire d'un language Basic integré dans le Bios de la machine ou vendu en cartouche. Et d'un point de vu technologique ces machines se distinguaient d'une console principalement par l'architecture memoire avec un tres gros pool memoire mais unifié et partagé par tout les procs (CPU et GPU) plutot que de toutes petites memoires mais specialisés et reservés a chaque procs.
Avoir beaucoup de RAM etait une nécéssité pour ces machines qui se devaient de proposer la possibilité de programmer d'ou ces choix technologiques un peu different mais au final c'etait avant tout des machines de jeu et qui doivent etre abordé dans l'histoire du jeu video.


Quelle est donc le point commun de ces 3 machines? La rupture technologique de cette fin d'année 1979?
Toutes les 3 sont a ma connaissance les 3 premieres machines a proposer un GPU "moderne" avec gestion d'un background, une backtable, un Tile set, des sprites 2D (et plus ou moins de reflexion sur le scrolling). On voit apparaitre le type de GPU qui vont nous accompagner ensuite pendant la génération de console 8 et 16bit. Mais pas seulement, ce sont aussi les 3 premieres machines a proposer les premiers vrai sound chip avec des performences qui permettent de jouer de la musique (avec une resolution suffisante pour jouer des notes "justes")
Ca fait beaucoup de coincidence simultané, suffisement pour en faire une date remarquable, y a une vrai rupture technologique assez net meme si dans le resultat (les jeux) c'est lissé par d'autre facteur.


Ca ressemble aussi a une sorte de confrontation entre Texas Instrument et General Instrument les 2 concurrents de l'epoque. General instrument a ecrasé TI sur le marché des Pong en fournissant 75% des pong chip de tous les pong de la planete.
L'intellivision est une machine 100% Général Instrument, le TI 99/4 est une machine 100% TI evidement et sortent toutes les  en meme temps.
Les 2 machines ont bizarrement cette particularité d'etre toute les 2 equipé d'un CPU 16bit (pas vraiment ordinaire pour l'epoque) ce qui donne une premiere confrontation technologique. Elles sont donc aussi equipé d'un GPU moderne ce qui est aussi une nouveauté initié sur ces machines et celui de TI sera par la suite celebre car utilisé dans plein d'autres machines (notamment servira pour toutes les machines Sega et inspirera celui de la NES) donc c'est TI qui gagnera cette bataille. Et ces machines seront aussi la premiere confrontation des 2 sound chip ensuite devenu tres celebre et qu'on retrouvera dans absolument toutes les consoles et micro a venir jusqu'a l'Atari ST mais la c'est General Instrument qui gagnera cette bataille notamment par sa qualité superieur (ce qui fait d'ailleurs que l'Intellivision a objectivement un sound chip de meilleur qualité qu'une Master system sortie 6 ans plus tard mais equipé encore du sound chip de TI, c'est dire la faiblesse de la MS sur ce point...)
Donc intéressant a regardé aussi sous cette angle.


L'Atari 400/800 m'interresse particulierement. Les bases technologiques sont celle de l'Atari VCS, c'est le meme CPU 6502 overclocké a 1.8mhz (donc comme une NES ce qui fait un tres bon CPU) et reprend aussi le GPU TIA de la VCS customisé mais qui reste un GPU 1D comme je l'ai deja longuement expliqué mais cette fois accouplé a un second chip, un microprocesseur qui va piloter le TIA pendant toute la frame (au lieu de devoir le faire avec le CPU comme avec la VCS) pour en faire un vrai GPU 2D autonome. Mais ce second procs qui accompagne le TIA execute réelement un programme pendant l'affichage, une "display list", ce qui donne alors un GPU programmable avec une certaine flexibilité et ouvre plein de possibilité de trick comme la possibilité notamment de faire du vrai scrolling full screen d'une facon economique en ressource et tres proche d'une NES.
La ou le TI 99/4 est capable d'afficher une image de grande qualité pour l'epoque (notamment en terme de couleur).  l'Atari 400/800 est un peu plus limité en qualité d'image mais a plus de potentiel en terme de dynamique et de mouvement et donc encore plus "console", se detache tres nettement du TI99, c'est une machine clairement plus intéressante pour les joueurs, le TI99 ne fait pas le poid.

un petit comparatif de scrolling sur Zaxxon entre l'Atari et des consoles sortie bien plus tard mais equipé du GPU de TI tel que dans le TI 99/4 (ici Coleco et SG1000, le TI99 serait incapable de faire cela malgres le meme GPU car il avait de grosse contrainte CPU/memoires).

Sur Colecovision equipé donc du GPU TI


Sur SG-1000 equipé du meme GPU


Sur Atari 800, moins riche graphiquement mais un vrai scrolling au pixel et sans gros effort, au final un cachet encore plus console que des consoles pour une machine plus vieille.


Meme son sound chip le Pokey est intéressant, ca sera l'une des rares machines avec le C64 et la NES a avoir un sound chip sur mesure et pas un sound chip TI/GI/Yamaha. L'Atari 400/800 est une vrai machine de jeu.
C'etait je pense une machine ideal pour la scene Demo (plein de trick visuel possible, des capacités pour faire de la chiptune). La scene demo a surtout debuté avec le C64 mais je me demande si l'Atari 800 a pas aussi initié le mouvement.
En comparaison l'Atari 400/800 meme si moins connu etait technologiquement plus interressant et plus d'avant-garde que ne l'etait le celebre Atari 520/1040

La console Atari 5200 qui sortira plus tard justement entre la Colecovision et la SG1000 est en fait un Atari 800 ce qui en fait finalement une machine plus intéressante que je ne le pensais jusqu'alors mais qui n'aura pas le temps de s'exprimer. Elle pourrait etre consideré comme la premiere console "scrolling free" malgres que ca ne soit pas aussi cablé que dans la NES, sur NES non seulement le scrolling ne prend pas de ressource mais il ne demande pas vraiment d'effort non plus du programmeur car c'est vraiment prit en charge par le hardware, l'Atari demande un effort de comprehension et de programmation avec un peu de ressource pour faire un scrolling propre mais c'est une machine quand meme bien plus capable en scrolling que ce qui existait a ce moment la. C'est le chainon manquant.

[Coca_Impact]

Encore très intéressant, je pense qu'il me manque un gros bagage pour comprendre tout ce que tu dis, mais l'essentiel  est compris ^^

[guyzou]

On va dire que ca a sa place ici:
http://www.lemonde.fr/pixels/article/2014/08/25/florent-lecoanet-30-ans-et-quintuple-champion-du-monde-a-super-mario-kart_4475456_4408996.html

Titre un peu pompeux vu le nombre de participants, mais j'apprécie l'initiative de ces fous de la manette! :jap:

Sans doute quelque uns ici aurait leur place dans les 10 meilleurs mondiaux....

[upsilandre]

Je me suis fais une petite session NES 1986 avec du Zelda, Metroid, Castlevania, Kid Icarus, Ghost'n goblins.
Ce qui m'a sauté aux yeux c'est qu'a cette epoque tout est encore a faire et y a pas encore les codes du jeu video qu'on connait ce qui donne parfois des choix un peu perturbant quand t'y rejoue aujourd'hui

Par exemple cette idée d'utiliser des coeurs pour autre chose que la vie c'est tres genant (Dans Castlevania les coeurs servent pour la magie et dans Kid Icarus c'est de la monnaie, personne ne ferait ca aujourd'hui).
Et niveau gameplay y a chaque fois des choix qui m'ont géné, qu'on trouverait etrange aujourd'hui.
Par exemple dans Catslevania quand tu sautes t'es ensuite obligé de tirer dans la direction que t'avais avant de sauter, tu peux pas tirer dans l'autre direction une fois en l'aire (pour shooter une chauve souris qui t'arrive dans le dos par exemple), tres perturbant.
Dans le meme genre sur Metroid si tu sautes en tirant vers le haut tu reste bloqué dans cette direction, tu ne peux pas au milieu de ton saut décider de tirer vers la gauche ou la droite pour shooter un ennemie qui approche, tres génant.
Dans Kid Icarus quand t'es a l'arret et que tu tire vers le haut (ou tu simplement que tu vise vers le haut) ca te bloque completement, tu peux meme plus sauter pour réagir par reflexe a une attaque.
Dans Zelda l'absence de déplacement en diagonale est perturbant aussi.

Parmis ces 4 la le plus sexy a rejouer c'est Castlevania je trouve, moins aride, on accroche assez vite et ca fonctionne bien encore aujourd'hui. C'est d'ailleurs tres proche d'un ghost'n goblins (je suis assez fan des Makaimura) je pense que c'est pas juste une coincidence. Le contexte morbide, le type de saut, les armes multiples que l'on ramasse parfois contre son grés (nan je voulais pas cette arme de merde), pas de tire vers le haut mais tire accroupie, on retrouve vraiment les meme code de base  (mais ghost'n goblins est un peu moins rigide a manipuler notamment parce que y a pas ce choix etrange dont j'ai parlé plus haut, ici on peut tirer dans la direction qu'on veut pendant le saut).
Sauf que Ghost'n Goblins etait un jeu d'arcade, Castlevania est concu pour le salon et donc une adaptation avec cette intelligence d'y ajouter toute cette profondeur suplementaire car pas bridé par le contexte particulier de l'arcade qui conditionne le gamedesign. Je trouve que c'est une bonne illustration de cette transition de l'arcade au salon qui a beaucoup participé aussi a ouvrir de nouvelle porte. D'ailleurs on a l'impression que ce concept du Metroidvania qui arrive en force cette année la est vraiment la consequence de cette volonté de rupture avec l'arcade (tous ces jeux la, Zelda, Metroid, Castlevania, Kid icarus, sont un peu des Metroidvania)
Je pense que Castlevania a vraiment du impressionner les petits japonais de l'epoque, ca avait de la gueule quand meme comparé a ce qui existait.

Sinon j'ai profité de cette session pour observer l'usage des differents canaux sonore de la NES sur ces jeux vu que je m'intéresse pas mal aux sound chip en ce moment et l'usage est tres semblable d'un jeu a l'autre, on retrouve un certain schéma. De toute facon faudrait que j'ecrive un truc sur les sound chip.

[Coca_Impact]

Pour avoir fait du Metroid tout récemment, rien ne m'as vraiment gêner, j'ai même trouver ça étonnamment peu rigide...Et pourtant c'est pas mes qualités manette en main qui font mon prestige ni les autres d'ailleurs ! Mon souvenir est peut-être biaisé  :vice:

[upsilandre]

Pour avoir fait du Metroid tout récemment, rien ne m'as vraiment gêner, j'ai même trouver ça étonnamment peu rigide...Et pourtant c'est pas mes qualités manette en main qui font mon prestige ni les autres d'ailleurs ! Mon souvenir est peut-être biaisé  :vice:

C'est sur que les sauts sont moins rigide que Castlevania ou ghost'n goblins qui sont sur d'autre mecanique mais ce choix sur les tires par exemple est difficile a comprendre comme pour Castlevania. Y a des choix de mecanique de tire en saut qui sont pas terrible (pour Castlevania je pense savoir pourquoi).

[upsilandre]

Un truc qui m'a surprit hier dans Castlevania c'est qu'il y a vraiment beaucoup de clignotement de sprite. Je l'ai deja expliqué, sur NES et MS tu peux afficher beaucoup de sprite a la vertical mais pas a l'horizontal ou t'es limité a 8 sprites par scanline (c'est a dire par ligne affiché).

Ici dans Castlevania y a beaucoup de choix handicapant. Notamment l'arme principale qui est un fouet qui est donc un long sprite horizontal quand tu fouettes. le coup de fouet consome 6 sprites horizontaux + les 2 du personnage on atteint deja le max de 8 sprites. Tout ce qui s'affichera sur la meme ligne va donc produire des clignotements

A cela ils ajoutent une autre contrainte. Des elements de decors déstructibles (colone de feu, chandelier) qui sont composés de sprites au lieu de tiles de background et en plus a la hauteur d'ecran la plus charger en général. Du coup meme sans ennemie tu peux avoir des clignotements.

Et un 3eme points qui agrave encore les clignotements c'est le format des sprites. Sur NES tu as 2 choix de format de sprite. le standard 8x8 et le format 8x16 utilisé dans Castlevania et lorsque tu utilises le format 8x16 t'es obligé de l'utiliser pour tous les sprites (meme si le sprite fait seulement 2 pixel de haut) et donc quand t'as des clignotements tu peux te retrouver avec des clignotements sur 16 pixels de haut (donc l'equivalent de 2 sprites standard) au lieu de 8 a cause de ce format.

Par exemple dans Castlevania la chaine de ton arme fait 3 pixels de haut mais elle est obligé d'utiliser quand meme des sprites de 16 pixels de haut qui occupe donc 16 scanlines et augmente les chance de saturer l'affichage de sprite par scanline.



Voila a quoi ressemble Castlevania dans une situation sans ennemie mais avec juste 2 elements de decors destructible (qui utilisent donc des sprites) et l'utilisation de l'arme.
Ici sur l'emulateur on peut tricher et cocher une option pour s'affranchir des limites hardware de la NES et tout afficher meme quand la console n'en est pas capable. En effet sur cette simple scene on peut compter deja 12 sprites alignés a l'horizontal sur les memes scanlines alors qu'elle ne peut en afficher que 8.





Du coup en réalité il va falloir enlever 4 sprites pour que ca devienne affichable. Et donc quand on emule vraiment la NES sans cocher l'option magique ca donne ca:





et la frame d'apres on enleve 4 autres sprites different pour alterner et pouvoir ainsi afficher ceux qui avait disparu la frame d'avant et les rendre visible au joueur.





et ainsi de suite a chaque frame ce qui donne les clignotements bien connu





Et comme c'est des "double sprite" format 8x16 meme pour la chaine c'est donc comme si t'avais 2x plus de sprite qui clignotait. Avec un format 8x8 la partie superieur des flammes ou du corp du personnage serait indépendante et n'aurait pas clignoté car ne serait pas sur les meme scanline que la chaine.



Mais y a un 4eme element dans le jeu qui ajoute encore plus de clignotement. Plus difficile a expliquer et surtout a justifier car pas directement lié aux limitations d'affichage de la NES.



Ici sur cette image on voit que le personnage au repos est composé de tout juste 4 sprites 8x16, tout comme les colonnes en feu. Donc sur cette scene ca donne un max de 6 sprites sur la meme scanline. On est bien en dessous de la limite d'affichage de 8 et donc aucun probleme pour la NES a afficher cette scene sans clignotement et c'est bien le cas.

Mais quand on va se placer devant la colone alors on se retrouve avec ca a l'ecran





Ca clignote de partout alors meme qu'on est en dessous des limites d'affichage. D'ailleurs vous pouvez vous amusez a faire le test sur emulateur, meme en activant l'option magique qui permet en emulation de s'affranchir de la limite des 8 sprites ce clignotement la reste present contrairement aux autres. alors pourquoi?



C'est lié a la facon dont est géré la liste de sprite. La NES gère une liste de 64 sprites, c'est la liste de tous les sprites qui sont affichable sur l'ecran. Mais cette liste sert aussi de liste de priorité pour le PPU (GPU de la NES).
Un sprite c'est un element graphique qui est composé de pixels opaques mais aussi de pixels transparents qui laissent apparaitres ce qu'il y a derriere lui et ceci implique de déterminer qu'est ce qui est derriere et qu'est ce qui est devant et c'est l'ordre de la liste de sprite qui définie les priorités. Les sprites les plus haut dans la liste sont les plus prioritaires et s'affiche donc devant ceux qui sont en bas de la liste.

Et surtout c'est aussi cette liste de priorité qui va déterminer quelles sont les sprites qui ne seront pas affichés quand on dépasse la limite de 8 sprites sur la meme scanline. Si y a 10 sprites sur la meme ligne ce sont les 2 sprites les plus bas dans la liste qui seront zappé.
Et donc pour eviter que ce soit toujours les memes sprites qui soit exclus et qui alors deviendrait completement invisible a l'ecran, les programmeurs inversent la liste de sprite a chaque frame (ou la melange) ce qui change les priorités des sprites a chaque frame et produit les clignotements qu'on connait mais permet de rendre visible au joueur tous les elements.



Mais dans cette exemple on est dans un cas particulier ou l'on superpose 2 sprites, celui du personnage et celui de la colonne qui est un element du decors destructible composé de sprites. Avec des ennemis ou des items cette situation n'arrive pas vraiment car l'item disparait et l'ennemi te repousse mais ici on a une vrai superposition de sprite.
Normalement c'est dans cette situation que les priorités de sprites sont utilent, la logique voudrait que le personnage soit plus haut dans la liste que la colonne de feu et ainsi etre prioritaire et pouvoir etre tout le temps afficher par dessus la colone mais ici le programmeur melange la liste de sprite a chaque frame pour anticiper les moments ou y aura une surcharge de sprite horizontal et donc brouille toute logique de priorité.
Du coup les sprites qui composent le personnage sont parfois prioritaire et parfois ce sont ceux de la colonne qui sont prioritaires. Cette fois y a pas réelement de sprite qui disparaissent de l'affichage, tous les sprites sont bien affichés mais sont recouvert par un autre en alternance.





On se demande pourquoi rien est fait pour eviter au moins ca. Soit mettre tout le temps le personnage en haut de la liste pour qu'il soit toujours prioritaire et melanger seulement le reste de la liste ca suffirait pour les moments de surcharge.
Soit tout simplement désactiver le melange systematique de la liste de sprite quand c'est pas nécéssaire, c'est a dire quand y a pas de surcharge horizontal, et y a justement un flag dans l'un des registres du PPU qui t'indique cela. Ce flag s'active chaque fois que le PPU se retrouve dans une situation ou y a + de 8 sprites sur la meme scanline donc le programme peut savoir a quelle frame y a surcharge et donc activer le melange de la liste de sprite seulement quand c'est nécéssaire ce qui alors eviterait d'avoir des clignotements dans cette exemple ou y a pas de surcharge. Ce flag sert a ca, pourquoi ne pas l'utiliser?

Mais le mieux serait d'utiliser des tiles de background au lieu de sprite pour ces elements de decors. Tu peux tres bien faire des elements de décors destructibles avec des tiles de background, ca reglerait ce probleme + d'autre probleme de surcharge de sprite.

[Coca_Impact]

Pour le coup était tout vraiment très claire!
Peut-être qu'utiliser des sprites était ce qu'il y avait de plus court...Je sais pas XD

[upsilandre]

Ici le principale interet c'est que ca leur permet de placer cette elements de decors n'importe ou peu importe le background derriere.



on voit ici une barriere derriere la colone, puis une fontaine derriere l'autre.
Si la colone etait un element de background il ne pourrait rien y avoir derriere ou alors toujours la meme chose et ca limiterait les possibilité d'integration. Ca simplifie les choses.

[Coca_Impact]

Ha ok, merci!

[upsilandre]

j'ai refais une grosse partie sur Ghost'n goblins et la aussi c'est la foire au flickering et dans ce jeu c'est meme parfois problematique en terme de gameplay avec des projectiles ou ennemis qui disparaissent.

La raison ici est differrente de Castlevania. Sur NES les sprites sont en 2bpp soit seulement 3 couleurs ce qui rend compliqué la representation d'un personnage. Si on veut plus de 3 couleurs il faut superposer plusieurs sprites les uns sur les autres et c'est ce qu'ils ont fait ici avec Arthur (qui a une palette de 5 couleurs) et avec aussi pas mal d'ennemis. Alors ca donne quelque chose de jolie et proche de l'arcade mais ca sature tres vite l'affichage de sprite. Tous ces clignotement ca gache quand meme pas mal de jeu NES, ils gagnent a etre joué en emulation.

Mais y a d'autres grosses lacunes dans ce jeu. Les items (sprites) au sol dont la position n'est pas mis a jour de facon synchrone avec le scrolling du background. T'as le background qui scroll puis seulement la frame d'apres l'item au sol se déplace pour accompagner le scroll. Ca fait un effet de judder dégueulasse (sur les ennemis aussi).

Mais le pire c'est le scrolling. Le scrolling est saccadé, je comprend pas pourquoi! au lieu d'avoir un scrolling fluide au pixel et a 60fps comme dans Castlevania ou les autres, ici c'est un scrolling par pas de 3 pixels toutes les 3 frames et donc a 20fps. C'est vraiment décevant (surtout pour moi qui suit fan de cette serie).

Je préfere presque la version C64. C'est une version au rabais (bridé par le fait qu'elle est sortie je crois sur une cartouche 32Ko contre 128Ko sur NES) dont ils ont enlevé pas mal de passage donc pas une version tres acceptable mais au moins c'est fluide et sans sprite qui clignote. C'est propre.

[Coca_Impact]

Il me semblait que j'arrivais à effacer des ennemis sur MegaMan 2... :vice:
C'est toute le déception d'un homme que tu nous montres là  :no4: