Re: MEGA DRIVE vs SUPER NINTENDO : Fight !

[aminelune]

... ce qui est plaisant avec la MD c'est qu'on peut reproduire la qualité et la complexité des musiques sur un piano pour banbins!

faut etre un banbin pour qu'on puisse reproduire la musique de ma megadrive sur ce genre e piano

[Invité]

Une interruption prend 44 cycles ???
Ca tombe comme un cheveux sur le soupe mais en gros oui.

JSR (An) = 16 cycles
BSR/JSR abs.w = 18 cycles (adresse ou offset 16 bits)
JSR abs.l = 20 cycles (adresse 32 bits)

RTS = 16 cycles

donc le couple JSR/RTS c'est 34 cycles en général mais c'est directement un saut 16 bits et y'a pas d'histoire de pénalité si le saut fait plus de 128 bytes ou franchi une page :p

Sur le 6502 oui, mais pas sur le 6280 (ou même le 65c02 il me semble ) , 7 (jsr) + 7 (rts), donc même avec la pénalité sur le 6502 tu rajoutes 2 cycles, c'est très largement inférieur au 68000
Le BSR par contre est nul à chier sur les 65xx,quasi inutilisable, car il ne présente aucun avantage .

Heureusement y'a tjs des astuces qd tu as besoin de vitesse, pour les fonctions que tu appelles très souvent tu peux utiliser cette séquence :

Code:


    LEA RETURN,A0    ;Return address goes in A0. (8 cycles)
    JMP routine          ;Jump to the subroutine    (10 cycles)
RETURN          ;A0 points to this spot.
    ...


Soit 18 cycles

Tu oublies le return ??
Et ça sauvegarde pas l'état des registres, donc c'est un minimum 18 cycles ..

Et oui une interruption c'est 44 cycles car le registre SR est sauvegardé sur la pile puis modifié. Le 68000 gère un système de priorité d'interruption (8 niveaux utilisateurs + 2 niveaux systèmes)...

Ouch, 8 cycles sur 65xx

[Stef]

Sur le 6502 oui, mais pas sur le 6280 (ou même le 65c02 il me semble ) , 7 (jsr) + 7 (rts), donc même avec la pénalité sur le 6502 tu rajoutes 2 cycles, c'est très largement inférieur au 68000
Le BSR par contre est nul à chier sur les 65xx,quasi inutilisable, car il ne présente aucun avantage .

Oui je sais que pour ce genre d'instruction c'est *largement* plus rapide sur un 6502.

Code:


    LEA RETURN,A0    ;Return address goes in A0. (8 cycles)
    JMP routine          ;Jump to the subroutine    (10 cycles)
RETURN          ;A0 points to this spot.
    ...


Tu oublies le return ??
Et ça sauvegarde pas l'état des registres, donc c'est un minimum 18 cycles ..

Heu oui j'oublie le return... 8 cycles soit 26 en tout, je me disais 18 ça me paraissait peu.
Mais toi non plus ça ne sauvegarde pas les registres. La seul différence c'est que sur le 68000 plutot que de stocker l'adresse de retour sur la pile, tu peux stocker dans un registre d'adresse (A0 & A1 sont volatiles par convention donc nul besoin de les sauvegarder).

Ouch, 8 cycles sur 65xx

Oui oui je sais, mais l'interruption sur 6502 est très simple comparé à celle du 68000 :p

je trouve que ça ne sert à rien de comparé en nombre de cycle... Un 6502 ne comporte qu'environ ~3500 transistors, il est extrêmement simple comparé à un 68000 qui en comporte environ 20x plus.
En gros les instructions du 6502 correspondent aux micro instructions du 68000 (chaque instruction du 68000 est décomposée en micro instruction en interne), donc quand bien même le 6502 va plus vite pour exécuter ses instructions, il faut bien voir qu'elles sont bien moins efficace que les instructions du 68000.
Et surtout l'avantage du 68000 est qu'il ne requiert qu'un accès mémoire tout les 4 cycles, de ce fait on peut le faire monter en fréquence sans y adjoindre une mémoire trop couteuse. Au final l'efficacité et l'équilibre globale du système s'en trouve bien meilleur :) Meme si on dit qu'un 6502 n'est pas un RISC, la simplicité de ses instructions le rapproche pas mal de ce type d'architecture alors que le 68000 est un CISC jusqu'au bout de ses ongles.

Il est sur que si tu compares le ratio instruction / cycle, le 6502 est largement devant, mais ça vraiment, c'est pas le plus important :o
Vu sa fréquence (enfin quand il tourne à 7.1 Mhz) ton 6280 aura l'avantage sur les interruptions, les appels de méthode etc... mais c'est rarement ce qui représente un bottleneck dans le code d'un jeu, donc à mon sens, pas l'essentiel.

[Lesarthois]

J'aimais les salles d'arcade et je ne comprenais pas que l'on puisse se contenter d'avoir dans son salon, sans l'ambiance des salles, et contre beaucoup de sous, des consoles qui n'étaient pas au niveau, ou qui étaient orientées baston et coutaient encore plus cher.

Moi c'était l'inverse...

Comment, mais comment apprécier un jeu au milieu d'une salle bruyante et enfumée, entouré de gens qui attendaient leur tour, à mettre des pièces sans arrêt sans arrêt, tout ça pour jouer à un jeu avec 3 écrans en boucle, alors que chez soi, tranquillement devant son écran, on pouvait avoir des dizaines d'heures à jouer, gratuitement (vive le piratage de disquettes) sur des jeux avec un univers riche, une histoire travaillée, une atmosphère...

[Kulten]

Ah tiens c'est marrant ça ! Comme quoi...

[Invité]

Heu oui j'oublie le return... 8 cycles soit 26 en tout, je me disais 18 ça me paraissait peu.
Mais toi non plus ça ne sauvegarde pas les registres. La seul différence c'est que sur le 68000 plutot que de stocker l'adresse de retour sur la pile, tu peux stocker dans un registre d'adresse (A0 & A1 sont volatiles par convention donc nul besoin de les sauvegarder).

Oui moi non plus ça sauvegarde pas, je me suis un peu emporté ..

Oui oui je sais, mais l'interruption sur 6502 est très simple comparé à celle du 68000 :p

je trouve que ça ne sert à rien de comparé en nombre de cycle... Un 6502 ne comporte qu'environ ~3500 transistors, il est extrêmement simple comparé à un 68000 qui en comporte environ 20x plus.
En gros les instructions du 6502 correspondent aux micro instructions du 68000 (chaque instruction du 68000 est décomposée en micro instruction en interne), donc quand bien même le 6502 va plus vite pour exécuter ses instructions, il faut bien voir qu'elles sont bien moins efficace que les instructions du 68000.
Et surtout l'avantage du 68000 est qu'il ne requiert qu'un accès mémoire tout les 4 cycles, de ce fait on peut le faire monter en fréquence sans y adjoindre une mémoire trop couteuse. Au final l'efficacité et l'équilibre globale du système s'en trouve bien meilleur :) Meme si on dit qu'un 6502 n'est pas un RISC, la simplicité de ses instructions le rapproche pas mal de ce type d'architecture alors que le 68000 est un CISC jusqu'au bout de ses ongles.

Il est sur que si tu compares le ratio instruction / cycle, le 6502 est largement devant, mais ça vraiment, c'est pas le plus important :o
Vu sa fréquence (enfin quand il tourne à 7.1 Mhz) ton 6280 aura l'avantage sur les interruptions, les appels de méthode etc... mais c'est rarement ce qui représente un bottleneck dans le code d'un jeu, donc à mon sens, pas l'essentiel.

La simplicité de ce CPU, est ce qui fait sa force ..
Bien sur dans le cas d'une console de cette gen c'est un avantage, sur une station/serveur, le 68000 sera surement largement devant .

Le problème c'est si tu dois faire des interruptions /ligne pour un effet, pas style distorsion car il me semble que sur MD, tu as une liste pour cela (le VPC fait ça tout seul il me semble ??), mais pour d'autres effets (style au hasard jouer un sample ) ce sera super lent avec un 68000 44*256 lignes = 11264 cycles VS 2048 pour le 6280 .
Ce je veux te démontrer, c'est que sur le total d'un jeu, le 6280 fera au moins jeu égal avec la MD, et ce même si il est cadencé plus rapidement .
Car là ou la gen 65xx excelle, est très utilisé dans une console 8/16 bit, énormément même ..
Les interruptions, les sauts à des routines, les boucles,branchements conditionnels etc..., tu peux pas dire que ce soit négligeable, puisque cela compose facilement 70% d'un jeu .

C'et un goulot d'étranglement, je suis d'accord, mais tu perds énormément de cycles si on met tout ça bout à bout .

Le fait d'avoir un CPU 16 bit, ne veux absolument rien dire ce qui compte c'est le rendement instructions/cycles ..

[Invité]

J'aimais les salles d'arcade et je ne comprenais pas que l'on puisse se contenter d'avoir dans son salon, sans l'ambiance des salles, et contre beaucoup de sous, des consoles qui n'étaient pas au niveau, ou qui étaient orientées baston et coutaient encore plus cher.

Moi c'était l'inverse...

