Re: MEGADRIVE vs SUPER NINTENDO : Fight !

[wiiwii007]

Je viens de lancer Final Fight 1 et 3 via emulateur pour ce dernier, J'ai fait les 3 premiers niveaux et je vous assure a aucun moment il y n'y a eu 4 ennemies a l'ecran.
Maximum 3 ennemies simultané, quand l'un meurt, il est vite remplacé par un autre.
pourtant FF3 date de 95!!
je suis pas prêt de lâcher ma série SOR, rien que sur le premier épisode j'ai jamais réussi a compter le nombre d'ennemies max a l’écran, si on a pas peur et qu'on avance jusqu'a ce que le scrolling s’arrête tout seul sans tuer aucun mechant, on a une vague impressionnante qui nous submerge, a mon avis on dépasse largement les 10 facilement. Bon c'est vrai que parfois ca clignote ou ca ralentit aussi, mais quand meme, c'est trois fois plus que sur SNES.
Heureusement qu'il existe une version MCD de FF pour rattraper tout ca!

 

 

C'est clair qu'il n'y a pas photos dans cette comparaison, mais perso, ce qui me gonfle le plus, ce n'est pas de ne pas avoir plein d'ennemis à l'écran mais plutôt que les ennemis se battent quasiment tous de la même façon...

Sur SOR, même si il y a que trois ennemis à l'écran, ceux-ci sont plus mobiles et chiants à battre et du coup tu t'amuses, dans final fight et dans le même cas, c'est pas super... Comme quoi, de beaux graphismes (je les trouve bien supérieur à SOR) ne font pas un super jeu...

[Stef]

A vrai dire j'ai pas regardé le jeu en profondeur, je n'ai vu que les 2 plans, et ils étaient assez sommaires .
De plus le jeu n'ayant pas bcp de scrollings, c'est pas compliqué à refaire avec un seul plan, mais c'est surtout parce que les seconds plans sont simples, limites fait pour le swap de tiles .
Je vais essayer de voir pour les 3 plans du jeu ..

EDIT: ouai, le swap de tiles serrait plus valable pour les niveaux en intérieur .

Y'a aussi le boss du début qui zoome en mode 7, ça aussi ça serrait pas simple à faire .

Ouais y'a quelques effets comme ça ou effectivement tu ne pourras pas les retranscrire tel quels mais y'a toujours moyen de faire autrement et pas forcément moins bien

[Stef]

C'est clair qu'il n'y a pas photos dans cette comparaison, mais perso, ce qui me gonfle le plus, ce n'est pas de ne pas avoir plein d'ennemis à l'écran mais plutôt que les ennemis se battent quasiment tous de la même façon...

Sur SOR, même si il y a que trois ennemis à l'écran, ceux-ci sont plus mobiles et chiants à battre et du coup tu t'amuses, dans final fight et dans le même cas, c'est pas super... Comme quoi, de beaux graphismes (je les trouve bien supérieur à SOR) ne font pas un super jeu...

Déjà honnetement 3 gugus à l'écran c'est pas folichon question action mais en plus oui, l'IA est ridiculement faible sur les BTA snes en général... Je me souviens de Legend, jeu qui avait été encensé par la presse à l'époque (car développé par une équipe française). Les développeurs affirmaient même qu'ils étaient fier de l'IA... Quand j'ai eu le jeu j'ai pleuré tant c'était chiant à mourir... l'IA essayait toujours de t'entourer, ça en était ridicule tellement le placement des ennemis étaient prévisible. Un jeu vite revendu :-/
FF souffre clairement du même défaut... sur SNES. La version MegaCD conserve heureusement le feeling de l'arcade à ce niveau là =)

[wiiwii007]

Il faudrait que je le teste un jour ce FF sur MCD. 

Sinon, pour la " défense " de FF2 sur Snes, je dirais que c'est cool pour les enfants. Lorsque j'y ai joué avec le gosse de ma colloc, ben c'était génial pour lui. Je ne me souviens plus si il y a des niveaux de difficulté mais c'est peut-être pour ça que j'ai trouvé ça limite. Pourtant j'ai le souvenir d'avoir mis la difficulté max et d'être arrivé avec le petit au dernier niveau directe  (le petit a 4 ans...)

[Stef]

Si tu n'as jamais testé la version MCD effectivement je pense que tu devrais le faire au moins une fois (attention tu vas prendre une claque comparé à la version SNES ).

[Invité]

Par contre niveau couleurs, c'est assez moche 

[Stef]

Ouais c'est plutot moche mais franchement pour le coup c'est pas très important
Puis tu as le color hack de Gabriel qui améliore un peu la misère si vraiment t'es tatasse :p

https://www.youtube.com/watch?v=hw4G_ofpEQc

[Invité]

C'est déjà bcp mieux,ça change des couleurs cadavres pas frais de la VO ..

[Stef]

Ouais à croire que le gars qui s'occupait des graphismes à l'époque avait un écran foireux

[Maskass]

Final Fight en arcade y a pas tellement plus d'ennemis que ça en simultané. Y en a plus que trois à la fois c'est sûr, mais si on dépasse les 5 c'est déjà très rare. Y a très peu d'endroit où les ennemis affluent, de mémoire.
Donc bon qu'il y en ait moins sur SNES c'est un peu normal, on n'a jamais dit que c'était une borne d'arcade, on n'a pas cette prétention contrairement à vous.

Dans SoR il y a plus d'ennemis mais les sprites sont plus petits. 
Donc si je résume les arguments des Segamans, dans SoR c'est génial d'avoir de l'action au détriment des petits sprites, mais dans Samuraï Spirits par contre vaut mieux avoir des gros sprites et un jeu plus lent... va comprendre.  

Je ne dis pas ça pour critiquer SoR et encenser FF, je m'en fout, mais faudrait vous accorder dans ce que vous dites. 

C'est facile de faire un jeu à la Combatribes ou Double Dragon avec des petits sprites pour en mettre plein l'écran, même la SNES saurait le faire.

[Invité]

Final Fight en arcade y a pas tellement plus d'ennemis que ça en simultané. Y en a plus que trois à la fois c'est sûr, mais si on dépasse les 5 c'est déjà très rare. Y a très peu d'endroit où les ennemis affluent, de mémoire.
Donc bon qu'il y en ait moins sur SNES c'est un peu normal, on n'a jamais dit que c'était une borne d'arcade, on n'a pas cette prétention contrairement à vous.

Sur snes tu peux pas en avoir plus que 3 (4 avec le perso du joueur) pour 2 raisons .
1- Le nombre de sprites / ligne.
2- La résolution de 256 pixels.

Pour le 1 rien qu'un jeu comme rushin beat clignote avec 4 persos, et les sprites sont plus petits, pour la résolution avec déjà 4 persos à l'écran tu vois plus rien .

[wiiwii007]

Je ne comprends pas bien cette histoire de " sprite ", t'appelle quoi un " sprite " ? Et pourquoi (si les sprite sont bien des " perso " comme je le pense) turtle in time arrive à en afficher plus de 4 ?

J'y comprends plus rien dans cette histoire.

[Invité]

Un sprite est un élément indépendant du décors .
Il est de taille variable, autant en longueur qu'en largeur en terme de pixel .
Sur snes un sprite peu atteindre la taille max de 64x64 pixels et min de 8x8 pixels .
Bien sur tu peux faire des sprites de 128x128 pixels (ou plus) en combinant plusieurs sprites  .
Comme sur toutes les machines tu as une limite de pixels sprites affichables sur une même ligne, sur snes c'est 272 (les pixels transparents comptent,d'ou l'appellation de pixels sprites et non sprites tout court), et quand elle est atteinte, les pixels suivants ne sont plus affichés ,d'où le clignotement de sprites 

Sur Md cette limite est de 256 en résolution écran de 256 pixels et 320 en réso 320, sur PCE elle est de 256 pixels peu importe la résolution écran(256/320/512), et sur SGX elle est de 512 pixels peu importe la résolution écran(256/320/512) .
Les résolutions données sont des résolutions horizontales .

