Re: MEGADRIVE vs SUPER NINTENDO : Fight !

[Dagnirendae]

Contra III à 2 il rame grave à certain passage, je ne pense pas que ce soit le cas sur la version MD (je ne l'ai pas) qui en met pourtant plein l'écran.

Donc en gros tu n'as jamais testé Contra sur MD, mais d'après ton petit doigt il est forcément mieux que celui sur SNES ?   

Ne me fait pas dire ce que je n'ai pas dit (ou écrit en l'occurrence).

[Maskass]

Contra III à 2 il rame grave à certain passage, je ne pense pas que ce soit le cas sur la version MD (je ne l'ai pas) qui en met pourtant plein l'écran.

Donc en gros tu n'as jamais testé Contra sur MD, mais d'après ton petit doigt il est forcément mieux que celui sur SNES ?   

Ne me fait pas dire ce que je n'ai pas dit (ou écrit en l'occurrence).

J'interprète peut-être mal ta phrase, mais quand d'un côté du dis que sur SNES ça rame grave, et que ce n'est sans doute pas le cas sur MD (bien que tu ne l'aies pas testé) alors qu'il en met quand même plein l'écran, il y a pas loin à penser que tu estimes celui sur MD bien mieux que celui sur SNES.   

[Dagnirendae]

Contra III à 2 il rame grave à certain passage, je ne pense pas que ce soit le cas sur la version MD (je ne l'ai pas) qui en met pourtant plein l'écran.

Donc en gros tu n'as jamais testé Contra sur MD, mais d'après ton petit doigt il est forcément mieux que celui sur SNES ?   

Ne me fait pas dire ce que je n'ai pas dit (ou écrit en l'occurrence).

J'interprète peut-être mal ta phrase, mais quand d'un côté du dis que sur SNES ça rame grave, et que ce n'est sans doute pas le cas sur MD (bien que tu ne l'aies pas testé) alors qu'il en met quand même plein l'écran, il y a pas loin à penser que tu estimes celui sur MD bien mieux que celui sur SNES.   

Contra sur Snes fait parti de mon top 3 de la console, je doute que je préfère l'opus MD, neanmmoins, sur la version Nintendo, ça rame grave sur certain passage et je doute que la version Sega ait se genre de ralentissements inhérents au CPU asthmatique de la snes.

[ace76]

As-tu simplement vérifier les jeux que je viens de citer ?

Claymates et bipbip ?

Bipbip?tu parles de road runner? C'est joli comme tout,ca speed un peu,mais a mille lieues de Sonic.
Claymates ca va un peu plus vite,voire vite mais y' a pas grand chose a afficher.

[wiiwii007]

Donc en gros, Sonic c'est magnifique (Mouai)et ça speed à deux milles et sur Snes c'est ou jolie mais ça speed pas, ou c'est laid mais ça speed... Mmmmhh Mauvaise fois ?

Allez je vais dire que je n'ai rien vu marqué...  

[ace76]

oui, c'est tout a fait ca !

[lessthantod]

Sur SNES tu as TWINBEE RAINBOW BELL ADVENTURE qui est bien speed!  



Sinon je suis complètement d'accord sur le fait que SONIC est infaisable sur SNES ... tout comme plein de jeux SNES seraient infaisables sur MD!

[Dagnirendae]

Il a l'air vraiment très sympa ce twinbee !!

[lessthantod]

Ha ça pour sur, lui et LOONEY TUNES sont bien les 2 seuls jeux "speed" de la SNES qui puisse "un peu" concurrencer les SONIC de la MD ... CLAYMATES et ROAD RUNNER sont eux sacrément mauvais!

[Invité]

Quand bien même tu mesurerais le mips de la SNES tu serais en dessous de celui du 68000, faut pas oublier que sur SNES tu as beaucoup de wait state (accés ram, passage en 16 bits).
Ensuite un mips 6502 vaut environ 0.3 mips 68000 donc bon... calcul facile 

Oui d'ailleurs cette norme s'appelle la norme fanboy  

[TotOOntHeMooN]

Le 6502 c'était un super 6800 (mais pas 68000).
Il a en gros les perf d'un Z80, donc faut arrêter à un moment.

[philip]

Sur SNES tu as TWINBEE RAINBOW BELL ADVENTURE qui est bien speed!  



Sinon je suis complètement d'accord sur le fait que SONIC est infaisable sur SNES ... tout comme plein de jeux SNES seraient infaisables sur MD!

Des jeux SNES infaisables sur MD, mais avec ou sans DSP ?

[ace76]

Le 6502 c'était un super 6800 (mais pas 68000).
Il a en gros les perf d'un Z80, donc faut arrêter à un moment.

Merci de rectifier.

[lessthantod]

Sur SNES tu as TWINBEE RAINBOW BELL ADVENTURE qui est bien speed!  



Sinon je suis complètement d'accord sur le fait que SONIC est infaisable sur SNES ... tout comme plein de jeux SNES seraient infaisables sur MD!

Des jeux SNES infaisables sur MD, mais avec ou sans DSP ?

Le mode 7, le nombre de couleurs affichables, et la qualité sonore des jeux SNES ne peuvent pas être reproduits sur MD ... tout comme les jeux les plus pêchus/speed de la MD ne peuvent pas être portés sur SNES.

[Invité]

Le 6502 c'était un super 6800 (mais pas 68000).
Il a en gros les perf d'un Z80, donc faut arrêter à un moment.

En gros alors, car il a les perfs d'un Z80 mais avec une fréquence x4 ..
Mais bon venant d'un pro CPC, ça ne m'étonne pas . 

[fanoplusplus64K]

C'est bien beau les mips et les mhz mais c'est pas très concret.Ne pas oublier la largeur du bus et de l'Alu du 68K, le nombre de registres aussi ce qui fait moins accéder à la mémoire.Sans compter les instructions qui sont surement plus lentes mais sont souvent l'équivalent de plusieurs autres du hu6280.
Enfin, je passerai aussi sur l'adressage 8bits du hu6280.Je crache pas dessus et je pense qu'il est super bien adapté à une machine comme la PCE.
De manière plus concrète, je serai curieux de voir les performances d'un bout de code équivalent sur les deux procs , genre intensivement utilisés dans un jeu vidéo, par exemple un test de collision abox/abox ou même point/abox, codé de part et d'autre par deux programmeurs maîtrisant respectivement le 68K et le Hu6280, ça aurait quand même une autre gueule que de comparer les mips et les mhz.
Pour info, le rapport 6502/Z80 fréquence d'horloge à performance "égale" est censé un peu supérieur à 2.Encore une fois la fréquence est encore un argument sans intérêt car les architectures sont différentes.

[Invité]

On est d'accord fano, je parle pour une console de jeu 8/16 bit, et seulement là .
Le rapport de 4, qui me paraissait quand même exagéré je l'ai lu lors de recherche Z80 vs 6502 sur plusieurs sites différents ..
je sais que les 65xx ont des instructions pipelinées, ces CPU sont souvent donnés pour 1 cycle en écriture/lecture ..
Chaque CPU à ses atouts et ses faiblesses, je sais que les 65xx ont pour seul objectifs un rapport cycles/fréquence le plus élevé possible, et seulement ça ..
donc si ton objectif c'est ça alors c'est le bon CPU, si c'est faire du C ou de l'assembleur sans te prendre la tête alors oui le Z80/68000 seraient surement le bon choix ..
Mais dire que l'ASM 65xx c'est dur alors que sur Z80/68000 c'est trop simple, là c'est du n'importe quoi.

bcp aussi assimilent 6502 au seul et unique CPU du C64 @0.98 mhz comme référence .

De manière plus concrète, je serai curieux de voir les performances d'un bout de code équivalent sur les deux procs , genre intensivement utilisés dans un jeu vidéo, par exemple un test de collision abox/abox ou même point/abox, codé de part et d'autre par deux programmeurs maîtrisant respectivement le 68K et le Hu6280,

entièrement d'accord avec toi, un code générique, pour une tache générique, avec aucun partie prix ..
Un simple test entre 2 sprites via bouncing box, actuellement j'en suis à 100 cycles max pour une détection de collision sur 16 bit entre 2 sprites .

[fanoplusplus64K]

En étant un petit peu rationnel, je pense qu'on peut en discuter avec plaisir pendant des heures.Je dois avouer que hu6280 et le 6502 me perturbent un peu dans l'approche mais je peux comprendre l'inverse pour quelqu'un habitué à une autre architecture.Je serai tenté de penser, mais je peux me tromper, que ces processeurs sont plus pratiques pour les compilateurs C.
Après , il faut reconnaître que le 68K est super bien foutu (ceux qui ont codé sur x86 en 16 bits en savent quelque chose), rien à voir avec le Z80 ou le 6502.

Euh , sinon j'adore la SNES et la MD pour des raisons bien différentes, autant techniquement que par leur ludothèque.Que choisir entre super g'n'g et Contra hard corps , hein ? lol

[Invité]