En même temps, ne le prends pas mal mais, vu ton jeune âge, tu n'as clairement pas connu l'âge d'or des salles d'arcade et/ou ce parallèle terriblement excitant/frustrant entre les sorties arcade de l'époque et leur conversions sur consoles de salon quelques mois plus tard.

[Invité]

Les joies d'un double dragon en arcade

[Invité]

Les joies d'un double dragon en arcade

Toi, je t'aime !

[Stef]

La simplicité de ce CPU, est ce qui fait sa force ..

et aussi sa faiblesse...

Le problème c'est si tu dois faire des interruptions /ligne pour un effet, pas style distorsion car il me semble que sur MD, tu as une liste pour cela (le VPC fait ça tout seul il me semble ??), mais pour d'autres effets (style au hasard jouer un sample ) ce sera super lent avec un 68000 44*256 lignes = 11264 cycles VS 2048 pour le 6280 .

Oui mais voilà, la MD intègre beaucoup de chose qui font que tu peux te passer de cette interruption horizontal, que ce soit pour la distortion (effectivement cablé si on peut dire, y'a une liste dans le VDP pour ça) et même pour jouer un sample, le Z80 est justement là pour ça.
Après tu peux toujours avoir besoin de l'interruption horizontal pour d'autre effets...
genre l'effet à la axelay ou tu reprogramme le scroll vertical par ligne, dans ce cas effectivement tu bouffes 44 * 224 cycles (et pas 256 car tu n'as pas l'interruption en vblank)... mais 44, sur les 488 cycles par scanline c'est pas non plus la cata, et il te reste tout le vblank.

Ce je veux te démontrer, c'est que sur le total d'un jeu, le 6280 fera au moins jeu égal avec la MD, et ce même si il est cadencé plus rapidement .
Car là ou la gen 65xx excelle, est très utilisé dans une console 8/16 bit, énormément même ..
Les interruptions, les sauts à des routines, les boucles,branchements conditionnels etc..., tu peux pas dire que ce soit négligeable, puisque cela compose facilement 70% d'un jeu .

Et non, je en suis pas d'accord avec ça ^^
En général il faut savoir qu'un jeu met le gros de son code logique dans le vblank, 80% des jeux ne font rien ou presque pendant la zone active. Et quand c'est le cas, ça signifie que le jeux nécessitent des calculs particulièrement lourds, genre de nombreuses collisions, des calculs physiques ou je ne sais quoi (enfin plus que de la simple logique de base) et dans ce cas si tu optimises ton code pour bien exploiter le 68000 tu arriveras à des perfs similaires ou supérieur au 6280, pour les différentes raisons que j'ai déjà cité.
En gros comme je l'ai déjà dit, pour un petit traitement découpé et isolé ok, le 6280 fera mieux mais dés que tu feras un traitement en masse, le 68000 reprendra l'avantage. Et c'est toujours le traitement en masse qui représente le goulot dans un jeu ou n'importe quoi de gourmand, dans ton code tu as toujours 10% critique qui bouffe 90% du temps CPU. C'est là que tu optimises et dans ce cas le 68000 te permettra d'aller plus loin.

[Invité]

Oui mais voilà, la MD intègre beaucoup de chose qui font que tu peux te passer de cette interruption horizontal, que ce soit pour la distortion (effectivement cablé si on peut dire, y'a une liste dans le VDP pour ça) et même pour jouer un sample, le Z80 est justement là pour ça.
Après tu peux toujours avoir besoin de l'interruption horizontal pour d'autre effets...
genre l'effet à la axelay ou tu reprogramme le scroll vertical par ligne, dans ce cas effectivement tu bouffes 44 * 224 cycles (et pas 256 car tu n'as pas l'interruption en vblank)... mais 44, sur les 488 cycles par scanline c'est pas non plus la cata, et il te reste tout le vblank.

Ouai mais j'ai pris 256 comme ref, car en réalité un plein écran c'est 240 lignes, les 16 dernières sont dans l'overscan (je pense que sur Md c'est pareil non ??) ..
Sauf si tu défini que ton image ne fait que 224 lignes .
Enfin ça marche comme ça sur PCE ..

Et non, je en suis pas d'accord avec ça ^^
En général il faut savoir qu'un jeu met le gros de son code logique dans le vblank, 80% des jeux ne font rien ou presque pendant la zone active. Et quand c'est le cas, ça signifie que le jeux nécessitent des calculs particulièrement lourds, genre de nombreuses collisions, des calculs physiques ou je ne sais quoi (enfin plus que de la simple logique de base) et dans ce cas si tu optimises ton code pour bien exploiter le 68000 tu arriveras à des perfs similaires ou supérieur au 6280, pour les différentes raisons que j'ai déjà cité.
En gros comme je l'ai déjà dit, pour un petit traitement découpé et isolé ok, le 6280 fera mieux mais dés que tu feras un traitement en masse, le 68000 reprendra l'avantage. Et c'est toujours le traitement en masse qui représente le goulot dans un jeu ou n'importe quoi de gourmand, dans ton code tu as toujours 10% critique qui bouffe 90% du temps CPU. C'est là que tu optimises et dans ce cas le 68000 te permettra d'aller plus loin.

Ca change rien, vblank ou pas tes cycles supplémentaires sont toujours là .
Et pour les traitement de masses, je vois pas en quoi le 68000 serait supérieur, un traitement c'est toujours que des saut, branchements etc, pas du calcul en virgule flottante,c'est sur si on fait du calcul de fractales ok ...
Je vois aucun jeux présent sur les 2 supports qui mette en défaut le CPU de la nec, même pas sur des jeux SEGA comme after burner 2 qui se permet le luxe d'être plus rapide sur NEC ..
Ou même sur le shoot de la sgx aldynes ou le CPU doit se coltiner 64 sprites de plus ,et toutes les collisions qui vont avec, + la gestion d'un second layer ..

Effectivement le Z80 va aider pour les samples, mais il est aussi très lent pour les accès au bus, et ne peux rien faire quand le 68000 ou le VDC accède à la ram .
De plus il me semble qu'il doit aussi faire du banc mapping pour ne pas être cantonné à seulement 32 ko, donc lent aussi .
Il permet juste de ne pas faire attendre le 68000, que le chip FM veuille bien recevoir les données .

C'est pour ça que c'est quasi impossible d'avoir des samples de qualité dans un jeu, soit c'est le CHIP FM qui est trop lent, soit le Z80 ..


A croire que les optimisations de code ne sont valables que sur le 68000, il suffit de voir ce que fait un C64 avec un 6502 @ 0.9 mhz, pour voir l'efficacité des ces CPU.
Donc non ta théorie n'est pas valable .

[Stef]

Les joies d'un double dragon en arcade

Toi, je t'aime !

Moi c'était terrible y'avait une salle d'arcade juste à côté de mon école primaire !
J'arrivais en retard tout les matins en classe à cause de ça, d'ailleurs j'aurais vraiment pu mal tourner à cause de ça X'D
Y'a de grands moments dans sa vie qu'on n'oublie pas, par exemple le jour ou j'ai découvert comment on faisait la manchette dans Double Dragon (ce qui m'a permis de finir le jeu enfin), j'avais 8 ans ^^
En fait j'ai regardé comment les autres faisaient quand ils jouaient ( ), j'aurais jamais eu l'idée à l'époque d'appuyer sur 2 boutons à la fois...

[Invité]

Bon qui n'a pas aimé DD en fait
Ce jeu m'a marqué, j'ai jamais pu retrouver les sensations de l'arcade, sauf grâce à mame .

[Stef]

Ouai mais j'ai pris 256 comme ref, car en réalité un plein écran c'est 240 lignes, les 16 dernières sont dans l'overscan (je pense que sur Md c'est pareil non ??) ..
Sauf si tu défini que ton image ne fait que 224 lignes .
Enfin ça marche comme ça sur PCE ..

C'est ce que j'entendais par vblank (ce que tu appelles overscan).
Tu n'as pas d'interruption horizontal durant l'overscan, ça n'a aucun intérêt puisque tu n'affiches plus l'image.

Ca change rien, vblank ou pas tes cycles supplémentaires sont toujours là .

Mais si, puisque pendant le vblank (overscan) tu n'as pas d'interruption horinzontale... ce que je dis c'est que la plupart des jeux font leur logique durent le vblank car c'est pendant cette période que tu peux mettre à jour els données graphiques sans perturber l'affichage.

Et pour les traitement de masses, je vois pas en quoi le 68000 serait supérieur, un traitement c'est toujours que des saut, branchements etc, pas du calcul en virgule flottante,c'est sur si on fait du calcul de fractales ok ...

Ben les traitements de masses ça peut être n'importe quoi, mais tu manipules de la donnée, quoiqu'il arrive. Et pour ça, le 68000 va être plus efficace que le 6280.
Quand bien même tu as des branchements et autres.
Comme je te l'ai dis, je veux bien te montrer par un exemple, tu me files un bout de code efficace avec le 6280 qui traite un bloc de données, je te donne la conversion en 68000 et on compare...

Je vois aucun jeux présent sur les 2 supports qui mette en défaut le CPU de la nec, même pas sur des jeux SEGA comme after burner 2 qui se permet le luxe d'être plus rapide sur NEC ..

Mais bien sur, les jeux sont tailler pour la machine, et le 6280, à 7 Mhz est tout de même très véloce, il n'est pas loin du 68000 ! Après y'a le talent des développeurs qui comptent aussi. AF2 sur MD, c'est pas vraiment une réussite...

Ou même sur le shoot de la sgx aldynes ou le CPU doit se coltiner 64 sprites de plus ,et toutes les collisions qui vont avec, + la gestion d'un second layer ..

Faut il encore que le jeux les affiches les 64 sprites en plus
Honnetement si on doit comparer le nombre de sprites (indépendant, pas de groupement) max poussé par un shoot sur les consoles de cette génération, je suis prêt à parier qu'on trouve le max sur Megadrive (bien que le VDP limite à 80).

Effectivement le Z80 va aider pour les samples, mais il est aussi très lent pour les accès au bus, et ne peux rien faire quand le 68000 ou le VDC accède à la ram .

Non non le seul moment ou le Z80 est bloqué c'est quand tu fais un DMA qui retient le BUS central (le 6800 est bloqué aussi). Ensuite le Z80 et le 68000 bosse avec un système de cycle steal. Le Z80 va accéder au BUS dés que l'instrution actual du 68000 l'a relaché. Comme la mémoire est plus rapide que le 68000, ça donne une petite pénalité mais rien de méchant... en moyenne je compte 2 cycles Z80 de pénalité sur un accés à la bank 68k et ça correspond sur le vrai hardware.

De plus il me semble qu'il doit aussi faire du banc mapping pour ne pas être cantonné à seulement 32 ko, donc lent aussi .

Bien sur le Z80 étant un CPU 8 bits il accède qu'à 64 KB de mémoire, et dans le cas de la mémoire 68000, c'est par bank de 32K (le reste étant dédié aux différents ports hardware, son, video...)
Après tout vient de ton driver, tu peux bufferiser la lecture des samples par exemple (ce que je fais). Du coup je peux mixer 4 samples PCM 8 bits à 16 Khz et ça me bouffe à peine 50% du Z80.

Il permet juste de ne pas faire attendre le 68000, que le chip FM veuille bien recevoir les données .
C'est pour ça que c'est quasi impossible d'avoir des samples de qualité dans un jeu, soit c'est le CHIP FM qui est trop lent, soit le Z80 ..

O_o ?? La principale raison des samples de mauvaise qualité sur MD est software. La MD est tout à fait capable de faire du sample de très bon qualité (et certains jeux le prouvent). Je pense que Sega aurait du travailler le SDK ou simplement mieux expliquer comment utiliser efficacement le Z80 pur jouer du PCM.

A croire que les optimisations de code ne sont valables que sur le 68000, il suffit de voir ce que fait un C64 avec un 6502 @ 0.9 mhz, pour voir l'efficacité des ces CPU.
Donc non ta théorie n'est pas valable .

Les optimisations marchent partout mais un 6502 reste un 6502, faut pas se voiler la face :p Les marges d'optimisations sur ce CPU sont moindres que sur un 68000 quoique tu en dises, t'as pas de registres, un intruction set des plus limité, ça coupe court à pas mal de choses.
Le C64 sans ses assistances hardware ne ferait pas grand chose.

[Invité]

Mais si, puisque pendant le vblank (overscan) tu n'as pas d'interruption horinzontale... ce que je dis c'est que la plupart des jeux font leur logique durent le vblank car c'est pendant cette période que tu peux mettre à jour els données graphiques sans perturber l'affichage.

Ok mais tu réagis comme si seulement les interruptions étaient en défaveur du 68000, y'a pas que ça ..
Après pour des samples de qualité faut bien se synchroniser avec quelque chose de rapide non, enfin sur PCE on utilise les HSYNC pour faire des samples de qualité supérieure ou égale à 15 khz,le timer ne suffit pas en général .

Ben les traitements de masses ça peut être n'importe quoi, mais tu manipules de la donnée, quoiqu'il arrive. Et pour ça, le 68000 va être plus efficace que le 6280.
Quand bien même tu as des branchements et autres.
Comme je te l'ai dis, je veux bien te montrer par un exemple, tu me files un bout de code efficace avec le 6280 qui traite un bloc de données, je te donne la conversion en 68000 et on compare...

J'ai rien vu de tel à part un exemple tout taillé pour le 68000 que tu as donné, et encore quand on prend tout en compte l'ecart n'est pas si important que ça, par rapport à tout ce que tu perds sur le reste

Mais bien sur, les jeux sont tailler pour la machine, et le 6280, à 7 Mhz est tout de même très véloce, il n'est pas loin du 68000 ! Après y'a le talent des développeurs qui comptent aussi. AF2 sur MD, c'est pas vraiment une réussite...

Bon mais si à chaque fois qu'un exemple n'est pas à l'avantage de la Md, c'est une version baclée, c'est quand même un jeu sega non ??

Faut il encore que le jeux les affiches les 64 sprites en plus
Honnetement si on doit comparer le nombre de sprites (indépendant, pas de groupement) max poussé par un shoot sur les consoles de cette génération, je suis prêt à parier qu'on trouve le max sur Megadrive (bien que le VDP limite à 80).

Possible quand la MD abuse de sprites rikiki à 8 pixels ..
Ca je peux pas l'enlever à la MD, sa gestion des sprites est excellente, et optimisé pour économiser le MAX de VRAM.
Ca et son DMA, je suis envieux ..

Non non le seul moment ou le Z80 est bloqué c'est quand tu fais un DMA qui retient le BUS central (le 6800 est bloqué aussi). Ensuite le Z80 et le 68000 bosse avec un système de cycle steal. Le Z80 va accéder au BUS dés que l'instrution actual du 68000 l'a relaché. Comme la mémoire est plus rapide que le 68000, ça donne une petite pénalité mais rien de méchant... en moyenne je compte 2 cycles Z80 de pénalité sur un accés à la bank 68k et ça correspond sur le vrai hardware.

Oui dans le meilleurs des monde, dans un jeu ou tu utilises un max le 68000, le z80 n'a pas énormément de marge de manoeuvre,si en plus tu prend le fait que les accès aux données sont lente..

Ce que j'au vu sur sega-16 en lisant les topic sur le sujet, c'est bien ce que je disait, la MD n'est pas faite pour les samples, et c'est un calvaire d'arriver à faire ne serai-ce que du 4 bit @16 khz dans un jeu, alors que sur PCE, c'est finger in the noze,pas besoin d'un second CPU, le petit 6280 8bit se débrouille tout seul ..

Bien sur le Z80 étant un CPU 8 bits il accède qu'à 64 KB de mémoire, et dans le cas de la mémoire 68000, c'est par bank de 32K (le reste étant dédié aux différents ports hardware, son, video...)
Après tout vient de ton driver, tu peux bufferiser la lecture des samples par exemple (ce que je fais). Du coup je peux mixer 4 samples PCM 8 bits à 16 Khz et ça me bouffe à peine 50% du Z80.

Oui en demo sans rien qui tourne autour,un traitement basique des samples ..
Des qu'il s'agit de jeu, c'est out, finish, même des gars comme chilly willy,sik,TmEE par exemple, explique très bien la difficulté de samples de la MD, même un qui dit que même le yam du ST permet de faire plus facilement des samples que le le yam FM de la MD ..
Pourtant je pense pas que ce soit des fanboys nintendo ..

Sans parler de la difficulté de se synchro avec le Z80,impossible de détecter les interruptions VDP ..

O_o ?? La principale raison des samples de mauvaise qualité sur MD est software. La MD est tout à fait capable de faire du sample de très bon qualité (et certains jeux le prouvent). Je pense que Sega aurait du travailler le SDK ou simplement mieux expliquer comment utiliser efficacement le Z80 pur jouer du PCM.

Quand la technique fait que tu peux pas, même en étant un excellent coder Z80 tu peux pas, le problème vient aussi que le z80, n'a aucun controle sur le matériel comme le VDP, les synchros pour jouer des samples sont du coup hard à gerer..

Et ça change pas le fait ,que le CHIP FM est un vaux , j'invente rien .
Donc c'est bien beau de critiquer le snes à ce niveau lol ..

Les optimisations marchent partout mais un 6502 reste un 6502, faut pas se voiler la face :p Les marges d'optimisations sur ce CPU sont moindres que sur un 68000 quoique tu en dises, t'as pas de registres, un intruction set des plus limité, ça coupe court à pas mal de choses.
Le C64 sans ses assistances hardware ne ferait pas grand chose.

Ok, le C64 à des assistances, mais c'est pas une snes non plus, la snes est largement mieux fournie niveau assistance, avec un CPU 4/5 fois plus puissant ..
Le C64 n'est pas non plus plus puissant qu'une nes ou une SMS ..
Donc imagines ce qu'un dev expérimenté ferait sur un 65816 !!!
Tout comme le 6280, et bien plus puissant que le 6502.

une quote de sik

Don't forget bank switching... And they may have added the samples and checked for overflow instead of using a look-up table, making things worse performance-wise. That, and general lack of Z80 expertise, the Z80 is much slower than it seems...

Faut pas se voiler la face, la MD est pleines de défauts de conception ,comme les autres, reste à savoir ce qui peut être contourner, et ce qui ne peut pas .

[Stef]

J'ai rien vu de tel à part un exemple tout taillé pour le 68000 que tu as donné, et encore quand on prend tout en compte l'ecart n'est pas si important que ça, par rapport à tout ce que tu perds sur le reste

Ben comme je te dis, trouve moi un exemple, vraiment... un truc bete, une detection de collision, je ne sais pas, n'importe. Je pourrais t'en trouver des exemple mais tu vas me dire que je trouve encore un exemple qui avantage le 68000.

Bon mais si à chaque fois qu'un exemple n'est pas à l'avantage de la Md, c'est une version baclée, c'est quand même un jeu sega non ??

Mais non mais il faut reconnaitre que tu prends des exemples pourris sur MD ! AF2 sorti en 1990 (plutot début la machine) et déjà à l'époque mal noté ! Bien sur que je n'utilise pas ce genre de jeux comme référence comme ce qu'on peut faire sur MD. Et oui je le dis sans problème, beaucoup de portage arcade Sega était tout simplement pourri sur MD, c'est un fait ! Je pense que c'était presque voulu pour éviter de faire concurrence à l'arcade de l'époque. Franchement bon nombre de jeux auraient pu être bien mieux réussi. Et c'est pareil sur PCE, tu n'utilises pas les jeux honteux sur la machine pour faire un comparatif (genre Altered Beast)...

Possible quand la MD abuse de sprites rikiki à 8 pixels ..
Ca je peux pas l'enlever à la MD, sa gestion des sprites est excellente, et optimisé pour économiser le MAX de VRAM.
Ca et son DMA, je suis envieux ..

Mais la taille du sprite ne change rien, s'il s'agit d'un sprite statique, qu'il soit en 8x8 ou 32x32 ça ne change strictement rien. Si on a autant de petits sprites dans les jeux MD, c'est que la console le permet ! A l'inverse de la PCE ou la SNES ou ça pose des problèmes. Ce sont justement ces petits sprites, ces petites particules d'explosions ou n'importe quoi qui rendent les jeux si "vivant" sur MD, et c'est leur manque qui rendent les jeux SNES particulièrement inertes.

Oui dans le meilleurs des monde, dans un jeu ou tu utilises un max le 68000, le z80 n'a pas énormément de marge de manoeuvre,si en plus tu prend le fait que les accès aux données sont lente..

Dans la démo BadApple j'utilise le 68000 a fond ainsi que le DMA ! C'est le pire des cas pour le Z80, pour autant le sample est joué sans grésillement alors qu'il est décompressé par le Z80 (4 bits ADPCM décompressé en 8 bits PCM). Et je n'utilise qu'à peine 20% du Z80 car le sample est seulement à 13 Khz (au dessous ça ne rentrait plus dans la rom). Vraiment le 68000 n'a aucun impact significatif sur le Z80 et vice versa, seul le DMA en a et seulement si tu tentes d'accéder à la bank 68k en même temps. Comme je le montre dans la démo BadApple, un driver adapté outre passe le problème facilement ! J'ai fourni les sources de BadApple, tu peux facilement voir le code du driver Z80 utilisé...
Le problème avec beaucoup de jeux MD, c'est qu'il utilise le DMA à outrance sans chercher à adapter le driver alors que bien souvent, le DMA n'était pas nécessaire, et surtout un driver Z80 modifié aurait pu outre passer le problème.

Ce que j'au vu sur sega-16 en lisant les topic sur le sujet, c'est bien ce que je disait, la MD n'est pas faite pour les samples, et c'est un calvaire d'arriver à faire ne serai-ce que du 4 bit @16 khz dans un jeu, alors que sur PCE, c'est finger in the noze,pas besoin d'un second CPU, le petit 6280 8bit se débrouille tout seul ..

Ah tu me fais rire, t'as vraiment du lire en travers X'D
Tu ferais bien de regarder cette vidéo :
https://www.youtube.com/watch?v=KsMRe_QenvU

Sur PCE ça bouffe le CPU central, c'est du 5 bits, sur MD c'est gratuit, c'est du 8 bits et tu oses dire que c'est mieux sur PCE :p
D'ailleurs sur PCE l'interruption horizontal continue pendant le VBlank ? sinon tu fais comment ?

Oui en demo sans rien qui tourne autour,un traitement basique des samples ..
Des qu'il s'agit de jeu, c'est out, finish, même des gars comme chilly willy,sik,TmEE par exemple, explique très bien la difficulté de samples de la MD, même un qui dit que même le yam du ST permet de faire plus facilement des samples que le le yam FM de la MD ..
Pourtant je pense pas que ce soit des fanboys nintendo ..

Mais arrêtes avec le coup de la démo, c'est un driver Z80, ça signifie que tu le pose et il marche quelque soit le jeu puisque c'est indépendant ! Après oui ce n'est pas aussi simple que sur une SNES, car il faut coder ton driver sonore sur le Z80 et donc à la mano. Mais c'est aussi ça qui rend le système beaucoup plus flexible et tu peux repousser les limites. Au début on pensait qu'on pouvait pas faire plus de 2 voix PCM. Au final on se rend compte qu'on peut en faire 4 et même je pourrais monter jusqu'à 8 voix PCM à 16 Khz... et ce, sans intervention du 68000.

Haha bah oui, trop bien le yam du St... tu sais t'as le même sur MD, c'est le fameux PSG. Rien ne t'empêche de faire du sample avec (After Burner 2 le fait sur MD) mais la qualité n'est pas la même et c'est un peu la solution de facilité pour faire du sample en multi voix.

Sans parler de la difficulté de se synchro avec le Z80,impossible de détecter les interruptions VDP ..

Bien sur que si, tu recois les interruptions verticales, je les utilise dans mon driver BadApple, c'est d'ailleurs grace à ça que je peux continuer à jouer le sample pendant un éventuel DMA. Tout ce que je fais c'est d'éviter un accés à la bank 68k pendant tout le vblank.

Quand la technique fait que tu peux pas, même en étant un excellent coder Z80 tu peux pas, le problème vient aussi que le z80, n'a aucun controle sur le matériel comme le VDP, les synchros pour jouer des samples sont du coup hard à gerer..

Et ben faudra que tu m'expliques comment j'ai fait alors Surtout que je suis loin d'être un excellent codeur Z80...

Le Z80 a accés au VDP (qui contient le PSG) mais en ce qui concerne les accés aux ports vidéo même, ça ne sert à rien car le Z80 est 8 bits alors que les ports sont 16 bits.

Et ça change pas le fait ,que le CHIP FM est un vaux , j'invente rien .
Donc c'est bien beau de critiquer le snes à ce niveau lol ..

Le problème c'est que tu répètes sans savoir de quoi il s'agit exactement
Veau dans le sens ou il ne prend pas plus de ~32000 écritures/seconde, la belle affaire ! C'est un chip midi, la programmation FM prend rarement plus de 500 écritures / seconde. Et ça limite la qualité du sample à environ ~32 Khz... ce qui est bien plus que nécessaire.

Ok, le C64 à des assistances, mais c'est pas une snes non plus, la snes est largement mieux fournie niveau assistance, avec un CPU 4/5 fois plus puissant ..
Le C64 n'est pas non plus plus puissant qu'une nes ou une SMS ..
Donc imagines ce qu'un dev expérimenté ferait sur un 65816 !!!
Tout comme le 6280, et bien plus puissant que le 6502.

Heureusement que la SNES est mieux doté qu'un C64, ça piquerait un peu sinon ? :p
Ben des dev expérimentés ont déjà bossé sur SNES, tu crois que les équipes de Nintendo étaient des manches ? Et on a déjà vu ce que ça donne...
Et je sais que le 6280 est plus puissant qu'un 6502, j'ai jamais dit le contraire.

Don't forget bank switching... And they may have added the samples and checked for overflow instead of using a look-up table, making things worse performance-wise. That, and general lack of Z80 expertise, the Z80 is much slower than it seems...

Il doit manquer quelque chose dans ton quote O_o ? il parle d'un driver de l'époque je pense et c'est pas une surprise que les drivers d'époque (comme GEMS) étaient vraiment pas fameux. Le bank switching est galère car c'est un registre sérialisé. Il m'a emmerdé au début mais à partir du moment ou j'ai commencé à bufferiser le problème a tout simplement disparu.

Faut pas se voiler la face, la MD est pleines de défauts de conception ,comme les autres, reste à savoir ce qui peut être contourner, et ce qui ne peut pas .

J'ai jamais dit qu'il n'y avait pas de défauts, mais non pas "plein" comme tu le laisses entendre.
Le principal, je l'ai déjà dit : le manque de couleurs (ou plutot de palette).
Après on peut voir la complexité de la partie sonore comme un défaut, il est vrai que des interruptions YM connectés, un registre de bank complet auraient simplifié la vie. Mais comme je l'ai déjà dit, ce sont des défauts contournables et donc pas vraiment génant pour moi à partir du moment ou tu sais comment faire.
Si c'est ça que tu appelles plein de défaut...

[Lesarthois]

Ah tiens c'est marrant ça ! Comme quoi...

Je précise que je plaisante
Pas tout à fait mais bon, j'ai GRANDEMENT exagéré ma vision négative de l'arcade

Quasi tout les mardi je suis avec une asso de jeu rétro, là on va bientôt avoir fini de monter une borne d'arcade deux joueurs en MAMEcab, je peut te dire que je serais pas le dernier à l'utiliser

En même temps, ne le prends pas mal mais, vu ton jeune âge, tu n'as clairement pas connu l'âge d'or des salles d'arcade et/ou ce parallèle terriblement excitant/frustrant entre les sorties arcade de l'époque et leur conversions sur consoles de salon quelques mois plus tard.

Aurais-je 20 ans de plus, ça ne changerait pas le fait que pour trouver une salle d'arcade, il me fallait faire 50 km pour en trouver une, sinon c'était le vieux flipper déglingué d'un bar dégueulasse.

Après, ce que je préfère en JV, ce sont les jeux de puzzle, d'aventure (type l'aigle d'or ou day of the tentacles) et les point'n'click.
Des genres peu représentés en arcade, tu admettras (mis à part les jeux de puzzle sans doute)

[Agathon]

Stef, dis moi, il n'y a donc aucun moyen de contourner voir dépasser ce problème de couleur sur megadrive?

[Stef]

Stef, dis moi, il n'y a donc aucun moyen de contourner voir dépasser ce problème de couleur sur megadrive?

Il y a des moyens mais tu seras toujours embêté avec ce problème de couleurs...
Tu peux en afficher jusqu'à ~1500 couleurs simultanément, ce qui est plus ou moins le maximum théorique avec l'effet highlight / shadow. Mais là pour le coup, c'est utilisable uniquement en démo et pas en situation réelle.
En situation réelle, au mieux tu combines reprogrammation de palette et effet highlight / shadow, ce qui te permettre de dépasser les 64 couleurs mais ça reste très contraignant dans les couleurs et reste loin d'offrir la même souplesse que d'avoir des palettes supplémentaires. La MD n'aurait que 2 fois plus de palettes (8 plutot que 4) ça aurait grandement aidé !

Vidéo intéressante sur le nombre de couleurs affichées simultanément sur MD :
https://www.youtube.com/watch?v=Z9rjwECf2wQ

[Agathon]

Merci pour l'info. Y a pas de démo avec plein de couleurs sur MD? Histoire de voir ce que ça donne...

[Stef]

Y'en a une qui affiche un peu plus de 1500 couleurs sur un écran plus ou moins fixe donc c'est juste pour montrer que c possible, voici ce que ça donne :



Au milieu tu as les couleurs en intensité normale.
A gauche en mode shadow.
A droite en mode highlight.
Ce qui est interessant c'est que ces modes ajoutent réellement de nouvelles couleurs absentes de la palette de base.

[Agathon]

Qu'est ce qui empêche donc dans les fait la megadrive dutiliser ça dans les jeux?

[Stef]

Ben comme tu le vois, les couleurs utilisent un pattern bien particulier pour en afficher le plus possible. Quand tu modifies une palette, tout les tiles qui utilisent cette palette sont affectés. Sur une image fixe tu peux "controler" ces contraintes mais si l'image n'est pas fixe avec un scrolling libre selon les controles du joueur, il devient impossible de bien controler les différents contraintes et de jouer sur ce genre d'effet. Le cas le plus simple, c'est la reprogrammation de palette à un certain scanline, pour simuler une transparence dans de l'eau par exemple, bon nombre de sonic utilise cette effet. Dans ce cas la contrainte est simple à gérer, on change les couleurs juste à partir d'un certain scanline, tout ce qui est au dessus utilise certaines couleurs, tout ce qui est en dessous en utilise d'autres... mais voilà, à part simuler un niveau d'eau, ou un brouillard pourquoi pas, on peut pas en faire grand chose. Les effets de highlight / shadow sont applicables plus simplement, mais là encore, ça ne sert qu'à assombrir ou éclaircir une teinte.

[Invité]

Ben comme je te dis, trouve moi un exemple, vraiment... un truc bete, une detection de collision, je ne sais pas, n'importe. Je pourrais t'en trouver des exemple mais tu vas me dire que je trouve encore un exemple qui avantage le 68000.

Je t'en ai donné plein d'exemple, boucles, saut conditionnel, saut à une routine interruption, que des trucs classiques et bateau dans un programme .

Mais non mais il faut reconnaitre que tu prends des exemples pourris sur MD ! AF2 sorti en 1990 (plutot début la machine) et déjà à l'époque mal noté ! Bien sur que je n'utilise pas ce genre de jeux comme référence comme ce qu'on peut faire sur MD. Et oui je le dis sans problème, beaucoup de portage arcade Sega était tout simplement pourri sur MD, c'est un fait ! Je pense que c'était presque voulu pour éviter de faire concurrence à l'arcade de l'époque. Franchement bon nombre de jeux auraient pu être bien mieux réussi. Et c'est pareil sur PCE, tu n'utilises pas les jeux honteux sur la machine pour faire un comparatif (genre Altered Beast)...

Ah bon raté sur Md, un jeu sega, fait pas sega, sur une console sega ..
Forcement la PCE, est avantagé c'est clair .
Le constat est le même avec out run.

Attends tu veux quand même pas comparer la conversion d'altered beast sur PCE, et After Burner2 sur MD ..
On peut prendre gate of thunder si tu veux ??

Sinon donnes moi un jeu aussi beau que dracula X sur PCE, sur MD !!

Mais la taille du sprite ne change rien, s'il s'agit d'un sprite statique, qu'il soit en 8x8 ou 32x32 ça ne change strictement rien. Si on a autant de petits sprites dans les jeux MD, c'est que la console le permet ! A l'inverse de la PCE ou la SNES ou ça pose des problèmes. Ce sont justement ces petits sprites, ces petites particules d'explosions ou n'importe quoi qui rendent les jeux si "vivant" sur MD, et c'est leur manque qui rendent les jeux SNES particulièrement inertes.

C'est sur entre des sprites 8*8 et 32*32 y'a pas de différence ??
Techniquement, c'est un atout c'est clair, à l'écran,l'utilisation massive fait que les jeux MD, ressemble à des jeux consoles, contrairement à la snes ou à la PCE ..
Même constat entre les FF et les SOR .

Et puis dire que les jeus MD sont plus vivants que les autres, ca c'est de l'argument de fanboy, perso je vois rien de tel dans les jeux MD, pas plus que les autres ..
Un magical chase sur PCe, est bien plus diversifié dans les sprites,décors et effets que quasi n'importe quel jeu MD ..

Dans la démo BadApple j'utilise le 68000 a fond ainsi que le DMA ! C'est le pire des cas pour le Z80, pour autant le sample est joué sans grésillement alors qu'il est décompressé par le Z80 (4 bits ADPCM décompressé en 8 bits PCM). Et je n'utilise qu'à peine 20% du Z80 car le sample est seulement à 13 Khz (au dessous ça ne rentrait plus dans la rom). Vraiment le 68000 n'a aucun impact significatif sur le Z80 et vice versa, seul le DMA en a et seulement si tu tentes d'accéder à la bank 68k en même temps. Comme je le montre dans la démo BadApple, un driver adapté outre passe le problème facilement ! J'ai fourni les sources de BadApple, tu peux facilement voir le code du driver Z80 utilisé...
Le problème avec beaucoup de jeux MD, c'est qu'il utilise le DMA à outrance sans chercher à adapter le driver alors que bien souvent, le DMA n'était pas nécessaire, et surtout un driver Z80 modifié aurait pu outre passer le problème.

Oui dans ta demo, moi dans un jeu je fais du 5 bit 15khz sans me faire chier,avec son seul CPU 8 bit soit disant moins bon qu'un 68000 donc ...
Toi il te faut ET LE 68000 ET LE Z80, pour faire moins bien dans une demo .
Ton 8 bit audio n'est qu'une interpolation, et reste de qualité 4 bit .

Ah tu me fais rire, t'as vraiment du lire en travers X'D
Tu ferais bien de regarder cette vidéo :
https://www.youtube.com/watch?v=KsMRe_QenvU

Sur PCE ça bouffe le CPU central, c'est du 5 bits, sur MD c'est gratuit, c'est du 8 bits et tu oses dire que c'est mieux sur PCE :p
D'ailleurs sur PCE l'interruption horizontal continue pendant le VBlank ? sinon tu fais comment ?

Ah ouai super des digits pendant des écrans fixes, effectivement la MD dépote grace à ses 2 CPU ..
Déconnes pas, ça bouffe pas plus que toi au final, avec des samples de meilleure qualité.
J'ai pas à me faire chier avec du code complexe, je fait la synchro soit au timer soit au hsync,que du classique .
Et de plus comme je l'ai dit ton 8 bit est interpolé, ca reste du 4 bit .

Pour l'interruption HSYNC qui dure sur le VBLANC ???
J'ai jamais vu ça lol, du moins pas sur PCE,ou alors c'est que tu as un soucis de code qui dure trop longtemps ..
Regardes le player de XM sur 6 voix de tom, il fait tout en HSYNC et timer, ça prend 70% de CPU
Et ç'est pas optimisé en plus.
La même chose sur MD est impossible .

Si on compare les meilleurs samples sur PCE c'est du 10 bit 33.5 khz largement mieux que ce qui peux se faire sur MD, 4 bit 24 khz .

Mais arrêtes avec le coup de la démo, c'est un driver Z80, ça signifie que tu le pose et il marche quelque soit le jeu puisque c'est indépendant ! Après oui ce n'est pas aussi simple que sur une SNES, car il faut coder ton driver sonore sur le Z80 et donc à la mano. Mais c'est aussi ça qui rend le système beaucoup plus flexible et tu peux repousser les limites. Au début on pensait qu'on pouvait pas faire plus de 2 voix PCM. Au final on se rend compte qu'on peut en faire 4 et même je pourrais monter jusqu'à 8 voix PCM à 16 Khz... et ce, sans intervention du 68000.

Haha bah oui, trop bien le yam du St... tu sais t'as le même sur MD, c'est le fameux PSG. Rien ne t'empêche de faire du sample avec (After Burner 2 le fait sur MD) mais la qualité n'est pas la même et c'est un peu la solution de facilité pour faire du sample en multi voix.

J'insiste sur la demo, car ok c'est un driver Z80, mais ton z80 tourne seul, il à le bus pour lui tout seul ..
On verra si tu arrive à faire ça dans un jeu .
Sik qui à développé projet MD, et très loin de faire aussi bien dans son jeu, car justement le z80, n'est pas tout seul.

Bien sur que si, tu recois les interruptions verticales, je les utilise dans mon driver BadApple, c'est d'ailleurs grace à ça que je peux continuer à jouer le sample pendant un éventuel DMA. Tout ce que je fais c'est d'éviter un accés à la bank 68k pendant tout le vblank.

Va faire du sample avec la synchro verticale, je comprend aussi pourquoi tu peux pas dépasser les 4 bit 4khz ..

Et ben faudra que tu m'expliques comment j'ai fait alors Surtout que je suis loin d'être un excellent codeur Z80...

Le Z80 a accés au VDP (qui contient le PSG) mais en ce qui concerne les accés aux ports vidéo même, ça ne sert à rien car le Z80 est 8 bits alors que les ports sont 16 bits.

OK, bon le 6280 est 8 bit aussi et le VDC est 16 bit, et aucun soucis, c'est pas ma faute si sega, n'a pas fait que des bons choix dans sa console ..

Le problème c'est que tu répètes sans savoir de quoi il s'agit exactement
Veau dans le sens ou il ne prend pas plus de ~32000 écritures/seconde, la belle affaire ! C'est un chip midi, la programmation FM prend rarement plus de 500 écritures / seconde. Et ça limite la qualité du sample à environ ~32 Khz... ce qui est bien plus que nécessaire.

Non le veau, surtout parce que le 68000 est obligé d'attendre que le yam FM puisse recevoir des données, ça ralentit tout, tu peux pas te permettre de blocquer le CPU, pour un chip audio,d'ou des samples 4bit @4khz dans les jeux qui utilisent le 68000 pour les samples...
Et ça crachotte, car le flux n'est pas continu.
C'est pas gênant quand tu fais du FM, car tu peux sans problème synchroniser l'audio sur le VBLANK,et ne nécessite pas bcp de données, par contre pour les samples,faut que ça dépote, et alimenter le chip de données soutenues, d'ou la difficulté de lire des samples sur MD ..

La limite des samples @32 khz ???
Tiido un autre codeur Md, explique que tu peux pas dépasser les 24 khz, en fait 27, mais là c'est aléatoire ..
C'est fou comme ton discours ici ne correspond pas du tout, à ce qui est dit sur sega-16 .
Ou même le discours de chilly willy (et des autres aussi), est bien plus dur sur le couple 68000/z80/chip FM ..
C'est pas moi qui est dit que SEGA aurait mieux fait de mettre une voix DMA pour les samples, plutôt que le Z80 .

Heureusement que la SNES est mieux doté qu'un C64, ça piquerait un peu sinon ? :p
Ben des dev expérimentés ont déjà bossé sur SNES, tu crois que les équipes de Nintendo étaient des manches ? Et on a déjà vu ce que ça donne...
Et je sais que le 6280 est plus puissant qu'un 6502, j'ai jamais dit le contraire.

Ce que je veux dire, c'est que même avec des assistances, un C64 n'a pas les perfs d'une nes ou une SMS (qui ont quasiment les même assistances, voire plus), alors avec une snes .
Et les gars de nintendo n'étaient pas plus des manches que ceux de SEGA, sauf quand ça t'arrange hein

Il doit manquer quelque chose dans ton quote O_o ? il parle d'un driver de l'époque je pense et c'est pas une surprise que les drivers d'époque (comme GEMS) étaient vraiment pas fameux. Le bank switching est galère car c'est un registre sérialisé. Il m'a emmerdé au début mais à partir du moment ou j'ai commencé à bufferiser le problème a tout simplement disparu.

Donc pour toi

Don't forget bank switching... And they may have added the samples and checked for overflow instead of using a look-up table, making things worse performance-wise. That, and general lack of Z80 expertise, the Z80 is much slower than it seems...

Ca n'est pas assez explicite ???
Et quand tu lis les posts, il en ressort ce que je t'ai dit, j'ai même pas eu à interpreter tellement c'était explicite .
Le Z80 est lent dés que tu touches au bus, et encore plus si tu dois faire du bank switching avec .
Le problème avec les samples, c'est que plus la qualité des samples augmente, plus il faut un débit soutenu des données dans le CHIP sonore, et une synchro rapide .
Donc ce que peut faire le 68000 mais pas le YAM, ni le Z80 .

J'ai jamais dit qu'il n'y avait pas de défauts, mais non pas "plein" comme tu le laisses entendre.
Le principal, je l'ai déjà dit : le manque de couleurs (ou plutot de palette).
Après on peut voir la complexité de la partie sonore comme un défaut, il est vrai que des interruptions YM connectés, un registre de bank complet auraient simplifié la vie. Mais comme je l'ai déjà dit, ce sont des défauts contournables et donc pas vraiment génant pour moi à partir du moment ou tu sais comment faire.
Si c'est ça que tu appelles plein de défaut...

Elle en a autant que les autres, le problème, c'est qu'a t'entendre, elle n'en à pas, et les qualité chez les autres ne servent pas à grand choses ..
Je connais pas suffisamment la snes pour pouvoir en débattre réellement, pas contre la PCE, elle en a aussi plusieurs, plus ou moins chiantes ..
Je te les donnes sans problème .
La théorie, c'est super sur ce qui aurait du être fait pas fait, mais dans la pratique, au niveau sample in game, je vois rien de top sur MD ..
Perso je préfère de loin le système de la PCE pour jouer des samples,bcp plus simple et pratique, donc au final plus efficace, que celui de la MD.

Une autre petite cote pour la route :

Originally Posted by kool kitty89
It's arguably a hardware issue too:
the hardware facilities for sample playback are inherently programming dependent, and thus far from foolproof . . . it's a lack of hardware that causes this problem. Lack of timer interrupts for (otherwise nearly ideal) YM interval timers, shitty bank switching on the Z80, overhead from accessing the slow YM2612 interface, let alone a simple DMA sound circuit. (a single DMA sound channel would still need software mixing for more channels or software decoding of compressed samples, but that's far, far better than what's there now, and also far more foolproof to program)
As it is, you're stuck with raw, cycle counted code to allow for PCM timing, or the considerable overhead from polling timers for playback timing (GEMS uses the latter, and it's very CPU intensive -limited to around 10 kHz max)