[wiiwii007]

Donc, si je comprends bien, on ne peut pas en mettre plus de 4 sur Snes si les 4 sprites sont à leur max en taille, c'est ça ? et si ils font des sprite plus petit ça donne quoi ? on peut augmenter le nombre de sprite ?

Désolé avec mes questions à la con mais ça me trotte depuis un moment dans la tête. 

[Invité]

Donc, si je comprends bien, on ne peut pas en mettre plus de 4 sur Snes si le sprite est à son max, c'est ça ? et si ils font des sprite plus petit ça donne quoi ? on peut augmenter le nombre de sprite ?

Oui si la somme des 4 arrivent ou dépassent la limite de pixels sprites / ligne, sans quoi ça clignote et c'est moche .
Tu peux en afficher 34 (il me semble) sur la même ligne si tes sprites font 8 pixels de long .
Et je parle de ligne, et non à l'écran .
La gestion des sprites niveau hardware sur snes est ultra merdique, d'où les problèmes des jeux et surtout des shoots .

[wiiwii007]

Ok, je me demandais pourquoi dans des shoot on peut faire plus... Tout s'éclaire d'un coup. Merci TOUKO 

Donc, si Final Fight avait eu des sprites comme SOR (plus petit) on aurait pu avoir 1 sprite en plus à l'écran ? Si c'est jouable, je trouve ça con d'avoir privilégié la grosseur des sprites sur leur nombre...

[Stef]

Sur Md cette limite est de 256 en résolution écran de 256 pixels et 320 en réso 320, sur PCE elle est de 256 pixels peu importe la résolution écran(256/320/512), et sur SGX elle est de 512 pixels peu importe la résolution écran(256/320/512) .
Les résolutions données sont des résolutions horizontales .

T'es gentil Touko, tu arranges bien les choses pour la SNES là :p Dis comme ça on a l'impression qu'elle a l'avantage alors que c'est faux...
Le gros problème sur SNES (et sur PCE dans une moindre mesure), c'est la limitation aux sprites carrés qui fait que lorsque tu utilises un sprite de 32 pixels de large et ben il fait forcément 32 px de haut aussi... du coup ça bouffe 32 pixels de sprite sur 32 lignes (même si une grosse partie est transparente, par exemple quand le perso est allongé au sol)... Sur MD les sprites sont beaucoup plus flexibles et tu peux avoir un sprite de 32x8 par exemple (toutes les tailles possibles entre 8x8 et 32x32 en fait).
C'est surtout grace à ça que les sprites sur MD clignotent moins facilement que sur SNES, surtout quand tu affiches de gros sprites comme dans les BTA. Il suffit de voir FF sur MCD, au final la partie affichage est toujours géré par la Megadrive et là y'a pas photo, on voit bien qu'on peut en afficher bien plus que sur la SNES grace à cette plus grande flexibilité dans la taille des sprites. Et sur SNES tu as encore un autre problème, tu n'as que 2 choix de taille de sprites possible à la fois (entre 8x8, 16x16, 32x32 et 64x64)... du coup tu te retrouves avec des compromis à la con entre charge plus élevé au niveau du CPU pour gérer des metasprites complexes (gros sprites à partir de plein de petits sprites) et des clignotements.. et comme le CPU de la SNES est un veau ça n'arrange rien :-/
Bref, pour ça que la SNES c'est de la merde

[Stef]

Ok, je me demandais pourquoi dans des shoot on peut faire plus... Tout s'éclaire d'un coup. Merci TOUKO 

Donc, si Final Fight avait eu des sprites comme SOR (plus petit) on aurait pu avoir 1 sprite en plus à l'écran ? Si c'est jouable, je trouve ça con d'avoir privilégié la grosseur des sprites sur leur nombre...

