Re: MEGADRIVE vs SUPER NINTENDO : Fight !

[Seb25]

Et la version pour Sharp x68000

elle est hors concours, vu le prix de la machine à l'époque même si elle est au top.

[Invité]

1990.

Source : Gamopat
http://gamopat.com/article-17890888.html

[Seb25]

Franchement la version MD est plus qu'honorable, il faut vraiment saluer le boulot de Sega pour convertir les hits de Capcom sur sa console, c'est vraiment nickel et je pense que Capcom n'aurait pas mieux réussi la convertion.

Dire que les versions micros Atari ST et Amiga ont été réalisés par US gold ou plutot complètement massacrés, la MD n'a pas échappé à certains jeux US gold mais il me semble que c'était un peu mieux soigné sur console, il y avait peut être des contrôles qualité plus strictes sur consoles.

[Invité]

Tu m'étonnes : quand tu vois ce que Capcom himself a fait sur MD avec Megaman et Punisher, tu m'étonnes qu'ils auraient mieux fait de laisser Sega faire leurs conversions :)

[Seb25]

La version X68000 de G'NG est sortit tard : 1994

Je viens de voir le dernier épisode de Game sack ou comment une console mythique comme la PC engine a laissé la place à un fiasco avec la PC FX, quelle déchéance quand même, si le CD rom de la Snes aurait donné ce genre de jeux, je suis presque content qu'il ne soit jamais sortit.

[Seb25]

Tu m'étonnes : quand tu vois ce que Capcom himself a fait sur MD avec Megaman et Punisher, tu m'étonnes qu'ils auraient mieux fait de laisser Sega faire leurs conversions :)

Après ils ont quand même soigné le Mickey Great Circus Mistery, plutot coloré pour de la MD

[airdream]

Et si tu veux mon avis perso, je pense que même la Megadrive seule est capable de faire même mieux que le Final Fight MCD qui fait pourtant figure de référence... Certes c'était quasi-impossible à l'époque, mais de nos jours si tu reprogramme tout le jeu, et que tu l'enfile sur une cartouche de 64 Megs, mis à part pour la bande sonore (et encore), pour tout le reste ont pourrait même exploser la version arcade...

La version arcade est hors de portée, niveau graphisme ( résolution graphique de 384*224 ) et nombre de couleurs à l'écran .

Meme sur CPS1 Final Fight fait meme pas 30MB.
alors oui avec 64 MB si FF etait reprogramme sur MD, (pas sur MCD), avec une cartouche de 64MB, il serait tres tres proche de la version arcade (ce qui est deja le cas de la version MCD) et pourrait meme se payer le luxe d'avoir des détails en plus.

pour les couleurs, sur MD la en effet ca reste une limite mais en les repensants, on peux faire mieux que ce qui a ete fait a la va vite a l'epoque. Tout est question de temps et de soins que l'on y accorde, avec cette rom MCD retravaillé en voila la preuve.

A gauche l'original, a droite le jeu retravaillé. 

   

http://www.romhacking.net/hacks/2087/

Après ils ont quand même soigné le Mickey Great Circus Mistery, plutot coloré pour de la MD

Ils ont mis du temps pour commencer a s'appliquer sur MD, les premiers jeux Capcom sur MD ne bénéficiaient pas du plus grand soin, Konami a ete un peu plus "correct" des le debut.
ceci dit c'est vrai que ce Mickey magical quest 2 est presque aussi beau que sur SNES, la différence ne saute pas aux yeux, dommage de pas avoir eu le 1 et le 3.
Meme si les graphismes sont plus chatoyants sur SNES, La MD a quand meme une resolution superieure, et l'espace de jeux est souvent plus large, ce qui permet aux jeux de plateformes de voir les obstacles/ennemis a une distance plus confortable.
Remarquez comme on se sent a l'etroit sur les ecrans SNES.

[Seb25]

Belle initiative de recolorisé FF, la version d'origine était vraiment granuleuse mais je trouve qu'il reste moins coloré que sur Snes, c'est comme le patch des voix digits de SF2, c'est bien de corriger les défauts des jeux MD mais sur Snes, le travail était soigné déjà à l'époque, pas besoin de color hack.

Pour Magical Quest 2, je pense que le jeu a été vraiment pensé pour être équivalent sur les 2 machines, je le trouve moins impressionnant visuellement que le 1er Magical Quest qui était vraiment sublime dès le 1er niveau avec de bien belles transparences, sans compter les boss qui mettaient en valeur les rotations et zooms dont est capable la Snes.

Pour les images que tu as postés, la résolution est un plus mais dès qu'il faut faire des effets d'ombre, c'est moins beau sur MD et l'effet est même absent dans EWJM2.

[Stef]

Je vois mais le résultat aurait été plus probant avec au moins un niveau supérieur avec un escalier parceque là on a vraiment l'impression d'un Wolf avec une skin Duke Nukem

Effectivement le moteur est utilisé comme un simple raycaster ce qui est dommage. Il y a surement des contraintes qui fait que du full 3d n'était pas possible non plus mais en tout le remplissage se fait vraiment comme du rendu de polygone texturé (ce qui est un choix assez étrange en effet).

