Re: MEGADRIVE vs SUPER NINTENDO : Fight !

[Invité]

Non a jeu egal, on le ressent vraiment sur snes que c'est d'une lenteur affligeante.

J'allais vous demander vos avis ! Very Happy

Je viens de vous dire pourquoi sur SNES c'est plus lent je me requote :
" la SNES a pas un mauvais processeur en terme de vitesse mais sa difficulté (Hard et processeur) la rend difficile a optimiser."
Un exemple concret regardé les nombres homebrews sur SNES et MD , la SNES est vraiment plus compliqué et donc y'a moins de monde , on est d'accord que la SNES reste plus populaire que la MD (je dis pas qu'elle est meilleur chaqu'un sera juge), mais en général la SNES reste assez populaire pourtant cette popularité devrait faire que la SNES a plus homebrews mais ce n'est pas le cas.

Je vous assure que faire du code optimisé sur SNES c'est loin d’être trivial, surtout que son architecture ne rend pas facile certain optimisation.
Un exemple concret la SNES gère mal les positions X (et donc si on veut qu'un perso soit 'coupé' s'il est au bord de l'écran) ,ben ça peu prendre beaucoup de code (donc du calcul) , pareil pour passer les sprites de 16x16/32x32 par exemple (certe un peu moins).

Sur MD le coût est quasiment nul a coter vu qu'il faut faire aucun acrobatie pour faire ce genre de chose.
Le 65816 est un hybride 8/16 bit il faut avoir une certaine méthodologie pour éviter de passer trop souvent de passer en mode 8bit / 16 bits.
La 68000 peut gérer facilement des calculs 8/16 bits en 'même temps' , sur le 65816 ça a un coût si on passe du 8bit en 16bit ainsi de suite , donc la conclusion d’où pourquoi il est plus compliqué a optimiser , de meme le 6502 en général est plus compliqué a optimiser que du 68000 , alors ici pas beaucoup de personne code mais juste pour info :
Le 68000 possède :
-8 registre de DATA (8/16/32 bits).
-8 registre d'ADDRESS (8/16/32 bits).

Le 65816 :
-1 Accumulateur (8 bits OU 16 bits).
-2 Registre secondaire (8 bits OU 16 bits).

*Registre c'est une mémoire du processeur
*accumulateur veut dire que c'est le registre qui peut faire des calculs donc sur les '6502' , on peut faire des calculs (addition/soustraction ect) que sur celui ci.
Le 68000 on peut faire des addition/soustractions ect sur tout les registres.
Mais la différence n'est pas que la sur le 68000 on peut comparer 2 registres pas sur le 6502 ainsi de suite.

Ce qui est en Fast Rom seiken dentetsu 3 l'est par exemple.

[Invité]

The LowROM / HighROM stuff and the SlowROM/ FastROM stuff are absolutely independant. There is Low Slow ROMs, Low Fast ROMs, High Slow ROMs, and eventually High Fast ROMs. The older games are usually Low and Slow, and the newers are usually High and Fast, but there is mix of them (Secret of Mana is a High Slow ROM, while CastleVania - Dacula X is a Low Fast ROM). 

http://forums.nesdev.com/viewtopic.php?t=540

 C'est plus complexe que ca on dirait.
C'est sur que la frequence CPU est lie a ca?

Oui c est sur,sur SNES ça marche comme ça,cependant l accès a la RAM reste à 2,6mhz même en fast ROM.

Non a jeu egal, on le ressent vraiment sur snes que c'est d'une lenteur affligeante.
Pourtant GnG est plus recent sur snes

Ce jeu a un problème dans le code de gestion des sprites .
https://forums.nesdev.com/viewtopic.php?f=12&t=12189&p=138973&hilit=ghouls#p138973

[Stef]

Mais c'est aussi clairement un problème d'architecture (capacité sprite de la SNES) et de la faiblesse du CPU en général. Si tu avais un 68000 dans la SNES, la gestion calamiteuse des sprites (Kannagi a un peu expliqué) ne serait pas aussi critique. Le fait d'avoir un CPU "faiblard" ne fait qu'empirer la situation. Ce n'est pas qu'il est nécessairement plus difficile d'optimiser le code avec le 65816, c'est surtout qu'il laisse beaucoup moins de possibilités de manière générale. L'instruction set limité couplé à une architecture beaucoup plus simple fait que le CPU est moins efficace pour effectuer des traitements en général. Tu vas devoir faire beaucoup plus d'instructions que sur le 68000 pour effectuer une même tâche.

[airdream]

est ce que la snes est la console la plus mal foutue de chez nintendo?
ils etaient omnibulé par le gain que le reste peu importe...

[Invité]

Non le 68000 n'aurait pas résolu vraiment le souci pour les sprites, pour moi c'est juste que l'OAM doit être en 16 bits et non en 8 bits :/
Cela aurait résolu le probleme des différentes tailles et des positions en X/Y de la SNES.

Je ne suis pas totalement "d'accord" sur ton dernier paragraphe.
Oui le 65816 est plus difficile a optimiser les compilateurs C le démontre clairement.

Tu vas devoir faire beaucoup plus d'instructions que sur le 68000 pour effectuer une même tâche.

De manière général c'est vrai , mais c'est la que on peut parler d'optimisation , je pense que certain programmeur talentueux en montré que y'avait quand meme des différences entre la façon de codé (Nasir Gebelli , Manfred Trenz ,les programmeurs de Super Aleste) , en gros je trouve qu'il est plus compliqué d'optimiser en 65816 , mais je pense que tu devrais coder un peu en 6502 , tu comprendrais ou je voudrais en venir .
En gros il est facile de faire du code lourd sur du 6502 , donc il faut alléger le code est la c'est plus compliqué parce que ça demande de revoir son algo du coup.

Chez Nintendo oui sûrement que la SNES est la plus mal foutu niveau architecture.
Les autres sont largement plus simple (et mieux pensé).

[lessthantod]

La NES, la GB et la SNES, c'est de loin la meilleure période Big N ...

ils etaient omnibulé par le gain que le reste peu importe...

Dans ce cas le Mega CD et le 32X, c'est dans quel but? comment le justifier?

[Stef]

Non le 68000 n'aurait pas résolu vraiment le souci pour les sprites, pour moi c'est juste que l'OAM doit être en 16 bits et non en 8 bits :/
Cela aurait résolu le probleme des différentes tailles et des positions en X/Y de la SNES.

Je ne suis pas totalement "d'accord" sur ton dernier paragraphe.
Oui le 65816 est plus difficile a optimiser les compilateurs C le démontre clairement.

Tu vas devoir faire beaucoup plus d'instructions que sur le 68000 pour effectuer une même tâche.

De manière général c'est vrai , mais c'est la que on peut parler d'optimisation , je pense que certain programmeur talentueux en montré que y'avait quand meme des différences entre la façon de codé (Nasir Gebelli , Manfred Trenz ,les programmeurs de Super Aleste) , en gros je trouve qu'il est plus compliqué d'optimiser en 65816 , mais je pense que tu devrais coder un peu en 6502 , tu comprendrais ou je voudrais en venir .
En gros il est facile de faire du code lourd sur du 6502 , donc il faut alléger le code est la c'est plus compliqué parce que ça demande de revoir son algo du coup.

Chez Nintendo oui sûrement que la SNES est la plus mal foutu niveau architecture.
Les autres sont largement plus simple (et mieux pensé).

J'ai pas dit que le 68000 enlevait le problème des sprites de la SNES, franchement c'est trop pourri d'avoir cette gestion OAM 8 bits (je l'ai déjà dit, quand tu programmes sur SNES t'as plus l'impression d'être sur un 8 bits que sur une 16 bits pour de multiples raisons, dont la gestion par banque et l'OAM 8 bits)... C'est juste qu'avec le 68000 le problème aurait était moins *critique*, tu pourrais avoir un registre d'adresse qui pointerait toujours sur la partie haute et un autre sur la partie basse de l'OAM. Enfin juste que les meilleures performances du CPU permettrait de moins galérer mais clairement à mon sens ça reste un super défaut de la machine quoiqu'il arrive.

