Hardcore Retrogaming

je me fais un gros document google qui reunit tout.
J'ai deja fait 4 dossiers tres exhaustif (Channel F, RCA studio II, Astrocade de Bally et l'Odyssey 2), ca me donne de gros pavé mais qui me permettent de retrouver rapidement le moindre details techniques sur ces machines (et les liens vers les documents utilent. Dailleurs je me demande si je devrais pas archiver ausis les document et pas juste les liens. Certain document ont une valeur inestimable, si ils devaient disparaitre ca serait tragique).
J'ai meme creusé encore plus que les premieres fois, notement sur les CPU car s'est vraiment interressant de se frotter aux cpu de cette epoque.
et a cela j'ai ajouté une partie "remarques" ou je note toutes les remarques plus globale que je peux faire sur cette periode (moi c'est vraiment la decenie 1975-1985 qui m'interresse), deja une quinzaine

Je suis deja a 30 000 caracteres. Prochaine machine l'intellivision ou j'ai pas mal de chose a dire. Je vais zapper la VCS et la NES car c'est des machines vraiment mainstream qu'on cotoi regulierement et que j'ai ou vais programmé donc je peux me permetre de garder au moins ces 2 la en tete et de me passer d'aide memoire (d'autant que j'aurais beaucoup a noter sur ces machines) et me concentrer sur les autres machines.

J'ai + creusé les CPU (notement pour mieux cerner leur performence respectives), c'est l'un des truc interressant dans la demarche de s'interresser a ces premieres machines c'est la diversité de CPU et l'exotisme de ceux ci (le F8 de fairchild, le 1802 de RCA, le microcontrolleur 8048 de intel, le CP1600 de General instrument...). Ca te donne une vision et une comprehension asser interressante de ce qu'est un CPU.


Je suis donc revenu notement sur celui de Fairchild qui equipe la channel F. La premiere fois je l'avais survolé. Ce qui intrigue tout de suite c'est avant tout l'absence total de bus d'adresse chose vraiment incongru dans un CPU.
La premiere fois j'avais cru a un abus de language, j'avais bien vu qu'a coté du bus de donnée il y a avait quand meme un bus de control de 5 pins nommé ROMc et je pensais que c'etait ce bus qui servait de bus d'adressage de facon multiplexé (en 3 cycle ce qui donnerait 3x5= 15 bit d'adressage) et que pretendre qu'il y avait pas de bus d'adresse c'etait un peu jouer sur les mots.

Mais en y revenant je me suis rendu compte qu'il y a vraiment pas de bus d'adresse et que le bus 5bit ROMc ne sert pas a ca.
Alors comment on fait fonctionner un CPU qui ne peut pas adresser de memoire pour piocher ses instructions et données?

Faut deja savoir ce qu'est un PC (program counter) c'est l'element le plus commun a tous les CPU, c'est un registre (au moins 16bit en general) qui contient l'adresse de la prochaine instruction a executer. Donc le CPU balance le contenu de ce registre sur son bus d'adresse pour s'alimenter de la prochaine instruction et chaque fois que le CPU execute une instruction il incremente le PC (de 1 ou + selon la longueur de l'instruction précedante) pour continuer a executer le programme en cours. C'est aussi le PC qui est modifier quand on fait un jump, et qui est sauvegarder dans la pile quand on fait un call a une subroutine

Dans la Channel F le CPU n'a pas de PC. Ce sont tous les elements de memoire (ROM ou RAM) qui integre toutes un PC. ils ont tous la meme valeur (et change en meme temps) si bien que chaque element de memoire sait ou en est le programme.
Le CPU lui se contente d'utiliser son bus de control ROMc qui avec ses 5 lignes permet 32 commandes differentes et ce sont ces commandes qui vont piloter les differentes memoires. Si le CPU veut la prochaine instruction il envoi donc une commande pour soliciter les memoires en lecture. chaque memoire a un PC et donc sait si elle est concerné par cette requete si c'est le cas elle envoi l'instruction correspondante mais toutes les memoires sont relié sur le meme bus et recoivent cette commande et donc elle vont toute incrementer leur PC (selon le type de commande) et rester toutes syncronisé (malgres qu'lele ne communique pas entre elle).
Si le CPU a besoin de faire un jump alors il envoi un autre type de commande qui signal a chaque memoire que le data qui leur arrive sur le bus de donnée est a mettre dans le LSB (les 8bit inferieur ) de leur PC pour le mettre a jour (et faire donc un jump dans la page actuel, avec une autre commande le CPU peut aussi modifier le MSB du PC, les 8bit superieur)