Pour la démo de Star fox, ça tourne bien sauf les déchirures d'écran horizontales, après il faut voir en conditions de jeu si ce serait aussi fluide mais c'est déjà bien mieux que ce qu'on pouvait voir dans les jeux 3D flat de l'époque

Il faut bien voir que dans un jeu comme Starfox, ce qui consomme quasi tout le temps cpu, c'est les transformations 3D et le rendu. Dans la démo ces 2 parties sont fonctionnelles.. Certes en condition de jeu y'a des ennemis a ajouter... Mais quand tu vois comment le moteur tourne, tu te dis qu'il est définitivement possible de faire quelque de proche au starfox SNES sur une MD sans hardware supplémentaire. Pour le déchirement horizontal, tu parles d'un problème de VBlank ? Ou tu parles du plan qui se penche derrière ?

[airdream]

Sur FF SNES les couleurs meme si elles sont plus belles que sur MD, ne sont pas a la hauteur de ce que peu offrir la SNES. Si le jeu devait etre retravaille sur SNES, Ca serai plus sur l'ajout d'un 2 joueur, et des 3 perso dispo des le depart, mais les couleurs auraient aussi a y gagner
une cartouche de 16 ou 24 MB devrait faire l'affaire pour ca.

Pour magical quest, je partage ton avis le 1er est une tuerie, et je ne retrouve pas cette magie dans ses suites.
seul le cote 2 players donne un avantage aux suites.

[Stef]

Je suis pas sur de tes calculs, même si des roms de 500 ns ont été utilisées avec les premiers jeux il semble que 200 ns soit le minimum pour un fonctionnement normal  ..

Heu tu te rends compte que c'est un peu aberrant ce que tu dis là?
tu verras que sur le topic que tu as cité y'a pas mal d'erreur avec des gens qui s'embrouillent avec temps d'accès et temps de cycle, aussi certains oublient l'aspect 16 bits du bus... Bref on lit un peu tout et n'importe quoi 😊
Dans les faits pour supporter un DMA type Rom --> vram il faut de la rom a 1.66mhz et pour supporter le Rom --> cram il faut de la rom a 3.22 Mhz (mais c'est pas vraiment utile car faisable depuis la ram). Dans les faits pour ne pas occasionner de wait state sur le 68k il fallait au moins 1.92mhz soit 520ns... Ce qui est vraiment lent. Sur Snes il faut au moins 2.78 mhz, donc la rom était un peu plus couteuse, sans même parler de la Fast rom encore plus cher pour éviter un cpu un peu plus rapide.

[Seb25]

Il faut bien voir que dans un jeu comme Starfox, ce qui consomme quasi tout le temps cpu, c'est les transformations 3D et le rendu. Dans la démo ces 2 parties sont fonctionnelles.. Certes en condition de jeu y'a des ennemis a ajouter... Mais quand tu vois comment le moteur tourne, tu te dis qu'il est définitivement possible de faire quelque de proche au starfox SNES sur une MD sans hardware supplémentaire. Pour le déchirement horizontal, tu parles d'un problème de VBlank ? Ou tu parles du plan qui se penche derrière ?

En fait, dès que la caméra penche d'un coté quand le vaisseau vire à droite ou à gauche, j'ai eu cette impression de déchirures horizontales sur la sphere en 3d vers 1:29, bon après ça reste une démo bien réalisée.

[tbp]

Sur FF SNES les couleurs meme si elles sont plus belles que sur MD, ne sont pas a la hauteur de ce que peu offrir la SNES. Si le jeu devait etre retravaille sur SNES, Ca serai plus sur l'ajout d'un 2 joueur, et des 3 perso dispo des le depart, mais les couleurs auraient aussi a y gagner
une cartouche de 16 ou 24 MB devrait faire l'affaire pour ca.

Y'a qu'à comparer le  1er Final Fight SNES au Final Fight 2 et surtout au Final Fight 3 pour se convaincre que ce 1er portage n'était pas terrible du tout en dépit de couleurs chatoyantes. Mais à l'époque, il n'y avait presque que ça alors les possesseurs de SNES étaient satisfaits, là on a presque 25 ans de recul dans nos propos.
Pour la taille des cartouches et ça déjà était dit maintes fois, à l'époque la mémoire coûtait bien plus cher que maintenant pour fabriquer des cartouche en masse. Donc SEGA ou NINTENDO calculaient bien les choses pour ne pas se ruiner et optimisait leur rentabilité, au détriment de la qualité du contenu, ce qui se traduisait parfois par de gros sacrifices (voire un massacre), ou tantôt par des petits sacrifices ^^

Tu m'étonnes : quand tu vois ce que Capcom himself a fait sur MD avec Megaman et Punisher, tu m'étonnes qu'ils auraient mieux fait de laisser Sega faire leurs conversions :)

Rien n'est moins sûr parce que les conversions des hits d'arcade de SEGA sur Megadrive pour certaines auraient pu être aussi meilleures. Touko et d'autres membres pourront mieux argumenter là-dessus et connaissent mieux le sujet qui a été déjà abordé y'a quelques mois.
Ensuite, je trouve que Punisher n'est pas un mauvais jeu, j'aime bien ce Beat them All sur MD, je le trouve dynamique et respectant l'esprit ou le feeling du jeu d'arcade, agréable à jouer et aucun contenu essentiel n'a été tronqué. Seule sa réalisation graphique a été bâclée et on sait tous que la MD est capable de mieux.
Mais je trouve la "critique" trop sévère et quelque peu injuste envers ce jeu en soi, il faut le prendre avant tout comme un jeu MD à part entière et faire abstraction du jeu arcade originale.

[Stef]

Oui je connais tout cela , Je connais pas tout les gars de NesDev , mais si tu me parle du sous forum SNES-Dev il n'y a alors que 2,3 gars que je considère talentueux , le reste a force d’être sur la prog SNES ont ds connaissances mais rien extraordinaire de mon point de vue.

Après très peu vienne du 'monde de la programmation' en général ils sont plus d'un autre milieu alors les regles de programmation c'est pas leur fort , ils sont tres compétent techniquement mais cela ne veut pas dire que ça soit des personnes qui sont fort en algorithmie ou qu'il maitrise plusieurs paradigme , ce sont des domaines très différents.
Pour ma part par exemple faire du pascal + algo te rend plus compétent que de faire de l'assembleur sur une machine particulière.

Oui c'est vrai, peut être que pour certains c'est plus une connaissance de la machine sans forcement avoir l'expérience en programmation derrière... Sinon du coup tu fréquentes quels forums pour ça car en forum "retro Dev" y'a pas non beaucoup de chose :-/ je connais assemblergame, spritesmind (dédié sega 16bits), atariage (plutôt Atari), quelques autres que je n'ai pas en tête mais c'est pas bien folichon en général.

[Stef]

En fait, dès que la caméra penche d'un coté quand le vaisseau vire à droite ou à gauche, j'ai eu cette impression de déchirures horizontales sur la sphere en 3d vers 1:29, bon après ça reste une démo bien réalisée.

Ah oui ça doit la version de la démo qui n'utilise pas encore le dma, dans les derniers versions le déchirement n'est plus la.

[Invité]

Heu tu te rends compte que c'est un peu aberrant ce que tu dis là? 
tu verras que sur le topic que tu as cité y'a pas mal d'erreur avec des gens qui s'embrouillent avec temps d'accès et temps de cycle, aussi certains oublient l'aspect 16 bits du bus... Bref on lit un peu tout et n'importe quoi 😊

J'ai bien vu que personne ne semblait d'accord, mais bon y'a quand même le gratin du dev Md dans ce topic, TMee, chilly, nunno (WM), etc .. 
mais même avec ton estimation on est à 250 ns pour la RAM MD, donc toujours plus rapide que les 270 ns pour la fast ROM/RAM de la snes,donc mettre ce type de RAM ET ROM sur snes pour que le CPU tourne à un 3,58 réel + DMA en conséquence,avec en plus un passage à 64 ko de ram était faisable sans aucun soucis .

Dans les faits pour ne pas occasionner de wait state sur le 68k il fallait au moins 1.92mhz soit 520ns... 

Oui le 68k peut se contenter de mémoire aussi lente sans soucis, mais pas le DMA, pour que le DMA fonctionne dans tout ses modes de copies il lui faut de la mémoire bcp plus rapide,donc ça annule l'intérêt du 68k en ce qui concerne l'utilisation de mémoire lente dans une console pour moi .
 

Je viens de voir le dernier épisode de Game sack ou comment une console mythique comme la PC engine a laissé la place à un fiasco avec la PC FX,

La PCFX était une super console 2D, une supergrafx dopée aux hormones,mais sortie bcp,bcp trop tard ..

Y'a qu'à comparer le  1er Final Fight SNES au Final Fight 2 et surtout au Final Fight 3 pour se convaincre que ce 1er portage n'était pas terrible du tout en dépit de couleurs chatoyantes. Mais à l'époque, il n'y avait presque que ça alors les possesseurs de SNES étaient satisfaits, là on a presque 25 ans de recul dans nos propos.
Pour la taille des cartouches et ça déjà était dit maintes fois, à l'époque la mémoire coûtait bien plus cher que maintenant pour fabriquer des cartouche en masse. Donc SEGA ou NINTENDO calculaient bien les choses pour ne pas se ruiner et optimisait leur rentabilité, au détriment de la qualité du contenu, ce qui se traduisait parfois par de gros sacrifices (voire un massacre), ou tantôt par des petits sacrifices ^^

Tout à fait, la logique à toujours été de dépenser moins pour gagner plus, et puis sur une cartouche de 8Mb avec un jeu de début de vie de la machine, je trouve que FF n'est pas si pourri .
Mais c'est le lot de toutes les machines .

[Stef]

J'ai bien vu que personne ne semblait d'accord, mais bon y'a quand même le gratin du dev Md dans ce topic, TMee, chilly, nunno (WM), etc .. 
mais même avec ton estimation on est à 250 ns pour la RAM MD, donc toujours plus rapide que les 270 ns pour la fast ROM/RAM de la snes,donc mettre ce type de RAM ET ROM sur snes pour que le CPU tourne à un 3,58 réel + DMA en conséquence,avec en plus un passage à 64 ko de ram était faisable sans aucun soucis .

Le calcul est pourtant simple :
Sur MD, pour le cas extrême ou tu utilises le DMA vers CRAM et VSRAM (ce qui est rare) :
1 / (262 * 60 * 205) ~ 310.3 ns donc en théorie 310 ns est suffisant mais pour la sécurité on va dire 300ns.
Après pour la RAM c'est un peu plus compliqué, car y'a le refresh. Du coup tu as un temps d'accès et ensuite un temps de cycle ( http://en.wikipedia.org/wiki/Dynamic_random-access_memory ) et pour le DMA c'est le temps de cycle qui est important (qui est plus rapide que le temps d'accès) du coup en terme d'accès la RAM de la MD doit se contenter de ce que le CPU lui demande soit 520 ns et un temps de cycle de 300 ns pour le DMA. La RAM de la SNES (à 2.78 Mhz) doit avoir un temps d'accés de 350 ns et un temps de cycle qui n'a ici pas besoin d'être plus rapide (et du coup peut être utiliser une SRAM plutot qu'une DRAM comme sur MD). Du coup à quantité équivalente, la RAM de la SNES est malgré tout plus cher que celle de la MD (le access-time étant le plus difficile à réduire). Et aussi je pense que l'intérêt de mettre de la RAM à 3.58 Mhz (ce qui aurait je pense sensiblement augmenté le cout de la machine) était de toute manière limité à cause de la ROM qui n'aurait pas pu suivre dans un premier temps... peut être aurait ce été malgré tout un choix plus judicieux de mettre 64 ko de RAM à 3.58 Mhz et réduire les couts sur d'autres composants vu l'architecture de la machine.
Enfin bref, sur MD, inutile de mettre de la ROM rapide car le DMA vers CRAM et VSRAM peut être fait depuis la RAM et n'a que peu d'intéret. Et puis même sur la RAM au final les couts sont moindre grâce à l'utilisation possible de DRAM pas très rapide, c'est ça tout l'avantage du 68000 et du bus 16 bits de la MD.
La SNES souffre énormément de son architecture 8 bits, de son CPU à faible rendement et est obligé d'avoir des composants plus rapide (ROM à 350 ns ou 270 ns pour la fast ROM et ram à 350 ns) pour des résultats moindres.

Edit: dans les faits même si la RAM de la MD doit avoir un temps d'accès certifié de 520ns pour répondre au CPU elle peut aller plus vite ce qui permet d'overclocker le CPU (mais après ce n'est plus certifié et en général ça commence à foirer au dessus de 12 Mhz).

[Invité]

Ah ok, voilà une explication claire pour une fois ..

Là je suis d'accord,c'est logique et ça concorde .. 

La SNES souffre énormément de son architecture 8 bits, de son CPU à faible rendement et est obligé d'avoir des composants plus rapide (ROM à 350 ns ou 270 ns pour la fast ROM et ram à 350 ns) pour des résultats moindres.

On est d'accord, mais le passage à 3,58 te fait gagner 40% de cycles CPU en plus et de BP pour le DMA .
C'est pas rien quand même,surtout que bcp de cycles CPU sont dépensés pour corriger des erreurs de conceptions, comme l'OAM en bois .

[Stef]

Ah ok, voilà une explication claire pour une fois ..
Là je suis d'accord,c'est logique et ça concorde .. 

Ha non mais j’appuie toujours mes dires avec des chiffres ! Je ne vois pas comment tu peux dire ça

On est d'accord, mais le passage à 3,58 te fait gagner 40% de cycles CPU en plus et de BP pour le DMA .
C'est pas rien quand même,surtout que bcp de cycles CPU sont dépensés pour corriger des erreurs de conceptions, comme l'OAM en bois .

Comment tu calcules un gain de 40% en passant de 2.78 à 3.58 Mhz O_o ? Même en considérant la RAM et la ROM, ça te fait juste 0.8 Mhz de plus soit par rapport à 2.78 Mhz environ 29% de plus ce qui n'est pas si énorme, et ce qui à mon sens, ne sauve pas la machine :p

[Invité]

Ha non mais j’appuie toujours mes dires avec des chiffres ! Je ne vois pas comment tu peux dire ça 

Oui avec des chiffres, mais pas les explications qui vont avec   

Comment tu calcules un gain de 40% en passant de 2.78 à 3.58 Mhz O_o ? Même en considérant la RAM et la ROM, ça te fait juste 0.8 Mhz de plus soit par rapport à 2.78 Mhz environ 29% de plus ce qui n'est pas si énorme, et ce qui à mon sens, ne sauve pas la machine :p

C'est 2.56 la vraie fréquence et non 2.78, mais effectivement ça donne un 30% et pas 40 ..
30% c'est déjà bcp pour 1mhz de plus .
Avec 30% de CPU (tu gagnes presque 18 000 cycles/frame) et pour le DMA,avec 30% la console fait mieux en h32 que la MD en h40 (on arrive à 7.4 ko / frame, j'ai pris 5.7 ko comme ref pour le DMA de la snes),donc pas négligeable du tout  .

Enfin je vois ton objectivité là, 30% de CPU+DMA c'est pas bcp, mais 20% en plus pour la MD sur la résolution (qui se voit pas en plus) c'est énorme 

[Stef]

C'est 2.56 la vraie fréquence et non 2.78, mais effectivement ça donne un 30% et pas 40 ..
30% c'est déjà bcp pour 1mhz de plus .
Avec 30% de CPU (tu gagnes presque 18 000 cycles/frame) et pour le DMA,avec 30% la console fait mieux en h32 que la MD en h40 (on arrive à 7.4 ko / frame, j'ai pris 5.7 ko comme ref pour le DMA de la snes),donc pas négligeable du tout  .

En fait c'est 2.68 Mhz de base, on s'y perd toujours avec ces chiffres :p
Soit 33% de plus, mais quoiqu'il en soit pour que ça marche il faut à la fois une RAM et une ROM à 3.58 Mhz et autant la RAM pourquoi pas avec certains concessions ailleurs, mais la ROM je pense qu'il aurait été très difficile pour Nintendo d'utiliser une ROM si rapide dés le début, ça aurait beaucoup augmenté le cout des cartouches (qui était déjà assez élevé).
Et je ne vois pas pourquoi tu lies les performances du DMA à ça, c'est un raccourci bien trop facile ! Les performances du DMA s'attachent aussi à la vitesse de la VRAM et du PPU et là c'est une tout autre histoire (faire passer le transfert de 8 master cycle à 6 master cycle demande surement des modifs internes du PPU assez importantes et une VRAM plus rapide).

Enfin je vois ton objectivité là, 30% de CPU+DMA c'est pas bcp, mais 20% en plus pour la MD sur la résolution (qui se voit pas en plus) c'est énorme 

Déjà c'est 33% contre 25%. Pour la SNES c'est surtout que 33% de pas grand chose ben ça fait toujours pas grand chose    C'est mieux mais toujours insuffisant pour une console de cette catégorie :p
Et pour la MD, les 25% de pixels en plus c'est tout dans la largeur, du coup en terme d'espace de jeux c'est quand même pas négligeable, je pense que les screens postés un peu plus haut le montrent bien.

[sengoku 2]

Et si tu veux mon avis perso, je pense que même la Megadrive seule est capable de faire même mieux que le Final Fight MCD qui fait pourtant figure de référence... Certes c'était quasi-impossible à l'époque, mais de nos jours si tu reprogramme tout le jeu, et que tu l'enfile sur une cartouche de 64 Megs, mis à part pour la bande sonore (et encore), pour tout le reste ont pourrait même exploser la version arcade...

La version arcade est hors de portée, niveau graphisme ( résolution graphique de 384*224 ) et nombre de couleurs à l'écran .

Meme sur CPS1 Final Fight fait meme pas 30MB.
alors oui avec 64 MB si FF etait reprogramme sur MD, (pas sur MCD), avec une cartouche de 64MB, il serait tres tres proche de la version arcade (ce qui est deja le cas de la version MCD) et pourrait meme se payer le luxe d'avoir des détails en plus.

pour les couleurs, sur MD la en effet ca reste une limite mais en les repensants, on peux faire mieux que ce qui a ete fait a la va vite a l'epoque. Tout est question de temps et de soins que l'on y accorde, avec cette rom MCD retravaillé en voila la preuve.

A gauche l'original, a droite le jeu retravaillé. 

   

http://www.romhacking.net/hacks/2087/

Je répondais à Sentenza qui avait employé le terme " exploser ", quant à toi Airdream tu dis " serais très très proche de la version arcade ", donc je rejoins ton avis. Par contre, je n'étais pas d'accord avec le terme "exploser ".


Même Stef et d'autres MD fans disent que :
 " Et pour la MD, les 25% de pixels en plus c'est tout dans la largeur, du coup en terme d'espace de jeux c'est quand même pas négligeable, je pense que les screens postés un peu plus haut le montrent bien."

Donc si vous prenez en compte cela pour les jeux en commun Snes Vs MD comme le roi lion etc..., alors avec un jeu CPS 1 converti sur MD, vous devez dire que les 25 % de pixels en + dans la largeur en faveur du CPS 1, ça pèse lourd dans la balance.

[Invité]

En fait c'est 2.68 Mhz de base, on s'y perd toujours avec ces chiffres :p

nan c'est bien 2,56 ou alors la doc est fausse,ou alors la slow rom ne tournerait pas à la même vitesse que la wram .

http://wiki.superfamicom.org/snes/show/Programming+with+FastROM

Et je ne vois pas pourquoi tu lies les performances du DMA à ça

Parce que le DMA est bel est bien défini par rapport à la vitesse de la RAM ici, étant la partie accessible la plus lente .

performances du DMA s'attachent aussi à la vitesse de la VRAM et du PPU et là c'est une tout autre histoire (faire passer le transfert de 8 master cycle à 6 master cycle demande surement des modifs internes du PPU assez importantes et une VRAM plus rapide).

Surement, c'est pas une fois que tout est fini, que tu remets tout en question, c'est surement une de ces raisons que la vitesse du CPU et le choix de la RAM sont resté en l'état,et que le passage en 512 pixels n'augmente en rien la vitesse de transfert .
La VRAM est une 100 ns, donc je pense largement suffisante .

Déjà c'est 33% contre 25%. Pour la SNES c'est surtout que 33% de pas grand chose ben ça fait toujours pas grand chose     C'est mieux mais toujours insuffisant pour une console de cette catégorie :p 

Non, 20% de 320 = 64 pixels, 64+256 pixels = 320 pixels 
bah avec plus de 7ko de transfert DMA et 18000 cycles CPU de plus on fait bcp de choses .. 
Bon c'est vrai que sur 68k tu fais 2 additions 8bits ça prend déjà 18000 cyles 

Donc si vous prenez en compte cela pour les jeux en commun Snes Vs MD comme le roi lion etc..., alors avec un jeu CPS 1 converti sur MD, vous devez dire que les 25 % de pixels en + dans la largeur en faveur du CPS 1, ça pèse lourd dans la balance. 

Tu rêves là, pour le pro Md, les chiffres n'ont pas les mêmes valeurs selon le sens où ils sont employés   
Le preuve avec stef,20% d'un côté c'est énorme, 30% de l'autre c'est pas bcp) 

[Stef]

nan c'est bien 2,56 ou alors la doc est fausse,ou alors la slow rom ne tournerait pas à la même vitesse que la wram .

http://wiki.superfamicom.org/snes/show/Programming+with+FastROM

Ben je pense qu'il y a effectivement une erreur avec ta doc :
http://www.smwiki.net/wiki/Super_Nintendo_Entertainment_System

Et surtout ça ne colle pas sur les coef multiplicateur :
Slow ROM & RAM = master / 8 = 21.47 / 8 ~ 2.68 MHz
Fast ROM  = master / 6 ~ 3.58Mhz

Parce que le DMA est bel est bien défini par rapport à la vitesse de la RAM ici, étant la partie accessible la plus lente .

Ben ça c'est toi qui le dit, dans les faits je pense que tout est calé sur cette vitesse et que le PPU et la VRAM ne peuvent pas aller plus vite de toute façon... Si c'était possible tu penses bien que le DMA supporterait la vitesse de la Fast-ROM (ce qui offrirait un gain de bande passante importante en cas d'utilisation de Fast ROM).

Non, 20% de 320 = 64 pixels, 64+256 pixels = 320 pixels 
bah avec plus de 7ko de transfert DMA et 18000 cycles CPU de plus on fait bcp de choses .. 
Bon c'est vrai que sur 68k tu fais 2 additions 8bits ça prend déjà 18000 cyles 

Non j'ai calculé dans l'autre sens et pour les 2 côtés   donc pour être juste c'est soit 33% et 25% ou ~27% et 20%... Tu peux troller mais ça n'enlève rien au résultat :p

Tu rêves là, pour le pro Md, les chiffres n'ont pas les mêmes valeurs selon le sens où ils sont employés   
Le preuve avec stef,20% d'un côté c'est énorme, 30% de l'autre c'est pas bcp) 

Mais oui c'est bien connu, je suis d'archi mauvaise foi...

[Invité]

Ben je pense qu'il y a effectivement une erreur avec ta doc : 
http://www.smwiki.net/wiki/Super_Nintendo_Entertainment_System

Et surtout ça ne colle pas sur les coef multiplicateur :
Slow ROM & RAM = master / 8 = 21.47 / 8 ~ 2.68 MHz
Fast ROM  = master / 6 ~ 3.58Mhz

Je pense aussi, car sur snesdev, ils parlent bien de 2,68 aussi .
D'ailleurs justement en parlant de wram, c'est bien de la DRAM, donc de la grosse merde pour les 65xx car elle te bloque le DMA et le CPU pendant 40 cycles à chaque ligne pour le refresh .

Ben ça c'est toi qui le dit, dans les faits je pense que tout est calé sur cette vitesse et que le PPU et la VRAM ne peuvent pas aller plus vite de toute façon... Si c'était possible tu penses bien que le DMA supporterait la vitesse de la Fast-ROM (ce qui offrirait un gain de bande passante importante en cas d'utilisation de Fast ROM).

Ah non pas du tout, et pareil c'est sur snesdev que c'est dit que c'est bien par rapport à la wram/slow rom ..

Non j'ai calculé dans l'autre sens et pour les 2 côtés   donc pour être juste c'est soit 33% et 25% ou ~27% et 20%... Tu peux troller mais ça n'enlève rien au résultat :p

Euh non je trolle pas, 320 c'est bien 20% supérieur à 256 ..
Tu peux t'amuser avec ça si tu veux :
http://calculis.net/pourcentage#pourcentage


Je prends les devants et t'affiche le résultat:

256 × 100 ÷ 320 = 80
256 représente 80% de 320

Merde alors, même les calculateurs de % en ligne sont des nintendoll's 
Bon comme je suis bon joueur, 25% en plus sur 256 donne aussi 320 

Mais oui c'est bien connu, je suis d'archi mauvaise foi...

Bah comme tout le monde ici non ??
Maintenant si tu es sérieux en disant que tu ne l'es pas, c'est que tu es un gros fan boy alors 

[tbp]

Je répondais à Sentenza qui avait employé le terme " exploser ", quant à toi Airdream tu dis " serais très très proche de la version arcade ", donc je rejoins ton avis. Par contre, je n'étais pas d'accord avec le terme "exploser ".

Avec un bon moteur et une démarche d'optimisation sur une cartouche de grande capacité, oui la Megadrive est capable de délivrer un jeu de type arcade de grande qualité, et on pourrait avoir un excellent portage de Final Fight, sans doute mieux graphiquement que le portage Final Fight CD (mais on a de superbes musiques...).
Cela dépend du jeu et de l'exigence au niveau des effets et de la "charte" graphiques etc. Par exemple, il sera difficile d'obtenir une qualité très approchante sur un jeu comme The Punisher Arcade, ce n'est pas du même degré technique qu'un Final Fight 1er du nom.
Par contre, des jeux comme celui-là Big Fight https://www.youtube.com/watch?v=UAJR-3KOODQ, un Captain Commando ou un Undercover Cops, ce serait potentiellement possible et dans le domaine du raisonnable. Je pense que la limite haute se situerait au niveau d'un Cadillacs & Dinosaurs (mais celui-là a de très gros sprites... à voir ^^). Nous verrons bien le niveau de qualité que l'équipe de WaterMelon auront réussi à atteindre avec Project Y. Le temps nous le dira mais ça nous montrera concrétement le potentiel en la matière de la Megadrive.

[speedsterharry]

Je prends les devants et t'affiche le résultat:

256 × 100 ÷ 320 = 80
256 représente 80% de 320

Euh désolé, mais tu te trompes, si 256 représente bien 80% de 320,
320 n'est pas supérieur de 20% à 256 (imprègne-toi de cette mantra, elle pourra t'etre utile pour détecter des conneries assenées à la télé)
320 représente 320/256 de 256, càd 1,25 de 256 càd 25% supérieur à 256

On ne compense pas une baisse de 10% par une hausse de 10% (fais le test si tu veux)

Les gens le pensent (et toi aussi touko) car ils confondent 100% de 256 et 100% de 320 dans leur raisonnement ...

Pour tout ce qui est architecture des machines, tu m'enfonceras comme tu veux cela dit

[Stef]

Je pense aussi, car sur snesdev, ils parlent bien de 2,68 aussi .
D'ailleurs justement en parlant de wram, c'est bien de la DRAM, donc de la grosse merde pour les 65xx car elle te bloque le DMA et le CPU pendant 40 cycles à chaque ligne pour le refresh .

40 cycles à chaque ligne ??
Je pense que c'est 40 cycles par frame non ? le refresh se fait "heureusement" assez peu souvent. Je suis étonné du choix de la DRAM pour la WRAM sur SNES mais bon.

Ah non pas du tout, et pareil c'est sur snesdev que c'est dit que c'est bien par rapport à la wram/slow rom ..

C'est des suppositions et on peut pas vraiment savoir mais il apparait quand même que le master / 8 pour clocker le DMA est très pratique et qu'il y a de forte chance que ça ne puisse pas se faire plus rapidement. Et rien que le fait que la Fast ROM ne permette pas à celui ci d'aller plus vite semble confirmer mes dires...  mais bon après on ne pourra jamais savoir en détail.

Euh non je trolle pas, 320 c'est bien 20% supérieur à 256 ..
Tu peux t'amuser avec ça si tu veux :
http://calculis.net/pourcentage#pourcentage

Non mais t'es un sacré toi ! Tout dépend du sens que tu considères.
Inverses les chiffres dans ton formulaire...
320 = 125% de 256
soit 100% de 256 + 25% de 256.
Et 256 représente 80% de 320...
Donc je dirais, dans un bon français il vaut mieux dire que 320 c'est 25% de plus que 256 (si on considère 256 comme la valeur de référence).
Et j'ai calculé de la même manière pour dire que 3.58 Mhz c'est 33% de plus que 2.68Mhz (2.68 étant la valeur de référence).

Je prends les devants et t'affiche le résultat:

256 × 100 ÷ 320 = 80
256 représente 80% de 320

Le pire c'est que tu insistes, je pense que tu avais très bien compris ce que je voulais dire.
La valeur de référence c'est 256, donc 320 c'est bien 25% de plus, on va pas faire un fromage pour 5% non ?

Merde alors, même les calculateurs de % en ligne sont des nintendoll's 
Bon comme je suis bon joueur, 25% en plus sur 256 donne aussi 320 

Ah bon quand même (je lis au fur et à mesure)

[Invité]

Donc je dirais, dans un bon français il vaut mieux dire que 320 c'est 25% de plus que 256 (si on considère 256 comme la valeur de référence).

 
Trop fort, ouai le bon français quand ça t'arrange   

La valeur de référence c'est 256, donc 320 c'est bien 25% de plus, on va pas faire un fromage pour 5% non ?

Pas du tout, d'où ma phrase si on prend 256 comme ref c'est 25% 

Ah bon quand même (je lis au fur et à mesure) 

Voilà,c'est ce que je dis, mais 20/25% en faveur de la Md c'est bcp, 30/33% en faveur de la snes c'est peu, mais à part ça tu n'es pas de mauvaise foi  ..

40 cycles à chaque ligne ??
Je pense que c'est 40 cycles par frame non ? le refresh se fait "heureusement" assez peu souvent. Je suis étonné du choix de la DRAM pour la WRAM sur SNES mais bon.

Oui les 40 cycles sont pris au milieu de chaque ligne .
Moi aussi je l'ai été, mais bon maintenant plus rien me surprend sur snes 

[Stef]

Voilà, c'est ce que je dis, donc 20/25% en faveur de la Md c'est bcp, 30/33% en faveur de la snes c'est peu, mais à part ça tu n'es pas de mauvaise foi  ..

Tu aimes bien en rajouter, relis mes phrases j'ai jamais dis ça... J'ai jamais dit que la résolution de la megadrive était *beaucoup* plus grande mais simplement le fait que tout étant répartie dans la largeur ça sent quand même nettement en terme d'espace de jeu quand tu joues au même jeu sur les 2 machines (encore une fois, voir les screenshots postés précédemment). Et sur SNES tu considères une full augmentation de 33% ce qui est un *gros* raccourcis. Et puis ce n'est pas la bande passante video le problème de la SNES ! A résolution équivalente c'est à peu près identique à la MD, le vrai problème ça reste son CPU. Même s'il tournait en full à 3.58 Mhz, il resterait plus lent que le 68000 de la MD tout en nécessitant des composants plus cher.
Enfin on tourne en rond... je pense qu'au moins tu comprends mieux pourquoi je trouve l'architecture 65x0 si mauvaise.

Oui les 40 cycles sont pris au milieu de chaque ligne.

Oui j'avais lu ça, mais je pensais que c'était 40 cycles par frame et pas par ligne...
En gros tu as 1325 master cycles par ligne pour le CPU plutot que 1365 cycles, c'est pas non plus une grosse perte :p


Ah et pour le plaisir :
https://www.dailymotion.com/video/x18f48a_mega-drive-genesis-best-visuals-and-effects-part-1-2_videogames
https://www.dailymotion.com/video/x18ezu4_mega-drive-genesis-best-visuals-and-effects-part-2-2_videogames

[Invité]

Tu aimes bien en rajouter, relis mes phrases j'ai jamais dis ça... J'ai jamais dit que la résolution de la megadrive était *beaucoup* plus grande mais simplement le fait que tout étant répartie dans la largeur ça sent quand même nettement en terme d'espace de jeu quand tu joues au même jeu sur les 2 machines (encore une fois, voir les screenshots postés précédemment). Et sur SNES tu considères une full augmentation de 33% ce qui est un *gros* raccourcis. Et puis ce n'est pas la bande passante video le problème de la SNES ! A résolution équivalente c'est à peu près identique à la MD, le vrai problème ça reste son CPU. Même s'il tournait en full à 3.58 Mhz, il resterait plus lent que le 68000 de la MD tout en nécessitant des composants plus cher.
Enfin on tourne en rond... je pense qu'au moins tu comprends mieux pourquoi je trouve l'architecture 65x0 si mauvaise.

On serra jamais d'accord, car tu oublies quand même que le combo 68k + Z80 coûte très cher,de plus tu oublies quand même que si le 68000 sait se contenter de mémoire lentes donc moins chère, ton DMA lui non (même si elle est moindre que sur 65xxx) .
Si on était dans la configuration d'un ordi, je serrai totalement de ton avis.
Là le problème de la snes ne vient pas de son CPU, mais surtout de l'architecture qui est mal pensée, ton problème c'est que tu focalises tout sur le CPU comme si tout le reste était clean, et c'est là où je suis pas d'accord avec toi .
Je peux te garantir qu'avec un CPU en full 3,58, et une archi clean comme sur Md ou PCE ,la snes n'aurait eu aucun soucis .

Après que tu trouves les 65xx pourris, bon bah c'est ton avis, mais alors accepte aussi que d'autres trouvent le 68000 dans une console, pourri aussi 

En gros tu as 1325 master cycles par ligne pour le CPU plutot que 1365 cycles, c'est pas non plus une grosse perte :p

Bah,oui 1325 cycles par ci, 18000 par là, sachant qu'au max (3,58) le CPU ne dispose que de 60000 cycles ça commence à compter,sans compter tout les cycles perdus à compenser des trucs qui sont normalement géré sur Md ou PCE , et vu les jeux qu'on a pu avoir sur snes, on peut franchement dire que le CPU n'est pas si mauvais que ça .