There are certainly software workarounds for this, but it's still not immediately obvious or straightforward, especially if game developers haven't specifically hired experienced Z80 assembly language coders to handle it. (let alone the many using pre-made SEGA sound drivers)

The PC engine itself is much better off for PCM, even without a dedicated CPU to offload this to. It's got a nice fast 6502 CPU and onboard interval timers to use for interrupt driven PCM playback. (and 650x CPUs are lightning fast at interrupt handling) Using the onboard 7 kHz timer takes around 5% CPU time to play a single PCM channel . . . you could use the scanline interrupt timer (15.7 kHz) too, but that's clunkier (added overhead from needing to be reset after each interrupt) so a better option for later games would have been an added timer on-card. (very simple/cheap add-on to use that would have made tons of sense had the Hucard format remained the focus of the platform)
It's also pretty straightforward to use paired channels to allow much better than 5-bit resolution, up to 10 bits. (done by adjusting the volume control on the channels to match up so 1 handles the lower 5-bits and the other the upper 5-bits) So using 4 of the WSG channels could allow 10-bit stereo PCM. (could probably manage a decent multi-channel stereo MOD player like that and still have enough CPU time left to be better off than most SNES games)

[Agathon]

Elle en a autant que les autres, le problème, c'est qu'a t'entendre, elle n'en à pas, et les qualité chez les autres ne servent pas à grand choses ..