Et quand je parle d'optimisation, pour les compilateurs C c'est un autre problème, le fait de ne pas avoir de registre est déjà un gros problème, mais je pense que le plus difficile c'est aussi ce partitionnement par bank. Si tu veux utiliser efficacement le CPU tu dois intelligemment travailler avec les bank mémoires. Pour un compilateur c'est l'enfer de gérer ça et c'est pourquoi le code généré est en partie si pourri.

On a déjà beaucoup beaucoup discuté sur ces 2 CPUS, sur la manière dont on peut optimiser le code etc... tu as de la marge de toute manière avec tout les CPUS, heureusement ! Mais un CPU qui ne t'offre qu'un accumulateur 8/16 bits avec possibilité de faire des opérations que sur ce registre te limite forcément plus qu'un CPU où tu disposes de 8 registres 8/16/32 bits pour toutes les opérations + 8 registres d'adresses (qui supportent aussi un certain nombre d'opérations). Les combinaisons sont plus grande donc mathématiquement plus de possibilité d'arranger ton code. Sur 68000 en général le but est de réussir à charger toutes les variables de travail dans des registres et de travailler ensuite avec, le but étant souvent de manipuler un buffer d'entrée que tu transformes en buffer de sortie avec des opérations entre les 2. Avec un code optimal à la fin ta complexité s'apparente à lecture données / operations / écriture données et là dessus en puissance brute le 68000 défonce allègrement le 65816, c'est un fait. C'est ce qui fait qu'au final, tu en tireras plus sur le 68000 que sur le 65816 quand tu optimises des 2 côtés (et je parle bien sur à fréquence *mémoire* équivalente, je ne compares pas sur le fréquence CPU qui n'est pas comparable). J'ai déjà donné mon estimation de performance ici.. pour moi en gros un 68000 à 7.7 Mhz ~ un 65816 à 5 Mhz.
Sauf qu'un 65816 à 5 Mhz, c'est impossible à faire rentrer dans une SNES à cette époque là.

