Re: MEGADRIVE vs SUPER NINTENDO : Fight !

[Invité]

Pour moi ce qui serait intéressant pour la SNES ça serait d'exploité la Super FX , personnellement même en lisant la doc j'ai pas encore compris tout a fait comment elle fonctionne niveau programmation.

[Doc_Skunkovitch]

Ppour moi ce qui serait intéressant pour la SNES ça serait d'exploité la Super FX , personnellement même en lisant la doc j'ai pas encore compris tout a fait comment elle fonctionne niveau programmation.

Et lancer un duel : SuperFX vs Sega Virtua Processor !

[Invité]

lecture du port manette ailleurs que sur les 250 microseconde dédie pour dans le vblank 

Ca c'est faux,tu as ce problème car tu utilises la lecture auto du port manette de la console .
C'est un problème connu sur snes(voir le forum snesdev) 

Les transferts DMA sont long du coup obligé de codé une routine tampon

Ils sont long car tu les fais long, forcement tu es limité en BP, comme toutes les machines .
En H32 la snes fait du 6,2 ko/vblank (1364 cycles/lignes, et 8 cycles /octets de transfert DMA, le vblank fait 38 lignes), la Md fait 7,2 ko/vblank en H40 ..

C'est marrant de vanter le DMA de la Md alors qu'en fait il est lent quand tu accèdes à la VRAM, car le VDP y accède en 8 bit .
Donc en H40 le VDP de la Md fait ses transferts @ 6,71 mhz, la snes toujours @2,68 mhz (merci nintendo d'avoir mis de la ram lente) .
Pour info le transfert DMA VRAM ->VRAM de la PCE en H32 est de 6,3 ko/s en Vblank .

rien que pour avoir la coupure d'un personnage quand il est au bord de l'écran c'est un casse tete ,qui m'a demandé a repensé mon architecture juste pour ça...

C'est clair que niveau sprites c'est la cata, comment nintendo a pu pondre un truc pareil !!! 

[Invité]

lecture du port manette ailleurs que sur les 250 microseconde dédie pour dans le vblank 

Ca c'est faux,tu as ce problème car tu utilises la lecture auto du port manette de la console .

Les transferts DMA sont long du coup obligé de codé une routine tampon

Ils sont long car tu les fais long, forcement tu es limité en BP, comme toutes les machines .
En H32 la snes fait du 6,2 ko/vblank (1364 cycles/lignes, et 8 cycles /octets de transfert DMA, le vblank fait 38 lignes), la Md fait 7,2 ko/vblank en H40 ..

Ecoute j'ai fait le test sur la SNES avec émulateur et une vraie SNES.
Je sais pas ce que t'appelle lecture auto mais la SNES est clair c'est le registre $4218 a $421F qui permet de lire la manette.
On ne peut la lire que a un certain moment comme l'indique la documentation officiel de la SNES : https://2img.net/r/hpimg15/pics/354646CapturedocSNES.png , ailleurs tu risque des bugs.

7,2 ko/vblank  c'est plus rapide que 6,2 ko/vblank , donc ça reste un peut plus lent et c'est pas négligeable d'avoir un truc un peu plus rapide.


J'ai l'impression que beaucoup suis le forum snesdev , pourtant a ma connaissance il n'y a personne qui code sur SNES ici ^^'

Et lancer un duel : SuperFX vs Sega Virtua Processor !

L'idée est bonne dans les faits mais je crois que personne n'a jamais tenté de codé sur SuperFX ou sur Sega Virtua Processor.

[Invité]

Je sais pas ce que t'appelle lecture auto mais la SNES est clair c'est le registre $4218 a $421F qui permet de lire la manette.

Je me souviens plus des adresses,mais je sais que la snes dispose d'une lecture auto des pad (tu lis directement des ports, ça t'évites d'écrire une routine dédiée), et pouvoir récupérer les infos est justement extrêmement serré en terme de timing(c'est un truc à la con,style dans les 3 premières ligne d'affichage),je vais essayé de retrouver le topic en question  .

EDIT: C'est bien ça, il s'agit bien de l'auto joypad read :

Auto Joypad Read

When enabled, the SNES will read 16 bits from each of the 4 controller port data lines into registers $4218-f. This begins between dots 32.5 and 95.5 of the first V-Blank scanline, and ends 4224 master cycles later. Register $4212 bit 0 is set during this time. Specifically, it begins at dot 74.5 on the first frame, and thereafter some multiple of 256 cycles after the start of the previous read that falls within the observed range.
Reading $4218-f during this time will read back incorrect values. The only reliable value is that no buttons pressed will return 0 (however, if buttons are pressed 0 could still be returned incorrectly). Presumably reading $4016/7 or writing $4016 during this time will also screw things up.

sur la doc snes : 
http://wiki.superfamicom.org/snes/show/Timing

7,2 ko/vblank  c'est plus rapide que 6,2 ko/vblank , donc ça reste un peut plus lent et c'est pas négligeable d'avoir un truc un peu plus rapide.

On est d'accord 

J'ai l'impression que beaucoup suis le forum snesdev , pourtant a ma connaissance il n'y a personne qui code sur SNES ici ^^'

J'aime bien lire ce que font les homebrewers des autres machines, je lis aussi spritesmind qui est lui sur le dev MD 

[Stef]

Ok mais au delà de la démo technique, l'objectif un jour, c'est bien d'avoir un jeu du niveau technique de SMK ou de F-Zero ?

A la base c'est une démo technique, mais là clairement c'est le rendu de mode 7 le bottleneck et clairement si gasega arrive à faire tourner une démo préléminaire à 30 FPS, tu peux être assuré qu'il sera capable de faire un vrai jeu complet avec le même niveau de performance... car là tout n'est pas encore optimisé. Il suffit de voir ses démos préliminaires de wolfenstein 3D où ça tournait à 12 FPS et le jeu quasi finalisé tourne minimum à 15 FPS.

ce jour là il faudra bien lacher la MD qui a ses limites quand même, pour passer au MCD et pourquoi pas à la 32X pour afficher un jeu aussi coloré que ce qu'on a sur Snes.

Franchement le 32X, même si le faible nombre de jeux ne le montre pas vraiment, c'est carrément une autre dimension !
Tu ne peux pas comparé le 32X et la SNES, ni même le SFX et le 32X... Le 32X est *largement* plus puissant.
Le 32X te permet d'accèder à un frame buffer full 16 bits (RGB555) par exemple et la puissance des 2 SH-2 est sans commune mesure avec ce qu'on a avec la SNES ou la MD, c'est juste incomparable...

A votre avis, est il possible de cumuler les capacités du MCD et de la 32X pour avoir à la fois le mode 7 du MCD et la palette étendue de la 32X dans un jeu de course ?

Dans les faits, l'association MCD32X n'aura donné qu'un gain de couleurs pour quelques jeux MCD en FMV, d'où ma question de savoir si cette association aurait pu donné quelque chose de plus intéressant dans des vrais jeux.

C'est possible, le 32X a été fait pour être combiné avec le MCD, mais dans les faits il y a seulement 4 ou 5 jeux sortis pour ce setup, et seulement des jeux de type FMV... réellement un 32X + MCD ça ressemble à une Saturn sans ses capacités vidéo.

Si il y a plus de jeux MD que sur SNES , c'est surtout que sur la MD c'est clairement plus facile de codé dessus , par exemple si on voit sur le forum pas mal d jeux MD sont fait grâce au Basic , la MD a un meilleur processeur et les contrainte technique sont moindre.

Sur SNES je peux en parlé je code dessus , rien que pour avoir la coupure d'un personnage quand il est au bord de l'écran c'est un casse tete ,qui m'a demandé a repensé mon architecture juste pour ça...
De quoi découragé n'importe quel programmeur non chevronné , tu rajoute ceci a la base fréquence , a l'assembleur et au processeur 8/16 et tu as tout les ingrédient réuni pour attiré les programmeurs dans les joies de la programmation SNES

Les transferts DMA sont long du coup obligé de codé une routine tampon , qui permet de ne pas faire les transfert tout d'un coup mais sur plusieurs frame , et seulement pour affiché 8 personnage...
Les contraintes SNES sont dur dans le sens ou tu te loupe et tu as carrément des bugs non émulable , un OAM appelé ailleurs dans le VBLANK gros bug , lecture du port manette ailleurs que sur les 250 microseconde dédie pour dans le vblank , tu as le droit a une VSync de 10seconde ect ect

Donc pour ma part cela ne m'étonne guère qu'il y a peu homebrew sur la SNES.

Je me disais, Kannagi, ça me dit quelque chose :p
C'est bien toi l'auteur du SDK SNES ? On s'est croisé à a RGC...
Sinon oui le fait que la scène MD est plus importante c'est directement lié aussi à l'architecture des 2 machines... y'a beaucoup de fan de la SNES mais quand il découvre le merdier quand ils veulent coder dessus il s'enfuient en courant  
Non vraiment c'est dommage, tu as des capacités vidéo interessantes mais tout le reste autour est bancale et du coup t'es assez frustré :-/
La MD c'est l'inverse, tu pestes sur les capacités graphiques (en fait sur le faible nombre de palette) mais tout le reste est vraiment bien foutu.

Ils sont long car tu les fais long, forcement tu es limité en BP, comme toutes les machines .
En H32 la snes fait du 6,2 ko/vblank (1364 cycles/lignes, et 8 cycles /octets de transfert DMA, le vblank fait 38 lignes), la Md fait 7,2 ko/vblank en H40 ..

Dans la théorie tu as 165.5 bytes / scanline sur SNES avec les cycles de refresh contre 205 bytes / scanline sur MD.
Un autre avantage de la MD c'est que tu peux transférer (plus lentement) durant la période active ce qui n'est pas possible sur SNES.

C'est marrant de vanter le DMA de la Md alors qu'en fait il est lent quand tu accèdes à la VRAM, car le VDP y accède en 8 bit .
Donc en H40 le VDP de la Md fait ses transferts @ 6,71 mhz, la snes toujours @2,68 mhz (merci nintendo d'avoir mis de la ram lente) .
Pour info le transfert DMA VRAM ->VRAM de la PCE en H32 est de 6,3 ko/s en Vblank .

Ben on le vante car même s'il fonctionne en 8 bits (pour la VRAM) il reste plus rapide que celui de la SNES alors que celle-ci est sortie 2 ans après... et à l'époque c'était relativement rapide quand même.
Vers la CRAM/VSRAM le DMA va effectivement 2 fois plus vite, c'est vrai que c'est dommage de ne pas avoir la même capacité pour la VRAM mais déjà les performances sont largement acceptable (et je pense que ça aurait bien augmenté les couts car 128 ko de VRAM obligé pour ça).

Et lancer un duel : SuperFX vs Sega Virtua Processor !

L'idée est bonne dans les faits mais je crois que personne n'a jamais tenté de codé sur SuperFX ou sur Sega Virtua Processor.

Il me semble que le SuperFX est bien documenté et que tu as un assembleur fonctionnel, certains programmes dessus il me semble sur NesDev. Le problème pour moi, c'est que déjà ce n'est plus vraiment de la SNES (mais bon ça c'est perso)... aussi tu te fermes au cart flash ne supportant pas le SFX, c'est à dire la plupart... puis si tu dois produire des cartouches pour une éventuelle distribution ça va être compliqué.
Aussi le SuperFX a des instructions super dédiées (à l'inverse du SVP), genre des instructions PLOT pour afficher un pixel à un endroit spécifique... c'est vraiment très spécialisé en fait, tu ne peux pas tout faire avec.

[airdream]

Arretez de dire que parce qu on prefere la MD on crache systematiquement sur le mode 7.
Moi qui suis plus SEGA, je suis vraiment fan de ce mode.
aujourd hui forcement pour la majorite des joueurs ca a mal vieilli, mais en 1990 ca donnait une nouvelle sensation jusque la inconnu, et des possiblites differentes pilotwings et un bon exemple, et en plus j adore ce jeu, tout comme f zero qui reste mon je de course ultime et pour lequel je suis surpris de voir la demo MD, qui est juste magnifique a mes yeux, pour l'exploit et non la comparaison avec la snes qui est et restera superieur quoi qu il en soit. de toutes facon sur MD ca ne deviendra jamais un jeu entier, trop de boulot pour un resultat qui restera mitigé.
En dehors du mode 7, bah la MD est devant en terme d animation, les BTU etaient un de mes genre favoris a mon adolescence, et sur SNES avec 3 ennemis non clairement ca me rebutais, dommage car il est vrai les couleurs etant plus abondantes, on avait de beaux screen comme batman returns qui est un de mes favoris.
Les shoot en dehors de quelques perles sur snes qui s en sortent vraiment bien, on a pas la peche qui les caracterisent sur MD.
Pour la comparaison 32000 / 512 couleurs n est pas representatif, je prefere comparer le nb de couleurs affichees simultanément qui est plus parlant.

[Seb25]

A noter qu'au Bresil, Tec Toy a développé en 1998 Duke Nukem 3D sur Megadrive ... de la vraie 3D (mais ultra moche, mais VRAIE 3D)

Alors ça je ne crois pas, la version MD reprend visiblement un moteur similaire à Wolfenstein puisqu'on a les mêmes limitations, aucune notion de hauteur, pas d'étages, d'escaliers, tout est au même niveau.

Sur le wiki us : The visuals were drastically simplified, being closer to early shooters like Wolfenstein 3d

Même sur PC, le 1er fps en vraie 3D c'est Quake

Et la vraie 3d sans add-on sur MD, ça tourne à 3/5 fps comme on l'a vu dans F22 interceptor, le jeu de golf posté par airdream ou Hard drivin.

[Stef]

Alors ça je ne crois pas, la version MD reprend visiblement un moteur similaire à Wolfenstein puisqu'on a les mêmes limitations, aucune notion de hauteur, pas d'étages, d'escaliers, tout est au même niveau.

Pourtant effectivement en interne c'est vraiment un moteur 3D avec du rendu de polygone texturé, ce n'est pas un raycaster comme wolf3D ou doom. Bien sur pour avoir de meilleur performance le sol et le plafond ne sont pas texturés mais l'architecture du moteur pourrait le supporter. C'est le seul jeu sur MD du genre à utiliser un vrai moteur 3D, les autres utilisent tous un raycaster.

Et de la vraie 3D flat, ça peut relativement bien tourner sur MD, quasiment aussi bien que ce que le super FX de la Snes permet:
https://m.youtube.com/watch?v=YUZpF2JLF4s

[Invité]

Un autre avantage de la MD c'est que tu peux transférer (plus lentement) durant la période active ce qui n'est pas possible sur SNES.

Exact, mais ça stope le CPU, et il me semble que c'est quasiment jamais utilisé (sauf pour des changement de palettes) ..
Même WM revendique un "modeste" 6ko de transfert DMA .

il reste plus rapide que celui de la SNES alors que celle-ci est sortie 2 ans après.

C'est vrai, seulement sur snes c'est plus lent à cause de la ram pourrie, une WRAM @ 3,58 comme la fast rom, et ton DMA tournait @3,58 aussi, tu augmentes la BP du DMA de 30% ..
Par contre tu mets seulement 64 ko de RAM, et non les 128 kikoulol marketing, pour dire à la TV, 2x plus que chez SEGA .

Tout comme le Md aurait eu une BP de malade avec des accès 16 bits à la VRAM ..

Et de la vraie 3D flat, ça peut relativement bien tourner sur MD, quasiment aussi bien que ce que le super FX de la Snes permet:
https://m.youtube.com/watch?v=YUZpF2JLF4s

Oui mais on est loin de voir tourner un jeu complet,il manque pas mal de choses par rapport à starfox, ou au moins le 1er niveau ..

[Stef]

Exact, mais ça stope le CPU, et il me semble que c'est quasiment jamais utilisé (sauf pour des changement de palettes.

Pour la palette tu fais ça durant le h blank donc ça va vite mais tu transfers que quelques couleurs par scanline. Sinon le vdp a quand même un fifo, tu peux très bien entrelacer ton code de transfer et faire autre chose en même temps, le tout avec le cpu et sans cycles perdus. Mais c'est vraiment dans un cas ou tu souhaites transférer le max par frame.

C'est vrai, seulement sur snes c'est plus lent à cause de la ram pourrie, une WRAM @ 3,58 comme la fast rom, et ton DMA tournait @3,58 aussi, tu augmentes la BP du DMA de 30% ..
Par contre tu mets seulement 64 ko de RAM, et non les 128 kikoulol marketing, pour dire à la TV, 2x plus que chez SEGA .

Ça n'a rien a voir avec la vitesse de la ram... C'est la vitesse du processeur vidéo et surtout les accès VRAM qui limitent ici (comme c'est le cas sur MD).
Sinon lors d'un transfert type rom --> VRam (ce qui arrive souvent) tu irais plus vite avec la Fast Rom et ce n'est pas le cas.

[Invité]

tu peux très bien entrelacer ton code de transfer et faire autre chose en même temps, le tout avec le cpu. Mais c'est vraiment dans un cas ou tu souhaites transférer le max par frame.

Ok, mais qui ne veux pas transférer un max / frame ??
Même WM pour son BTU reste dans le vblank pour les transfert .
 

Ça n'a rien a voir avec la vitesse de la ram... C'est la vitesse du processeur vidéo et surtout les accès VRAM qui limitent ici (comme c'est le cas sur MD).

Ah bon, et tu crois que la fréquence de 2,68 mhz (donc les 8 master cycles/octet) ça correspond a quoi ???
étant donné que la WRAM tourne à 2,68(ainsi que la slow rom) et est la partie la plus lente de la machine ton DMA est obligé d'être calé dessus,le DMA ne peux pas transférer plus que la vitesse de la RAM et/ou ROM,même si il peux être 2 fois plus rapide .

Dans les faits la snes transfère un mot tout les 2 cycles (si je me trompe pas), mais à 2,68 mhz,et non à la vitesse du proc vidéo comme sur Md ou PCE . .

Sinon lors d'un transfert type rom --> VRam (ce qui arrive souvent) tu irais plus vite avec la Fast Rom et ce n'est pas le cas.

Non, car la fréquence est bloquée sur 2,68mhz, et le fait d'avoir de la fast rom ne change rien aux timings des transferts, ce serra toujours 8 master cycles / octets, c'est figé   ..
Et c'est figé @2,68 mhz à cause de la WRAM .

[Seb25]

Alors ça je ne crois pas, la version MD reprend visiblement un moteur similaire à Wolfenstein puisqu'on a les mêmes limitations, aucune notion de hauteur, pas d'étages, d'escaliers, tout est au même niveau.

Pourtant effectivement en interne c'est vraiment un moteur 3D avec du rendu de polygone texturé, ce n'est pas un raycaster comme wolf3D ou doom. Bien sur pour avoir de meilleur performance le sol et le plafond ne sont pas texturés mais l'architecture du moteur pourrait le supporter. C'est le seul jeu sur MD du genre à utiliser un vrai moteur 3D, les autres utilisent tous un raycaster.

Et de la vraie 3D flat, ça peut relativement bien tourner sur MD, quasiment aussi bien que ce que le super FX de la Snes permet:
https://m.youtube.com/watch?v=YUZpF2JLF4s

Je vois mais le résultat aurait été plus probant avec au moins un niveau supérieur avec un escalier parceque là on a vraiment l'impression d'un Wolf avec une skin Duke Nukem

Pour la démo de Star fox, ça tourne bien sauf les déchirures d'écran horizontales, après il faut voir en conditions de jeu si ce serait aussi fluide mais c'est déjà bien mieux que ce qu'on pouvait voir dans les jeux 3D flat de l'époque.

[lessthantod]

Votre mission si vous l'acceptez, c'est de trouver une ode à la SNES qui puisse rivaliser avec celle là ...



TOUKO, je compte sur toi ...

[Invité]

majestueux ! :)

[Invité]

Un seul jeu suffit :

[Stef]

Ok, mais qui ne veux pas transférer un max / frame ??
Même WM pour son BTU reste dans le vblank pour les transfert .

Bien sur, raisonnablement tu restes dans le vblank, je voulais juste pointer un avantage sur l'architecture du VDP de la MD. Ses ports d'écritures avec le FIFO est vraiment bien pensé, et surtout il lui reste un peu de marge même pendant l'affichage là ou le VDP de la SNES est au taquet et n'accepte absolument aucun accès pendant la période active.
 

Ah bon, et tu crois que la fréquence de 2,68 mhz (donc les 8 master cycles/octet) ça correspond a quoi ???
étant donné que la WRAM tourne à 2,68(ainsi que la slow rom) et est la partie la plus lente de la machine ton DMA est obligé d'être calé dessus,le DMA ne peux pas transférer plus que la vitesse de la RAM et/ou ROM,même si il peux être 2 fois plus rapide .

Si le DMA de la SNES est synchronisé sur 8 master cycles c'est à cause du fonctionnement interne au PPU qui ne peut pas accepter plus d'écriture en VRAM. Et si on trouve 2.68 Mhz c'est logique car la WRAM est également synchronisé sur 8 master cycles et je dirais même que c'est un calcul de Nintendo bien évidemment. Tu t'imagines bien que si le DMA pouvait aller plus vite (6 master cycles) Nintendo ne se serait pas gêné pour en profiter avec la Fast Rom...
Sur MD la RAM n'est pas si rapide, le gros avantage c'est que le BUS est 16 bits et que le VDP passe par le FIFO pour le DMA ce qui lui permet de lire 16 bits en externe et de gérer les transferts en 8 bits (VRAM) en interne, du coup la RAM (et la ROM) de la MD suit sans problème... Avec de la VRAM 16 bits ça aurait déjà été plus compliqué, je pense que certaines ROM MD (les premières) n'auraient pas suivi (donc un passage par la RAM obligatoire).

[Invité]

Je me disais, Kannagi, ça me dit quelque chose :p
C'est bien toi l'auteur du SDK SNES ? On s'est croisé à a RGC...
Sinon oui le fait que la scène MD est plus importante c'est directement lié aussi à l'architecture des 2 machines... y'a beaucoup de fan de la SNES mais quand il découvre le merdier quand ils veulent coder dessus il s'enfuient en courant  
Non vraiment c'est dommage, tu as des capacités vidéo interessantes  mais tout le reste autour est bancale et du coup t'es assez frustré :-/
La MD c'est l'inverse, tu pestes sur les capacités graphiques (en fait sur le faible nombre de palette) mais tout le reste est vraiment bien foutu.

Non pas du tout , je ne suis jamais allé a la RGC et je ne suis pas l'auteur de SDK SNES.
Disons que ça me semble être un événement sympatique mais c'est loin d’être a coté de chez moi.
Sinon je suis d'accord avec toi la SNES a quand même pas mal de truc bancale même si ces capacités vidéo sont bien.
C'est tout le souci d'attiré de nouveau programmeur sur SNES , c'est pas simple il faut vraiment être motivé pour codé dessus.
Tout le monde parle de Nesdev ,en faite de son sous forum Snes-Dev pour être exact, mais je trouve que cela est représentative de la scéne homebrew de la SNES , il n'y a qu'un sous forum consacré au développent sur SNES   .

Il me semble que le SuperFX est bien documenté et que tu as un assembleur fonctionnel, certains programmes dessus il me semble sur NesDev. Le problème pour moi, c'est que déjà ce n'est plus vraiment de la SNES (mais bon ça c'est perso)... aussi tu te fermes au cart flash ne supportant pas le SFX, c'est à dire la plupart... puis si tu dois produire des cartouches pour une éventuelle distribution ça va être compliqué.
Aussi le SuperFX a des instructions super dédiées (à l'inverse du SVP), genre des instructions PLOT pour afficher un pixel à un endroit spécifique... c'est vraiment très spécialisé en fait, tu ne peux pas tout faire avec.

Oui bien sur mais comment dire c'est pas vu de démo l'utilisant et il n'y a qu'un exemple de code utilisant apparemment la Super-FX (que j'ai pas compilé) donc je peux pas vraiment le dire , mais ça serait exagérer de parler de bien connaitre la Super-FX,quand j'ai commencé la programmation SNES les exemple pour afficher sur la SNES sont horrible vraiment et donc très peu ouvert au nouveau programmeur.
Mais je me sens pas de décortiquais a nouveau le code source d'un code SNES , alors utilisant la Super-FX...

Je vais allé plus loin , mais vraiment j'ai l'impression que la plupart respecte peu les règles de programmation de base , ça saute jamais de ligne , ça connais pas les define et ça utilise des nombre magiques franchement deja que l'assembleur est pas le plus simple comme langage alors si le codeur code comme ces pieds ça rend le code encore plus imbuvable.
D'ailleurs ça revient un peu pourquoi y'a surement peu de codeur dessus , (et c'est pour cela que je travaille sur un tuto SNES).
Apres y'a de jolie code mais la plupart des exemple ceux qui sont dispo pour 'apprendre' a codé sur SNES ou a montré des exemples, sont surement les meilleurs exemple a ne pas faire x).

[Invité]

Si le DMA de la SNES est synchronisé sur 8 master cycles c'est à cause du fonctionnement interne au PPU qui ne peut pas accepter plus d'écriture en VRAM. Et si on trouve 2.68 Mhz c'est logique car la WRAM est également synchronisé sur 8 master cycles et je dirais même que c'est un calcul de Nintendo bien évidemment. Tu t'imagines bien que si le DMA pouvait aller plus vite (6 master cycles) Nintendo ne se serait pas gêné pour en profiter avec la Fast Rom...

Ah bon, et tu connais un DMA qui sais faire ça toi ???, varier ses cycles en fonction de la vitesse source/destination ??

Sur MD la RAM n'est pas si rapide, le gros avantage c'est que le BUS est 16 bits et que le VDP passe par le FIFO pour le DMA ce qui lui permet de lire 16 bits en externe et de gérer les transferts en 8 bits (VRAM) en interne, du coup la RAM (et la ROM) de la MD suit sans problème

Il me semble bien que du moins les ROM Md sont équivalentes en terme d'accès que la fast rom de nintendo ..

[Stef]

Ah bon, et tu connais un DMA qui sais faire ça toi ???, varier ses cycles en fonction de la vitesse source/destination ??

Mais ça pourrait très bien être géré par le bus, comme c'est le cas actuellement quand tu accèdes à la fast ROM depuis le CPU !
Le fait est que de toute façon le PPU ne permet pas d'accéder à la VRAM depuis l'extérieur plus rapidement.

Il me semble bien que du moins les ROM Md sont équivalentes en terme d'accès que la fast rom de nintendo ..

Oh que non, les premières ROM MD sont même assez lentes en réalité (de l'ordre de 500ns) et les dernières sont probablement plus lentes que la Fast Rom sur SNES... C'est l'avantage de l'architecture 16 bits de la MD.
Pour supporter un DMA type ROM --> VRAM il faut que la ROM tourne à 1.61 Mhz minimum (500 ns c'est suffisant) et pour un DMA type ROM --> CRAM il faut le double, du coup ça ne fonctionne qu'avec les ROM les plus rapides MD (sinon il faut passer par un transfert type RAM --> CRAM).

[Stef]

Non pas du tout , je ne suis jamais allé a la RGC et je ne suis pas l'auteur de SDK SNES.
Disons que ça me semble être un événement sympatique mais c'est loin d’être a coté de chez moi.

Ah désolé, j'ai vraiment une mémoire à 2 balles...
Je me souviens maintenant, c'était juste sur le forum en fait que j'ai vu ton pseudo

Tout le monde parle de Nesdev ,en faite de son sous forum Snes-Dev pour être exact, mais je trouve que cela est représentative de la scéne homebrew de la SNES , il n'y a qu'un sous forum consacré au développent sur SNES   .

Ben à défaut d'avoir mieux en fait :-/

Oui bien sur mais comment dire c'est pas vu de démo l'utilisant et il n'y a qu'un exemple de code utilisant apparemment la Super-FX (que j'ai pas compilé) donc je peux pas vraiment le dire , mais ça serait exagérer de parler de bien connaitre la Super-FX,quand j'ai commencé la programmation SNES les exemple pour afficher sur la SNES sont horrible vraiment et donc très peu ouvert au nouveau programmeur.
Mais je me sens pas de décortiquais a nouveau le code source d'un code SNES , alors utilisant la Super-FX...

Je vais allé plus loin , mais vraiment j'ai l'impression que la plupart respecte peu les règles de programmation de base , ça saute jamais de ligne , ça connais pas les define et ça utilise des nombre magiques franchement deja que l'assembleur est pas le plus simple comme langage alors si le codeur code comme ces pieds ça rend le code encore plus imbuvable.
D'ailleurs ça revient un peu pourquoi y'a surement peu de codeur dessus , (et c'est pour cela que je travaille sur un tuto SNES).
Apres y'a de jolie code mais la plupart des exemple ceux qui sont dispo pour 'apprendre' a codé sur SNES ou a montré des exemples, sont surement les meilleurs exemple a ne pas faire x).

Y'a pourtant pas mal de gars talentueux sur NesDev justement et qui codent sur Snes, tu as même quelques SDK, mais j'imagine que tu connais déjà tout ça non ? Ca métonne que ça soit si... archaique.

[Invité]

Y'a pourtant pas mal de gars talentueux sur NesDev justement et qui codent sur Snes, tu as même quelques SDK, mais j'imagine que tu connais déjà tout ça non ? Ca métonne que ça soit si... archaique.

Oui je connais tout cela , Je connais pas tout les gars de NesDev , mais si tu me parle du sous forum SNES-Dev il n'y a alors que 2,3 gars que je considère talentueux , le reste a force d’être sur la prog SNES ont ds connaissances mais rien extraordinaire de mon point de vue.

Après très peu vienne du 'monde de la programmation' en général ils sont plus d'un autre milieu alors les regles de programmation c'est pas leur fort , ils sont tres compétent techniquement mais cela ne veut pas dire que ça soit des personnes qui sont fort en algorithmie ou qu'il maitrise plusieurs paradigme , ce sont des domaines très différents.
Pour ma part par exemple faire du pascal + algo te rend plus compétent que de faire de l'assembleur sur une machine particulière.

[Invité]

Pour supporter un DMA type ROM --> VRAM il faut que la ROM tourne à 1.61 Mhz minimum (500 ns c'est suffisant) et pour un DMA type ROM --> CRAM il faut le double, du coup ça ne fonctionne qu'avec les ROM les plus rapides MD (sinon il faut passer par un transfert type RAM --> CRAM).

Je suis pas sur de tes calculs, même si des roms de 500 ns ont été utilisées avec les premiers jeux il semble que 200 ns soit le minimum pour un fonctionnement normal  ..

http://www.sega-16.com/forum/archive/index.php/t-17019.html

Donc pour la fast rom snes il faut de la 270 ns, largement au même niveau que celle dont la Md a besoin .
Donc si effectivement avoir de la ROM aussi rapide sur MD ne sert pas trop à grand chose, la RAM par contre doit être à cette vitesse ..

[sengoku 2]

Et si tu veux mon avis perso, je pense que même la Megadrive seule est capable de faire même mieux que le Final Fight MCD qui fait pourtant figure de référence... Certes c'était quasi-impossible à l'époque, mais de nos jours si tu reprogramme tout le jeu, et que tu l'enfile sur une cartouche de 64 Megs, mis à part pour la bande sonore (et encore), pour tout le reste ont pourrait même exploser la version arcade...

La version arcade est hors de portée, niveau graphisme ( résolution graphique de 384*224 ) et nombre de couleurs à l'écran .

[tbp]

Certes, on aura pas des dégradés de couleurs et une résolution aussi fine mais je pense qu'on en sera pas si loin que ça dans Project Y si le jeu est bien peaufiné, en tous cas c'est bien parti pour que ce soit le cas. Et à mon avis, Streets of Rage 3 est d'ores et déjà battu d'avance sur le plan visuel et technique donc reste Final Fight CD comme qualité à franchir surtout en terme de sprites de grande taille et de fluidité.
Et les seuls sur SNES à pouvoir soutenir une "comparaison technique" sur ce point particulier sont Final Fight 3 et Turtles IV In Time (et par extension en arcade un titre comme Cadillacs & Dinosaurs).

[lessthantod]

Juste comme ça, pour relancer le débat ... et comme on ne fait pas d’omelette sans casser des œufs, la mauvaise foi est de rigueur!



Bon la formule commence à s'épuiser entre ces 2 gars, c'est toujours les mêmes argument pour/contre ... mais sinon la conclusion est assez juste, ce sont 2 super jeux qui ne luttent pas sur le même terrains. G'NG sur MD est l’adaptation "fidèle" à l'arcade, alors que SG'NG a été pensé pour les consoles de salons et pour exploiter à fond les capacité technique de la SNES. Et puis 4 années les séparent, alors forcément que SG'NG est un mieux sur tous les points, il a eu le temps d'améliorer/peaufiner tous les éléments d'un G'NG.

[Invité]

Euh dans ce cas là vas y à fond ... et rions de ces 2 versions avec la SGX 

[Invité]

(à noter que la version SGX est sortie en meme temps que la version MD (ou presque))

[Invité]

Et la version pour Sharp x68000

[Seb25]

Bon la formule commence à s'épuiser entre ces 2 gars, c'est toujours les mêmes argument pour/contre ... mais sinon la conclusion est assez juste, ce sont 2 super jeux qui ne luttent pas sur le même terrains. G'NG sur MD est l’adaptation "fidèle" à l'arcade, alors que SG'NG a été pensé pour les consoles de salons et pour exploiter à fond les capacité technique de la SNES. Et puis 4 années les séparent, alors forcément que SG'NG est un mieux sur tous les points, il a eu le temps d'améliorer/peaufiner tous les éléments d'un G'NG.

Non, SG'NG est sortit en 1991, GG Arcade en 1988 donc 3 ans les séparent après c'est toujours ce que j'ai aimé chez Nintendo, on a des épisodes exclusifs à la console et pas des portages directs de l'arcade, quand même rien qu'avec cet exemple on peut se dire que les 2 consoles sont indispensables, pas comme maintenant où on a la même version d'un jeu quelque soit la machine.

[Seb25]

Et la version pour Sharp x68000

elle est hors concours, vu le prix de la machine à l'époque même si elle est au top.