C'est un des problèmes, le 2eme c'est le CPU poussif... suffit de voir comment FF3 ralentit quand tu joues à 2 avec... 3 ennemis à l'écran. Du coup les gros sprites sont là pour "remplir l'écran"... imagine un jeu avec des petits sprites et en faible nombre, ça ferait clairement pitié :-/

[wiiwii007]

Ok je comprends mieux tout le bordel, mais pourquoi dans super aleste (par exemple) il y a plein de petits sprites sans que ça clignote/ralenti ? On peut faire de même dans un BTA ?

[Stef]

Parce-que dans un BTA y'a une "IA" à gérer, une animation complexe avec des états là où les sprites de super aleste ont un déplacement super basique et scripté sans animations...
Super aleste est d'ailleurs hyper simple à ce niveau, ce qui rend le jeu particulièrement rigide (et du coup inintéressant pour moi), mais ça permet d'en afficher plus que d'autre shoots un peu plus complexe dans l'animation.

[wiiwii007]

rigide ? tu veux dire quoi ? car pour moi, un super aleste et un Thunder force ou un gynoug, je ne vois pas de différence d'IA... C'est toujours scripté non ?

Edit : Ok, j'avais mal lu, ce sont les BTA qui ont une IA complexe.

[tbp]

Donc si je résume les arguments des Segamans, dans SoR c'est génial d'avoir de l'action au détriment des petits sprites, mais dans Samuraï Spirits par contre vaut mieux avoir des gros sprites et un jeu plus lent... va comprendre.  

Tu confonds 2 genres différent : le VS Fighting et le Beat'em up/all. Dans un VS Fighting, il est évident qu'il vaut mieux avoir des sprites d'une taille satisfaisante pour tout bonnement pouvoir visualiser tes actions/mouvements ainsi que ceux de l'adversaire.
Qui plus est, en 60Hz, Samouraï Spirits bouge bien et comme il faut sur Megadrive.

Et là j'ai une question pour les "techniciens" : pourquoi les développeurs n'ont pas pu mettre Earthquake dans la version MD (le géant Texan) ?

C'est facile de faire un jeu à la Combatribes ou Double Dragon avec des petits sprites pour en mettre plein l'écran, même la SNES saurait le faire.

Eh bien non justement, la SNES ne saurait pas le faire, Touko t'as expliqué pourquoi (bas de page 22).

A ma connaissance, seuls 2 jeux SNES affichent plus de 3 ennemis simultanément à l'écran : King of Dragons et Turtles IV in time.

[Invité]

T'es gentil Touko, tu arranges bien les choses pour la SNES là :p Dis comme ça on a l'impression qu'elle a l'avantage alors que c'est faux...

C'est quand même incroyable de voir le mal partout stef, c'est obsessionnel chez toi ..
Il demande un truc simple, je répond par un truc simple, sans mettre en avant quoi que ce soit, si ce n'est que c'est merdique sur snes .
La preuve, il n'a fait aucune conclusion ... 

Le gros problème sur SNES (et sur PCE dans une moindre mesure),
c'est la limitation aux sprites carrés qui fait que lorsque tu utilises un sprite de 32 pixels de large et ben il fait forcément 32 px de haut aussi..

Faudra que tu me dises où tu as vu ça   
Bien qu'il ne peuvent pas avoir une taille de 8 pixels, ou des pas de 8, tu peux avoir toutes les tailles en pas de 16 pixels (H et V) jusqu'à 32x64,et toutes à l'écran ,et si pour toi un sprite 16x64 c'est carré,faut arrêter la colle    ..

et comme le CPU de la SNES est un veau ça n'arrange rien :-/

Encore une fois tu écris les choses à ta sauce, le CPU n'a rien a voir la dedans, l'organisation des sprites en VRAM contrairement à la MD/PCE n'est pas contigue, donc tu dois faire plusieurs transferts DMA (en général 2) pour mettre à jour les données graphiques d'un sprite des qu'il fait plus de 8x8 pixels, sans parler de l'OAM (la SAT sur snes) qui est divisée en 2 parties, et à 2 endroits différents en VRAM, tout ça réduit les perfs, et demande bcp plus d'utilisation CPU que les autres machines .
De plus le choix de seulement 2 tailles de sprites à l'écran est aussi un facteur limitant pour l'optimisation des sprites à l'écran .
Le problème de la snes, c'est l'organisation des sprites en VRAM, pas le CPU .

