Hardcore Retrogaming

J'ai enfin recu ma NES mini commandé en juillet, c'est beaucoup trop mignon.

Petit (gros) Gif pour montrer le shimmering que provoque certain type de scaling lorsqu'on a un scroling




A gauche c'est un scaling pour respecter le format originel de la NES (un peu etiré en largeur) et son pixel ratio de 8:7 (des pixels 14% plus large que haut) et a droite c'est avec un pixel ratio carré 1:1 mais qui du coup est propre (le ratio que je choisie en général en emulation).
C'est difficile de respecter ce pixel ratio originel de 8:7 (lié au dot clock 5.37 Mhz qu'on retrouve sur quasiment toutes les consoles de l'epoque) surtout si on veut des pixels bien délimité, bien net et sharp. Ca implique en général de faire un scaling ou les pixels n'ont pas tous la meme taille ce qui donne cette effet de shimmering lorsqu'il y a du scrolling (on a des sorte de ligne vertical de compression/dilatation du au changement de taille des pixels)

Ici j'ai volontairement prit le pire exemple pour montrer l'effet. Je montre ici ce que ca donnerait sur un ecran 240p (genre console portable , la 3DS par exemple), plus l'ecran d'affichage aura une resolution elevé mieux on poura faire le scaling (et les autres traitement si il y a), en 480p c'est mieux, en 720p encore plus et en 1080p c'est quasiment nickel... mais pas parfaitement.
Si on est vraiment puriste (car c'est quand meme tres difficile de voir le probleme en 1080p) la resolution théorique idéal qu'il faudrait pour reproduire ce pixel ratio 8:7 et avoir tous les pixels de meme taille (donc aussi propre que sur l'exemple avec les pixels carrés) c'est tout simplement de multiplier x8 la résolution horizontal (et x7 la vertical) et donc une résolution de 2048x1680 ce qui nécessite une TV 4K.
Les jeux parfait pour bien voir ce genre d'artefact c'est des jeux comme Castlevania ou Contra qui ont des scrolling ingame 60fps a 60pps (soit exactement un pixel par frame donc le scroling a la fois le plus lent et le plus fluide et sans judder) et qui ont aussi des background chargé (faut pas des aplats de couleur facon SMB sinon y a rien a voir)

En plus de ca y a une drole de coincidence c'est que cette resolution de 2048x1680 est aussi la résolution idéal pour reproduire le signal NTSC que fabrique le PPU de la NES (le PPU a cette particularité de produire en interne directement un signal NTSC, le PPU de la NES ne connait pas le RGB). En effet le signal NTSC a une frequence chromatique de 3.58 Mhz alors que le Dot Clock (la frequence des pixels de la NES et donc sa resolution horizontal) a une cadence superieur de 5.37 Mhz. C'est ce qui cause toute sorte d'artefact chromatique lors des transitions de couleur entre pixels car la periode chromatique est plus longue que l'affichage d'un pixel et donc cette periode chromatique se trouve a cheval sur 2 pixels.

Le PPU produit ce signal chromatique de facon tres rudimentaire sous la forme d'une vulgaire square wave et divise sa periode en 12 samples binaires (ce qui permet ensuite d'avoir 12 types de déphasage de cette square wave par rapport au color burst en debut de ligne qui donne le tempo et donc d'avoir les 12 teintes differente de la palette NES) mais seul 8 samples sur 12 ont le temps d'etre envoyé par pixel (la difference entre 5.37mhz et 3.58mhz). si les pixels consécutifs ont la meme couleur c'est pas grave la periode chromatique en court se prolonge sur le pixel suivant mais dès que ca change de couleur ca crée des ruptures dans la periode chromatique qui est modifié avant meme la fin de sa periode. Ca va donner ensuite divers interpretation par le decodeur NTSC qui donneront divers erreur dans le couleur selon le type de transition.

Donc a priori l'idéal pour bien reproduire ce processus c'est de choisir une resolution horizontal equivalente aux nombre de sample de la square wave chromatique que produit le PPU pour la simuler directement avec les artefact chromatique qu'elle engendre. et comme j'ai expliqué y a 8 samples chromatiques par pixels donc idéalement faut multiplier par 8 la résolution horizontal exactement comme pour le pixel ratio de 8/7.
C'est marrant comme coincidence, y a 2 phénomenes differents qui pointe vers la meme résolution idéal de 2048x1680. Je répète on est dans le pinaillage, c'est l'idéal théorique.

Une video dédié uniquement a la question des sprites (plutot que d'en parler par petit bout) pour boucler la question et revenir sur les notions importantes et aussi les trick dont j'avais pas encore parlé comme ca tout est dans la meme video. En terminant sur un decorticage de Solstice NES que j'ai decortiqué hier et qui est intéressant sur ce point.

https://youtu.be/mbjwVQJX-NI

upsilandre a écrit:

Une video dédié uniquement a la question des sprites (plutot que d'en parler par petit bout) pour boucler la question et revenir sur les notions importantes et aussi les trick dont j'avais pas encore parlé comme ca tout est dans la meme video. En terminant sur un decorticage de Solstice NES que j'ai decortiqué hier et qui est intéressant sur ce point.

https://youtu.be/mbjwVQJX-NI

Encore une fois c'est hyper intéressant, mais tu risque de vite avoir fait le tour de la Nes non?
Y a-t-il d'autres consoles avec des archi exotiques qui te branche et pour lesquelles tu pourrais faire le même type de vidéo (genre la PCE) ?

Les sujets manque pas, j'en ai une liste longue comme le bras. Parler des autres machines ou meme de l'arcade c'est bien a partir du moment ou t'as une machine de référence que tu comprend et qui sert a jauger ce qui fait les particularités ou l'identité de tel ou tel machine. La NES c'est tres bien comme machine de références pour parler des autres (celle d'avant ou d'apres) donc faut prendre le temps de comprendre. Parler des hardwares c'est intéressant principalement si tu le fais par comparaison a d'autre pour pointer les choses remarquable et situer ca dans une sorte de phylogénie.
J'aimerais bien parler aussi de soundchip ou des simulations transistors level (et de plein de jeu) mais y aura sans doute pas d'autre video avant un certain temps, je voudrais recoder un peu, faire un peu de hack, prendre le temps aussi de jouer a certain jeux NES que j'ai pas le temps de faire (la aussi j'ai une liste longue comme le bras), les videos on verra ca plutot en 2017 si je suis motivé.

Ce soir je me suis codé un petit programme en python pour transformer les samples DMC des jeux NES en fichier .wav et ca marche! Le python c'est vraiment cool (meme si j'avais deja tout oublié, il a fallu que je refeuillette un peu les doc ces derniers jours).

Du coup je cherche un visualizer qui permet de visionner les samples .wav (pouvoir zoomer ect...) C'est surtout pour ca que je voulais les transformer en .wav. Je voudrais par exemple pouvoir comparer visuellement les samples de bass des jeux Sunsoft, voir pourquoi ca sonne mieux par exemple dans Silius que dans Batman Jocker alors que ca a l'aire d'etre quasiment les meme samples.
Donc si vous connaissez un bon visualiser de sample ca m'intéresse.

Je me suis bien amusé a decortiquer les samples.
Ceux de Zelda ressemble effectivement pas a grand chose mais j'ai pu surtout comparer les samples de Silius et de Batman Joker.
Les 2 jeux (de Sunsoft) ont la meme approche, utiliser le canal DMC pour la basse a l'aide de 5 samples different. Les 5 samples ont la meme taille et la meme tonalité sur les 2 jeux donc on aurait pu penser qu'ils utilisent les meme samples mais ca sonnait pas pareille d'ou ma curiosité et effectivement en regardant de plus pret ce ne sont pas du tout les meme samples.

Batman est sortie apres Silius mais la basse de Silius sonne clairement mieux qualitativement quand tu ecoutes le canal isolé. Effectivement quand tu visualises les samples de Silius sont tres propres, on a une bonne amplitude avec une periode bien identifiable et un timbre bien marqué et qui évolue nettement entre le debut et la fin du sample (le pincement de la corde en debut de sample est marqué), vraiment le top du sample DMC a mon avis, probablement la meilleur facon d'utiliser le DMC (le DMC c'est quand meme tres limité). alors que les samples de Batman c'est clairement en dessous sur tous ces points.

Mais en plus les samples de Batman sont mal initialisé avec une mauvaise valeur de depart ce qui produit une saturation au debut qui donne ce petit bruit de claquement a chaque debut de sample. Quand on ecoute le canal DMC isolé du reste ca fait vraiment moche. Je me suis amusé a faire un hack qui corrige l'initialisation des samples pour enlever ce claquement et ca marche bien mais c'est possible que ca soit fait expres car quand tous les canaux sont melangé ca s'entend pas vraiment et ca ajoute aux percussions. Difficile de savoir si c'est volontaire.
J'ai fais aussi un autre hack ou j'ai remplacé les samples de Batman par ceux de Silius pour le fun, ca marche tres bien.
A mon avis les choix sur Batman sont probablement volontaire pour avoir un autre type de son mais du point de vue des samples quand tu les isoles ceux de Silius sont vraiment de meilleur qualité.
Ca se trouve ca peut etre aussi des histoires de droit. Il me semble que ce genre de sample ils les piquent sur des synthés, peut etre qu'ils ont pas pu garder ceux de Silius.
J'ai trouvé aussi un sample de percussion qui n'est pas utilisé dans le jeu a ma connaissance.

Je me suis amusé a samplé un de mes CD audio sur NES
https://drive.google.com/open?id=0B399kteofpYuaGRjVUNiMU5aWlE
Ca sonne bien

Reste maintenant a faire des versions avec compression, moins bonne qualité mais plus interressant au niveau du code.

Bon aujourd'hui je suis retourner sur Python pour coder le script qui me transforme le .wav (8bit bridé a 7bit) de Keziah Jones en ADPCM 4bit pour la NES. Il me sort a la fois un fichier raw qui contient la succession de delta ADPCM dont j'ai besoin pour la NES mais aussi un fichier .wav reconstruit a partir de ces data pour avoir tout de suite le resultat a l'ecoute (et surtout pouvoir visualiser la wave source avec celle ci l'une au dessus de l'autre et comparer)

Ca fonctionne pas mal. Ca absorbe plutot bien les gros changement d'amplitude a haute frequence (le sample de Keziah est assez exigent) tout en gardant la precision quand c'est calme. C'est pas exactement l'original forcement mais ca passe bien.

https://2img.net/h/s19.postimg.cc/okxuqrsqb/ADPCM4bit1.png
https://2img.net/h/s19.postimg.cc/dzdzermer/ADPCM4bit2.png
https://2img.net/h/s19.postimg.cc/4g4alaywj/ADPCM4bit3.png

En haut c'est la source et en bas c'est la version apres compression par mon algo ADPCM (qui prend donc 2 fois moins de place).

Mais la c'est la version 44khz du sample et malgres que ce soit de l'ADPCM tres basique (a vrai dire je connais pas d'algo ADPCM, j'ai juste pris le terme "adaptative" au pied de la lettre et fait a ma sauce car de toute facon j'aurais tres peu de budget CPU sur NES, ca laisse pas 36 solutions) meme si simple y a peu de chance que je puisse coder mon algo de décompression ADPCM sur NES pour du 44khz (ca veut dire un budget de 40 cycles CPU par sample). Le bute c'est plutot de viser le 22khz donc faut que je vois ce que ca donne en 22khz.

J'ai améliorer tout ca. J'ai continué de faire des test de sampling, de compression et jouer un peu avec les mappers.

- J'ai fais une version ADPCM du sample de Keziah Jones (donc compresser par rapport a la version PCM précedente qui etait du raw). C'est une version tres simple d'ADPCM mais qui marche bien et qui passe en 44khz (et meme en 48khz) alors que j'avais pas prevu d'avoir le budget cycle cpu.
Et je l'ai fais en configuration mapper UxROM pour pousser la PRG-ROM a 4Mo ce qui n'existe pas normalement (pas compatible avec tous les emulateurs). Du coup cette fois je peux mettre quasiment tous le morceau au lieu de quelques secondes.
https://drive.google.com/open?id=0B399kteofpYuSlFTVkxCd2FOaFk
Et pas de difference notable de qualité par rapport a la version sans compression. Ca vaut vraiment pas le coup de faire du raw meme si on veut la qualité max.

- La meme chose mais en version plus courte pour que ce soit compatible avec un everdrive (MMC5 512ko PRG + 512ko CHR pour exploiter les limites de l'everdrive, je fais passer une moitié du sample par le GPU).
https://drive.google.com/open?id=0B399kteofpYuSFdxczhIeTJxTDA
Ca fait une parfaite demo de sampling testable sur une vrai NES.

- Je me suis amusé aussi a faire une version DMC qui est la fonction hardware de sampling de la NES pour entendre ce que ca donne.
https://drive.google.com/open?id=0B399kteofpYuTmxlM1dFZW9tVTQ
C'est sur que c'est pas comparable avec la version software ADPCM, c'est affreux, mais au moins ca consomme rien en ressource (moins de 1% cpu).

- Et un autre sample en DMC (un monologue)
https://drive.google.com/open?id=0B399kteofpYuV3A1UERlY19LeEk


Je pense que je vais terminer par un petit ROM hack

il y a l'AGDQ en ce moment upsi, je pense que t'es au courant mais bon :

https://www.twitch.tv/gamesdonequick

J'ai pensé à toi parce qu'il y a pas mal de retro et aussi très souvent des jeux un peu méconnus, certains pourraient t’intéresser.

Upsi t'es un fou, tu pousses les choses jusqu'au bout je suis admiratif de ta patience et de ta méthode bravo à toi !!

Fétide a écrit:

il y a l'AGDQ en ce moment upsi, je pense que t'es au courant mais bon :

https://www.twitch.tv/gamesdonequick

J'ai pensé à toi parce qu'il y a pas mal de retro et aussi très souvent des jeux un peu méconnus, certains pourraient t’intéresser.

nan j'ai pas regarder cette année.
apparement le restream francais est toujours assuré
https://www.twitch.tv/lefrenchrestream

le planning
https://gamesdonequick.com/schedule

egb a écrit:

Upsi t'es un fou, tu pousses les choses jusqu'au bout je suis admiratif de ta patience et de ta méthode bravo à toi !!

D'ailleurs j'ai pas réussit a m'arreter. Je suis encore en train de faire une autre version ADPCM a la fois mieux compressé (3.56 bit par sample) et de meilleur qualité et niveau CPU j'arrive encore a faire passer ca en 44khz (ou 48khz) sur la NES.
J'aimerais bien passer a autre chose mais c'est assez amusant a faire et puis ca m'oblige a faire des va et viens entre Python et assembleur et ca c'est cool.
J'ai encore quelques test a faire avant de fermer ce dossier et j'aimerais terminé par un petit ROM hack. Je voudrais booster la cartouche de Megaman1 (pour la faire passer de 128Ko a 2Mo) et ajouter sur l'ecran titre (qui est tres basique, statique et sans musique) cette track remix la: https://www.emuparadise.me/soundtracks/highquality/download/Rockman1-6/FLAC/04_Dr.Wily_1_(Rockman2)_mix/3382
Ca serait rigolo.

La vie est un jeu et tu as bien raison de la vivre ainsi et d'en faire ton terrain de jeu.

C'est exactement comme ca que la curiosité devrait être utilisé

Impossible de trouver une NES MINI ici...

upsilandre a écrit:

Fétide a écrit:

il y a l'AGDQ en ce moment upsi, je pense que t'es au courant mais bon :

https://www.twitch.tv/gamesdonequick

J'ai pensé à toi parce qu'il y a pas mal de retro et aussi très souvent des jeux un peu méconnus, certains pourraient t’intéresser.

nan j'ai pas regarder cette année.
apparement le restream francais est toujours assuré
https://www.twitch.tv/lefrenchrestream

le planning
https://gamesdonequick.com/schedule

Le calendrier en Français (horaires) : https://docs.google.com/spreadsheets/d/1Ei_PQysQ8e4eFfhDqwfWU13xyBOBjIJKjNxjaUmcO3w/pubhtml

Voila ma version finale (version courte mais compatible everdrive): https://drive.google.com/open?id=0B399kteofpYuRFpfM1dfZkNBZHc

compression ADPCM 3.56bit a 44khz
Mes data sont stocker en paquet de 4 octets qui encodent 9 samples consécutif. le paquet a cette forme (chaque caractère est un bit):
ttttt111 44333222 76665554 99988877

"ttttt" se sont les 5bit qui servent a pointer l'une des 32 tables de 8 delta que j'ai prédefini
ensuite les chiffres comme "111" indique les 3bit qui pointe le delta a selectionner dans la table ttttt qu'il va falloir ajouter a la valeur du sample precedent pour obtenir le sample suivant (il sagit d'encoder les difference entre 2 samples plutot que leur valeur absolu, assez classique comme principe). 111 c'est pour le premier sample du paquet, 222 pour le second ect...

C'est a la production des data que se fait la selection de la table la plus adapté a chaque paquet de 9 samples, mon algo python test les 32 tables sur chaque paquet de 9 samples, donne un score pour chaque table et choisie ensuite la meilleur pour l'inclure ensuite dans les metadata (le "ttttt" )
Et j'arrive ensuite a decoder ca sur NES en 30-40 cycles CPU par sample (pour du 44khz tu as 40.5 cycles. C'est sur que tu peux rien faire d'autre par contre).

En tout cas cette version marche tres bien. La wave ressemble comme 2 goutes d'eau a la version raw. J'aime bien joué au jeu des 7 erreurs en affichant les waves l'une sur l'autre en zoom max.

Aujourd'hui j'ai fais un petit hack de Megaman1. Je vous laisse découvrir (faut mettre le son)
https://drive.google.com/open?id=0B399kteofpYuQlJUeDVXbERfZmc

Petite video

https://youtu.be/5mvDjXXfBNg

Quelques Gifs

Effet de Halo lumineux dans Ys SMS en utilisant un cache noir en sprite (pareille sur NES)



Probleme de gestion de priorité dans Ys NES



L'un des raster effect les mieux reussit sur NES



un autre combiné a des sprites



Le Fantasy zone NES "escroc edition" (Celle de Tengen) avec le pire flottement de sprite jamais vu (forcement avec 15fps pour les sprites et 60fps pour le scrolling amuse toi a epingler un sprite sur le Background)



Et a l'instant je viens de tomber sur cette cutscene en jouant a Ninja Gaiden II. Je vous laisse juger.

La cutscene

Fétide a écrit:

La cutscene

C'est très drôle, tu fais ça maintenant, tu as toutes les ligues de vertu qui te tombent sur le dos...

Je me suis fais le Shinobi de Tengen sur NES, y a pas a dire c'est vraiment des escroc