Donc le CPU peut modifier tous les PC de toutes les memoires en une seul commande. les memoires ont aussi un DC (data counter) pour les instruction qui font appel a une valeur en memoire c'est le DC qui va servir a ca de la meme maniere que le PC (la aussi ils ont tous la meme valeur), c'est a dire controlé a distance par le CPU et son bus de controle.
en fait y en a meme 2 de chaque (2 PC et 2 DC) dans chaque memoire pour sauvegarder le PC et le DC quand y a un call a une subroutine.

Donc voila un parfait exemple de CPU tres exotique. Ca implique ici qu'on ne peut pas utiliser de ROM ou de RAM ordinaire. les memoires sont une partie integrante du CPU et sont donc produit aussi par fairchild.
Pour les ROM (y a pas de RAM externe dans la Channel F) c'est donc un chip qui se nomme PSU (program storage unit) qui joue se role (et qui peut avoir d'autre fonction) et qui integre 1Ko de ROM. On peut en cumuler 32.
Dans la channel F y en a 2 pour le Bios mais c'est aussi des PSU qu'on retrouve dans les cartouche (2, 3 ou 4) car la aussi on ne peut pas utiliser de la ROM ordinaire.

un tres bon exemple de comment les jeux NES ont enormement evolués au fil des ans. La comparaison entre Batman Return of the Joker sur NES et Batman Returns sur Master System (a relativiser. c'est pas le meme jeu, pas le meme studio, mais la meme epoque, le jeu NES est meme sortie un peu avant) qui a la base est une machine superieur a la NES.

Master system
https://youtu.be/eb94wcq13X4?t=46s

NES
https://youtu.be/p1Ivxnpbd5Y?t=17m42s

Faut dire que les Batman NES de Sunsoft sont de vrai demo techniques bourrées de tricks mais on voit bien a quelle point les background sur NES peuvent etre dynamiques (le level juste avant ou l'on accompagne un enorme Tank est aussi tres ingenieux, tous les autres aussi, chaque level est un défi technique), impossible de faire la meme chose sur Master System.
C'est la consequence au depart d'un choix economique, pour mettre tres peu de VRAM dans la console (2Ko) Nintendo decide donc que les patterns des tiles seront sur la cartouche directement adressable par le PPU la ou sur une Master System ils faut les déplacer une a une dans la VRAM de 8Ko de la console seul memoire adressable par le GPU.
Du coup avec l'evolution des cartouches la NES peut profiter du bank switching pour switcher instantanément des pages entieres de patterns sans rien avoir a déplacer (et donc pouvoir animer un décors) la ou sur une Master System faudrait changer beaucoup de patterns de la VRAM entre 2 frame pendant le Vblank ce qui n'est pas possible.

Des choix économiques ont donc poussé la NES a avoir une architecture avec un port cartouche tres cablé et donc plutot évolutif et vu la durée de vie de la console au final ca a ete payant. Ce Batman est vraiment impressionnant pour de la NES.

Dommage que Sega n'ait pas utilisé la même technique sur MD (puce dans les cartouches). Même si la MD a été poussée très loin (de mon point de vue, il suffit de regarder les jeux des deux ou trois premières années et ceux des dernières années pour voir qu'il y a un gouffre), elle aurait certainement encore pu aller au delà avec des puces dans les cartouches (Nintendo a gardé ce procédé dans la SNES).

D'un autre coté, on voit exactement ce dont la MD était capable sans ajout de puce "magique".

Terry a écrit:

Dommage que Sega n'ait pas utilisé la même technique sur MD (puce dans les cartouches). Même si la MD a été poussée très loin (de mon point de vue, il suffit de regarder les jeux des deux ou trois premières années et ceux des dernières années pour voir qu'il y a un gouffre), elle aurait certainement encore pu aller au delà avec des puces dans les cartouches (Nintendo a gardé ce procédé dans la SNES).

D'un autre coté, on voit exactement ce dont la MD était capable sans ajout de puce "magique".

Les add-ons c'est pas ce qui manquait sur la MD (32X - MegaCD - modem)
Mais je pense pour ma part que c'est Hudson et Nec qui avaient sortit le top du top des add-ons avec le pcengine duo et le ram pack ... ça donnait des jeux limite NeoGeo (sauf le son wav pourri)

Mais c'est vrai que l'approche de BigN de mettre des puces dans les cartouches était très malin

Je pourais pas dire pour la MD et la SNES mais pour la NES et la MS y a une difference tres notable.
le bus du GPU de la NES est connecté a la fois a la VRAM et a la cartouche alors que sur MS il n'est connecté qu'a la VRAM.
La MS avait 8x + de VRAM donc elle pouvait s'en contenter a priori sauf qu'en realité ce cablage de la NES est pour moi vraiment la bonne facon de faire une console a l'epoque, c'est a dire profiter a fond du fait que les jeux sont sur des ROMs et donc permettre au GPU d'y acceder directement plutot que de faire du loading ROM vers VRAM facon MS comme si c'etait une disquette (meme si c'est une disquette tres rapide).

Resultat sur NES tu peux switcher 8Ko de pattern en une dizaine de cycle CPU (juste le temp d'executer la commande de bank switching) alors que sur MS ca en prendra plutot 100 000 car faut deplacer chaque octet (et donc tu le fera pas de toute facon car faut le faire pendant le Vblank donc t'as pas beaucoup de temps, quand tu modifie a la volé les pattern entre 2 frames sur MS ca va etre juste quelques unes pas une centaine).
C'est bien pratique si tu veux avoir un decor tres dynamique (l'animation de la jungle, des torches et meme la parallaxe du ciel dans la video que j'ai posté c'est un simple bank switching de quelques cycle qui produit tout ca) ou un sprite principale tres gros et bien animé.

ici les plus gros metasprite de batman par exemple sont composé d'environ 20 a 25 sprites 8x8 (ce qui est un peu abusé car du coup ca clignote de partout, c'est un sapin de noel ce jeu, y a des frames de batman qui font 8 sprites de large, soit 100% du budget d'affichage par scanline juste pour batman) , tu pourrais pas stocker toutes les frames d'animations dans la memoire de pattern des sprites que ce soit sur NES ou MS (ca representerait peut etre un millier de pattern 8x8) mais sur NES pas de probleme, tu stock juste une seul frame ou deux d'animation (en gros tu te reserve un espace de 64 sprites sur les 256) et tu fais un bank switching selon la frame d'animation que t'as besoin, un bank switching d'une page de 1Ko ca te permet de switcher 64 sprite d'un coup (tu peux switcher plus que ca en meme temps mais par contre tu peux pas switcher moins que 64 sprites donc autant les utiliser).

La MS utilise aussi souvent cette methode mais la t'es obligé de vraiment modifier toi meme les pattern en les chargeant de la ROM vers la VRAM et modifier 25 pattern pendant le Vblank ca me parait pas possible car t'as d'autre chose a faire (voir d'autre pattern a changer pour animer aussi le background) et en plus les pattern MS sont 2x plus lourde (4bpp)
a la louche je dirais que sur MS tu peux peut etre changer 10 patterns par frame voir peut etre une quinzaine (sur les 448 de la VRAM), sur NES tu peux en changer 64, 128, 256 ou meme la totalité des 512 a tout moment et sans aucun impacte sur les ressources. Apres faut avoir aussi des grosses cartouches si tu veux balancer autant de pattern.

un atout de la NES qui compense la faiblesse de son affichage 2bpp vs 4bpp

La comparaison avec la NES fait mal !

Le batman sur NES on dirait presque un jeu 16 bit !
Je n'avais encore jamais vue ça !