Sans prendre aucun parti pris, car je suis neutre comme la Suisse,
j'ai vraiment pas le sentiment en lisant que c'est ce qu'il sous entends.

[D-rouleuR]

sans prendre part au précédents post, je dirais mégadrive pour moi
=> rien que pour les sonic elle dépasse la snes

[lessthantod]

je dirais mégadrive pour moi
=> rien que pour les sonic elle dépasse la snes

Hé bien avec un argument béton comme celui-là c'est sûr que c'est difficile de passer derrière toi ... moi je dirais SNES
=> rien que pour les mario elle dépasse la MD

[Stef]

Ah je dois que c'est fatiguant de te répondre TOUKO, très honnêtement j'ai l'impression de me fatiguer pour rien. Je répète souvent les mêmes choses, vraiment...

Je t'en ai donné plein d'exemple, boucles, saut conditionnel, saut à une routine interruption, que des trucs classiques et bateau dans un programme .

Je t'ai déjà dit que j'attendais autre chose qu'un simple instruction, que c'était débile de comparer ainsi. Je te parle d'une vraie fonction, un tri, un affichage de sprite en soft (en gérant les pixels transparents), gérer le déplacement de 50 sprites... le but étant que tu me donnes un bout de code 6280 que je traduis en code 68000 et ensuite on peut comparer. Je crois que je t'ai déjà soumis l'idée genre 5 fois... Après si tu en as pas envie ok je comprends, mais c'est juste une méthode pour te montrer, par la pratique, pourquoi le 68000 n'est pas si lent malgré son faible débit instruction/cycle.

Ah bon raté sur Md, un jeu sega, fait pas sega, sur une console sega ..
Forcement la PCE, est avantagé c'est clair .
Le constat est le même avec out run.

Attends tu veux quand même pas comparer la conversion d'altered beast sur PCE, et After Burner2 sur MD ..
On peut prendre gate of thunder si tu veux ??

Je te dis justement que ça n'a pas
d'intérêt de comparer des jeux qui sont clairement pas le reflet de ce
qu'une machine est capable de faire. Donc exit le AF2 sur MD, exit le altered beast sur PCE, ces jeux sont clairement pas représentatif.
Oui tu peux me parler de Gate of Thunder, qui est plus représentatif, malgré ses bruitages digne d'une master system :p
Mais c'est pas avec ça que tu peux inquiéter les shoots MD...

Sinon donnes moi un jeu aussi beau que dracula X sur PCE, sur MD !!

Heuu.. quel rapport ???

C'est sur entre des sprites 8*8 et 32*32 y'a pas de différence ??
Techniquement, c'est un atout c'est clair, à l'écran,l'utilisation massive fait que les jeux MD, ressemble à des jeux consoles, contrairement à la snes ou à la PCE ..
Même constat entre les FF et les SOR .

En terme de ressource, si le sprite est statique ça ne change strictement rien, tu dois tout autant gérer ses déplacements et ses collisions, qu'importe la taille du sprite ! Là encore j'ai déjà du l'expliquer 20 milliards de fois...
Si le sprite est animé bien sur l'histoire est différente, mais en terme de sprite animé, que ça soit la SNES ou la PCE c'est clairement pas ça !
Des gros sprites bien animés, t'en as sur FF CD, sur Vectorman, sur Alien Soldie, SOR3 (surtout en nombre sur celui ci)... bref la MD en est très largement capable.

