Megadrive et Super Nintendo : parlons technique !

[Invité]

Bonsoir, ne supportant plus du tout le topic à troll "Mega Drive vs Super Nintendo" dans la section 16-bits, je tenais absolument à créer topic en parallèle afin d'opposer, sur le plan techniques, les deux consoles de SEGA et Nintendo.

Ici, on parle surtout de hardware, de programmation, d'optimisation et de jeux quand ceux-ci démontrent une technique aboutie comme Thunder Force IV ou FZERO par exemple.

Le but du topic c'est aussi de rassembler des informations techniques sur chaque console.

Merci pour votre participation.

[lord2laze]

On est la Shingo, a fond avec toi.

3 boutons, c'est pas beaucoup pour une manette non ?

Pourquoi ils ont pas mis la couleur sur la MD ?

Pourquoi ils ont négligé la qualité sonore quand ils sont conçus la MD ?

[Invité]

1) Trois boutons c'était la norme dans les salles d'arcade avant la sortie de Street Fighter 2.
2) Pour le nombre de couleur je n'en sais rien.
3) La qualité sonore n'a pas été négligé, car la puce correspond à ce qui se faisant en arcade.

Bref c'est pas un topic à troll ici, si tu veux t'amuser et te défouler, reste sur le topic dédié, merci.

[Metalik]

Je me permet ici de mettre une interview du boss de Treasure qui date de 1993 (je l'ai mis aussi sur le topic du projet Y). Vous verrez que ce qu'il dis ne change pas du constat actuel.

NB: L'interview existe en Français, mais je ne la retrouve plus.

Treasure:

[ace76]

Trop bon!!

[Invité]

@Metalik aurais-tu une source d'où provient cet interview s'il te plaît?

All things considered, the 68000 is a very good CPU allowing room for experimentation while the SNES hardware limits you to their design standards. Scaling and rotation can be implemented in the Sega software, forget it on the SNES.

Je me demande sur quels éléments se base t-il pour affirmer que le zoom et la rotation peuvent être implémenté du Mega Drive, du moins sans faire de grosses concessions au niveau des performances...

[Metalik]

Trop bon!!

C'est de Masato Maegawa le boss de Treasure. Dans un communiqué de 2017, il c'est manifesté pour que SEGA produise aussi une Megadrive Mini et de qualité supérieur aux consoles ATGame.
Le fait que SEGA ai récemment casser le partenariat avec ATGame pour produire la MD Mini, et qu'ils aient rappeler des concepteur de la machine original, et des gens qui ont travailler dessus (sans aucune précision), il n'est pas impossible que ce dernier soi de la partie...

http://game.freefrencharticles.com/index.php/2017/10/31/masato-maegawa-de-treasure-veut-que-sega-fasse-un-mega-drive-mini/

[Metalik]

@Metalik aurais-tu une source d'où provient cet interview s'il te plaît?

La source tout comme l'interview est rare. Je ne la trouve plus. Elle date de très longtemps, c'est d'ailleurs grâce à mes souvenir que je la ressort et que j'essaie de trouver un bon lien. Il me semble que cette interview a été publier en français à l'époque (je ne suis pas sure, il faudrait faire des recherches).

Cependant il y a ça:

https://i1.wp.com/megadrive.me/wp-content/uploads/2011/10/treasure-gamefan-interview.jpg?fit=1176%2C1600&ssl=1

[Invité]

Nickel merci

[lord2laze]

@Metalik aurais-tu une source d'où provient cet interview s'il te plaît?

All things considered, the 68000 is a very good CPU allowing room for experimentation while the SNES hardware limits you to their design standards. Scaling and rotation can be implemented in the Sega software, forget it on the SNES.

Je me demande sur quels éléments se base t-il pour affirmer que le zoom et la rotation peuvent être implémenté du Mega Drive, du moins sans faire de grosses concessions au niveau des performances...

J'avais lu que pour faire du zoom sur Megadrive, ils demandaient aux joueurs de rapprocher leur tête de l'écran tout en continuant de jouer.

Pour les rotations, fallait tourner la télévision à la main, c'est pour ca qu'ils conseillaient de jouer à la MD sur des télé de 36 CM.

J'ai plus les sources par contre, excusez moi.

[Metalik]

Je me demande sur quels éléments se base t-il pour affirmer que le zoom et la rotation peuvent être implémenté du Mega Drive, du moins sans faire de grosses concessions au niveau des performances...

C'est pareil sur SNES. Même si la console à été calibré pour produire ce genre d' effets, elle ne peu pas le faire n'importe où et n'importe comment. Ce genre d'effet est très limité même sur SNES, et la plupart du temps ils sont utilisé sur des plans fixe, avec très peu de sprites, et sans un arrière plan animé. Souvent, les Zoom et les rotation hors mode 7, n'ont lieux que sur un plan fixe, avec aucun décors de fond...

Sur Megadrive, faire du Zoom et de la rotation, c'est très facile, ça demande juste un peu plus de mémoire et de programmation. Mais ce n'est pas ce que SEGA à voulu mettre en avant. D'autant plus que même sur SNES, les zooms et les rotations sont aussi de l' esbroufe, et au final les meilleurs jeux de la console ne sont pas basé sur ça. Le zoom, la rotation, c'est juste un petit effet et en rien ça ne fait un jeu...

Mais c'est aussi ça le talent de la SNES, de Nintendo et des boites qui ont bossé dessus. Savoir créer l'illusion, avec des jeux parfois super bien foutu. Mais si ont parle technique pure, il ni y a rien de vraiment très expectionnel; c'est juste que parfois, ça a été super bien réussi.

D'ailleurs, Paprium devrait faire tout ça, et de façon bluffante si les promesses et les dernière rumeurs sont vrai. Le jeu inclura de la transparence, du zoom, de la distorsion, de la rotation et même un univers sonore rarement atteins sur 16 Bits, le tout en plein jeu...

[Tryphon]

N'exagérons rien. Un zoom et une rotation en temps réel sur MD (cd pas précalculé), c'est difficile.

Ça ne peut pas se faire en plein écran à 6O fps. Donc soit on réduit le framerate, soit on réduit la résolution (souvent les deux), ou on se contente de le faire sur quelques sprites.

On est assez loin de la facilité d'utilisation du mode 7.

[Invité]

Je ne vois pas vraiment l’intérêt de ce topic personnellement :)
De plus ça troll déjà pas mal donc bon :p
Tout a déjà était dit sur ces deux consoles , et on les connais plutôt bien les deux techniquement parlant !