je peux comprendre, je sais que tu es Z80, et que l'approche 65xx qui consiste à faire des écriture/lecture avec la ram, la zero page pour être précis, peu sembler bizarre et forcement moins performante que d'utiliser des registres .
C'est vrai, mais en ce qui concerne cette archi ce n'est pas pénalisant du tout contrairement au Z80 ou au 68k, où il faut garder les variables dans les registres le plus longtemps possible ..
Je ne dis pas non plus que sur 65xx j'ai des érections sur le fait de n'avoir que 3 registres, 2 de plus serait pas de refus .

Je serai tenté de penser, mais je peux me tromper, que ces processeurs sont plus pratiques pour les compilateurs C.

C'est le cas, du fait de leur petit nombre de registres + gestion de la pile, les 65xx ne sont pas fait pour ça, et montrent leur limite pour ces langages de haut niveau .

De plus le 6280, est un custom de 65C02, donc bien meilleurs que le 6502  .

Euh , sinon j'adore la SNES et la MD pour des raisons bien différentes, autant techniquement que par leur ludothèque.Que choisir entre super g'n'g et Contra hard corps , hein ? lol

Bien sur   
Moi mon choix est fait c'est RTYPE remake sur CPC  

[Stef]

@fanoplusplus64k> T'es l'auteur du remake de R-Type CPC ?? Si c'est le cas félicitation ! J'ai vu ton travail à une RGC (je ne sais plus laquelle) et c'était vraiment impressionnant. 

Sinon concernant cette phrase :

De manière plus concrète, je serai curieux de voir les performances d'un bout de code équivalent sur les deux procs , genre intensivement utilisés dans un jeu vidéo, par exemple un test de collision abox/abox ou même point/abox, codé de part et d'autre par deux programmeurs maîtrisant respectivement le 68K et le Hu6280, ça aurait quand même une autre gueule que de comparer les mips et les mhz.

C'est exactement ce que j'ai dis et même proposé plusieurs fois à Touko :
Il me donne un morceau de code particulièrement optimisé pour le 6280 et je le converti pour le 68000 (sachant que je ne suis pas un guru du 68000). Ensuite on peut faire l'inverse mais là on peut trouver plein de cas ou le 68000 sera bien plus performant (copie de donnée, operations 16 bits ou 32 bits, multiplication / division...) et Touko va dire que c'est de la triche
Le but est bien évidement de considérer un morceau de code qu'on répète X fois car ce qui consomme dans un jeu : des petites portions de code mais qu'on doit executer un grand nombre de fois (comme le test de collision).

[Invité]

C'est exactement ce que j'ai dis et même proposé plusieurs fois à Touko :
Il me donne un morceau de code particulièrement optimisé pour le 6280 et je le converti pour le 68000 (sachant que je ne suis pas un guru du 68000). Ensuite on peut faire l'inverse mais là on peut trouver plein de cas ou le 68000 sera bien plus performant (copie de donnée, operations 16 bits ou 32 bits, multiplication / division...) et Touko va dire que c'est de la triche
Le but est bien évidement de considérer un morceau de code qu'on répète X fois car ce qui consomme dans un jeu : des petites portions de code mais qu'on doit executer un grand nombre de fois (comme le test de collision).

 
T'es ultra gonflé quand même, en qu'elle année tu m'as proposé ça ???
Mais de toutes façons,j'ai l'habitude avec toi, moi je suis gentil c'est les autres qui sont méchants, je connais ce refrain que trop bien ..

Ensuite on peut faire l'inverse mais là on peut trouver plein de cas ou le 68000 sera bien plus performant (copie de donnée, operations 16 bits ou 32 bits, multiplication / division...

Des fois stef, je me demande si tu as déjà programmé un jeu ..
Opérations sur 32 bit, div/mul n'importe quoi, même les ops sur 16 bit sont pas si fréquentes, et là aussi je pourrais te montrer que dans la majorité des cas le 6280 serra plus rapide ..
Mais comme d'hab tu squizes 90% des taches dans un jeu qui consiste à modifier des variables notamment 8 bit, des tests, des branchements, appels de fonctions, gestion d'interruptions, soit que des domaines ou le 68K est un veau .
Donc je compare sur un domaine que je connais, les jeux 2D, rien de plus .

[fanoplusplus64K]

@fanoplusplus64k> T'es l'auteur du remake de R-Type CPC ?? Si c'est le cas félicitation ! J'ai vu ton travail à une RGC (je ne sais plus laquelle) et c'était vraiment impressionnant.

Euh merci pour nous
Ton pseudo me dit quelque chose , on avait pas discutaillé asm 68K ?

