Hardcore Retrogaming

Le premier prototype de la Famicom





A gauche ca doit etre la version custom du CPU et a droite le PPU j'imagine. Tout ca avant integration.
Au moins y a de la R&D, c'est pas Sega et sa SG1000 qui n'est qu'une contrefacon de la Colecovision.

La Game Gear c'est vraiment une Master System. A part la palette qui a ete boosté c'est purement le hard de la Master system.
Et donc malgres la faible résolution de l'ecran (160x144), en interne c'est toujours géré avec une tilemap de 256x224 comme sur Master System. Du coup les portages gères des elements graphiques en interne qui ne sont meme pas visible a l'ecran.
Par exemple Wonder boy (a droite ce qui s'affiche a l'ecran, a gauche la tilemap géré dans la console de la meme facon que dans la version Master System)





La Game Gear c'est juste une Master System en zoom permanent.

Ce gâchis... Ils auraient pu optimiser pour éventuellement réduire la consommation de piles

Meme le dot clock est celui de la Master system alors qu'il y a pas besoin. Du coup le GPU doit etre inoccupé 60% du temps.

J'avais compris que c'était une Master Système portable à cause du Master System converter pour la Game gear ...

Une sorte de boitier bien trop petit à l'époque pour y loger tout une batterie de composants électronique susceptible de convertir quoi que ce soit.

Mais ce qui m'avait également surpris, c'était la similarité entre Sonic 1 sur Master System et le même jeu sur Game Gear, rigoureusement identique !
Dans les moindres recoins ! Et ce sans aucun ""convertisseur"" !

La c'était sur pour moi, la Game Gear n'était qu'une Master System portable ...

apparemment c'est aussi assez facile d'ajouter une sortie TV sur la GameGear vu son dot clock de console de salon.


J'ai regardé les copro SNES.
Y en a principalement 3 qui sont dans la plupart des cartouches custom. Le DSP1, le SA-1 et le SuperFX.


