MEGADRIVE vs SUPER NINTENDO : Fight !

guyome a écrit:La version 3DO est en 320x224, ça peut donner une idée de ce à quoi ça pourrait ressembler sur MD, couleurs mises à part ?

Plus ou moins effectivement, mais la 3Do n'a pas du tout les mêmes contraintes que la MD en matière d'affichage de sprites, donc faut être très prudent .

touko a écrit:Non si tu adaptes SF2 directement à partir de l'arcade, tu vas pas utiliser des sprites faits pour du 256 en 320, tu vas les réduire pour du 320, et il seront plus gros, donc plus de pixels / ligne,donc même situation qu'en 256 .
Et tu oublies de toutes façons le HUD qui est en sprites, donc pour le 3ieme plan en sprites c'est mort .

La version Arcade, c'est bien du 384x224 non ? Ca aurait été plus fidèle à l'originale du coup.

En fait tu aurais la version 256 en 320(techniquement parlant), mais plus fidèle dans l'aspect ratio oui,l'image ferait moins écrasée horizontalement .

Ok, donc toi tu penses que techniquement la MD ne pouvait pas le faire fidèlement sur du 320, trop gros sprites des persos et trop pour les décors/HUD ?
Perso, je pensais plus que les équipes de Capcom ne voulaient pas se faire chier à tout redessiner pour la MD, et ont juste fait une conversion des sprites du 1er SFII SNes.

TotOOntHeMooN a écrit:

Luke a écrit:On mesure 3 fps d'input sur un jeu MD en 60fps sur CRT. J'imagine donc qu'on est en 5 ou 6 d'input sur un jeu en 30. Le 60 c'est plus de confort et plus de réactivité à la manette, et un visuel plus fluide, c'est pas rien.

Une télé CRT (50/60Hz) a 0 input lag sur le premier pixel de la première ligne, et 16.66ms (1/60ème de frame) d'input lag sur le dernier pixel de la dernière ligne. Et ce n'est pas parce que l'on affiche que 30 fps, que ça va ralentir de balayage de l'écran, il sera toujours à 60hz (ici), soit en moyenne 8.33ms d'input lag.

Si la Mega Drive a du input lag (tu nous dira où tu as lu ça), c'est éventuellement lié au démultiplexage des manettes et en aucun cas ça peut prendre 3 fps. Augmenter ou diminuer le framerate n'y changera rien.

Le framerate c'est quand même l'un des éléments qui impacte le plus l'input lag en général.
Un jeu en 60 fps avec un moteur qui traite tout dans la frame (c'est pas le cas de tous les jeux 2D et surtout pas les jeux 3D) ca veut dire entre 0 et 1 frame d'input lag aléatoire (qui dépend du delta entre le moment ou t'appuie et la lecture des inputs par le jeu) + 1 frame de lag moteur (logique et construction des data graphique) + entre 0 et 1 frame d'affichage soit en moyenne 2 frames de lag pour un jeu 8/16bit parfaitement optimal (genre SMB).
En 30 fps tu doubles les 2 premières chiffres. En 15 fps ca double encore. Si le moteur n'est pas "mono-threadé" pour déférer/paralléliser certaines taches ca double encore etc... des fois t'as des jeux 2D 8/16bit basique qui ont 10 frames d'input lag, et en général c'est d'abord lié a un mauvais framerate (genre les jeux en 20fps ce qui commence a etre un peu honteux pour un jeu 2D 8/16bit). Mais en général un jeu 8/16bit a 30fps sur CRT il y a pas de quoi se plaindre, ca reste un input lag très faible comparé a plein d'autre cas qu'on a connu.
C'était aussi les problèmes des jeux 3D qui au début avaient des framerates bas en plus de passer par un framebuffer et d'avoir un traitement plutôt dual-threadé (par exemple pour paralléliser les calcules de transformation des vertices et la rastérisation en bossant sur des frames différentes F+1 et F+2 pendant que la frame F est en cours d'affichage) et meme parfois tri-threadé quand par exemple sur PS3 l'image rastérisé repassait ensuite par le CPU pour une étape de post-processing (en général pour faire du AA) qui se faisait en parallèle du reste donc tu pouvais avoir le GPU qui affiche la frame F pendant que le CPU post-process la frame F+1, que le GPU rastérise la frame F+2 et que le CPU traite la physique ou de la géométrie (pour préparer les ombres par exemple) de la frame F+3 et toi qui appuie mais dont l'input ne sera lu qu'a la frame F+4. Si le jeu avait en plus le malheur de tourner a 20fps fallait multiplier tout ca par 3.

TotOOntHeMooN a écrit:

pcengineman a écrit:je suis pas pro nintendo plutot sega, mais quand je vois super ghouls n ghost par rapport a la version megadrive la c'est la claque, la version super nes est nettement plus belle.....j'ai les 4 versions sur nes,master system,megadrive, et super nes

Super GNG a été fait car il n'était pas possible de porter GNG sur SNES. 
Heureusement qu'ils en ont profité pour faire des graphismes colorés.

C'est vrai que c'est compliqué de faire des portages de jeu CPS ou IREM sur SNES, la différence de résolution horizontal est un peu trop élevé (384 < 256), ca oblige a vraiment tout réadapter.

Luke a écrit:

touko a écrit:Non si tu adaptes SF2 directement à partir de l'arcade, tu vas pas utiliser des sprites faits pour du 256 en 320, tu vas les réduire pour du 320, et il seront plus gros, donc plus de pixels / ligne,donc même situation qu'en 256 .
Et tu oublies de toutes façons le HUD qui est en sprites, donc pour le 3ieme plan en sprites c'est mort .

La version Arcade, c'est bien du 384x224 non ? Ca aurait été plus fidèle à l'originale du coup.

En fait tu aurais la version 256 en 320(techniquement parlant), mais plus fidèle dans l'aspect ratio oui,l'image ferait moins écrasée horizontalement .

Ok, donc toi tu penses que techniquement la MD ne pouvait pas le faire fidèlement sur du 320, trop gros sprites des persos et trop pour les décors/HUD ?
Perso, je pensais plus que les équipes de Capcom ne voulaient pas se faire chier à tout redessiner pour la MD, et ont juste fait une conversion des sprites du 1er SFII SNes.

C'est plus un problème de place sur la cartouche. Faire le jeu en 256 ou 320, tout en respectant les proportions originales, ca changerait rien pour les capacités d'affichages de la Megadrive qui s'adaptent au dotclock, par contre ca augmente de 25% la taille de la ROM en plus de devoir refaire les graphismes plutot que de recycler ceux de la SNES, c'est doublement problématique

upsilandre a écrit:C'est vrai que c'est compliqué de faire des portages de jeu CPS ou IREM sur SNES, la différence de résolution horizontal est un peu trop élevé (384 < 256), ca oblige a vraiment tout réadapter.

Oui, j'avais aussi Super R-Type en tête. Quand les boss font déjà 256 de large, c'est compliqué.

touko a écrit:Et tu oublies de toutes façons le HUD qui est en sprites, donc pour le 3ieme plan en sprites c'est mort .

Le HUD est sur le plan window, avec des sprites pour réintégrer les morceaux de plan qui sont bouffés

@touko Street Fighter II en 320, il faut juste croper l'arrière plan et reprendre les sprites CPS.

Hpman a écrit:Il y a au moins une frame de délai, le jeu traite les inputs pendant que la console affiche le résultat des inputs précédents. Deux si la machine bosse en double buffer (CPS1-2, PSX, saturn etc)

Oui. Dans ce cas, on ne parle plus d'un soucis de Mega Drive sur une CRT, mais de toutes machines.

D'ailleurs fun fact, la résolution de la Virtual Boy c'est celle du CPS. Il y a un SF2 sur Virtual Boy et il reprend exactement les sprites arcade .

Ca donne des persos beaucoup trop larges si ils sont pas retouchés, CF versions PC DOS.

Il y avait un topic à la recherche de SF2 320px, il y a quelques années (spoiler: elle n'existe pas), le plus proche est la version 3do mais même cette version n'est pas exactement à l'échelle pour du 320, sans compter que la conversion des visuels est assez sommaire (on vire une colonne sur x, et retouche ici ou la).

@upsilandre Je ne savais pas. Balaise ! 

Sinon, j'ai souvenir de bornes Capcom Q-Sound avec écrans 16:9 qui faisaient tourner Street Fighter II Turbo. Pour le coup, la résolution de 384x224 était pleinement justifiée. (oui c'était plus "fat")

Dans quelle résolution les éléments circulaires sont parfaitement rond sur Street Fighter II ?

Une archive


C'est rond en 384 de large sur un écran 4:3. Les pixels ne sont pas carrés c'est fait comme ca.

Ok, donc toi tu penses que techniquement la MD ne pouvait pas le faire fidèlement sur du 320, trop gros sprites des persos et trop pour les décors/HUD ?

Je parlais juste pour rajouter le 3ieme plan en sprites, le 320 n'aurait rien changé à ce niveau .

Hpman a écrit:

touko a écrit:Et tu oublies de toutes façons le HUD qui est en sprites, donc pour le 3ieme plan en sprites c'est mort .

Le HUD est sur le plan window, avec des sprites pour réintégrer les morceaux de plan qui sont bouffés

Pas sur ,car le plan windows prend la place du plan A, et tu peux voir par exemple sur le niveau de ken que ce n'est absolument pas le cas, après probable qu'il y ait un mix des 2.

TotOOntHeMooN a écrit:@touko Street Fighter II en 320, il faut juste croper l'arrière plan et reprendre les sprites CPS.

Oui mais faut adapter les sprites qui sont en 384, au 320, et donc seront plus gros qu'en 256 si on garde les proportions .

touko a écrit:

Hpman a écrit:

touko a écrit:Et tu oublies de toutes façons le HUD qui est en sprites, donc pour le 3ieme plan en sprites c'est mort .

Le HUD est sur le plan window, avec des sprites pour réintégrer les morceaux de plan qui sont bouffés

Pas sur ,car le plan windows prend la place du plan A, et tu peux voir par exemple sur le niveau de ken que ce n'est absolument pas le cas, après probable qu'il y ait un mix des 2.

Pauvre fou

Ahaha les bâtards, ils ont utilisé des sprites pour le bateau, et comme je le pensais le hud est un mix; bon limité c'est vrai.

Mais bon si on tient compte des sprites pour le hud, des sprites des joueurs quand ils sautent ou font des coups en l'air, on peut clairement pas faire un plan avec des sprites de toutes façons sans avoir de clignotements .
J'ai pas pu vérifier, ma rom de SF2 marche pas avec gens, et j'ai pas cherché plus loin .

Bien vu en tous cas 

Pour l'anecdote il y a aussi de la magouille en arcade: les plans n'ayant pas de priorité par tile, et la bateau bougeant de haut en bas, comment ne passe-t-il pas devant le sol (même plan que le ciel).
Capcom à collé un sprite en bas pour boucher le trou
Sprite qui ne sera pas changé dans super SF2 avec le nouveau bateau

Bon par contre HUD en sprites sur CPS, afin d'avoir les 3 plans pour les décors.

Sur 3DO, il semblerait que le jeu soit en 288x224 dans un écran de 320x240 et que rien ne soit adapté.

Après, idée à la con, mais ça donnerait quoi SF2 patché pour ouvrir l'écran en 40 colonnes au lieu de 32 ? On aurait un écran plus large pour y déplacer les perso et plus de sprites affichables. A voir ce que rendrait l'aspect ratio des sprites.

Bon, Touko, tu veux pas adapter Super Street Fighter II sur SuperGrafx + Arcade Card ?

Ben voilà plein d'infos intéressantes  

HpmanUne archive  


C'est rond en 384 de large sur un écran 4:3. Les pixels ne sont pas carrés c'est fait comme ca.


J'ai un soucis de compréhension à ce niveau. Comment peut-on s'y prendre pour faire des ronds si le pixel n'est pas carré ?

Les pixels artistes, ils se foutaient du résultat final avec la déformation des CRT, ou bien anticipaient plus ou moins à l'avance ? Ca me parait compliqué pour les proportions souhaitées  

xinyingho a écrit:

Stef a écrit:l'introduction avec Ruy
[....]
le stage de Ruy

C'est pas Ruy mais Ryu !

En plus j'ai fait plusieurs fois l'erreur Je me demande comment j'ai pu l'inverser (rien qu'en le prononçant tu as le bonne orthographe).

Sinon, un SFII en 320 spécifique à la MD est donc bien possible alors, ok. par contre le Super serait trop gourmand en taille de rom si on veut éviter les mapper trop couteux...
On a la réadaptation de R-Type en cours, celle de Final Fight, purée il faut qu'une équipe se mette sur le 1er SFII, le world warriors ! Ca tiendrait peut-etre sur une 32mb.

Luke a écrit:J'ai un soucis de compréhension à ce niveau. Comment peut-on s'y prendre pour faire des ronds si le pixel n'est pas carré ?

Les pixels artistes, ils se foutaient du résultat final avec la déformation des CRT, ou bien anticipaient plus ou moins à l'avance ? Ca me parait compliqué pour les proportions souhaitées  

Bah c'était dessiné sur des bécanes tournant dans la même résolution (X68000 je suppose chez capcom).
Encore aujourd'hui photoshop permet de travailler avec des pixels non carrés

Hpman a écrit:

Luke a écrit:J'ai un soucis de compréhension à ce niveau. Comment peut-on s'y prendre pour faire des ronds si le pixel n'est pas carré ?

Les pixels artistes, ils se foutaient du résultat final avec la déformation des CRT, ou bien anticipaient plus ou moins à l'avance ? Ca me parait compliqué pour les proportions souhaitées  

Bah c'était dessiné sur des bécanes tournant dans la même résolution (X68000 je suppose chez capcom).
Encore aujourd'hui photoshop permet de travailler avec des pixels non carrés

Yep, on peut travailler en Dl/DV pal ou ntsc sous PS. Je ne sais pas pourquoi, j'ai toujours pensé que les artistes de l'époque travaillaient forcément sur du pixel carré. J'ai vu plusieurs fois des bases de travail sur pixel carré, c'était meme des fois à la main sur du papier à petits carreaux, notamment chez Irem.
Si ils avaient pour certaines firmes des bécanes "calibrées", ça explique des choses.

guyome a écrit:Bon, Touko, tu veux pas adapter Super Street Fighter II sur SuperGrafx + Arcade Card ?

Euh non trop long, et j'ai pas envie de me faire striker par capcom .
Mais c'est vrai que ça serait un super projet .

J'ai un soucis de compréhension à ce niveau. Comment peut-on s'y prendre pour faire des ronds si le pixel n'est pas carré ?

En réalité les pixels ronds n'existent que sur les CRT.

touko a écrit:

guyome a écrit:Bon, Touko, tu veux pas adapter Super Street Fighter II sur SuperGrafx + Arcade Card ?

Euh non trop long, et j'ai pas envie de me faire striker par capcom .

Bof, les portages MD de Final Fight montrent que Capcom n’est pas aussi taquin que Nintendo sur ce genre de sujets.

touko a écrit:Euh non trop long, et j'ai pas envie de me faire striker par capcom .
Mais c'est vrai que ça serait un super projet .

Je plaisantais de toute façon.
Avoir, peut être, Shinobi ou Double Dragon ou Dragon Ninja ce sera déjà formidable, surtout pour une machine qui est aussi confidentielle.
C'est tellement frustrant de devoir seulement imaginer ce que pourrait être tous ces hits de la MD ou de la SNES sur la SGX quand on a entrevu ses capacités...

C'est clairement rageant de n'avoir que si peu de jeux dédiée à cette SGX, elle avait largement les capacités pour tenir le coup et recevoir des super productions jusqu'à la sortie de la gamme 32 bit NEC.
Par la meme occasion tous les jeux CD Rom, (super, arcade) auraient bénéficié de sérieux avantages de sprites supplémentaires et de second plan de tuiles. Malheureusement la SGX aurait soit été limitée par le format Hucard, soit par la RAM du Super CR Rom donc ca reste aussi du challenge que de développer dessus des jeux de dernières générations 16 bit dessus il me semble. Mais dans le lot il est évident qu'un Super Street Fighter 2, un bon run n gun à la Contra, du beau plateformer à la magical quest par exemple auraient été facilement réalisable et aurait aidé a faire décoller cette console vite oubliée par son propre créateur.

Saviez vous d'ailleurs que Magical Quest 1 était prévu sur MD en janvier 94 avant qu'ils ne décident de se focaliser sur sa suite sur SNES/MD, et donc abandonner le 1 sur MD    

ci dessous ce sont bien des captures MD car la barre d'énergie n'est pas la même que sur SNES
J'en avais vu aussi dans les magazines Français type consoles+, Player one ou Joypad mais je ne retrouve plus...