[Stef]

T'es ultra gonflé quand même, en qu'elle année tu m'as proposé ça ???
Mais de toutes façons,j'ai l'habitude avec toi, moi je suis gentil c'est les autres qui sont méchants, je connais ce refrain que trop bien ..

Non mais tu plaisantes O_o ??? Je te l'ai proposé 2 ou 3 fois lors de nos précédents débats 68000 vs 6280 :p A chaque fois tu éludais ou me répondais que tu n'avais pas d'exemples en tête...

Des fois stef, je me demande si tu as déjà programmé un jeu ..
Opérations sur 32 bit, div/mul n'importe quoi, même les ops sur 16 bit sont pas si fréquentes, et là aussi je pourrais te montrer que dans la majorité des cas le 6280 serra plus rapide ..
Mais comme d'hab tu squizes 90% des taches dans un jeu qui consiste à modifier des variables notamment 8 bit, des tests, des branchements, appels de fonctions, gestion d'interruptions, soit que des domaines ou le 68K est un veau .
Donc je compare sur un domaine que je connais, les jeux 2D, rien de plus .

Haha j'en étais sur "ouin c'est de la triche"... j'avais bien raison  
90% du temps se passe dans 10% du code, et dans un shoot typiquement les collisions c'est ce qui use, donc libre à toi de poster un exemple très optimisé pour ton 6280 pour de la collide box (avec des jump etc...) et moi j'essai de faire un code équivalent 68000.
Même pas peur   Tu pourras pas dire que je ne te laisse pas le choix...
Ah et puis, c'est sur que la simple copie de données, on en utilise pas beaucoup dans un jeu ^^

[Invité]

90% du temps se passe dans 10% du code, et dans un shoot typiquement les collisions c'est ce qui use,

Quoi tu utilises des div/mul dans les tests de collisions toi ??? 

donc libre à toi de poster un exemple très optimisé pour ton 6280 pour de la collide box (avec des jump etc...) et moi j'essai de faire un code équivalent 68000.

Pas de soucis ..

Haha j'en étais sur "ouin c'est de la triche"... j'avais bien raison  

t'as fumé ou quoi ??, je sais que tu as l'habitude de sortir des cas improbable pour avoir raison, les opérations sur 32 bit, les Mul/div en sont un exemple flagrant .
Vachement utiles dans un jeu .

[Stef]

@fanoplusplus64k> T'es l'auteur du remake de R-Type CPC ?? Si c'est le cas félicitation ! J'ai vu ton travail à une RGC (je ne sais plus laquelle) et c'était vraiment impressionnant.

Euh merci pour nous
Ton pseudo me dit quelque chose , on avait pas discutaillé asm 68K ?

Vous ? vous êtes plusieurs sur ce projet ?
On avait du discuté un peu mais très rapidement, je voulais repasser le lendemain (dimanche) pour discuter un peu plus mais j'ai du partir plus tot que prévu.

[Invité]

y'a aussi totoonthemoon présent ici, qui à retouché les grafs .

[Stef]

90% du temps se passe dans 10% du code, et dans un shoot typiquement les collisions c'est ce qui use,

Quoi tu utilises des div/mul dans les tests de collisions toi ??? 

Mais non... à la base je disais ça car je t'ai proposé de prendre un morceau de code particulièrement adapté et optimisé pour le 6502 / 6280... que je convertissais en code 68000 pour comparer. J'ai juste dit que si moi ensuite je faisais l'inverse: prendre un code adapté et optimisé pour le 68000 tu me dirais que je triche car il y a plein de cas ou le 68000 peut être beaucoup plus rapide que le 6280 (comme la multiplication / division, copie mémoire). C'est tout... tu te braques tellement que tu ne prends pas la peine de lire correctement :p

[Stef]

y'a aussi totoonthemoon présent ici, qui à retouché les grafs .

Ah ok, je ne savais pas, ben facilitations à eux 2 alors ^^ Enfin je me souviens avoir était particulièrement impressionné par le smooth scrolling qui n'est pas évident sur un CPC

[Invité]

Non j'ai jamais dis ça, mais bon un test de collisions devrait être bons pour toi ??
Moi ça l'est ..

[Stef]

Non j'ai jamais dis ça, mais bon un test de collisions devrait être bons pour toi ??
Moi ça l'est ..

Of course :)

[Invité]

C'est tout... tu te braques tellement que tu ne prends pas la peine de lire correctement :p

Paille, poutre, tout ça stef  
et on compte tout, init des registres comprise ...