PS: J'ai déjà codé sur un 6502, en fait c'est même le premier CPU que j'ai codé en assembleur (sur VIC-20)... mais aujourd'hui je trouve juste que c'est trop pénible de programmer là dessus, ça ne va pas plus loin. Je n'aime pas beaucoup le Z80 non plus (donc c'est pas quelque chose contre le 6502 en particulier même si je trouve que c'est le pire des CPUs quand même dans tout ce que j'ai pu essayer :p)

[Invité]

De manière général c'est vrai , mais c'est la que on peut parler d'optimisation , je pense que certain programmeur talentueux en montré que y'avait quand meme des différences entre la façon de codé (Nasir Gebelli , Manfred Trenz ,les programmeurs de Super Aleste) , en gros je trouve qu'il est plus compliqué d'optimiser en 65816 , mais je pense que tu devrais coder un peu en 6502 , tu comprendrais ou je voudrais en venir .

Exactement,et en plus on peut vraiment dire que la marge d'optimisation est qd même énorme, car arriver à faire super alest ou RR² en slow rom, tout en étant obligé de se farcir la gestion des sprites de la snes(qui te bouffe du CPU pour rien), moi je trouve ça fort pour un CPU @2.6mhz .

SAuf qu'un 65816 à 5 Mhz, c'est impossible à faire rentrer dans une SNES à cette époque là.

Si mais pas avec le design de base de mos/wdc qui est en 2 phases et donc nécessite de la ram tournant 2x plus vite que le CPU(1/2 cycles d'accès au BUS), donc oui tel quel c'était pas possible,sauf faire comme hudson, et re-designer le CPU normalement en CPU 1 phase et 1 cycle d'accès au bus .

la slow rom snes est à 200ns et 120 pour la fast rom(@3.58mhz), la rom @7,16 mhz de la pce est à 140ns(le CPU de la PCE est un CPU 1 phase) ..

Pour moi il est clair que nintendo s'en branlait de la vitesse du CPU, et seul le coût de la console comptait, car il pouvait facilement upgrader le CPU via cartouche, comme nintendo a bcp upgradé la nes .

[Invité]

Oui je suis d'accord pour le 68000 laisse plus de possibilité pour l'optimisation je suis au courant hein (je code en 68000 aussi) et effectivement en général on bosse avec les 8 + 7 registres ,donc oui en terme optimisation c'est top

Le 6502/65816 en général comme les accès a la ram sont pas trop lente , il serve de registre intermédiaire (sans trop abuser) , pour ma part je bosse tjs sur SNES(ou PCE tiens) avec 16 octets temporaire.

Bref le seul truc c'est niveau chiffre , pour moi la MD (niveau CPU) est de 33/40% plus rapide que la SNES en slow rom.
D'apres Stef la MD est 50% plus rapide (que je trouve exagérer) , beaucoup de jeux sur SNES ont montré que la différence était pas si énorme (je parle du 50%).
Après certes la différence entre les versions comme je l'ai dit la difficulté du processeur/hard sur SNES était un frein pour l'exploité a fond.

Exactement,et en plus on peut vraiment dire que la marge d'optimisation est qd même énorme, car arriver à faire super alest ou RR² en slow rom, tout en étant obligé de se farcir la gestion des sprites de la snes(qui te bouffe du CPU pour rien), moi je trouve ça fort pour un CPU @2.6mhz .

Oui clairement , dommage que SoM est moins considérer comme un jeu assez technique (ou il faut une sacré performance en terme optimisation) pourtant a mes yeux le jeu exploite pas mal de chose (mais moins visible du coup).

[Invité]

Oui clairement , dommage que SoM est moins considérer comme un jeu assez technique (ou il faut une sacré performance en terme optimisation) pourtant a mes yeux le jeu exploite pas mal de chose (mais moins visible du coup).

C'est vrai, mais pour bcp un RPG ca demande peu de ressources,et ils te balanceront toujours un shoot en fasse.
Pour ma part le RPG est l'exercice le plus difficile,surtout sur des consoles 8/16 bit.

[Invité]

Ben ça dépend un RPG tour par tour il est vrai que c'est pas le plus gourmand (et pas super technique enfin ça depend FF 6 est pas trop mal), mais un A-RPG c'est vraiment autre chose.
Ben si tu veux une liste de ce que doit gerer SoM ^^ :
-Zorder (ou Yorder comme tu veux) perso/perso et perso/BG
-L'animation de palette (perso et background)
-L'animation des sprites
-L'animation des BG
(Oui un shoot gere rarement tout ces composantes surtout BG et palette).
-Les collisions mur/hitbox ( sur 6 ou 12 perso a l'écran) , les collisions perso/perso et perso/mur.
-la transparence (et la gérer avec les sprites in game c'est pas le plus facile (et le moins gourmand ) ) , preuve en est SoM (avec terranigma) sont les seul A-RPG qui le gère bien (dans le sens ou le perso peut entrer sortir de l'eau).
-L'IA
-et d'autre truc aussi.

Sur 2.67 MHZ 60FPS

[Stef]

Je dois admettre pour pour moi, un RPG c'est quand même assez léger à gérer en terme de performance pure. En terme de complexité du moteur je ne dis pas (monde ouvert, scrolling multi directionnelle, beaucoup d'objets à gérer en même temps...) mais définitivement en terme d'animation brute, de complexité de sprites à afficher etc... je trouve que c'est tout de même un cran en dessous d'un beat'em all par exemple. Le shoot, ça va être surtout de la collision, beaucoup de sprites mais peu de complexité sur le moteur, peu d'animations... Un beat'em all ou un shoot à la contra c'est assez lourd car non seulement tu as de la collision à gérer (bon de ce côté ça va encore) mais c'est surtout en terme de bande passante / animation sprite (avec souvent du meta-sprite à gogo) que c'est vraiment lourd. Aussi selon le jeu, tu peux avoir du scrolling multi directionnel à gérer en même temps, je trouve ça assez hardu techniquement, en tout cas plus qu'un RPG où le moteur en lui-même est peut être plus complexe mais ensuite en charge CPU c'est relativement léger... Ce n'est pas pour rien non plus qu'on trouve pléthore de jeu de ce genre sur SNES... la machine est vraiment à son avantage: bel esthétique avec ses nombreuses couleurs, effets graphiques cablés qui permettent d'en mettre plein la vue avec les magies et musiques "symphoniques" qui participent beaucoup à l'ambiance pour ce genre de jeu. Bref pour moi la SNES est taillée pour le RPG (le seul truc qui pèche à mon sens pour ce style c'est sa faible résolution). Un beat em all à la Street Of Rage par contre, je trouve que c'est un défi vraiment compliqué pour cette machine.

[Invité]

On est pas vraiment d'accord alors un A-RPG c'est un beat them all avec du leveling et une histoire donc bon
en terme de calcul ça bouffe plus que tu ne le crois
Toutes les techniques qui se trouve sur un BTA se trouve sur un A-RPG sauf que un A-RPG gère encore plus de truc.
et encore les collissions sur un A-RPG sont bcp plus complexe que SOR , c'est vraiment pas comparable (relis en haut tu vera ce qu'il faut gerer).
Apres las A-RPG assez bien foutu (techniquement je parle) ce compte sur le doigts d'une main , Illusion of Time , Terranigma , secret of Evermore et Seiken Dentetsu 2 et 3.
En terme de Sprite j'avais donner facile 70 sprite a gérer sur SoM c'est pas ce qu'on peut appeler peu

mais c'est surtout en terme de bande passante / animation sprite (avec souvent du meta-sprite à gogo)

Quand t'as les BG a upload (l'animation des BG) , la palette , les meta sprite , les 6 perso/ennemi , les armes , magies ect (je vais pas remettre je que j'ai écrit), tu crois que ça bouffe pas (beaucoup) de la bande passante ?

mais ensuite en charge CPU c'est relativement léger...

j'ose esperer que tu parle pour un RPG tour par tour , parce que sinon je crois qu'une longue discussion s'impose :)

[Stef]

On est pas vraiment d'accord alors un A-RPG c'est un beat them all avec du leveling et une histoire donc bon
en terme de calcul ça bouffe plus que tu ne le crois
Toutes les techniques qui se trouve sur un BTA se trouve sur un A-RPG sauf que un A-RPG gère encore plus de truc.
Apres las A-RPG assez bien foutu (techniquement je parle) ce compte sur le doigts d'une main , Illusion of Time , Terranigma , secret of Evermore et Seiken Dentetsu 2 et 3.
En terme de Sprite j'avais donner facile 70 sprite a gérer sur SoM c'est pas ce qu'on peut appeler peu

mais c'est surtout en terme de bande passante / animation sprite (avec souvent du meta-sprite à gogo)

Quand t'as les BG a upload (l'animation des BG) , la palette , les meta sprite , les 6 perso/ennemi , les armes , magies ect (je vais pas remettre je que j'ai écrit), tu crois que ça bouffe pas (beaucoup) de la bande passante ?

Non mais y'a quand même une grosse différence... Dans les RPG les persos sont riquiquis. Tu les fais tenir dans un seul sprite hard 32x32 max, au pire 2 sprites hard. Les étapes d'animation sont faibles et peuvent quasi tenir en VRAM pour les persos principaux. Dans un BTA, les persos sont plus gros, en méta sprites avec une gestion intelligente pour ne pas défoncer la limite scanline trop rapidement et tu dois animer les persos rapidement. Vu la taille ça ne tient pas en VRAM et du coup tu dois balancer tout en VRAM pendant le VBlank, ce qui n'est pas chose facile quand tu es limité à 5 KB (SNES) ou 7 KB (MD) par VBlank... Sachant que tu dois souvent reconstruire une bonne partie de la SAT (ou OAM) pour gérer correctement le Y order / flip et le clip des persos (pour là encore optimiser ta bande passante scanline). Je veux bien croire qu'un A-RPG c'est pas super simple à gérer mais vraiment non tu ne pourras pas me faire dire que c'est plus lourd ni même aussi lourd qu'un BTA :p

Est-ce qu'on voit souvent les A-RPG ramer sur SNES (ou sur tout autre machine) ? Même question maintenant pour les BTA ? Y'a surement une bonne raison à ça

[Invité]

C'est comparable dans le degré de sophistication du système. Chacun peut s'exprimer différemment, sous forme de calculs ou d'affichage.

[Invité]

Ben si tu veux une liste de ce que doit gerer SoM ^^ :
-Zorder (ou Yorder comme tu veux) perso/perso et perso/BG
-L'animation de palette (perso et background)
-L'animation des sprites
-L'animation des BG
(Oui un shoot gere rarement tout ces composantes surtout BG et palette).
-Les collisions mur/hitbox ( sur 6 ou 12 perso a l'écran) , les collisions perso/perso et perso/mur.
-la transparence (et la gérer avec les sprites in game c'est pas le plus facile (et le moins gourmand ) ) , preuve en est SoM (avec terranigma) sont les seul A-RPG qui le gère bien (dans le sens ou le perso peut entrer sortir de l'eau).
-L'IA
-et d'autre truc aussi.

Sur 2.67 MHZ 60FPS 

Oui, c'est un concentré des difficultés de chaque style de jeu, tu rajoutes le fait qu'il faut en plus un bon scénar,de beaux graphismes, un bonne ambiance sonore,et t'as le ponpon

[Invité]

Clairement Touko

Non mais y'a quand même une grosse différence... Dans les RPG les persos sont riquiquis. Tu les fais tenir dans un seul sprite hard 32x32 max, au pire 2 sprites hard. Les étapes d'animation sont faibles et peuvent quasi tenir en VRAM pour les persos principaux. Dans un BTA, les persos sont plus gros, en méta sprites avec une gestion intelligente pour ne pas défoncer la limite scanline trop rapidement et tu dois animer les persos rapidement. Vu la taille ça ne tient pas en VRAM et du coup tu dois balancer tout en VRAM pendant le VBlank, ce qui n'est pas chose facile quand tu es limité à 5 KB (SNES) ou 7 KB (MD) par VBlank... Sachant que tu dois souvent reconstruire une bonne partie de la SAT (ou OAM) pour gérer correctement le Y order / flip et le clip des persos (pour là encore optimiser ta bande passante scanline).

Faux tu ne peux pas mettre du 32x32 pour la simple raison qu'il y'a la transparence (l'eau a gérer) et donc comme la transparence touche tout le sprite tu dois faire donc des meta sprite de 2x2.
Et donc ton perso fera 4 sprites (et donc gérer le YFLIP + que quand y'a l'eau de faire changer la priorité sur les sprites du bas).
Faux encore de dire que tout peut prendre en VRAM pour les perso principaux en faite c'est le contraire la VRAM est super rempli.
Tu as 32x32 pour un perso donc 0x200 octet
tu fait x3 tu as  0x600 octet
tu a les armes sur du 16x32 x3 = 0x300 octet
les ennemi sont plus gros (vont jusqu'a 48x48 pour certain)
- 0x480 x 3 = 0xD80
-menu = 0x600
-les degat = 0x900
-les magies x3 : 0XC00
Total 0x3180 /0x4000
J'ai pas compté quelque petit truc , mais non tu ne peux pas mettre tout les perso avec leur animation en VRAM



En terme de sprite ça fait donc :
3 perso 4x3 = 12 sprites.
3 armes = 2x3 = 6 sprites
3 ennemi 6x3 = 18 sprites
6 gros dégât = 3*6 = 18 sprites
3 magie = 3*6 sprites = 18 sprites
+ 3 sprite du Hud
ça fait donc 75 sprites affichable , quasiment tout en meta sprite

+ les collision qui sont plus complexe (apparemment t'es pas au courant que les collisions dans toute les machines sont souvent le goulot d'étranglement du CPU).

En terme de bande passante avec tout je que j'ai dit tu peux imaginer que en faite , on ne fait que envoyer continuellement des donners (y'en a même un peu trop).

Est-ce qu'on voit souvent les A-RPG ramer sur SNES (ou sur tout autre machine) ? Même question maintenant pour les BTA ? Y'a surement une bonne raison à ça Wink

D'un coter comme je l'ai dit il y a que 5 Action RPG bien foutu techniquement dont 3 de square soft et 2 de Enix ,  tu as ta réponse ? :)

Je veux bien croire qu'un A-RPG c'est pas super simple à gérer mais vraiment non tu ne pourras pas me faire dire que c'est plus lourd ni même aussi lourd qu'un BTA :p

Libre a toi de le croire j'ai deja pas mal écrit et argumenté , après si tu pense que un BTA consomme plus je peux rien de dire de plus.

[airdream]

Pour moi il est clair que nintendo s'en branlait de la vitesse du CPU, et seul le coût de la console comptait, car il pouvait facilement upgrader le CPU via cartouche, comme nintendo a bcp upgradé la nes .

les jeux avec upgrade? une cinquantaine de jeux sur le millier existant... tu m'as pas convaincu la, et ca n'a pas non plus convaincu les studios de developpement.
95% des jeux snes composent avec ce qui il y a seulement dans la console et ont du sacrifier tellement de bonnes idees pour que ca passe sur snes sans assistance.

[airdream]

La NES, la GB et la SNES, c'est de loin la meilleure période Big N ...

ils etaient omnibulé par le gain que le reste peu importe...

Dans ce cas le Mega CD et le 32X, c'est dans quel but? comment le justifier?

meilleure periode bigN oui mais quel exploit avec une console aussi faiblarde, les felicitations vont surtout aux developpeurs de jeux mais pas aux concepteurs de la snes.

MCD et 32X c'est un autre probleme marketing cette fois, les machines semblent assez bien foutues, dans ce cas je salue les concepteurs qui devait etre plus agueri que les ingenieurs nintendo.
et puis cette erreur MCD ou 32X existe malgre tout encore de nos jours sous une forme differente avec les evolutions PS4 et XBOX ONE
il y a toujours une partie de joueurs fortunés qui n'attendent que ca, un upgrade.

[Stef]

Faux tu ne peux pas mettre du 32x32 pour la simple raison qu'il y'a la transparence (l'eau a gérer) et donc comme la transparence touche tout le sprite tu dois faire donc des meta sprite de 2x2.
Et donc ton perso fera 4 sprites (et donc gérer le YFLIP + que quand y'a l'eau de faire changer la priorité sur les sprites du bas).
Faux encore de dire que tout peut prendre en VRAM pour les perso principaux en faite c'est le contraire la VRAM est super rempli.
Tu as 32x32 pour un perso donc 0x200 octet
tu fait x3 tu as  0x600 octet
tu a les armes sur du 16x32 x3 = 0x300 octet
les ennemi sont plus gros (vont jusqu'a 48x48 pour certain)
- 0x480 x 3 = 0xD80
-menu = 0x600
-les degat = 0x900
-les magies x3 : 0XC00
Total 0x3180 /0x4000
J'ai pas compté quelque petit truc , mais non tu ne peux pas mettre tout les perso avec leur animation en VRAM



En terme de sprite ça fait donc :
3 perso 4x3 = 12 sprites.
3 armes = 2x3 = 6 sprites
3 ennemi 6x3 = 18 sprites
6 gros dégât = 3*6 = 18 sprites
3 magie = 3*6 sprites = 18 sprites
+ 3 sprite du Hud
ça fait donc 75 sprites affichable , quasiment tout en meta sprite

+ les collision qui sont plus complexe (apparemment t'es pas au courant que les collisions dans toute les machines sont souvent le goulot d'étranglement du CPU).

En terme de bande passante avec tout je que j'ai dit tu peux imaginer que en faite , on ne fait que envoyer continuellement des donners (y'en a même un peu trop).

Est-ce qu'on voit souvent les A-RPG ramer sur SNES (ou sur tout autre machine) ? Même question maintenant pour les BTA ? Y'a surement une bonne raison à ça Wink

D'un coter comme je l'ai dit il y a que 5 Action RPG bien foutu techniquement dont 3 de square soft et 2 de Enix ,  tu as ta réponse ? :)

Je veux bien croire qu'un A-RPG c'est pas super simple à gérer mais vraiment non tu ne pourras pas me faire dire que c'est plus lourd ni même aussi lourd qu'un BTA :p

Libre a toi de le croire j'ai deja pas mal écrit et argumenté , après si tu pense que un BTA consomme plus je peux rien de dire de plus.

Mais là dans ton calcul de 75 sprites tout est fixé et pré-alloué. En gros c'est le max qu'il te faudra si tout arrive en même temps (ce qui est jamais le cas). Et en plus tu parles uniquement de sprites carrés 2x2 (petits sprites donc) qui est une contrainte de la SNES. Sur MD tu diviserais quasiment par 2 le nombre de sprite à utiliser pour un résultat équivalent. Et je n'ai toujours pas compris le problème qui se pose avec la transparence, que tu le gères sur le sprite complet (4x4) ou sur 1/4 de sprite (2x2) je ne vois pas en quoi ça aide, ton sprite bougeant au pixel prêt.
Dans un BTA, tu peux avoir 16 sprites pour un seul meta sprite avec des tailles différentes et des offsets à changer à chaque frame. Dans ton cas tout est fixé et pré-alloué: tout est 2x2, ou 2x1 ou 2x3, il n'y a pas grand chose de dynamique dans la gestion du moteur de sprite. A mon sens c'est une grosse simplicité comparé à un BTA où tu as besoin d'une gestion plus flexible en terme d'allocation ressource. Tu peux pas te dire : je pré-alloue 2 persos, 2 armes, 4 ennemis, 2 items de décor... avec 16 tiles max pour ça, ça et ça... Ca te limiterai bien trop sur le design de ton jeu. Dans un bon BTA les ennemis ont de tailles différentes, les boss sont plus gros et selon les niveaux le nombre d'ennemis peut varier... ça t'oblige à avoir un moteur bien plus flexible. Alors oui les Final Fight sur SNES sont un mauvais exemple et ont surement des moteurs plus simple et figé car le nombre d'ennemis est limité à 3, y'a pas / peu d'items / arme ou éléments du décor que tu peux casser. Mais regarde SOR2, démarre le jeu dans un émulateur comme exodus et regarde à quel point la table des sprites est dynamique selon la charge à l'écran.

[Invité]

Pour la transparence grosso modo vu qu'elle est gérer cela enlève obligatoirement le choix du 32x32 pour les perso/ennemi.
De plus on parle ici de temps de temps de calcul ? Donc obligé de gerer autant de sprite est très lourd pour la SNES (tu dira pas le contraire) , 75 c'est le max certes mais même si on réduit cela d'un peu (1 magie + 2 gros degat c'est pas rare) on est autour des 50 sprites.

Donc d’après toi faire des meta sprite qui varie , prend énormément de calcul ? (au point de prend plus que les collisions 6 perso a l'écran avec des collisions entre perso/perso et perso/mur ?).
Je pensais ahma que pour faire ceci on lisait une table de meta sprite :)

Si SOR2 a plus d'ennemi a l'écran je n'ai parce que il gère le truc de manière plus flexible(enfin sûrement) mais que la MD gère un peu plus de sprite par scanline que la SNES.
Enfin tu peux réarranger les metasprites comme tu le veux sur SNES ça se compte plutôt par 256 pixel par scanline donc bon
Si sur MD c'est le meme principe (donc 320 pixel par scanline) ça fait 6 perso max a l'écran et donc oui tu peux très bien te limiter a 8 sprite par perso par exemple (si on compte pas les boss).

[Tryphon]

Kannagi, t'as déjà codé un BTA ? Sur une vieille architecture ?

[Invité]

Oui et non le seul BTA que j'ai commencé a programmer c'est sur Neo Geo , donc j'ai pas eu trop de contrainte la
Tu peux même te permettre de faire du HiColor donc bon ^^

Après la question suppose que tu doute de mes compétences c'est ton droit

[Tryphon]

C'est gentil à toi de préciser mes droits :) mais non, je ne doute pas de tes compétences, je doute juste du fait que tu aies correctement estimé les contraintes dans les deux cas observés.

Quand tu écris :

Donc d’après toi faire des meta sprite qui varie , prend énormément de calcul ?

tu n'as pas compris que le problème dans un BTA est moins le calcul (encore qu'il y a autant, sinon plus, de tests de collisions qu'avec un A-RPG) que la gestion des ressources, notamment du DMA. Ce n'est pas lire la table de metasprites qui limite, mais d'envoyer les tiles du metasprite courant en VRAM, à chaque frame.

Si tu avais programmé un BTA sur une 16 bits (à part la NeoGeo et peut-être la Supergrafx), tu te serais heurté à ce problème dans les premières heures de dev.

Stef a évoqué tous les points que j'avais l'intention de soulever dans une réponse précédente. En particulier, je ne comprends pas non plus le problème avec la transparence. Je ne sais pas du tout comment la SNES gère ça, mais si je voulais faire un tel effet sur MD (qui ne la gère pas, à moins d'utiliser du Shadow / Highlight mais ça ne rendrait certainement pas terrible ici), à vue de nez (j'y ai pas plus réfléchi que ça) je ferais soit du dithering par dessus le sprite, ce qui m'obligerait juste à changer la priorité de la tile "eau", soit un changement de palette du sprite en début de scanline (à la Sonic). Dans les deux cas ça n'oblige pas à redécouper le sprite. En plus, il me semble que la SNES propose plus de facilités pour ce genre d'opérations en début de scanline.

[Stef]

Pour la transparence grosso modo vu qu'elle est gérer cela enlève obligatoirement le choix du 32x32 pour les perso/ennemi.
De plus on parle ici de temps de temps de calcul ? Donc obligé de gerer autant de sprite est très lourd pour la SNES (tu dira pas le contraire) , 75 c'est le max certes mais même si on réduit cela d'un peu (1 magie + 2 gros degat c'est pas rare) on est autour des 50 sprites.

Je ne comprends pas pourquoi tu dois obligatoirement te passer du 32x32 pour la transparence. Est-ce que tu parles de la priorité avec les éléments du décor (Y ordering) ? Où le bas du corps doit par exemple passer derrière un arbre et le haut du corps devant une maison ? Car justement les maps des RPG sont désignés pour éviter ce genre ce cas de figure (et le fait d'avoir de petits sprites pour les persos aident pas mal à ce niveau). Ou tu parles par exemple d'un fleuve en transparence et les sprites passent par dessus ? J'imagine qu'il s'agit d'un problème de priorité mais je ne vois pas en quoi le 16x16 va résoudre le problème, sauf si la map est désignée de telle manière à...

Sinon oui dans l'absolu gérer 50 sprites sur SNES bien sur ça fait beaucoup et ce n'est pas facile on est d'accord. Mais c'est quand même plus simple quand tu as une gestion purement statique où tout tes sprites sont toujours au même slot dans l'OAM. Il te reste "juste" à mettre à jour les propriétés (position, palette, flip et priorité) quand c'est necessaire. Encore une fois je ne dis pas que c'est simple mais juste qu'un BTA assez évolué peut être vraiment complexe à ce niveau !

Donc d’après toi faire des meta sprite qui varie , prend énormément de calcul ? (au point de prend plus que les collisions 6 perso a l'écran avec des collisions entre perso/perso et perso/mur ?).
Je pensais ahma que pour faire ceci on lisait une table de meta sprite :)

Si SOR2 a plus d'ennemi a l'écran je n'ai parce que il gère le truc de manière plus flexible(enfin sûrement) mais que la MD gère un peu plus de sprite par scanline que la SNES.
Enfin tu peux réarranger les metasprites comme tu le veux sur SNES ça se compte plutôt par 256 pixel par scanline donc bon
Si sur MD c'est le meme principe (donc 320 pixel par scanline) ça fait 6 perso max a l'écran et donc oui tu peux très bien te limiter a 8 sprite par perso par exemple (si on compte pas les boss).

En fait j'y ai pas mal pensé quand j'ai désigné le Sprite Engine de SGDK, j'ai essayé de faire un moteur de sprite flexible pour tout les cas de figure et clairement pour moi le cas le plus complexe c'était le cas des BTA. où tu peux avoir pas mal de gros sprites, avec des changements d'arrangement entre chaque frame, une gestion du clipping des sprites en dehors de la fenêtre de vision pour optimiser l'affichage sur le scanline, le transfert d'un gros paquet de tile à chaque frame.
Je suis assez impressionné par Final Fight CD, je pense qu'il est vraiment à la limite de ce que peut faire le VDP de la MD... De gros sprites bien animés, beaucoup d'items à l'écran  (caisses + tonneaux + armes), vraiment la gestion des ressources sprites dans ce jeu doit être bien complexe et consommer pas mal de ressource CPU. Sur borne d'arcade c'est simple car tu as des ressources hard à gogo, du coup tu te poses même pas la question, tout est alloué en "statique" et ça rentre sans problèmes ... Sur MD ou SNES, pour ce genre de jeu c'est bien plus complexe que tu dois composer avec des ressources limitées (sprite hard, limite scanline, peu de VRAM). Si tu fais tout en statique ton jeu sera plus pauvre car contraint directement. Si tu veux exploiter au max les ressources tu es obligé de faire une allocation plus dynamique mais aussi beaucoup plus complexe à mettre en oeuvre.
Enfin dans le cas de Final Fight CD la question ne se pose même pas sur SNES, avec seulement 16 KB de VRAM dédiée aux tiles sprites je crois que c'est déjà foutu dés la base pour faire un portage correct. Sur Final Fight CD quasiment 30KB de la VRAM est réservé aux tiles sprites :-/ Tu pourrais économiser sur le HUD sur SNES (3ème plan) mais 16 KB ça reste quand même trop faible.

[Invité]

tu n'as pas compris que le problème dans un BTA est moins le calcul (encore qu'il y a autant, sinon plus, de tests de collisions qu'avec un A-RPG)

Euh non,ton sprite peut être composé de 500 sprites, niveau soft il serra vu comme 1 seul, tu vas pas faire des tests de collisions pour chaque sprites composant ton meta sprite .
Donc non un BTA niveau collisions c'est peanuts .

Si tu fais tout en statique ton jeu sera plus pauvre car contraint directement. Si tu veux exploiter au max les ressources tu es obligé de faire une allocation plus dynamique mais aussi beaucoup plus complexe à mettre en oeuvre.

Bien sur qu'une gestion dynamique est galère à faire,mais à t'écouter tout est dynamiques sur MD ..
Pour un BTA, si tu penses ton jeu correctement tu n'en a pas besoin, du moins sur MD/PCE, sur snes je sais pas vu son système de banque pour les sprites .
J'ai fait un dump de la vram de SOR2, y a rien de dynamique dedans .

les jeux avec upgrade? une cinquantaine de jeux sur le millier existant... tu m'as pas convaincu la, et ca n'a pas non plus convaincu les studios de developpement.
95% des jeux snes composent avec ce qui il y a seulement dans la console et ont du sacrifier tellement de bonnes idees pour que ca passe sur snes sans assistance.

upgradable facilement ne veut pas dire tout le temps, tu peux pas dire que mettre un CPU dans les cartouches n'était pas aisé, vu le nombre de puces différentes qui sont sorties .
Ah bon, des bonnes idées sacrifiées sans assistance ??, c'est vrai que tout les hits snes sont des cartouches avec puces ..

[Tryphon]

tu n'as pas compris que le problème dans un BTA est moins le calcul (encore qu'il y a autant, sinon plus, de tests de collisions qu'avec un A-RPG)

Euh non,ton sprite peut être composé de 500 sprites, niveau soft il serra vu comme 1 seul, tu vas pas faire des tests de collisions pour chaque sprites composant ton meta sprite .
Donc non un BTA niveau collisions c'est peanuts .

Euh non, il n'est pas rare qu'un gros metasprite comporte plusieurs hitbox pour épouser à peu près la forme du sprite (imagine un sprite en forme de croix dans un carré de 64 pixels, tu fais comment avec une seule hitbox ?) Le cas d'école c'est les versus fighting à la SF2 (ok, c'est pas un BTA, mais cette problématique s'y retrouve).

De plus lors des collisions sprite / background, tu dois tester toutes les tiles qui intersectent le sprite, et ça c'est proportionnel à la taille de ton sprite.

Plus d'autres trucs, comme les projectile, les différents types de hitbox (par exemple, pour Shinobi, y'a une hitbox classique, une hitbox "offensive" (qui peut tuer le perso), une hitbox defensive (qui peut arrêter un projectile). Et je t'assure que c'est pas peanuts :)

[Invité]

Euh non, il n'est pas rare qu'un gros metasprite comporte plusieurs hitbox pour épouser à peu près la forme du sprite (imagine un sprite en forme de croix dans un carré de 64 pixels, tu fais comment avec une seule hitbox ?) Le cas d'école c'est les versus fighting à la SF2 (ok, c'est pas un BTA, mais cette problématique s'y retrouve).

SF2, vu que je suis plus ou moins en train de faire un fighting,pas besoin de ça, tu changes le pattern du perso que tu touches en fonction du type de coup, haut/moyen/bas,c'est tout, et tu testes juste 2 hitbox.

[Tryphon]

Vu comme je comprends ta question, je dirais : tous ? Mais ça ne doit pas être ça.

Un jeu où il y a plusieurs hitbox par sprite ? Je t'en ai cité un.

Au passage, dans SOR2, les sprites des joueurs sont dynamiques (VRAM 0x3000)

Edit : si tu édites tes questions pendant que j'y réponds, c'est difficile

J'avais aussi démarré un fighter, plus exactement j'étudie la possibilité de porter un sous-ensemble de MUGEN.

[Invité]

Au passage, dans SOR2, les sprites des joueurs sont dynamiques (VRAM 0x3000)

On a pas la même def de dynamique alors, moi je parle pas de changer les patterns en VRAM, mais d'allouer des slots VRAM aux sprites, mais c'était peut être la première version pour vous .

Dans un BTU forcement les 2 joueurs (au moins) vont charger les patterns en VRAM en cours d'animation  .

De plus lors des collisions sprite / background, tu dois tester toutes les tiles qui intersectent le sprite, et ça c'est proportionnel à la taille de ton sprite.

Réellement je pense pas, les détections avec le bgnd dans un BTU sont sommaires(c'est pas un jeu de plateforme), donc au meta sprite je pense .

[Invité]

Je crois que pas beaucoup ont compris la transparence sur SNES.
Si tu active la transparence , le sprite tu pourra changer la  priorité , alors priorité basse il sera en dessous de l'eau est donc t'aura l'impression que tout ton perso est sous l'eau , ce qu'on ne veut pas (le haut du corps est la partie émerge).
Et pour ça ben tu divise ton sprite en 2x2 par exemple, pour que le haut reste hors de l'eau et le bas dans l'eau.
Et je que je dit c'est vraiment la seule méthode pour gérer ce cas de figure (mais comme je me répète il est assez rare il est que dans 2 Action RPG).

tu n'as pas compris que le problème dans un BTA est moins le calcul (encore qu'il y a autant, sinon plus, de tests de collisions qu'avec un A-RPG) que la gestion des ressources, notamment du DMA. Ce n'est pas lire la table de metasprites qui limite, mais d'envoyer les tiles du metasprite courant en VRAM, à chaque frame.
Si tu avais programmé un BTA sur une 16 bits (à part la NeoGeo et peut-être la Supergrafx), tu te serais heurté à ce problème dans les premières heures de dev.

Et dans un A-RPG tu ne crois pas que tu dois renvoyer a chaque frame ?
Je te fait la liste ce que tu dois envoyer a chaque frame :
-la Palette BG et personnage (variable mais en moyenne 0x70 octet)
-les Perso (1 perso = 0x200 octet)
-les armes (1 arme = 0x100 octet)
-les ennemis (1 ennemi (0x200-0x400 octet)
-les magies (1 magie = 0x300 octet)
-les degats ( 0x180 octet max)
-le BG (tile map) ( en multi directionel 0xF00 octet)
-le BG (data pour les animations) (variable moyenne 0x200 octet)
-Le hud (variable moyenne 0x100 octet)

C'est ce qu'on appelle peu sûrement

Sur MD ou SNES, pour ce genre de jeu c'est bien plus complexe que tu dois composer avec des ressources limitées (sprite hard, limite scanline, peu de VRAM). Si tu fais tout en statique ton jeu sera plus pauvre car contraint directement. Si tu veux exploiter au max les ressources tu es obligé de faire une allocation plus dynamique mais aussi beaucoup plus complexe à mettre en oeuvre.

Je n'ai pas dit le contraire j'ai dit que tu met une table de meta sprite qui indique les sprite a charger , c'est pas ce qu'on peut appeler lourd en calcul (un peu complexe oui a mettre en place).