faut dire que la version MS n'est pas tres brillante non plus, y a probablement mieux a faire, mais tu pourrais pas reproduire le passage NES que j'ai mis qui s'appuie entierement sur la force du bank switching de la CHR-ROM.

Y a une émission que j'avais découvert y a pas mal de temps sur nolife la fois ou j'avais pris un abonnement d'un mois pour allez fouiller dans les archives et j'etais tombé sur les premiers épisodes de cette serie. Ca s'appel Very Hard et ca parle uniquement de hardware.
Et j'ai decouvert que c'etait produit en association avec MO5 et que l'émission vient de se terminer et maintenant tous les episodes sont dispos sur dailymotion, 34 episodes de 5 a 10mn.

https://www.dailymotion.com/playlists/user/assomo5/1


C'est du bon boulot, sans tabous (les mots techniques, les références des chips, les chiffres... pour une fois ne sont pas considéré ici comme des "gros mot" a eviter a tout prix. On a meme droit a du porn sur les PCB filmé en gros plan) et bien sourcé. Je valide completement

Y a notamment un episode ou j'ai vraiment apprit des truc. Celui sur l'Archimede, un micro britanique que je ne connaissais pas du tout et qui est responsable de la creation du premier CPU ARM et donc la naissance de l'architecture RISC ARM qu'on retrouve dans tout les smartphones, tablettes ou la GBA, DS, 3DS...
Pour moi c'etait passionnant comme episode car je connaissais pas du tout cette histoire.
Et cette archimede sortie en 1987 (en meme temps que le X68000 ou l'Amiga 500 pour situer) se retrouvait alors avec un CPU bien plus performent que le classic 68000 tout en utilisant moins de transitors. On retrouvait un peu l'efficacité du 6502 qui avait fait son succes.
Pour faire de la 3D c'etait sans aucun doute une meilleur machine que l'Amiga ou meme le X68000 (mais bon en face les PC commencait aussi a avoir des CPU tres puissant)


Y a aussi un making of de l'émission pour mieux se rendre compte
https://www.dailymotion.com/video/xxhn9i_debug-mode-very-hard_tech

j'ai eu un archimede   

a l'epoque, ca donnait la puissance d'un 386 pour un 1/4 du prix, et tout était au top, y compris l'OS totalement en avance en terme de feature, de multitache ou de Wysiwig

On peut comparer avec l'A500, mais les prix étaient pas les mêmes, y avait un décalage entre les gammes. l'archimede de 87 etait plus à comparer avec l'amiga de 85 a 20000FF, apres ils ont sorti une version "low-cost" comparable, le A3000, celui que j'avais pris, low-cost, il coutait encore le double du prix d'un Amiga 500, et après, c'etait vraiment une machine de bidouille (super Basic, etc) avec une communauté très peu développé en France.

upsilandre a écrit:

c'est justement tout l'interet. Si t'as juste envie de rejouer a un seul jeu qui t'avais marqué tu peux le faire en 30 secondes sans avoir a rien chercher, rien manipuler, rien configurer
Donc non ce n'est pas bien mieux, c'est juste different comme demarche.

oui, ponctuellement, c'est pas mal, mais parfois un peu instable, ce qui peut laisser qq mauvaises impressions.

Enfin bon, ils ont pas Xenon 2, donc   

wazoo a écrit:

j'ai eu un archimede   

a l'epoque, ca donnait la puissance d'un 386 pour un 1/4 du prix, et tout était au top, y compris l'OS totalement en avance en terme de feature, de multitache ou de Wysiwig

On peut comparer avec l'A500, mais les prix étaient pas les mêmes, y avait un décalage entre les gammes. l'archimede de 87 etait plus à comparer avec l'amiga de 85 a 20000FF, apres ils ont sorti une version "low-cost" comparable, le A3000, celui que j'avais pris, low-cost, il coutait encore le double du prix d'un Amiga 500, et après, c'etait vraiment une machine de bidouille (super Basic, etc) avec une communauté très peu développé en France.

en 87 l'archimede c'etait 2x le prix de l'amiga 500 mais le X68000 c'etait 2x le prix de l'archimede.

edit: l'A500 en 87 c'etait 500 livres, l'archimede de base (A305) a 512Ko comme l'A500 c'etait 800 livres (875 pour la version 1Mo).
Si tu tapais pas dans la version professionnel ca restait accessible et pour quelqu'un qui en angleterre aurait eu l'idée un peu folle de faire de la 3D temps réel en 87 c'etait j'imagine une alternative interressante.
Et l'OS en ROM ca c'est classe aussi (si je me souvient bien le workbench de l'amiga c'etait sur disquette)

upsilandre a écrit:

Y a une émission que j'avais découvert y a pas mal de temps sur nolife la fois ou j'avais pris un abonnement d'un mois pour allez fouiller dans les archives et j'etais tombé sur les premiers épisodes de cette serie. Ca s'appel Very Hard et ca parle uniquement de hardware.
Et j'ai decouvert que c'etait produit en association avec MO5 et que l'émission vient de se terminer et maintenant tous les episodes sont dispos sur dailymotion, 34 episodes de 5 a 10mn.

https://www.dailymotion.com/playlists/user/assomo5/1


C'est du bon boulot, sans tabous (les mots techniques, les références des chips, les chiffres... pour une fois ne sont pas considéré ici comme des "gros mot" a eviter a tout prix. On a meme droit a du porn sur les PCB filmé en gros plan) et bien sourcé. Je valide completement

Y a notamment un episode ou j'ai vraiment apprit des truc. Celui sur l'Archimede, un micro britanique que je ne connaissais pas du tout et qui est responsable de la creation du premier CPU ARM et donc la naissance de l'architecture RISC ARM qu'on retrouve dans tout les smartphones, tablettes ou la GBA, DS, 3DS...
Pour moi c'etait passionnant comme episode car je connaissais pas du tout cette histoire.
Et cette archimede sortie en 1987 (en meme temps que le X68000 ou l'Amiga 500 pour situer) se retrouvait alors avec un CPU bien plus performent que le classic 68000 tout en utilisant moins de transitors. On retrouvait un peu l'efficacité du 6502 qui avait fait son succes.
Pour faire de la 3D c'etait sans aucun doute une meilleur machine que l'Amiga ou meme le X68000 (mais bon en face les PC commencait aussi a avoir des CPU tres puissant)


Y a aussi un making of de l'émission pour mieux se rendre compte
https://www.dailymotion.com/video/xxhn9i_debug-mode-very-hard_tech

  super cette emission.
j'ai tout bouffé  

upsilandre a écrit:

en 87 l'archimede c'etait 2x le prix de l'amiga 500 mais le X68000 c'etait 2x le prix de l'archimede.

edit: l'A500 en 87 c'etait 500 livres, l'archimede de base (A305) a 512Ko comme l'A500 c'etait 800 livres (875 pour la version 1Mo).

En import, c'etait bien plus gros comme ecart, en France, l'A500 etait distribué, alors que les Acorn, c'etait vraiment dûr à trouver.

Citation :

Si tu tapais pas dans la version professionnel ca restait accessible et pour quelqu'un qui en angleterre aurait eu l'idée un peu folle de faire de la 3D temps réel en 87 c'etait j'imagine une alternative interressante.

et la PAO avec les polices TrueType, etc

Citation :

Et l'OS en ROM ca c'est classe aussi (si je me souvient bien le workbench de l'amiga c'etait sur disquette)

oui, c'etait vraiment en avance, mais après, ca restait assez nouveau comme utilisation, la machine était multi tache, mais avec pas assez de RAM pour faire tourner vraiment plusieurs trucs, mais ca en jetait.

Après, je l'ai revendu pour un 286, et j'ai eu l'impression de revenir en arriere, mais au moins, je pouvais bosser dessus.

Parmis les notes que j'accumule dans un document je viens de m'en faire une sur la capacité d'affichage en sprite des consoles 2D mais sous un angle different et qui me parait intéressant que j'explique apres.

- Colecovision     > 12.5% (256)
- SG1000           > 12.5% (256)
- MSX                > 12.5% (256)
- NES                > 25% (256)
- Master system > 25% (256)
- Intellivision       > 40% (160)
- C64                 > 60% (160)
- PC-Engine       > 100% (256)
- SNES             > 100% (256)
- Megadrive       > 100% (320)
- X68000           > 200% (256) / 133% (384)  
- NeoGeo          > 480% (320)


Toutes ces machines avaient une gestion des sprites cablé en hard (jusqu'a la NeoGeo, ensuite on est passé a autre chose, avec du blitter, du simple deplacement de data dans un framebuffer ou du sprite sous forme de billboard polygonal). C'est a dire que le GPU ajoute les pixels du sprite par dessus le backrgound au dernier moment a la volé pendant que l'ecran est en train de balayer la ligne concerné par ces sprites. Du coup ces GPU devaient préparer pendant le balayage de la ligne précédente les pixels de sprites a afficher la ligne suivante.

Et donc ces GPU ont tous une limite dans le nombre de sprite qu'ils peuvent préparer et charger pendant la durée de balayage d'une ligne (car c'est tres bref) ce qui donne donc systematiquement une limite de sprite affichable sur la meme scanline et cette valeur fait partie des données déterminante sur la capacité d'affichage de ces machines.

Par exemple une NES ne peut afficher que 8 sprites de 8 pixels de large sur la meme ligne, soit l'equivalent de 64 pixels de sprite par scanline et sachant que la resolution standard d'un jeu NES c'est 256 j'ai défini donc une valeur de capacité d'affichage de sprite par scanline en pourcent de l'affichage horizontal total.
Donc ici la capacité d'affichage de sprite de la NES est de 25% c'est a dire que si on met cote a cote tous les sprites qu'elle peut afficher par scanline ca remplira un quart de la largeur de l'ecran, au dela de ca faudra se contenter de multiplexer et donc faire clignoter les sprites.

Donc dans ce petit tableau recapitulatif j'ai mis cette valeur en % et entre parenthèse la resolution horizontal que j'ai choisie pour définir cette valeur et qui est la résolution la plus courante des jeux de la machine. Bien sur plus cette résolution est elevé mieux c'est (pour ca que j'ai placé la megadrive devant la SNES malgré un pourcentage equivalent).

Si on lit ce tableau on peut noter deja que le C64 et l'intellivision sont bien placé dans le classement (mais dans une resolution limité. Quoique le C64 fait aussi du 60% en 320 mais les sprites sont alors monochrome donc rarement utilisé, c'est pas une resolution courante dans les jeux)

On peut dire aussi qu'on a commencer a avoir vraiment quelque chose de correct quand on a atteint les 100% (PC-Engine, SNES, Megadrive)

La machine a reve X68000 evidement bien placé (pour une machine sortie entre la Master system et la PC-engine) surtout en low-res (le 256 c'est la resolution des adaptations de Sega type Space Harrier, After Burner, Thunder blade, hang-on qui du coup ne sont pas pixel perfect car c'etait du 320 a l'origine. Alors que le 384 c'etait pour les adaptations pixel perfect du CPS de Capcom)

Et on remarque bien la NeoGeo qui explose tout mais attention ca peut etre un peu trompeur car la NeoGeo etait effectivement vraiment une machine a sprite et la ca ressort vraiment mais c'est aussi parce que la NeoGeo ne gere pas de background ou de scrolling, elle fait tout avec des sprites. Tous les backgrounds sur NeoGeo sont des sprites et donc parfois sur plusieurs couches meme si partiel donc tu peux compter je pense 200% juste pour le background.

Marrant, La NeoGeo en plus de ne pas gérer de background et scrolling ne sait pas non plus gérer de rotation et de zoom de sprite. Juste une reduction de sprite (en "sautant" des pixels) donc un sprite zoomé sur Neogeo est juste un sprite affiché dans sa taille réel sans reduction (et donc peu de chance de voir un sprite pixeliser).
Elle mise tout sur la force brute en sprite pour en cracher un maximum + un cablage direct du GPU vers la cartouche pour gérer directement un tile set jusqu'a 128Mo pour se permettre toutes les folies.

dans mame, les systèmes de cette epoque avec rotations et zooms sont des systemes qui fake la 3d comme galaxy force 2, power drift, thunderblade, etc

sur ce point une SNES est mieux cablé

Mais le plus surprenant c'est qu'il y a meme pas une fonction classic de "magnification" des sprites avec des entiers basic pour les afficher en taille x2, x3 ou x4 comme y a dans toute les consoles depuis l'Atari 2600 en passant par le videopack, intellivision, NES... et comme le tile set ne peut que se trouver en ROM et jamais en RAM y a meme pas moyen de gruger en soft avec le CPU. t'es obligé d'afficher les sprites a l'echelle 1:1 ou inferieur mais jamais superieur.
Probablement qu'il se sont dit qu'ils ont tellement de capacité qu'il pouvait se passer de ce genre de compromis (puisqu'ils peuvent afficher des sprites plus gros que l'ecran).

Etonnantes, ces trouvailles.

Un débat revient souvent sur les forums : savoir quelle machine de l'époque est la plus puissante en 2D pure. Est-ce la Neo Geo selon toi ? Ou la Saturn ? Ou la Dreamcast ? (forcément, les PS360, PS4 et Xbone le sont encore davantage je pense, tout comme la génération PS2/GC/Xbox)

la saturn etait au top a mon avis. evidemment la ps1 se debrouillait tres bien.

la dreamcast offrait tout ca avec un bump sur la resolution. sur dreamcast, on avait les jeux cps3 en 640x480, pas rien.

faut voir que la psp - entre ps1 et ps2 - se debrouille pas mal avec les emus arcade et neogeo.

La saturn c'est sur la 3D que ça merdait un max, je n'ai jamais compris pourquoi Sega avait pondu cette architecture.

Ils avaient quand même réussis à pondre un VF3 mais qui n'est jamais sortie, ça m'a beaucoup surpris surtout que ça n'avait pas l'air dégueux quand on se resitue dans le contexte de l'époque, au point que j'ai du mal à croire qu'il s'agisse vraiment de la saturn.

Le jour ou Uspi se penche dessus je m'installe confortablement, parce qu'a mon avis il va y avoir du boulot   

Rendering a écrit:

La saturn c'est sur la 3D que ça merdait un max, je n'ai jamais compris pourquoi Sega avait pondu cette architecture.

Ils avaient quand même réussis à pondre un VF3 mais qui n'est jamais sortie, ça m'a beaucoup surpris  surtout que ça n'avait pas l'air dégueux quand on se resitue dans le contexte de l'époque, au point que j'ai du mal à croire qu'il s'agisse vraiment de la saturn.

Le jour ou Uspi se penche dessus je m'installe confortablement, parce qu'a mon avis il va y avoir du boulot   

Le plus gros problème de la Saturn concernant la 3D selon moi c'est qu'elle ne gère pas l'alpha ... et ça fait une grosse différence sur le rendu de certaines textures (genre un "die hard trilogie" premier niveau n'aurai pas pu être possible sur Saturn)

Mais sinon niveau 2D elle était largement au dessus de la PS1 surtout grâce à une plus grosse quantité de RAM (la PS1 c'était pas la fête)

des trucs sympas en 2d sur saturn, plus tout un tas de shmups

http://m.youtube.com/watch?v=4vlSCTQXiRQ

Pour moi la Saturn ne peut pas completement rivaliser avec une NeoGeo combiné a des cartouches de 100Mo surtout sur du versus fighting, son acces direct au Tile set ne peut pas etre reproduit sur Saturn elle n'a pas assez de RAM pour cela (meme les 7Mo de RAM de la NeoGeo CD ne suffisait pas a supporter nativement les plus gros jeux NeoGeo, fallait les simplifier) faudrait gruger avec des methodes de compression, seul la génération suivante est en position de pouvoir surpasser la NeoGeo sur tous les points.
Mais on peut aussi imaginer plein de jeux 2D sur Saturn qui ne serait pas faisable sur NeoGeo parce que la Saturn est clairement plus puissante.

la saturn avait un ram pack de 4mo, bien utile pour les conversions d'arcade