-- le DSP1 est le plus ancien et le seul des 3 a etre un véritable coprocesseur. C'est a dire qu'il a aucune autonomie, il recoit une requete du CPU SNES pour executer une operation et renvoie aussitôt le resultat au CPU SNES qui l'attend.
Il fonctionne comme une extension du jeu d'instruction du CPU SNES (comme un vrai copro) et des instructions purement arithmétique mais assez avancé.
Il ameliore les multiplication/division du CPU SNES (qui est limité sur ce point) mais ajoute aussi plein de fonction complexe lié notamment a la 3D. De la trigonometrie avec des rotations 2D ou 3D, des matrices, du calcule de projection 3D (ca ressemble surtout a des routines de microcode stocké dans le DSP, les calcules peuvent prendre beaucoup de cycle, c'est pas instantané).
Le DSP1 a ete concu pour Pilotwings ce qui veut dire que des le lancement de la SNES y avait des cartouches custom donc dès le depart ils sont conscient des faiblesses de la machine et ont tout de suite integré cette strategie de copro ce qui est sans equivalent, c'est encore une bizarrerie de cette machine un peu bancale.
Mais du coup ca a permis de taper fort dès le debut avec pilotwings. Non seulement le jeu exploite tout de suite les innovations de la SNES (le mode 7 combiné au HDMA pour cette effet de perspective 2D) mais en plus contrairement a un F-Zero qui est un jeu purement 2D en perspective, Pilotwings est en quelque sorte un vrai jeu 3D (donc l'un des premiers sur console), la camera est géré dans un espace 3D avec tous les degrés de liberté et les elements d'interactions comme les anneaux composé de 10 spheres sont aussi gérés dans un espace 3D (ce sont des vectorballs ni plus ni moins) d'ou la nécessite de faire des calculs 3D avec le DSP1. Le jeu a meme plus de degrés de liberté 3D qu'un Starfox mais son affichage reste purement 2D (sprite + mode 7 + HDMA) contrairement a Starfox.




Ensuite vient le SA-1 puis plus tard le SuperFX. On peut ranger ces 2 la dans la meme categorie contrairement au DSP1 qui est appart.
Ce ne sont ni des copro ni des chips specialisés dans la rotation de sprites ou l'affichage de polygones. Ce sont juste des systemes CPU + RAM indépendant de la console et qui ont tout deux cette particularité d'etre capable de convertir du bitmap au format tuile/bitplan utilisé par les consoles.
L'idée c'est pas d'avoir des chips specialisés dans la 3D ou le scaling de sprite mais juste d'avoir un processeur généraliste capable de faire ce genre de traitement en software comme on le ferait sur un ordi sauf que quand tu fais du traitement software de transformation d'image tu le fais sur du bitmap, c'est a dire une image ou chaque pixel est bien rangé dans un octet distincte les uns derrière les autres sous la forme d'un tableau 2D et tu appliques tes traitement de transformation mathématique dans cette espace 2D mais les consoles manipulent pas de bitmap contrairement a un ordi. Elles manipulent des tuiles en bit-plans qui sont des formats inexploitable pour ce genre de traitement (chaque bit d'un pixel est répartit dans un octet different et pas de facon linéaire)
Donc le principe du SA-1 et du SuperFX ca va etre simplement de proposer un CPU assez performant pour faire des traitements graphiques en software et en bitmap comme sur un ordi et en meme temps d'etre capable ensuite de convertir le bitmap dans un format compatible avec l'affichage de la console.



-- le SA-1 est donc dans cette catégorie.
C'est simplement un CPU, le meme CPU que dans la SNES donc le meme jeu d'instruction (ca facilite l'usage) mais a une frequence 3-4 fois superieur donc suffisamment puissant pour commencer a faire des traitements graphique en software.
Il est accompagné de sa propre RAM pour etre indépendant sur ce point (Malgres tout les 2 CPU se battent quand meme pour l'acces a la ROM de la cartouche qui elle est unique). Globalement tu te retrouves avec 2 CPU quasi semblable en parallele facon Saturn ou 32X.
Le CPU du SA-1 en plus d'avoir une frequence bien plus elevé a aussi une unité arithmétique plus evolué. notamment tu peux faire des multiplications (ou division) vraiment 16bit en operande (et pas juste le resultat en 16bit et les operandes en 8bit comme sur SNES) mais y a pas d'instruction arithmétique complexe comme dans le DSP1. Et le SA-1 a aussi une autre RAM scratchpad interne de 2Ko pour executer encore plus vite certain bout de code.

Et surtout il integre donc cette capacité a convertir une image bitmap sous la forme d'un tileset affichable par la console. Cette conversion se fait a la toute fin, apres que le SA-1 a finit son boulot qui prend alors la forme d'un bitmap dans sa RAM. C'est pendant le transfert DMA de ce bitmap de la RAM du SA-1 vers la VRAM de la SNES que la conversion sera faite (dans une sorte de balaie synchrone entre le DMA du SA-1 et celui de la SNES en passant par le cache interne du SA-1 qui sert de tampon intermédiaire)
Le SA-1 a ete utilisé notamment pour Mario RPG, Kirby, Dragon ball Z... C'est celui qui a le plus servie



-- Le SuperFX est donc dans la meme categorie mais en plus performant.
On reste donc sur un systeme de traitement software (le SuperFX n'est pas un rasterizer de polygone ni un chip de calcule 3D) mais cette fois on abandonne le CPU de la SNES et on passe a un CPU un peu plus moderne de type RISC en pipeline (donc capable d'executer quasiment une instruction par cycle) avec donc un tout nouveau jeu d'instruction (ce qui permet de placer quelques nouvelles instructions plus tourné vers le traitement de data et de spécialisé quand meme un peu plus le CPU) et qui peut aller jusqu'a 21Mhz. On est sur quelque chose de bien plus puissant que le CPU de la SNES.
Il a aussi sa RAM a lui (32 ou 64Ko en général) et aussi un petit cache interne de 512 octets qu'il faut exploiter au mieux.
Niveau arithmetique le SuperFX n'a pas d'instruction avancé, y a meme plus de division contrairement au SA-1 (mais on garde les multiplication full 16bit que n'a pas la SNES) donc on est tres loin du DSP1 en terme de complexité des instructions arithmétiques mais il mise sur la force brute, la rapidité.

Mais le plus important encore une fois c'est la conversion des bitmaps. Contrairement au SA-1 cette fois la conversion se fait a la volé a chaque acces a la mémoire au travers d'une instruction dédié a la manipulation des pixels (et un buffer interne). L'instruction Plot prend des valeurs (X,Y,couleur) pour inscrire un pixel en memoire comme si on travaillait sur un bitmap et se charge de convertir ca automatiquement au format tuile et bitplan pour stocker en RAM au bonne endroit.
Donc en RAM on a pas un bitmap comme avec le SA-1 mais bien un tileset deja pret a l'emploi par la SNES. Cette instruction de conversion etant dédié a l'affichage de pixel bitmap elle va aussi etre accompagné de quelques optimisations cablés pour faciliter certain traitement comme l'alpha-coverage, le dithering (on en voit dans Starfox, tu peux pas utiliser plusieurs palettes differentes quand tu fais ce type de rendu ce qui te limite a une seul palette de 15 couleurs, le dithering est alors bienvenu), ou l'utilisation de source bitmap 4bpp, des auto-incrementation... des petites optimisations qui permettent d'economiser quelques instructions quand tu fais du traitement graphique en software mais les instructions plots qui sont avant tout conditionné par cette conversion a la volé est du coup surtout efficace quand tu ecris les pixels les un a coté des autres sur une ligne horizontal (il faut idealement 8 pixels horizontaux et aligné sur la taille d'une tuile) c'est la que c'est le plus efficace ce qui tombe bien pour la rasterisation de polygone qui se fait justement ligne par ligne. Ce qui fait d'ailleurs que l'on peut se demander comment ils ont optimiser le moteur pour Doom SNES car Doom c'est du raycasting et le raycasting c'est plutot du remplissage de ligne vertical.
Mais rien n'empeche de faire ce qu'on veut avec le SuperFX, ca reste du traitement software, on peut l'utiliser pour du traitement de sprite comme dans Yoshi's Island.

Par contre y a une procédure de sécurité pour les cartouches SuperFX. Comme elles consomment pas mal d'electricité par defaut le SuperFX est off. Le jeu dois dabord verifier quelle sont les accessoires qui sont branché sur la console et si certain accessoires sont branchés (type multitap 5 joueurs) un message doit inviter l'utilisateur a le débrancher avant de pouvoir activer le SuperFX et lancer le jeu.

L'age d'or de Sega. Suzuki + Hiro = 9001

upsilandre a écrit:

L'age d'or de Sega. Suzuki + Hiro = 9001

Mon gamin te remercie, c'est un gros fan de Space Harrier, il va adorer (surtout qu'il comprend le Jap lui, pas comme son père)

upsilandre a écrit:

La Game Gear c'est vraiment une Master System. A part la palette qui a ete boosté c'est purement le hard de la Master system.
Et donc malgres la faible résolution de l'ecran (160x144), en interne c'est toujours géré avec une tilemap de 256x224 comme sur Master System. Du coup les portages gères des elements graphiques en interne qui ne sont meme pas visible a l'ecran.
Par exemple Wonder boy (a droite ce qui s'affiche a l'ecran, a gauche la tilemap géré dans la console de la meme facon que dans la version Master System)



La Game Gear c'est juste une Master System en zoom permanent.

Parfois c'etait encore plus perfide.
Dans Space Harrier GameGear ils ont reprit strictement le jeu Master System mais pour faire genre c'est un vrai jeu GG ils ont modifié tous les sprites des ennemis et obstacle (a par les arbres) et de facon assez grotesque et raté parfois, c'est vraiment juste pour brouiller les pistes car le jeux est strictement le meme, meme code, meme pattern, tout est placé au meme endroit (aujourd'hui on crierait au scandale de pas avoir tout simplement laissé les sprites d'origine).

Mais quand j'ai lancé le jeu en mode debug j'ai vu un truc qui m'a plié de rire. Probablement quelque chose que personne n'avait jamais vu. Je vous laisse essayer de deviner avec ces screenshots internes:




A gauche la version GG et a droite la version SMS tel quelles sont gérées en interne (comme j'ai expliqué les 2 machines travaille en interne sur une tilemap 256x224, seul la zone d'affichage représenté par le cadre noir change, 160x144 pour la GG, 256x192 pour la SMS)

Oups le hud a moitié pas affiché

Pas loin, ca concerne effectivement le hud
Ce qu'il fallait voir c'est que naturellement sur GG quand il te balance une version SMS il refont quand meme le hud. au moins pour le déplacer dans la zone d'affichage et parfois aussi pour le simplifier comme ici (car y a deja pas beaucoup de place pour l'affichage donc vaut mieux qu'il soit discret) donc ici le hud GG est bien adapté pas de probleme... sauf qu'il ont laissé aussi le HUD de la version SMS hors champ au cas ou y aurait encore des gens pour penser que c'est pas la version SMS


Autre fail du meme niveau au cas ou ca suffirait pas... Vous remarquez que les couleurs sont plus sombre sur la version GG, c'est pas parce que j'ai fait une fausse manip, non, ce sont de vrais différences simplement du au fait qu'ils ont bêtement reprit la palette de la version SMS.

Les 2 consoles affichent le meme nombre de couleurs mais sur SMS les couleurs sont codé en RGB 6bit donc 2bit par composante alors que sur GG y a plus de nauances c'est 12bit soit 4bit par composante. Et bien sur GG ils ont utilisé seulement les 2bit de poid fort de chaque composante. Ils ont reprit les palettes du jeux SMS juste en déplaçant les bit: le blanc 100% (R11.G11.B11) devient un blanc 80% (R1100.G1100.B1100). D'autant plus absurde que ca veut dire qu'une partie de la luminosité est gaché par cette mauvaise conversion et donc de la consommation de pile.  

C'est du grand n'importe quoi car ils ont modifié l'apparence de chaque "sprite" mais en utilisant strictement la palette des anciens sprites (absurde) et sans meme faire une conversion de palette adapté a la GG. Tout ca n'a pas de sens et ca trahit qu'ils ont pas modifié les sprites pour profiter de la palettes (dans ce cas la de toute facon ils auraient simplement amélioré les sprites originaux qui sont bien plus cohérent) mais juste pour faire croire que c'etait un nouveau jeu alors que c'est rien d'autre qu'un rom hacking amateurs. Le fail complet dans l'arnaque.
Out Run par contre ils l'ont complètement refait.

upsilandre a écrit:

Autre fail du meme niveau au cas ou ca suffirait pas... Vous remarquez que les couleurs sont plus sombre sur la version GG, c'est pas parce que j'ai fait une fausse manip, non, ce sont de vrais différences simplement du au fait qu'ils ont bêtement reprit la palette de la version SMS.

Les 2 consoles affichent le meme nombre de couleurs mais sur SMS les couleurs sont codé en RGB 6bit donc 2bit par composante alors que sur GG y a plus de nauances c'est 12bit soit 4bit par composante. Et bien sur GG ils ont utilisé seulement les 2bit de poid fort de chaque composante. Ils ont reprit les palettes du jeux SMS juste en déplaçant les bit: le blanc 100% (R11.G11.B11) devient un blanc 80% (R1100.G1100.B1100). D'autant plus absurde que ca veut dire qu'une partie de la luminosité est gaché par cette mauvaise conversion et donc de la consommation de pile.  

ah quand même

Entre les 2 fails j'hésite quand meme. Le HUD de la version SMS qui reste présent dans la version GG alors que t'essaie de faire croire que c'est une nouvelle version je trouve ca vraiment fort mais c'etait sans conséquence a l'epoque puisque hors champ, fallait un emulateur pour le voir.

Alors que le recyclage de la palette des anciens sprites pour en faire de nouveaux et sans etre capable de faire la conversion ca a une conséquence direct. Si encore c'etait une console de salon ou une console portable OLED ca serait pas grave mais non c'est une console portable LCD.
En plus la conversion c'etait pas compliqué quand meme, y a que 2bit par composante donc au lieu de simplement ajouter deux zero:
00 > 0000
01 > 0100
10 > 1000
11 > 1100

Il fallait juste doubler chaque pair:
00 > 0000
01 > 0101
10 > 1010
11 > 1111

C'est pas bien plus compliqué et au moins c'est parfaitement conforme et sans perte de luminosité inutile.

Je le met ici NX Gamer fait une vidéo de performance de MGS sur PS1... Génial pas vu encore...

Cette fois c'est MGS 2 qui est analysé par NXGalzr

Tiens une vidéo qui ma fait penser à ce topic et à Upsi à propos de la Saturn :



On y parle d'une des grosses bête noire de l'époque techniquement parlant avec la Saturn, les "effets de transparence" très "problématique" sur cette machine en comparaison avec la Playstation, je me souviens qu'on en parlait beaucoup avec les jeux saturn ...

J'ai aussi été très étonné de voir les comparaisons vidéo avec les différents câbles vidéo dispo pour la machine, si on m'avait dit ça à l'époque

Tres bonne video. C'est le genre de video que j'aimerais faire (mais c'est beaucoup de boulot)

chris1515 a écrit:

Cette fois c'est MGS 2 qui est analysé  par NXGalzr

On voit que c'etait pas tout a fait du 60fps.

upsilandre a écrit:

chris1515 a écrit:

Cette fois c'est MGS 2 qui est analysé  par NXGalzr

On voit que c'etait pas tout a fait du 60fps.

il présice que c'est la version UK donc PAL donc 50hz pour le jeu et 25fps pour les cinématiques contrairement à la version jap/ntsc qui était en 60/30

Rendering a écrit:

Tiens une vidéo qui ma fait penser à ce topic et à Upsi à propos de la Saturn :



On y parle d'une des grosses bête noire de l'époque techniquement parlant avec la Saturn, les "effets de transparence" très "problématique" sur cette machine en comparaison avec la Playstation, je me souviens qu'on en parlait beaucoup avec les jeux saturn ...

J'ai aussi été très étonné de voir les comparaisons vidéo avec les différents câbles vidéo dispo pour la machine, si on m'avait dit ça à l'époque

Bcp d'infos !
Je connaissais pas l'histoire des quadrangles. les problèmes liés au fait que les VDP fassent des rendus séparés en parallele, j'en avais entendu parler, mais c'était pas aussi précis que ses exemples.
C'est vrai que le dithering sur saturn, c'était une signature aussi forte que les textures "cassés" de la play (intéressant qu'il en parle en toute fin).

Les quad de la Saturn c'etait assez connu, c'est le lot des machines specialisés 2D qui veulent faire de la 3D (et qui donc utilisent des sprites, un sprite déformable est un polygone a 4 sommet) comme la 3DO.

Les histoires de transparence y a eu effectivement des debats la dessus a l'epoque mais je ne m'y suis jamais vraiment intéressé et j'ai bien fait car c'est un probleme compliqué mais au moins la on comprend bien. Les 2 VDP (un pour les sprites, un pour les background, comme une SNES) savent faire de la transparence (donc que ce soit avec les sprite/poly ou avec les background contrairement a la SNES qui pouvait le faire seulement sur le background) mais c'est la combinaison des 2 qui pose probleme. Tu peux faire de la transparence avec un objet sprite/poly sur un autre sprite/poly ou sur un layer background mais faut choisir. Ton sprite/poly peut pas avoir de la transparence a la fois par rapport aux autres sprite/poly et en meme temps avec les background layer. Le VPD1 trace les sprites dans un framebuffer a part et le compositing avec les background impose des choix.

Et c'est la qu'on arrive au truc qui moi m'a le plus intéressé c'est la facon dont les jeux Saturn exploitent finalement les layers background 2D (donc le VDP2) dans les jeux 3D car a priori si tu fait un jeu purement 3D tel qu'on le fait sur une PS1, c'est a dire un assemblage de polygone jusqu'a la skybox, alors dans ce cas la Saturn n'utiliserait que ses sprites (VDP1) et donc pas de probleme de transparence (si ce n'est que ca a quand meme un cout et probablement superieur au cout sur PS1) sauf que ca veut dire ne pas exploiter du tout le second GPU (et sa VRAM qui est perdu aussi) et donc tu va pas loin de cette facon avec une demi Saturn.

Donc toute l'astuce des jeux Saturn a ete de trouver des astuces pour exploiter les layers de background dans les jeux 3D et pas seulement pour faire l'arriere plan (a la place d'une skybox) ou le HUD car la Saturn a aussi 2 background layer type mode 7 avec donc rotation (en + des bg 4 classiques) et donc avec ces layers mode 7 ils peuvent faire le sol d'un jeu 3D ce qui en plus de l'arrierre plan va permettre de soulager le VDP1 (ils peuvent utiliser aussi les background pour certain effet en utilisant le framebuffer VDP1 comme un background du VDP2). Mais du coup ca crée des conflits pour la transparence parce que t'as des melanges de sprite/polygones pour les objet et de background pour le sol (ou l'arriere plan) et ca se combine mal.

L'exemple de VF1 est excellent. La premiere version de VF1 utilisait un sol en polygone tel qu'on l'aurait fait sur PS1 (ils ont juste utilisé les bg du VDP2 pour l'arriere plan).
Puis ensuite ils ont réalisé qu'ils pouvaient faire le sol du jeu avec un background en mode 7 et donc ils ont ressortie une nouvelle version remix ou cette fois le sol est un background du coup non seulement il est de meilleur qualité et sans le clipping affreux de la version polygone mais en plus ils liberent des ressources pour le VDP1 et aussi de la VRAM du VDP1 ce qui va donc permettre aussi de mettre des textures sur les personnages et donc de les améliorer aussi.
Donc avec cette exemple on voit que l'evolution des jeux 3D Saturn se résume un peu a ca, mieux exploiter le VDP2 et ses background 2D dans les jeux 3D.

Panzer Dragon est un autre exemple, la surface du lac est un background qui en plus de soulager encore une fois le VDP1 permet avec de simple raster effect de faire un effet visuel sur l'eau qui aurait ete plus compliqué sur PS1 alors que la ca ne fait qu'utiliser le VDP2 qui de toute facon se tourne les pouces et a plein de VRAM libre.

Putain je vais devoir couper le son pour vraiment pouvoir mater cette vidéo.
Techniquement hyper interessant, mais putain quelle idée à la con il a de faire l'audio en Anglais alors que c'est imbitable et à la limite du supportable (encore un naze de Jap qui veut se la péter avec son Anglais de merde) ... surtout qu'il y a les sous-titres.

J'aurais pas mal de choses a dire sur la trinité PC-Engine, Megadrive, SNES, j'ai a peu pret fait le tour et je me suis pas mal intéressé a leurs technologie de RAM, a leur bande passante et aussi a leur compétence en terme de DMA qui est aussi un element tres important. Mais j'ai la flemme, on verra une autre fois peut etre (j'ai jeté aussi un oeil sur la GBA qui est dans la continuité).

Pas mal de chose a dire aussi sur le next level de l'emulation le "transistor level simulation". J'en avais entendu parlé mais je m'y suis vraiment intéressé cette fois et c'est fascinant ce que les gars font. Y a eu surtout un gros elan en 2010/2011, la les projet on l'aire plutot au point mort mais c'etait passionnant et ca m'a permis d'en savoir encore plus sur mon CPU préféré (le 6502) et sur les chip de la VCS et de la NES qui par chance ont ete un peu au coeur des projets. Mais la flemme aussi donc un autre jour.


Mais je finis toujours pas retourner vite fait sur la NES. La j'etais sur un petit décorticage du tout premier DragonQuest sur Famicom et j'etais assez surpris. Essayez d'estimer la quantité de data réservé aux patterns graphiques (les fameuses tuiles).
1 - Combien de data pour la totalité des patterns des sprites du joueur + ceux des PNJ ?
2 - Combien de data pour la totalité des patterns des environnements (exterieur, interieur et zone de combat)?
3 - Combien de data pour la totalité des patterns des sprites ennemis/monstres que l'on combat (excepté le boss final)?

http://www.quora.com/How-did-game-developers-pack-entire-games-into-so-little-memory-twenty-five-years-ago

Topic intéressant sur les astuces dans les jeux pour tenir dans la mémoire très faible des consoles pu ordinateur d'un autre temps

https://news.ycombinator.com/item?id=9739731

Un topic d'un dev qui a travaillé sur l'adaptation de MGS 1 sur PC