Et puis dire que les jeus MD sont plus vivants que les autres, ca c'est de l'argument de fanboy, perso je vois rien de tel dans les jeux MD, pas plus que les autres ..
Un magical chase sur PCe, est bien plus diversifié dans les sprites,décors et effets que quasi n'importe quel jeu MD ..

Y'a quelque chose d'aussi nerveux qu'un gunstar heroes, qu'un batman et robin, ou même qu'un contra hard corps sur PCE ? je serais curieux de voir ça !

Oui dans ta demo, moi dans un jeu je fais du 5 bit 15khz sans me faire chier,avec son seul CPU 8 bit soit disant moins bon qu'un 68000 donc ...
Toi il te faut ET LE 68000 ET LE Z80, pour faire moins bien dans une demo .
Ton 8 bit audio n'est qu'une interpolation, et reste de qualité 4 bit .

Mais justement dans ma démo on est dans un cas pire que 99% des jeux ! Je bouffe le DMA complet, le 68000 doit décompresser entre 4 à 5 ko de données par frame donc il est archi occupé à bouffer le BUS... Tu n'as pas pire cas que ça.
Et d'où tu tiens que mon audio 8 bits est du 4 bits interpolé O_o ??? tu sais c'est quoi du 4 bits ADPCM ?? c'est juste une compression qui dégrade un peu la qualité (comme du MP3), la SNES utilise une compression hardware 4 bits ADPCM aussi pour tout ses samples, et pour autant est-ce qu'elle sort en 4 bits interpolé ?? n'importe quoi vraiment le DAC de la MD est 8 bits, je sais pas d'où tu sors ce 4 bits...
Et bien sur que j'utilise le Z80, tu vas bientot reprocher à la MD d'avoir un CPU dédié pour le son comparé à la PCE qui en a pas, plutot fort !