C'est pareil sur SNES. Même si la console à été calibré pour produire ce genre d' effets, elle ne peu pas le faire n'importe où et n'importe comment. Ce genre d'effet est très limité même sur SNES, et la plupart du temps ils sont utilisé sur des plans fixe, avec très peu de sprites, et sans un arrière plan animé. Souvent, les Zoom et les rotation hors mode 7, n'ont lieux que sur un plan fixe, avec aucun décors de fond...

Sur SNES mode 7 ou pas , tu as accès toujours aux 128 sprites
Tu peux animé un plan (voir SoM qui fait les effet de l'orage et la map est animée) , si y'a pas plein de sprites ,c'est que ben y'avait aucun jeux qui avait besoin d'en afficher plein sur ce mode,  le souci c'est qu'il a était utilisé pour faire de la pseudo 3D , et les sprite en 2D est pas très approprié sur une tel map donc ça limite l'utilisation (ou alors tu faire un zoom/dezoom des personnage/objet/voiture mais ça va bouffer de la ROM ).

Le but du topic c'est aussi de rassembler des informations techniques sur chaque console.

Code:


Console : SNES    | MD
CPU     : 65816   | M68000
MIPS    : 1,17    | 1,33     (Millions Instruction Par Seconde)
RAM     : 128ko   | 64ko
Sprite  : 128     | 80
MPS     : 272 px  | 320px    (Max Pixel Scanline)
écran   : 256x224 | 320×224
BG      : 3       | 2
Palette : 16      | 4
Couleur : 32767   | 512


[Tryphon]

Tu n'es pas limité en nombre de sprites sur le mode 7 à ma connaissance. Par contre tu ne peux pas zoomer les sprites, et tu ne peux utiliser qu'un seul bg.

Le tableau comparatif que tu cites est assez peu pertinent : il cite des chiffres sans préciser les contraintes, pour les deux machines. Par exemple, quand tu utilises le mode graphique de la SNES autorisant 3 bg (la plupart n'en utilisent que 2), l'un des 3 ne peut utiliser que des palettes de 3 couleurs, ce qui limite grandement l'intérêt.

Idem pour les 128 sprites : il y a de grosses contraintes, que je ne maîtrise pas, et qui font que ça reste limité d'exploitation.

Par contre la SNES a des spécificités intéressantes, comme le HDMA, qui ne sont pas listées sur ce tableau.

Enfin, la comparaison des CPU en Mips est peu pertinente, les deux processeurs ayant une architecture très différente.

[Metalik]

N'exagérons rien. Un zoom et une rotation en temps réel sur MD (cd pas précalculé), c'est difficile.

Ça ne peut pas se faire en plein écran à 6O fps. Donc soit on réduit le framerate, soit on réduit la résolution (souvent les deux), ou on se contente de le faire sur quelques sprites.

On est assez loin de la facilité d'utilisation du mode 7.

C'est pour ça que j' ai exclus le mode 7 comme commodité.
Mais il faut bien pourtant avouer que sur SNES la plupart des gros zoom et les rotations se font sur écran fixe et sans arrière plan.

Le problème c'est que l'ont compare aussi trop le zoom Megadrive à celui de la SNES.
La résolution de la SNES étant moindre, ont arrive rapidement a un tas de pixel qui crève l'écran. La Megadrive ayant une résolution plus grande l'effet de zoom est moins flagrant; il parait plus détaillé et moins proche.

En ce qui concerne les rotations, la Megadrive assure sans doute bien plus que la SNES et sans aucun problème. Après c'est sure que si il y a cumulation de zoom et de rotation comme sur SNES grâce au mode 7, ça reste une autre histoire...

Cependant, maintenant qu'il existe un algorithme capable de produire un mode 7 sur Megadrive, peut être qu'il est possible de créer et de trouver des astuces de programmation qui imite tout ça...

[Invité]

C'est vrai que sur le papier la SNES semble terriblement plus puissante, mais comme dit @Tryphon il faut voir les contraintes, parce qu'utiliser 3 bg dont l'un est limité à des palettes de 3 couleurs...

[Tryphon]

J'aimerais bien savoir à quels zooms et rotations sur MD tu fais allusion.

Les quelques exemples que je connais en plein écran se font sur des zones très petites, ou en demi-résolution, et ressemblent largement autant à de la bouillie de pixels que sur SNES...

[Invité]

Kannagi parle en connaissance de cause, il a développé un nombre conséquent de projet sur SNES ( et bien d'autres consoles, c'est un fou ce type !!  ), et avec AlekMaul ce sont bien les seuls que je connaisse.

Un vieux tuto qu'il avait rédigé sur l'excellent site DVP : 
http://www.developpez.net/forums/d1469233/forums-beneficiaires-d-hebergement/priv-redaction/priv-articles/archives/2014-09-12-tutoriel-programmer-super-nintendo/


Son RPG qu'il doit terminer ... 


Et une autre vidéo avec en fin, le fameux mode 7




EDIT : Merci d'avoir déplacé le sujet.   

[Tryphon]

Oui, je sais, et je sais aussi qu'il connaît les limitations du tableau qu'il a posté

[scrolling]

Je lis les échanges technique que vous développez avec beaucoup d'intérêt et c'est vraiment passionnant.
Je suis tombé sur cette vidéo qui m'a tout simplement bluffé cette démo technique a été réalisé sur Megadrive 

[Invité]

@StudioVetea
Merci , eh oui j’espère bien qu'on leur fera changer d’avis

@Tryphon
Je ne suis pas d'accord parce que :
-le BG3 est très très utile pour le hud ! Et donc les 3 couleurs sont largement suffisante (surtout que tu peux changer la palette facilement donc pour le hud tu as le droit au moins à 4-8 palette).

-Non il y'a pas de contrainte particulière pour utiliser les 128 sprites , personnellement j'utilise une grande partie , sur mon RPG 48 sont dédié au personnage/ennemi (dans la partie haute des sprite qui sont triés).
La partie basse est dédié au ring menu (jusqu'a 20 sprite) et aux magies ( jusqu'a 18 sprites).
Mais un RPG n’utilise pas forcément tout les sprite , un shmup comme super aleste doit en avoir une utilisation excessive :)

-Oui et non la comparaison en MIPS est pertinente , ce qui n'est pas pertinent est de comparé deux fréquences d'une architecture différente
Le problème que je vois est que ce n'est qu'un chiffre qui est la 'moyenne' du temps de cycle des instruction, les MIPS sont difficile à évaluer sur ces cpu.

Bien sur le tableau n'est qu'un simple comparative sans parler des détails , mais il peut etre un bon résumé.

[Tryphon]

@Tryphon
Je ne suis pas d'accord parce que :
-le BG3 est très très utile pour le hud ! Et donc les 3 couleurs sont largement suffisante (surtout que tu peux changer la palette facilement donc pour le hud tu as le droit au moins à 4-8 palette).

S'il ne sert que pour le HUD, c'est quand même très différent des deux autres bg.

Non il y'a pas de contrainte particulière pour utiliser les 128 sprites , personnellement j'utilise une grande partie ! (sauf que je n'affiche pas tout) , Sur mon RPG 48 sont dédié au personnage/ennemi (dans la partie haute des sprite qui sont triés).
La partie basse est dédié au ring menu (jusqu'a 20 sprite) et aux magies ( jusqu'a 18 sprites).

D'après ce que j'ai lu, notamment par Touko, il y a :

* des contraintes de taille (tu ne peux utiliser que des sprites carrés, ce qui t'oblige à utiliser de petits sprites lorsque la forme est biscornue, ou inclure plein de tiles vides)

* des contraintes pour le placement des tiles d'un sprite donné, qui ne peut aller n'importe où en VRAM

D'ailleurs sur les deux exemples postés par Vetea, je vois rarement plus de 4 ou 5 objets en mouvements (sauf quand tu manipules les menus mais le jeu est alors stoppé), dont plusieurs identiques. Ce qui m'étonne : tes personnages sont carrés, tu peux utiliser une grande taille de sprites non ? Du coup tu n'as pas besoin de 48 sprites ?

-Oui et non la comparaison en MIPS est pertinente , ce qui n'est pas pertinent est de comparé deux fréquences d'une architecture différente

Le problème que je vois est que ce n'est qu'un chiffre qui est la 'moyenne' du temps de cycle des instruction, les MIPS sont difficile à évaluer sur ces cpu.

Comparer deux processeurs de même architecture en se basant sur le nombre d'instructions par seconde est une mesure comparative de performance fiable. En revanche ça l'est moins pour des architectures différentes.

C'est pas moi qui le dis c'est wikipedia :

Comparer deux processeurs de même architecture en se basant sur le nombre d'instructions par seconde est une mesure comparative de performance fiable. En revanche ça l'est moins pour des architectures différentes.

Non, je maintiens que ça n'a pas beaucoup de sens de les comparer. Ça masque le fait que l'un possède 4 registres et l'aitre 14, que l'un sait faire des opérations sur 32 bits alors que l'autre est déjà difficile à manipuler en 16, etc.

Non, objectivement je ne pense pas.

[Invité]

ah oui , c'est très différent que les autres BG je ne dis pas le contraire  mais il a quand même un BG spécifique pour ce qui peut être utile (ça évite d'avoir une barre noir pour le menu/score/pv/autre , comme on le voit souvent sur les jeux MD).
Et dans mon cas cela sert aussi pour la fenêtre et les dialogues donc assez utile tout en conservant les 2 BG ^^

Oui je connais ces contraintes , ce qui peut être pénible est que forcément il faut penser a bien avoir en tête ce qu'on veut mettre en VRAM et l'agencement de celui ci.
Mais cela ne t’empêche pas d'utiliser 128 sprites

D'ailleurs sur les deux exemples postés par Vetea, je vois rarement plus de 4 ou 5 objets en mouvements (sauf quand tu manipules les menus mais le jeu est alors stoppé), dont plusieurs identiques. Ce qui m'étonne : tes personnages sont carrés, tu peux utiliser une grande taille de sprites non ? Du coup tu n'as pas besoin de 48 sprites ?

Ben je fait de la transparence , si je met un gros sprite c'est l'ensemble du sprite qui sera sous l'eau , ce qui n'est pas l'effet voulu ici ! :)
Donc pour mes hero/pnj je fait un bloc 2x2 (de 16x16) et pour les ennemis , les dragons sont des meta-sprite (1 de 32x32 et 5 bloc de 16x16).
Donc comme je peux afficher 2 hero et 10 pnj , cela me fait donc 10*4 donc 48 sprite !
Donc en ville , on se retrouve avec 64 sprite au maximum.
Pour les parties bataille hero+arme + 3 dragons , ça peut aller donc à 36 sprites et au maximun cela pourra monter jusqu'a 72  (perso/ennemi , menu et magie).

D'ailleurs sur les deux exemples postés par Vetea, je vois rarement plus de 4 ou 5 objets en mouvements

Voila un exemple ou il y'a plus de 4 ou 5 objet à l'écran est tous animé + physique (sur les murs et entre les perso , et on peut les pousser ! ).
Je fait toujours des tests pour savoir ce que peut la console au maximum , ça évite les surprises plus tard ^^
Sinon qu'ils y a 4 ou 5 objets en mouvements ou pas , je les traite de façon identique la seule différence et l'envoie en VRAM qui est stoppé

Oui mais je ne suis pas d'accord avec ce que dit forcément wikipédia , la phrase aurait eu du sens avec le mot fréquence

Mais oui il y'a des différences pour les registres , mais le truc c'est que cela importe peu ici, vu qu'on utilise les registres que pour les calculs (c'est un cpu avec un accumulateur) , le but est de charger en RAM a chaque fois (ou de faire le calcul directement en RAM) et sur le 6502/65816 cela ne prend pas de cycle excessive (3 cycle dans la moyenne du proc quoi) , si tu te réserve 32 octets pour les mémoires temporaires pour simuler des 'registres' ça suffit amplement , pour le 16 bits c'est pas compliqué c'est juste un flag à changer, le but est d'éviter de faire des switch trop souvent.

[petitevieille]

Le gars a quitté Konami pour fonder Treasure, qui développera aussi sur N64. Il n'a pas rejoint SEGA.

[Invité]

Oui mais c'est quoi une "super nitnendo"

Une nes avec une cape !! 

Ensuite pour les 3 couleurs du BG 3 ce sont 3 couleurs par tile, et non pour tout le BG, donc avec les 8 palettes tu peux faire un truc sympa(on a du coup 24 couleurs possibles pour tout le BG), d'ailleurs dans tout les jeux ou il a été utilisé ça rend très bien,et pour un HUd ou un plan éloigné ça pose aucun problème .

[tilou]

moi je dis qu'une super nintendo avec une 68000 à la place du ricoh a la con, ca fait des jeux au niveau de la neogeo

[Invité]

@Touko effectivement , il est bon de le préciser

moi je dis qu'une super nintendo avec une 68000 à la place du ricoh a la con, ca fait des jeux au niveau de la neogeo

Sauf que la Neo Geo , sa puissance ne vient pas tant du CPU
La Neo Geo c'est 256 palettes , donc 4096 couleur affichable à l'écran et 65535 couleur possible.
Niveau Sprite elle peut faire jusqu'a 384 mais elle est capable d'afficher des sprites énorme d'ailleurs le background est un gros sprites :p
La SNES est limité à 16 ko pour les sprites ,sur Neo Geo tu as accès a toute ta ROM pour l'affichage de tes sprites pas le même délire
Bref une époque où les bornes d'Arcade était incomparables avec les consoles
(ce que je dis est aussi valable pour la MD , pas de comparaison possible).

[Tryphon]

@kannagi : j'ai pas mal de commentaires à faire, de questions à te poser, mais là je suis au tag et ça va être difficile (et je finis tard donc ça sera peut-être pas avant Jeudi), mais d'ici là, une question :

À ton avis, pourquoi beaucoup de jeux SNES présentent de gros ralentissements et/ou se débrouillent pour jamais afficher plus de 4/5 objets à l'écran ? Qu'est ce qui bloque ?

On n'a jamais eu de réponse claire à ce sujet. Certains disent que ça vient du PPU, du DMA, d'autres du CPU.

[ace76]

moi je dis qu'une super nintendo avec une 68000 à la place du ricoh a la con, ca fait des jeux au niveau de la neogeo

Ben,une MD avec une palette étendue s'en rapprocherait bien plus.

[Invité]

bah c'est bon alors, avec le MCD on les a les 300 megas, la MD c'est comme la NG alors 
Enfin .................. presque: