Re: Supergrafx

par Invité Lun 21 Oct 2013 - 20:30

La encore je n'avais pas compris ce que tu voulais dire, mais de toute manière en terme de bande passante c'est carrément le CPU qui te limite ? il me semblait qu'il n'était déjà pas assez rapide pour nourir un seul VDC à pleine vitesse, alors 2 ??
Sur MD le CPU, pourtant bien plus rapide que le 6280 en terme de débit mémoire est pourtant trop lent (et d'un facteur > x2) pour alimenter le VDP en pleine vitesse, comment tu fais sur PCE / SGX ? tu consommes toute la frame ?

Je veux dire que hors vblanc il te reste pas bcp de cycles/ligne pour pouvoir transferer en VRAM.
C'est clair que le 6280 n'est pas assez rapide pour utiliser toute la BP dispo, et tu en perds .
Et tu fais comment sur MD pour final fight, tu transfères tout pendant le vblank ???

Je me renseignes quand même, je pense que je commence à connaitre un peu la CPE à force, par exemple je sais qu'il faut 6 cycles minimum pour envoyer un byte dans le VDC, rien que ça je vois mal comme tu feras un FF de la trempe de la version CD sur SGX, alors en 512...

Tu verras bien Wink

Franchement j'ai pas mal étudié le 6502 et ses dérivés dernièrement et franchement je me demande comment on peut s'amuser à le comparer à un 68000. Car oui, à côté d'un 6502, on peut dire que le 68000 est tout puissant ! Le 6502 est tellement limité et simpliste, vraiment on est clairement pas du tout dans la même court...

C'est ça ton problème tu pense 6502, déjà le 65c02 est bien plus confortable à utiliser, le 6280 est encore au dessus .
Je te l'ai dit le 68k est un CPU généraliste, et pas rapide dans les instructions les plus utilisées dans un jeu .
il est peut être plus user friendly, mais ça en fait pas un CPU plus rapide .
Les chiffres, 0.7 mips pour le 68k et 1.2 mips+ pour le 6280 .
tes 20 instructions, c'est pas faux, sur 68k elles sont faites en interne,via le microcode qui va décomposer l'instruction, c'est plus facile à écrire, mais pas plus rapide .
Car ton instruction est figée, pas les miennes, tu peux facilement optimiser selon les cas, c'est ça qui fait la force des ces CPU .
C'est ultra efficace de n'avoir qu'a travailler sur 8 bit quand c'est pas nécessaire de travailler sur 16, et je peux te dire que c'est très souvent le cas.
Evidemment tu t'en fous toi tu es obligé de travailler que sur 16 bit, le 8 bit étant aussi lent .
Dans certains cas le 68k le sera plus rapide, je suis d'accord, mais ces cas là sont assez rares dans un jeu, et pas réellement déterminants .

Non mais oui tu en es encore à compter les mips ou les cycles sur les branchements Mais compare donc juste sur le résultat ! Sur ce que tu peux réellement faire avec un 68000 et enuite ce que tu vas faire avec un 6280 ou 65816. Tu pourras trouver des exemples à la con ou le 6280 est devant mais dés que tu vas vraiment avoir besoin de faire des traitements plus lourd l'architecture 16/32 bits bien plus avancée du 68000 te donnera un gros avantage. Tu crois vraiment que le 68000 embarque 20 fois plus de transistors qu'un 6502 pour faire beau ? le 6502 est le CPU 8 bits le moins cher et le plus simple possible, son architecture simpliste t'oblige à faire souvent 3/4/5 voire 20 instructions là ou le 68000 en a besoin d'une. Tu ne peux clairement pas comparer ces CPUs.

Même si les mips valent ce qu'ils valent (surtout quand ça t'arranges pas hein stef Wink

), y'a une marge confortable en faveur du 6280 ..
Dis moi, qu'est ce qui est le plus utilisé dans un prog de jeux video ??
les tests, les branchements, les sauts, et les gestion d'irq ..
Ca doit représenter pas loin de 80% des instructions d'un jeu, manque de pot le 6280 est quand même bien plus rapide .

Mais franchement tant mieux si tu es si sur de toi, je suis vraiment impatient de voir ce que tu vas réussir à faire sur cette machine... je pense juste que tu ne te rends pas bien compte à quel point le CPU est important et que l'architecture 16 bits de la MD est clairement un avantage pour ça :)

L'architecture 16 bit n'a rien a voir la dedans, comme dis 50 fois, que tu mettes 8 cycles pour un 16 bit, ou 2*4 cycles pour du 8 bit, ça revient au même .

Arf, non mais attends, c'est comme la version arcade X'D
Bien sur que toutes les décompositions ne sont pas à 30 FPS, laisse tomber la taille de la rom sinon, mais quand ils marchent par exemple, c'est en 30 FPS. Et c'est pas parce que les 2 persos marchent en même temps que les ennemis s'arrêtent
J'ai pas compris ou tu voulais en venir niveau argument ! Ouais les couleurs, c'est pas la panacé de la MD c'est clair. Mais pour le reste on est largement au dessus de la version SNES (que toi tu trouves plus rapide, on le sait )

Non là les couleurs sont vraiment moches, y'a un dithering de malade, c'est clair que la version SGX sera bcp plus belle .
Et non, pour moi elle est pas aussi rapide que l'arcade, sur arcade ca rame pas quand tu commences à toucher les ennemis, ni sur snes d'ailleurs .
Là c'est flagrant, c'est normal tant que tu tapes dans le vide, des que tu touche, on tombe à du 1 anim toutes les 4 frames voire moins .
Et il manque aussi pas mal de pattern d'anim, rien que pour la marche de guy c'est flagrant .
En arcade la marche de guy c'est 10 patterns, sur MD il doit y en avoir pas plus de 4/5 ..
Je dis pas que c'est mieux sur snes, mais j'ai pas cette sensation de lenteur quand tu touches.

De toutes façons le jour où je me lance sur un beat je ferrais des tests pour voir, évidemment j'ai pas suffisamment de compétence pour faire un FF .

EDIT: Pour les ralentissements, j'ai l'impression que ça vient de l'emulateur, sur le vrai hard ça se produit pas ..

par Invité Lun 21 Oct 2013 - 21:03

Aaaaah! La supergraphx! Que de rêves brisés avec cette machine!
Quand j' ai connu la PCE, en 91/92, et qu' on parlait de sa petite sœur, j' avais le cœur qui battait la chamade!
La pCE, le CDROm, la pce GT ....et ensuite une console 16bits avec des possibilités plus grandes...on imaginait pas faire mieux! Déjà que la pce rivalisait avec les 2 ténors de l' époque.

Je ne sais pas si il valait mieux soutenir cette console en abandonnant complètement la PCE (sa ludothèque n' étant pas perdue) ou ne pas se lancer dans ce projet, et attendre l' ère 32 bits pour sortir une vraie console de guerre.
A ce titre, la PC FX fut ma plus grande déception, même si sous exploitée (des purs jeux 2D assumés aurait plus lui permettre de vivre un peu plus), elle avait de quoi faire quelques jeux sympas, autres que des da interactifs.

Dommage, 2 faux pas de la part de la firme, qui ne reviendra jamais comme constructeur.

par Stef Lun 21 Oct 2013 - 22:13

Je veux dire que hors vblanc il te reste pas bcp de cycles/ligne pour pouvoir transferer en VRAM.
C'est clair que le 6280 n'est pas assez rapide pour utiliser toute la BP dispo, et tu en perds .
Et tu fais comment sur MD pour final fight, tu transfères tout pendant le vblank ???

Oui sur MD tu transfères que pendant le VBlank, idéalement, et en utilisant le DMA pour être à pleine vitesse. Hors VBlank tu peux transférer mais c'est beaucoup plus lent... Seulement dans ce genre de jeu, hors vblank tu as tendance à préparer ta prochaine frame. Sur PCE je conçois que le schéma n'est pas le même mais vu la vitesse à laquelle le CPU transfert il ne va plus de rester grand chose en temps CPU pour le reste.

C'est ça ton problème tu pense 6502, déjà le 65c02 est bien plus confortable à utiliser, le 6280 est encore au dessus .
Je te l'ai dit le 68k est un CPU généraliste, et pas rapide dans les instructions les plus utilisées dans un jeu .

Excepté des modes d'adressages et quelques instructions spécialisées (qui aident tout de même genre la copie de bloc) le design du CPU reste fondamentalement le même, t'as pas de shift variables, pas de multiplication, pas de division, tu restes loin de ce qu'offre le 68000...

il est peut être plus user friendly, mais ça en fait pas un CPU plus rapide .
Les chiffres, 0.7 mips pour le 68k et 1.2 mips+ pour le 6280 .
tes 20 instructions, c'est pas faux, sur 68k elles sont faites en interne,via le microcode qui va décomposer l'instruction, c'est plus facile à écrire, mais pas plus rapide .
Car ton instruction est figée, pas les miennes, tu peux facilement optimiser selon les cas, c'est ça qui fait la force des ces CPU .
C'est ultra efficace de n'avoir qu'a travailler sur 8 bit quand c'est pas nécessaire de travailler sur 16, et je peux te dire que c'est très souvent le cas.
Evidemment tu t'en fous toi tu es obligé de travailler que sur 16 bit, le 8 bit étant aussi lent .
Dans certains cas le 68k le sera plus rapide, je suis d'accord, mais ces cas là sont assez rares dans un jeu, et pas réellement déterminants .

Bon c'est un débat qu'on a déjà eu... l'idée des micro instructions est vrai, c'est exactement ça, avec le 6502 c'est comme si tu codais avec les micro code directement sauf que le 68000 a des instructions supplémentaires optimisées (genre un shift, une multiplication...) et surtout l'architecture 16/32 bits te donnera des avantages évidents. Enfin on va pas repartie là dessus.

Même si les mips valent ce qu'ils valent (surtout quand ça t'arranges pas hein stef ), y'a une marge confortable en faveur du 6280 ..
Dis moi, qu'est ce qui est le plus utilisé dans un prog de jeux video ??
les tests, les branchements, les sauts, et les gestion d'irq ..
Ca doit représenter pas loin de 80% des instructions d'un jeu, manque de pot le 6280 est quand même bien plus rapide .

Le move est *de loin* l'instruction la plus utilisée sur le 68000 (j'avais fait un outil de stats pour faire mon émulateur 68000). Les branchements viennent ensuite mais si tu retires les boucles d'attente alors des instructions comme add et sub passent devant. Les IRQ c'est juste négligeable à côté du reste...

L'architecture 16 bit n'a rien a voir la dedans, comme dis 50 fois, que tu mettes 8 cycles pour un 16 bit, ou 2*4 cycles pour du 8 bit, ça revient au même .

Oui mais non, c'est loin d'etre aussi simple, au final, quand tu compares sur les chiffres théorique d'efficacité optimale sur MD tu finis avec ça :
- 4 cycles pour une opération 16 bits simple ou un transfert mémoire (lecture ou écriture) de 16 bits.
- 8 cycles "" la même chose en 32 bits sans overhead.

Sur le 6280, j'ai du mal à évaluer cette efficacité optimale. Mais je pense que ça doit être du style :
- 2 cycles pour une opération 8 bits simple.
- 3 cycles pour un transfert mémoire 8 bits.
- des pénalités de 2/3 pour les mêmes opérations en 16 bits (8 bits x 2 + pénalité).

Et c'est là que tu vois l'avantage du 68000, car idéalement, dans un programme optimisé de manière optimale ce sont les chiffres qui vont ressortir. Les branchements ne seront que "des constantes" à côté.

Non là les couleurs sont vraiment moches, y'a un dithering de malade, c'est clair que la version SGX sera bcp plus belle .
Et non, pour moi elle est pas aussi rapide que l'arcade, sur arcade ca rame pas quand tu commences à toucher les ennemis, ni sur snes d'ailleurs .
Là c'est flagrant, c'est normal tant que tu tapes dans le vide, des que tu touche, on tombe à du 1 anim toutes les 4 frames voire moins .
Et il manque aussi pas mal de pattern d'anim, rien que pour la marche de guy c'est flagrant .
En arcade la marche de guy c'est 10 patterns, sur MD il doit y en avoir pas plus de 4/5 ..
Je dis pas que c'est mieux sur snes, mais j'ai pas cette sensation de lenteur quand tu touches.

De toutes façons le jour où je me lance sur un beat je ferrais des tests pour voir, évidemment j'ai pas suffisamment de compétence pour faire un FF .

EDIT: Pour les ralentissements, j'ai l'impression que ça vient de l'emulateur, sur le vrai hard ça se produit pas ..

Du coup tes ralentissements venaient de ton émulateur ? car regardes les vidéos youtube, y'a pas ces ralentissements dont tu parles... et l'animation de guy (comme cody ou Hagar) sont identiques à la version arcade, 30 FPS ! Rien à voir avec la décomposition de la version SNES. C'est dingue que tu n'arrives pas à voir la différence, c'est assez flagrant je trouve !

par pckid Lun 21 Oct 2013 - 22:21

Les amis pour faire avancer le débat , je vous propose de créer un jeu , l'un sur SGX et l'autre sur MD,
avec les mêmes sprites, tiles, et enjeu, et l'on verra quel jeu sera le meilleur.

Bon allez je rigole ! joueur fou

par Invité Lun 21 Oct 2013 - 23:33

Oui sur MD tu transfères que pendant le VBlank, idéalement, et en utilisant le DMA pour être à pleine vitesse. Hors VBlank tu peux transférer mais c'est beaucoup plus lent... Seulement dans ce genre de jeu, hors vblank tu as tendance à préparer ta prochaine frame. Sur PCE je conçois que le schéma n'est pas le même mais vu la vitesse à laquelle le CPU transfert il ne va plus de rester grand chose en temps CPU pour le reste.

je ferrais des tests pour voir ce que ça donne ..

Excepté des modes d'adressages et quelques instructions spécialisées (qui aident tout de même genre la copie de bloc) le design du CPU reste fondamentalement le même, t'as pas de shift variables, pas de multiplication, pas de division, tu restes loin de ce qu'offre le 68000...

tu entends quoi par shift variables ?? .
la multiplication tu utilise dans 90% la multiple de 2, donc pas utile .
Sur une console tu fais du jeu 2D, pas de la 3D ..
Et t'as pas intérêt qu'une interruption claque quand tu fais une multiplication ou une division Wink

Pour le 32 bit, j'en ai aucune utilité .
On peu parler des sauts/retours de routines, tu sais les fameux jsr/rts qui sont presque 3 fois plus lent que sur le 6280, c'est vrai que dans un jeu on les utilises peu ..
et ne parlons pas non plus des branchements conditionnels ..

Oui mais non, c'est loin d'etre aussi simple, au final, quand tu compares sur les chiffres théorique d'efficacité optimale sur MD tu finis avec ça :
- 4 cycles pour une opération 16 bits simple ou un transfert mémoire (lecture ou écriture) de 16 bits.
- 8 cycles "" la même chose en 32 bits sans overhead.

Sur le 6280, j'ai du mal à évaluer cette efficacité optimale. Mais je pense que ça doit être du style :
- 2 cycles pour une opération 8 bits simple.
- 3 cycles pour un transfert mémoire 8 bits.
- des pénalités de 2/3 pour les mêmes opérations en 16 bits (8 bits x 2 + pénalité).

Et c'est là que tu vois l'avantage du 68000, car idéalement, dans un programme optimisé de manière optimale ce sont les chiffres qui vont ressortir. Les branchements ne seront que "des constantes" à côté.

Voilà, tu penses 68K, j'ai pas de pénalité, que je travaille sur 8 ou sur 16 bit, c'est pas comme sur 68K
un octet prend 4/5 cycles, un mot 8/10 cycles (selon la mémoire concernée).
tu parles de 4/8 cycles, mais c'est une fois que tes données sont chargées, ça fait combien en plus pour les mettre en mémoire ???
Et ne me dit pas que ca compte pas, c'est faux, faut bien les charger pour les transferer .
Si je compte l'init un 32 bit c'est 32/40 cycles (lecture ram,ecriture ram), ou 37 constants, peu importe la mémoire avec les transferts de blocs, donc je prends un truc simple, prends le même cas que moi,et comptes l'init ..
On charge 32 bit d'un emplacement mémoire et on le met à un autre endroit, pas un transfert d'un truc déjà chargé ..

Les IRQ c'est juste négligeable à côté du reste...

Négligeables ???
bah quand tu sais que le 68K te bouffe 64 cycles pour prendre en compte une irq, rien que pour le vblank c'est 60x64 cycles de bouffé ..

Amuse toi à faire des effets hsync et c'est encore 64 cycles par interrupt(c'est presque 10x moins sur le 6280) .
heureusement que sega a mis des tables de scroll en vram pour palier au problème ..
Et là aussi dans la grande majorité des cas le 6280 sera plus efficace, car je suppose que pour un parallaxe tu dois faire scroller toutes les lignes de ce parallaxe non,donc modifier la table des lignes concernées en VRAM ??

Les interruptions pour le son si tu veux faire des digits,c'est pas négligeable tout ça,ça commence à compter ..
Mais bon tu peux demander à d'autre codeurs 65x ,tu verras ..
le 68K prend l'avantage des que tu veux faire du langage de haut niveau, là oui les 65x ne seront pas efficaces .

par Stef Mar 22 Oct 2013 - 0:15

Je vais faire une réponse courte car on a déjà noirci un bon paquet de page de forum avec ça :p
Par shift variable je voulais dire une instruction genre A << 7 voire A << X (les 2 instructions existent sur 68000).
Pour les IRQ, c'est 60 cycles le couple IRQ plus retour donc 60x60 cycles / seconde c'est rien, même avec l'interruption horizontale sur chaque scanline ça fait environ 10% du temps CPU, ce n'est pas négligeable certes mais ça reste faible sur la totalité... Et pour les tables, tu as un scrolling par "tile" sur MD, afin de t'éviter de mettre à jour chaque ligne. Mais dans le genre le HDMA de la SNES est plus flexible et pratique, il faut le reconnaitre.
Interruption du son pour les voix digits, haha tu te crois sur PCE, sur MD tu passes par le Z80 pour ça.

Enfin bon, la meilleur démonstration ça sera encore d'essayer et de voir ce que ça donne, c'est beau de donner des chiffres mais faut voir la pratique, si c possible :)

par Invité Mar 22 Oct 2013 - 0:23

c'est magique.

tu fais un post sur la MD tu finis par avoir un match Stef VS Touko

tu fais un post SNES tu finis par avoir un match Stef VS Touko

MAIS MIEUX : tu fais un post SGX et là ... tu finis par avoir un match Stef VS Touko

ENCORE LES GARS, C'EST ULTIMATE :)

par Invité Mar 22 Oct 2013 - 0:26

Reste l'Amiga et l'Atari ST, là aussi ils peuvent te faire un match Mr. Green

par **philip** Mar 22 Oct 2013 - 0:53

@Touko. Combien de palette pour la sgx, 1x512 ou 2x512 couleurs ?

PS: le système arcade du jeu toki ayant 1024 couleurs...

par Invité Mar 22 Oct 2013 - 0:57

Pareil que sur PCE 32 palettes, soit 481 couleurs affichables/512 ..
LA puce qui gére les couleurs est à part, elle est commune aux 2 VDC ..

Et pour les tables, tu as un scrolling par "tile" sur MD, afin de t'éviter de mettre à jour chaque ligne. Mais dans le genre le HDMA de la SNES est plus flexible et pratique, il faut le reconnaitre.

Comme d'hab j'adore ta façon de jouer sur les chiffres,pour prendre des exemples qui t'arrange ..
C'est bien / tiles, mais elles font 8 pixels, c'est vachement utile si ton parallaxe a un nombre de lignes non multiple de 8 ..
Conclusion tu passeras au scroll / ligne ..

par **philip** Mar 22 Oct 2013 - 1:02

Ah ok, je comprend mieux.

par Stef Mar 22 Oct 2013 - 10:05

TOUKO a écrit:Pareil que sur PCE 32 palettes, soit 481 couleurs affichables/512 ..
LA puce qui gére les couleurs est à part, elle est commune aux 2 VDC ..
Et pour les tables, tu as un scrolling par "tile" sur MD, afin de t'éviter de mettre à jour chaque ligne. Mais dans le genre le HDMA de la SNES est plus flexible et pratique, il faut le reconnaitre.
Comme d'hab j'adore ta façon de jouer sur les chiffres,pour prendre des exemples qui t'arrange ..
C'est bien / tiles, mais elles font 8 pixels, c'est vachement utile si ton parallaxe a un nombre de lignes non multiple de 8 ..
Conclusion tu passeras au scroll / ligne ..

Heu certes, le fait est que si tu as un scroll par tile, autant t'en servir non ? donc par simplicité tu vas aligner ton parallaxe sur 8 pixels. Si tu veux vraiment un parallaxe particulier 5/3 ou je ne sais quoi, oui tu repasses sur la ligne, et c'est également pourquoi je disais que le HDMA est très pratique pour ça (ou tu utilises l'interruption H que tu peux régler comme tu veux).

par Invité Mar 22 Oct 2013 - 10:48

J'ai fais quelques tests vite fait, donc 0 optimisation .

je transfère 5 x 3ko, soit 5 persos à l'écran en 64x96 pixels, CAD les dimensions de ceux de la borne.
j'en suis à 50% de CPU /frame(30 fps pour les anims), sachant que c'est du brut, que je transfère même des choses inutiles.
La majorité des ennemis actualisent seulement 1/3 des 3ko voire moins .

Donc c'est parfaitement faisable ... Very Happy

par **philip** Mar 22 Oct 2013 - 12:40

C'est bien avec 5 personnages, mais avec sept c'est mieux. Wink

par Invité Mar 22 Oct 2013 - 13:15

Ouai et avec 10 encore mieux ..
C'est juste un test rapide, pour faire un truc optimum faut passer du temps, et j'en ai pas pour le moment .
Tu crois quand même pas que FF MCD, y'a 0 optimisation non ?? Mr. Green

Elle raffraichi pas tout en totalité non plus .

par **philip** Mar 22 Oct 2013 - 13:29

Pour un beat them all, jouer à deux c'est super fun, donc les deux personnages joueurs + 5 pas beau.

PS: je m'exprime en tant que joueur. Wink

par Invité Mar 22 Oct 2013 - 13:33

lol, oui ok ...
Je pense que c'est faisable, avec les optimisations, et surtout éviter de transférer + que nécessaire .
Car pour le reste un beat c'est pas un shoot, y'a pas 50.000 collisions à gérer, aucun effet dans le décors etc ...

Et je vois que dans FF, bcp d'ennemis raffraichissent peu de choses en fait, juste les pieds pour la marche, le bras lors d'un coup, etc ..
Mais tout ça se réfléchi .

par kawickboy Mar 22 Oct 2013 - 13:34

ff mega-cd ce n'était pas une team capcom+sega, comme pour street fighter 2' ?

par Stef Mar 22 Oct 2013 - 13:44

FF CD c'est juste Sega, Street Fighter 2 c'est juste Capcom. En fait Sega avait commencé à faire son propre portage de SF2 mais Capcom a insisté pour que ce soit leur équipe qui s'en occupe (et au final je ne suis pas sur que ça soit une bonne chose vu le résultat).

par **philip** Mar 22 Oct 2013 - 13:45

TOUKO a écrit:lol, oui ok ...
Je pense que c'est faisable, avec les optimisations, et surtout éviter de transférer + que nécessaire .
Car pour le reste un beat c'est pas un shoot, y'a pas 50.000 collisions à gérer, aucun effet dans le décors etc ...

Il y a des pauses dans le scrolling lorsqu'il y a une grosse arrivée de brutes, tu peux afficher certaines de ces brutes en tiles, puis les remplacer en sprites au fur et à mesure de l'évolution des combats. Pour le chef du gang, souvent le plus grand, tu peux le faire tout en tiles sur le scroll A (décors = scroll B).

par Stef Mar 22 Oct 2013 - 13:50

TOUKO a écrit:J'ai fais quelques tests vite fait, donc 0 optimisation .

je transfère 5 x 3ko, soit 5 persos à l'écran en 64x96 pixels, CAD les dimensions de ceux de la borne.
j'en suis à 50% de CPU /frame(30 fps pour les anims), sachant que c'est du brut, que je transfère même des choses inutiles.
La majorité des ennemis actualisent seulement 1/3 des 3ko voire moins .

Donc c'est parfaitement faisable ...

50% juste pour le transfert, c'est beaucoup je trouve car j'imagine que tes sprites ne sont pas compressés donc c'est juste le transfert brut ?
Cela dit c'est déjà énorme comme quantité de transfert, sur MD c'est la limite de ce que tu peux transférer en VBlank à pleine vitesse (et effectivement FF CD doit être proche de ce chiffre mais uniquement dans le pire des cas). Pour te donner un chiffre, en comparaison sur MD ça ne consomme que le VBlank pour le transfert uniquement et donc environ 15% du temps CPU alors que tu es déjà à 50%.

par kawickboy Mar 22 Oct 2013 - 13:51

super sf2 c'est capcom tout seul mais pour sf2' il y a eu collaboration des 2, au moins 2 mags en avaient parlé à l'époque. sega jouait gros sur ce titre et franchement le résultat est bon, y compris en 50hz. ça n'empêche pas le turbo de la snes d'être excellent. par contre sur nec capcom n'est pas intervenu je crois.

mais le ff, j'ai arrêté d'y jouer régulièrement quand la version 360 (dispo en compil physique) avec 16/9 natif est sortie.

par Stef Mar 22 Oct 2013 - 14:00

philip a écrit:
TOUKO a écrit:lol, oui ok ...
Je pense que c'est faisable, avec les optimisations, et surtout éviter de transférer + que nécessaire .
Car pour le reste un beat c'est pas un shoot, y'a pas 50.000 collisions à gérer, aucun effet dans le décors etc ...
Il y a des pauses dans le scrolling lorsqu'il y a une grosse arrivée de brutes, tu peux afficher certaines de ces brutes en tiles, puis les remplacer en sprites au fur et à mesure de l'évolution des combats. Pour le chef du gang, souvent le plus grand, tu peux le faire tout en tiles sur le scroll A (décors = scroll B).

C'est vrai que le scrolling est fixe lors du combat avec le boss donc tu pourrais éventuellement utiliser le scroll A mais si ça tient dans les sprites (sans clignotements) ça ne présente pas beaucoup d'avantage car ce qui va te couter cher ça serait toujours la mise à jour des tiles, chose que tu ne peux pas cacher, même avec 64ko de vram dédié à un seul plan (comme on pourrait le faire avec la SGX) tu ne pourras pas tout faire rentrer, ça consomme énormement les animations de sprite dans ce genre de jeu. Pour donner une idée, il suffit de prendre l'image qui contient les animations d'axel (dans le topic SOR2 vs FF3) et de l'enregistrer en BMP (4bpp): 580 ko environ, en virant les espaces vides tu descends peut etre à 500 ko mais ca reste bien trop pour tenir en VRAM. Au mieux tu stockes quelques animations mais pas tous, donc l'interet est limité.

par Stef Mar 22 Oct 2013 - 14:03

kawickboy a écrit:super sf2 c'est capcom tout seul mais pour sf2' il y a eu collaboration des 2, au moins 2 mags en avaient parlé à l'époque. sega jouait gros sur ce titre et franchement le résultat est bon, y compris en 50hz. ça n'empêche pas le turbo de la snes d'être excellent. par contre sur nec capcom n'est pas intervenu je crois.

mais le ff, j'ai arrêté d'y jouer régulièrement quand la version 360 (dispo en compil physique) avec 16/9 natif est sortie.

Pour SF2' en fait Sega et Capcom ont travaillé dessus en effet, mais chacun sur leur propre version du jeu. Si tu cherches sur internet il existe un SF2 beta qui est la version initialement commencé par Sega. Tu verras qu'il y a beaucoup de différences avec la version de Capcom, qui montrent que les 2 jeux sont différents (SF2 beta n'est pas une pré version du SF2' que l'on connait aujourd'hui).

par Invité Mar 22 Oct 2013 - 14:10

Il y a des pauses dans le scrolling lorsqu'il y a une grosse arrivée de brutes, tu peux afficher certaines de ces brutes en tiles, puis les remplacer en sprites au fur et à mesure de l'évolution des combats. Pour le chef du gang, souvent le plus grand, tu peux le faire tout en tiles sur le scroll A (décors = scroll B).

C'est pas un problème du nombre de sprite, mais le montant à transférer, que ce soit des tiles ou des sprtites la taille à transférer reste la même Wink

50% juste pour le transfert, c'est beaucoup je trouve car j'imagine que tes sprites ne sont pas compressés donc c'est juste le transfert brut ?
Cela dit c'est déjà énorme comme quantité de transfert, sur MD c'est la limite de ce que tu peux transférer en VBlank à pleine vitesse (et effectivement FF CD doit être proche de ce chiffre mais uniquement dans le pire des cas). Pour te donner un chiffre, en comparaison sur MD ça ne consomme que le VBlank pour le transfert uniquement et donc environ 15% du temps CPU alors que tu es déjà à 50%.

Bah moi pas, 50% parait certe bcp, mais je transfère sans rien optimiser aussi ..
Mais c'est bizare que tu ais le temps de tout transférer en plein vblank, même avec le DMA .
C'est short le vblank, et ton DMA fait du 7ko/s il me semble ..
Après sur MD comme les persos semblent n'être qu'en 8 couleurs, les devs ont peut être joué sur les BP pour reduire le transfert .

Oui, pour éviter la compression, l'utilisation de l'AC sera peut être nécessaire .

500 ko, pour la version arcade, parce que je doute que le version MCD dispose de tout les patterns d'anim de l'arcade .
Rien que sur la marche de guy tu peux le voir .

Edit: j'ai le rip d'axel en arcade c'est 56 ko avec bcp d'espace inutile ..

par airdream Mar 22 Oct 2013 - 14:14

La collaboration sega/capcom aurait ete benefique pour le jeu car capcom semblait mal connaitre les astuces utiles a la MD (voix digitalise) mais le probleme de sega hors sonic team, est pzut etre leurs faible perfectionnisme qui fait defaut sur beaucoup de titre.
la version Beta de sf2 est bien moins reussi a mon sens, heureusement que capcom a donc propose sa version.

par shubibiman Mar 22 Oct 2013 - 14:16

par kawickboy Mar 22 Oct 2013 - 14:19

comment ils ont pu louper des bouts de gameplay comme certaines priorités ou certains combos ?

par Stef Mar 22 Oct 2013 - 14:28

airdream a écrit:La collaboration sega/capcom aurait ete benefique pour le jeu car capcom semblait mal connaitre les astuces utiles a la MD (voix digitalise) mais le probleme de sega hors sonic team, est pzut etre leurs faible perfectionnisme qui fait defaut sur beaucoup de titre.
la version Beta de sf2 est bien moins reussi a mon sens, heureusement que capcom a donc propose sa version.

Ben pour les voix digits on peut dire que SF2 c'est clairement pas une réussite sur MD Confused

Et la beta n'est pas si inférieure alors qu'il s'agit d'une version beta. La version actuelle est globalement bonne, sauf sur un point, les voix digits, et là dessus la beta faisait mieux (mais avec un drivers simple canal).

par kawickboy Mar 22 Oct 2013 - 14:32

les digits sur md ou nec, c'est clair que l'on n'y joue pas pour ça. sur md je retrouve le gameplay le plus proche de l'arcade, les différents niveaux de vitesse... nec je reste impressionné par la qualité des sprites, les plus fins des 3 versions.

par Stef Mar 22 Oct 2013 - 14:42

Bah moi pas, 50% parait certe bcp, mais je transfère sans rien optimiser aussi ..
Mais c'est bizare que tu ais le temps de tout transférer en plein vblank, même avec le DMA .
C'est short le vblank, et ton DMA fait du 7ko/s il me semble ..

Ben il te suffit de compter, ça rentre juste mais ça rentre :
5x3=15 ko à 30 FPS soit 7.5ko à 60 FPS (et donc 7.5ko par frame).
Sur MD (NTSC) tu as 38 lignes de blank, c'est faible certes mais le DMA te permet de transférer 206 bytes / ligne. Tu fais le calcul : 38*206 = 7.8 ko.
Sur une MD PAL tu aurais plus du double car tu as 88 lignes de blank mais ici on considère le NTSC car c'est le cas le plus difficile Wink

De manière réaliste, tu ne peux pas t'amuser à consommer autant à chaque frame rien que pour les tiles des sprites, car y'a aussi le tilemap à mettre à jour parfois. Disons qu'il te faut quelques frame à 80% de charge en tile voire moins pour te laisser le temps de mettre à jour le reste. Et si tu y arrives, tu as tout le CPU dispo sur le reste de la frame, ce qui te laisse beaucoup de temps pour faire les traitements et la décompression par exemple (qui consomme beaucoup de temps CPU !).

Après sur MD comme les persos semblent n'être qu'en 8 couleurs, les devs ont peut être joué sur les BP pour reduire le transfert .

Ca ne joue pas ça, tu transferts toujours des tiles en 16 coulerus en VRAM, le VDP ne sait gérer que ça.

Oui, pour éviter la compression, l'utilisation de l'AC sera peut être nécessaire .
500 ko, pour la version arcade, parce que je doute que le version MCD dispose de tout les patterns d'anim de l'arcade .
Rien que sur la marche de guy tu peux le voir .

Ah oui si tu te passe de décompression alors là effectivement tu pourras animer tes sprites à vitesse réelle mais tu vas être confronté à une autre problème, comment tu vas stocker tes tiles en mémoire centrale de l'AC ? sur Mega CD tu as 768 ko, c'est beaucoup mais ça marche car tout est compressé sinon ça serait impossible. Et il est impensable de streamer à la volée depuis le CD ! Il me semble que l'AC n'a "que" 256 ko de mémoire centrale, ça me parait un peu juste pour stocker les animations de tout les persos niveau en plus du niveau même compressés (ou alors faudra plus de phase de loading).

Sinon je te garantis que la version MegaCD reprends les mêmes anims que l'arcade, au moins pour les persos principaux (les ennemis c'est plus difficiles à dire). La marche de Guy est *identique*, Fait une comparaison frame à frame avec un bon émulateur et tu verras bien.

Edit: j'ai le rip d'axel en arcade c'est 56 ko avec bcp d'espace inutile ..

axel ? en arcade ? de quoi tu parles ? et là je pense que tu parles de la version compressée.