Ah ouai super des digits pendant des écrans fixes, effectivement la MD dépote grace à ses 2 CPU ..

Ah merde la MD ne fait que des digits pendant les écrans fixes, l'air con avec ma démo qui est censé être une vidéo (animé donc)...
De + en + fort :)

Déconnes pas, ça bouffe pas plus que toi au final, avec des samples de meilleure qualité.

T'as intérêt à bien optimiser ton code alors parce que 0% de ton CPU ça va pas te laisser beaucoup de temps...

J'ai pas à me faire chier avec du code complexe, je fait la synchro soit au timer soit au hsync,que du classique .
Et de plus comme je l'ai dit ton 8 bit est interpolé, ca reste du 4 bit .

Mais tu sais sur MD rien ne t'empêche de lire du PCM à partir du 68000 via le HBlank, certains jeux le font d'ailleurs (les premiers car il fallait être vraiment naze pour faire ça) ! Sur PCE tu dois réinit le registre d'interruption H, donc si l'interruption est rapide en elle même, tu reperd du temps là dessus (sur MD pas besoin).

Pour l'interruption HSYNC qui dure sur le VBLANC ???
J'ai jamais vu ça lol, du moins pas sur PCE,ou alors c'est que tu as un soucis de code qui dure trop longtemps ..

T'as lu ce que j'ai écrit ??? j'ai dit justement qu'il n'y en a pas sur MD, et ça m'étonnerait qu'il y en ai sur PCE car ça n'a pas de sens... du coup la qualité de ton PCM est foireuse à cause du vblank.

Regardes le player de XM sur 6 voix de tom, il fait tout en HSYNC et timer, ça prend 70% de CPU
Et ç'est pas optimisé en plus.
La même chose sur MD est impossible .

Dans Toy Story (dans un jeu donc) il y a un player de module en soft sur le 68000 :
https://www.youtube.com/watch?v=ItHHvKbT2JY

Si tu écoutes la musique d'intro (et de fin) de Toy Story sur MD tu remarqueras qu'on a pas du tout le genre de musique qu'on a habituellement sur MD.

Si on compare les meilleurs samples sur PCE c'est du 10 bit 33.5 khz largement mieux que ce qui peux se faire sur MD, 4 bit 24 khz .

Lis mieux les autres forums... je sais pas ou t'as été chercher ce 4 bits

J'insiste sur la demo, car ok c'est un driver Z80, mais ton z80 tourne seul, il à le bus pour lui tout seul ..
On verra si tu arrive à faire ça dans un jeu .
Sik qui à développé projet MD, et très loin de faire aussi bien dans son jeu, car justement le z80, n'est pas tout seul.

Je comprends rien à ce que tu racontes X'D
Comment ça le Z80 tourne seul ??? le 68000 tourne toujours même s'il fait des nop il accède en continue au bus... et comme je l'ai dit plus haut, la démo Bad Apple est "le pire des cas" d'utilisation de BUS et DMA, honnêtement un jeu ne ferait pas pire sur ce point, c'est normal, c'est justement le but d'une démo technique...

Sinon Sik a écrit son driver pour ne gérer qu'une seul voix PCM, il a privilégié l'API, les effets trackers etc... c'est son choix. Perso pour moi le driver ultime serait 4/6 voix PCM + 5FM + 3PSG + 1NOISE, on en a déjà parlé sur spritesmind, et côté Z80 c'est faisable. Le vrai problème c'est qu'il faut faire le tracker qui va avec (actuellement ils sont tous limité à 1 voix PCM + FM + PSG)... et c'est beaucoup de boulot !!

Tu devrais lire ce topic, il est très instructif sur les possibilités du Z80 :

http://gendev.spritesmind.net/forum/viewtopic.php?t=1165&highlight=ultimate+z80+driver

Bien sur que si, tu recois les interruptions verticales, je les utilise dans mon driver BadApple, c'est d'ailleurs grace à ça que je peux continuer à jouer le sample pendant un éventuel DMA. Tout ce que je fais c'est d'éviter un accés à la bank 68k pendant tout le vblank.

Va faire du sample avec la synchro verticale, je comprend aussi pourquoi tu peux pas dépasser les 4 bit 4khz ..

Ha c'est quand même dingue, même quand tu as tord, plutot que de reconnaitre tu vas tenter d'enfoncer d'une autre façon... Pas de chance tu n'as pas compris ce que je voulais dire... j'utilise la V-Int juste pour savoir quand ne pas accéder au bus 68k, pour balancer les samples vers le DAC tu utilises soit le timer YM ou soit tu comptes les cycles (ce que je fais, c'est plus rapide).

OK, bon le 6280 est 8 bit aussi et le VDC est 16 bit, et aucun soucis, c'est pas ma faute si sega, n'a pas fait que des bons choix dans sa console ..

Merci pour ta belle parole pleine de bon sens :)
C'est sur qu'un VDC 16 bits avec un CPU 8 bits c'est un meilleur choix qu'un VDP 16 bits avec un CPU 16 bits :)