Ok je comprends mieux tout le bordel, mais pourquoi dans super aleste (par exemple) il y a plein de petits sprites sans que ça clignote/ralenti ? On peut faire de même dans un BTA ?

D'où la betise de stef sur l'argument CPU, super aleste est bien plus intensif en utilisation CPU qu'un beat, mais comme les sprites sont plus petits, leur gestion est plus simples, tout en étant largement plus nombreux ,sans parler des collisions sprites/sprites et sprites/tiles très gourmands en CPU,et je parle même pas de RR² qui est encore plus poussé à ce niveau .

[wiiwii007]

Ok, merci à vous deux, j'y vois un peu plus clair. Si je veux savoir tout ça, c'est simplement pour mieux comprendre quand je joue, le pourquoi du comment des ralentissements ou autres clignotements pas pour donner l'avantage à l'une ou l'autre. J'étais HS en fait...   mais c'est super intéressant tout ça.

[Invité]

Ok, merci à vous deux, j'y vois un peu plus clair. Si je veux savoir tout ça, c'est simplement pour mieux comprendre quand je joue, le pourquoi du comment des ralentissements ou autres clignotements pas pour donner l'avantage à l'une ou l'autre. J'étais HS en fait...   mais c'est super intéressant tout ça.

Niveau gestion des sprites, la Md est la meilleure, suivit de près par la PCE, et loin derrière la snes ..
Et c'est bien cette organisation hardware des sprites qui pénalise la console, et demande plus d'efforts de la part des devs pour les contourner ...
Cette mauvaise gestion hardware, rajoute bcp de charge au CPU en plus d'être mal utilisé car mal codé .
Côté mauvaise utilisation du CPU la PCE est pareil, mais compense par sa fréquence élevée, quand tu vois comment tourne Art of fighting dessus en sachant que le code 68000 a été traduit quasi mot pour mot ..

Un jeu comme super GnG par exemple ralenti surtout à cause d'une mauvaise gestion des sprites par les devs, pareil pour gradius ..
FF2 c'est flagrant, à 2 tu as 5 persos à l'écran, ça clignote déjà, la faute aux tailles de sprites batardes, et en plus tu ne peux qu'en avoir 2 différentes sur un même écran donc c'est très difficile de maximiser les sprites à l'écran avec des tailles de persos comme ceux des FF  ..

[Stef]

C'est quand même incroyable de voir le mal partout stef, c'est obsessionnel chez toi ..
Il demande un truc simple, je répond par un truc simple, sans mettre en avant quoi que ce soit, si ce n'est que c'est merdique sur snes .
La preuve, il n'a fait aucune conclusion ... 

c'est un fait, la manière dont tu as présenté les infos laisse penser que la Snes a l'avantage sur le nombre de sprite par ligne et les clignotements alors que dans la réalité c'est tout a fait l'inverse et j'ai juste expliqué pourquoi... Je pense que c'est toujours mieux d'avoir le max d'infos pour bien comprendre ;-)

Encore une fois tu écris les choses à ta sauce, le CPU n'a rien a voir la dedans, l'organisation des sprites en VRAM contrairement à la MD/PCE n'est pas contigue, donc tu dois faire plusieurs transferts DMA (en général 2) pour mettre à jour les données graphiques d'un sprite des qu'il fait plus de 8x8 pixels, sans parler de l'OAM (la SAT sur snes) qui est divisée en 2 parties, et à 2 endroits différents en VRAM, tout ça réduit les perfs, et demande bcp plus d'utilisation CPU que les autres machines .
De plus le choix de seulement 2 tailles de sprites à l'écran est aussi un facteur limitant pour l'optimisation des sprites à l'écran .
Le problème de la snes, c'est l'organisation des sprites en VRAM, pas le CPU .

Ah non tu ne vas pas repartir dans ce délire..
j'ai pas envie de débattre la dessus. L'organisation foireuse est un facteur aggravant, le cpu est clairement la cause principale, c'est un cpu de merde, y'a même pas a débattre, point.

Et mea culpa pour la pce, j'étais convaincu qu'elle ne faisait que des sprites carrés... après une taille de 16 pixels minimum est aussi un handicap pour le clignotement, mais la Snes est la pire est de loin dans le domaine, ça on est d'accord...

[Stef]

rigide ? tu veux dire quoi ? car pour moi, un super aleste et un Thunder force ou un gynoug, je ne vois pas de différence d'IA... C'est toujours scripté non ?

Edit : Ok, j'avais mal lu, ce sont les BTA qui ont une IA complexe.

oui je parlais des BTA mais malgré tout y'a une différence entre un shoot comme gynoug et super aleste, ou même, compare simplement musha aleste a super aleste, tu verras que ce n'est pas du tout la même chose dans la dynamique. Sur super aleste c'est hyper figé avec des patterns simplistes et repetitifs, musha est bien plus vivant a coté... Bien sur touko va démentir mais je t'invite a te faire ton propre avis ;-) tu peux même essayer RR, qui souffre du même problème.. Y'a pas de secret, le cpu ne permet pas d'en faire autant, ça va pas plus loin...
Certains jeux comme GnG ou Gradius 3 n'ont pas été optimisés au mieux (la machine était alors mal connue, ses faiblesses également) et auraient pu mieux tourner, malgré tout tu en feras toujours beaucoup moins avec le CPU de la SNES que celui de la MD.

Et là j'ai une question pour les "techniciens" : pourquoi les développeurs n'ont pas pu mettre Earthquake dans la version MD (le géant Texan) ?

Il est évident qu'inclure ce personnage n'aurait pas été sans problèmes... Déjà en espace rom, ses animations doivent couter très chères mais même techniquement animer un perso aussi imposant (il fait tout l'écran en hauteur et est très large également) aurait probablement posé quelques soucis (ralentissement, clignotements) :-/

[philip]

Ouais à croire que le gars qui s'occupait des graphismes à l'époque avait un écran foireux

c'est le moins que l'on puisse dire, et le jeu tourne avec le 68000 plus véloce du mega CD ?

[Snoz]

Ah oui, pour une fois je suis d'accord, musha explose littéralement super aleste !!! (et c'est un pro SFC qui le dit)

[Stef]

Ouais à croire que le gars qui s'occupait des graphismes à l'époque avait un écran foireux

c'est le moins que l'on puisse dire, et le jeu tourne avec le 68000 plus véloce du mega CD ?

J'avais pas mal tracé le code du jeu lorsque j'ai développé la partie MegaCD de mon émulateur et au final le 68000 du MegaCD est utilisé principalement pour charger les données depuis le CD et gérer les bruitages. Tout le reste s'effectue côté Megadrive, de toute manière tu passes toujours par le processeur vidéo de la Megadrive, tu n'as pas le choix... c'est la grosse faiblesse du MegaCD :-/
En fait le 68000 côté MegaCD est interessant quand tu veux faire de la vidéo (décompression) ou pour calculer les tables de transformations quand tu utilises le chip vectoriel (pour le simili mode 7)... Quand tu restes sur un jeu purement 2D (comme pour Final Fight) au final son intérêt est assez limité :-/

[Invité]

de toute manière tu passes toujours par le processeur vidéo de la Megadrive, tu n'as pas le choix... c'est la grosse faiblesse du MegaCD :-/

D'ailleurs je me demandais: aurait-il pu en être autrement ?  
J'imagine que non, ou bien cela aurait été une nouvelle console à part entière..

Comment fonctionne le cd de la PCE, avec les system cards ? Quand on voit tourner un Sapphire par exemple, par rapport à une simple Hucard, c'est hallucinant..
La MD n'aurait-elle pas pu avoir son "arcade card" pour lire des jeux CD et ainsi améliorer ses perfs ?