Et ça crachotte, car le flux n'est pas continu.
C'est pas gênant quand tu fais du FM, car tu peux sans problème synchroniser l'audio sur le VBLANK,et ne nécessite pas bcp de données, par contre pour les samples,faut que ça dépote, et alimenter le chip de données soutenues, d'ou la difficulté de lire des samples sur MD ..

Si ça crachotte c uniquement parce que le Z80 est interrompue, et là encore, si le Z80 est interrompue, c'est du à de mauvaises pratiques (déjà expliqué avant).

La limite des samples @32 khz ???
Tiido un autre codeur Md, explique que tu peux pas dépasser les 24 khz, en fait 27, mais là c'est aléatoire ..

Tiido m'a effectivement dit qu'en général il ne dépasse les 27 Khz sur ses MD, après quoi il a des miss aléatoires. Pourtant sur toutes mes MD j'arrive toujours entre 32Khz et 33Khz avant d'observer des miss, c'est d'ailleurs pourquoi mon driver 1 PCM 8 bits fonctionne de 8 Khz jusqu'à 32 Khz. Alors peut être que selon les révisions de MD ça peut varier mais en tout cas sur les miennes vont toutes (j'ai testé sur 3 MD1 et une MD2) jusqu'à 32/33 donc c'est quand même assez curieux...
Je peux le prouver en faisant un enregistrement d'un sample à 32 Khz sur ma MD.

C'est fou comme ton discours ici ne correspond pas du tout, à ce qui est dit sur sega-16 .
Ou même le discours de chilly willy (et des autres aussi), est bien plus dur sur le couple 68000/z80/chip FM ..
C'est pas moi qui est dit que SEGA aurait mieux fait de mettre une voix DMA pour les samples, plutôt que le Z80 .

Mais j'ai dit plus haut qu'effectivement la partie audio était améliorable ! Avec de petits changements la vie des développeurs auraient été plus simples. Mais justement, c'est là la différence, c'est juste une histoire de complexité ! Ca reste possible, c'est contournable même si c'est plus difficile, c'est pourquoi pour moi ce n'est pas un gros défaut ! La encore je me répète.

Ce que je veux dire, c'est que même avec des assistances, un C64 n'a pas les perfs d'une nes ou une SMS (qui ont quasiment les même assistances, voire plus), alors avec une snes .
Et les gars de nintendo n'étaient pas plus des manches que ceux de SEGA, sauf quand ça t'arrange hein

Je parlais en développement pour Nintendo, niveau hardware la NES était une révolution, la SNES perso je trouve pas que ça soit une grande réussite technique. Ca va pas plus loin.

Donc pour toi

Don't forget bank switching... And they may have added the samples and checked for overflow instead of using a look-up table, making things worse performance-wise. That, and general lack of Z80 expertise, the Z80 is much slower than it seems...

Ca n'est pas assez explicite ???
Et quand tu lis les posts, il en ressort ce que je t'ai dit, j'ai même pas eu à interpreter tellement c'était explicite .
Le Z80 est lent dés que tu touches au bus, et encore plus si tu dois faire du bank switching avec .
Le problème avec les samples, c'est que plus la qualité des samples augmente, plus il faut un débit soutenu des données dans le CHIP sonore, et une synchro rapide .
Donc ce que peut faire le 68000 mais pas le YAM, ni le Z80 .

Non je répète, ton quote ne veut rien dire, j'aimerai bien que tu mettes le contexte autour que je comprenne mieux pourquoi il dit ça. Je ne vois pas en quoi le Z80 est lent excepté s'il veut parler du CPU en général, et le bank switch ça se contourne... encore une fois.

Elle en a autant que les autres, le problème, c'est qu'a t'entendre, elle n'en à pas, et les qualité chez les autres ne servent pas à grand choses ..
Je connais pas suffisamment la snes pour pouvoir en débattre réellement, pas contre la PCE, elle en a aussi plusieurs, plus ou moins chiantes ..
Je te les donnes sans problème .
La théorie, c'est super sur ce qui aurait du être fait pas fait, mais dans la pratique, au niveau sample in game, je vois rien de top sur MD ..
Perso je préfère de loin le système de la PCE pour jouer des samples,bcp plus simple et pratique, donc au final plus efficace, que celui de la MD.

C'est toi qui comprend ce que tu veux, très honnêtement j’essaie de rester assez objectif (même si je suis conscients de ne pas l'être tout le temps), j'apporte des preuves, ce que je dis est vérifiable... Je sais pas pourquoi tu es autant agressif envers la MD, tu balances des tonnes de choses que tu ne saisies pas forcément pour la rabaisser, je dois admettre ne pas comprendre pourquoi tu t'acharnes ainsi..
J'ai l'impression que quelque soit les preuves ou ce que je peux dire, de toute façon ton avis est déjà fermé. Je ne cherche pas à te convaincre, tu as le droit de penser ce que tu veux, je ne fais qu'énoncer des faits après tu en fais ce que tu veux mais parler dans le vide comme ça c'est un peu fatiguant...

Une autre petite cote pour la route :

....
As it is, you're stuck with raw, cycle counted code to allow for PCM timing, or the considerable overhead from polling timers for playback timing (GEMS uses the latter, and it's very CPU intensive -limited to around 10 kHz max)
...
There are certainly software workarounds for this, but it's still not immediately obvious or straightforward, especially if game developers haven't specifically hired experienced Z80 assembly language coders to handle it. (let alone the many using pre-made SEGA sound drivers)

The PC engine itself is much better off for PCM, even without a dedicated CPU to offload this to. It's got a nice fast 6502 CPU and onboard interval timers to use for interrupt driven PCM playback.
...
the WSG channels could allow 10-bit stereo PCM. (could probably manage a decent multi-channel stereo MOD player like that and still have enough CPU time left to be better off than most SNES games)

Mais je sais tout ça, mais tu vois la partie en gras, pour moi c'est le plus important :)
D'ailleurs puisque que tu es sur Sega-16, tu devrais lire la suite du post, tu verras que ça va dans mon sens, c'est ce qui ressort toujours...
Et je sais qu'on peux faire facilement du PCM sur PCE, et du bon PCM (SF2 en est l'exemple) mais ça consomme quand même sur le CPU central.

Sinon moi aussi je peux prendre des quotes qui vont dans mon sens :)

The consensus seems to be that Genesis and SNES
sound is technically incomparable. Any comparison of the sound quality
on either system is thus going to be subjective, and the only evidence
that can be used to support the absolute superiority of one system's
sound over the other is anecdotal at best.

The Frequency Modulation of the YM2612 is superior to what the SNES
can emulate using samples. The Genesis' DAC capabilities were only
technically limited to the quality of the code and the amount of ROM
space in the cartridge. Individual digital audio samples on the Genesis
could be played at a frequency comparable or superior to SNES titles.
Yuzo Koshiro and members of the homebrew community have also stated that
the Z80 is more customizable and flexible than the SNES's SPC.

The SNES sound system was, however, designed around PCM and supports
digital audio compression that the Genesis did not. Thus the SNES can
be said to be superior in quality in regard to PCM sound, just as the
Genesis is capable of FM sound that the SNES is not. This comparison
does not merit a digression to a qualitative finale. A system that had
industry standard FM and PCM sound capabilities was preferred in arcade
architecture from the time. Individual preference of Genesis or SNES
sound will be based on the subjective opinion that either FM sound or
PCM sound was superior.

[KJBi]

suis comme TOUKO, me concernant la PCE défonce le MD ou la SNES !
Stef j'ai lu ton argumentation : c'est ta vision des choses, mais pour moi les SHMUP sont tellement meilleurs, plus colorés, plus fluide et plus rapide sur PCE que sur MD. Je ne parle même pas des SHMUP sur l'autre console molle qu'est le SNES pour ce genre de jeux...

après je place la MD devant la SNES, et largement ! après c'est une affaire de gouts. il faut respecter les différents avis. Moi je suis fou de SEGA, de son génie et ses créations et du gameplay SEGA (merci l'arcade).

En tout cas c'était l'age d'or ! on avait trois consoles fabuleuses :-) PCE, MD et SNES ! Plus jamais on en connaîtra cela ! quand on voit aujourd'hui ce qu'on se tape : la pauvre guerre entre XBOX360 et PS3, incapable de faire des jeux fluides....

[Stef]

suis comme TOUKO, me concernant la PCE défonce le MD ou la SNES !
Stef j'ai lu ton argumentation : c'est ta vision des choses, mais pour moi les SHMUP sont tellement meilleurs, plus colorés, plus fluide et plus rapide sur PCE que sur MD. Je ne parle même pas des SHMUP sur l'autre console molle qu'est le SNES pour ce genre de jeux...

Plus coloré ok. Plus fluide, plus rapide... pas d'accord
Meme si la PCE a bon nombre d'excellent shoots, la MD reste reine dans ce domaine

[KJBi]

Quels sont tes shoots préférés sur MD pour voir ?

Je n'ai jamais vu quelque chose aussi beau que Rayxanber III sur MD !
du pixel art pour un shoot extra ordinaire !

NEXZR, y'a rien de tel sur MD !

bon j'arrête là, que dirais tu de créer un autre sujet car ici c'est MD contre SNES ;-)

au fait as tu une PC engine ?