Re: MEGADRIVE vs SUPER NINTENDO : Fight !

[Invité]

Il y a donc un truc que je pige pas, car mode 7 = 1 seul plan

Simple à comprendre, l'écran est divisé en 3, la partie où l'avion zoome est en mode 7, l'autre un mode graphique standard,le hud en haut est un plan. .
C'est facile à voir, l'avion ne passe jamais sur le plan du dessous, tu peux voir une ligne de démarcation .

Tu vois là, une des utilisations du HDMA,mais faisable tout aussi facilement via des intérruptions hsync .

[airdream]

Simple à comprendre, l'écran est divisé en 3, la partie où l'avion zoome est en mode 7, l'autre un mode graphique standard .
C'est facile à voir, l'avion ne passe jamais sur le plan du dessous, tu peux voir une ligne de démarcation. Le hud est un plan.

Merci pour l'info, belle utilisation du trick de la part de Konami, ingénieux!

[Invité]

C'est utilisé aussi dans MK, et dans plein d'autres .

[airdream]

Oui mais la les sprites passent de la zone haute a la zone basse, la ou sur SMK chacun reste dans sa zone

[Invité]

Oui mais la les sprites passent de la zone haute a la zone basse, la ou sur SMK chacun reste dans sa zone

CAD ??
Le changement de mode n'impacte pas les sprites .

[airdream]

Je decouvre rien de plus, dans contra 3 les deux guerriers comme leurs tirs passent devant la zone haute ou basse, tandis que SMK aucun sprites ne change pas du bas vers le haut ou vice versa

[Invité]

Je decouvre rien de plus, dans contra 3 les deux guerriers comme leurs tirs passent devant la zone haute ou basse, tandis que SMK aucun sprites ne change pas du bas vers le haut ou vice versa

D'accord, mais comme dit plus haut, c'est que le changement de mode n'impacte pas les sprites, du coup tu peux changer les modes sans que les sprites soient gênés .
Mario kart peut en faire de même si les devs en avaient une utilité .
Sur MD c'est pareil, changer le mode de scroll à la volé ne modifie pas les sprites .

[Stef]

Désolé par avance je débarque sur le forum et le topic donc j'ai pas bien suivie les debats, possible que je sois HS ou redondant.


Je profite de la discussion sur les parallaxes pour evoquer la table de scroll cablé en hard sur Megadrive qui semble quand meme une feature super sympa pour les programmeurs. On peut préparer une table a l'avance avec une valeur de scroll differente pour chaque ligne de chaque plan et meme pour chaque bande verticale 16 pixels de chaque plan (je me demande si les tables de scroll de ce genre existe sur d'autre machines?). 
Faire des parallaxes en pagailles, du line scroll ou autres distorsions semble un jeu d'enfant sur Megadrive donc ils s'en sont pas privés. La table de scroll est probablement la particularité hardware la plus singulière de la Megadrive, c'est peut etre son identité (avec son manque de palettes).

Quand y a un peu de talent ca donne parfois des effets de parallaxes réussit:

Eliminate Down



...

D'une certaine facon si on chipote (c'est le bute du topic j'imagine) on peut dire que les 2 derniers gif de Gynoug ne sont pas parfaitement reproductible sur SNES (a cause des parallaxes verticales sur les 2 plans simultanés) Sans oublier que la Megadrive fait tous ca sur des plans en 320 pixels de large contre 256 sur SNES.
Mais surtout sur Megadrive tout semble devs friendly (a part ses 4 pauvres palettes qui doivent etre un casse tete pour les graphistes j'imagine) ce qui est loin d'etre le cas de la SNES.

Ca c'est un super résumé des capacité de scroll de la MD
Effectivement dans les cas les plus complexes il est même pas tout a fait possible de répliquer certains effets cablés de la MD sur SNES (comme le quadruple scrolling de gynoug : 2 Horizontaux par scanline + 2 verticaux par colonne). Sur SNES effectivement on peut reproduire le scrolling vertical par colonne sur un granularité plus fine (8 pixels à la place de 16 pixels sur MD) mais la lourdeur (tant en code qu'en ressource) pour reproduire cet effet (en utilisant l'offset par tile) fait que peu de développeurs y ont eu recours alors que sur MD on voit cet effet utilisé dans pas mal de jeux. C'est vrai que la MD mettait très en avant ses capacités de scrolling, la SNES elle c'était plutot son mode 7 !

Et en plus c'est a priori cette communication particulière sous forme de palette/couleur/layer entre le VDC et le VCE qui a du donner l'idée de la SupergrafX? car c'est grace a ca qu'il est possible de mettre 2 VDC en parallèle car c'est l'information sur le layer (sprite ou background) qui a permis a priori de fusionner les 2 flux correctement dans un chip supplémentaire (et sans avoir besoin non plus de doubler le DAC et les palettes qui sont externe, c'est bienvenu aussi).
Si les VDC sortaient un simple signal RGB 9bit (ou directement un signal analogique) ca n'aurait pas ete possible d'en combiner 2 (le background de l'un aurait systématiquement ecrasé les sprites de l'autre). J'ai tendance a croire que la creation de la SupergrafX doit venir de ce constat, de cette possibilité singulière de parallélisation qu'offrait le VDC et le VCE.

En fait tu retrouves ce genre de chose sur d'autres machines, en tout cas sur MD tu as une sortie "digital" sur le VDP avec une pin SPR pour l'information de sprite/background, 4 pins pour la couleur et 2 pins pour la palette et une pin pour la priorité, le 32X utilise cette information pour blender son signal vidéo avec celui du VDP de la MD (et donc avec la possibilité de s'intercaler entre les plans et même de jouer avec les priorités).

[Stef]

La HSCROLL table de la MD est une astuce (très bonne) de sega pour palier la lenteur des interruptions du 68k .
Mais c'est pas gratuit, tu dois avoir une table en RAM, que tu copies en VRAM à chaque vblank .
Tu perds donc de la BP DMA.

La snes ou n'importe quelle console avec des interrutptions hsync peuvent faire la même chose, et en plus c'est plus flexible car tu n'es pas limité au seul scroll horizontal .
Le HDMA de la snes est bien meilleurs que le hscroll de la MD .

Oui le HDMA de la snes fonctionne comme ça, mais lui il peut changer tout un tas de registres, et pas seulement le H-scroll, en plus la table est en RAM .

Définitivement je ne pense pas que ça soit dans un soucis de lenteur d'interruption mais simplement d'ajouter des capacités de scrolling "hardware" et très visibles pour les développeurs... et ça a marché, beaucoup de jeux MD exploitent ces capacités. Sur SNES, le HDMA, aussi flexible soit-il est plus tricky à utiliser pour les développeurs et bouffe aussi un peu de temps CPU. Et l'air de rien, tu monopolises assez vite les différents canaux HDMA dés que tu veux utiliser plusieurs effets à la fois (reprogrammation de palette, scrolling horizontal par line sur 2 plans etc...).
Bref, c'est plus flexible mais ça a aussi ses limites. Sur SNES le HDMA est obligatoire en fait car le VDP n'accepte aucun accès extérieures pendant la période active (à l'inverse du VDP de la MD), la plupart des registres du VDP ne sont pas accessibles même pendant un H-Int ! C'est pour ça qu'ils ont intégrer un controleur spécialisé qui est capable de modifier certaines valeurs du processeur vidéo au seul moment où c'est possible en interne.

Le vscroll toutes les 2 tiles est plus pratique sur Md, mais est aussi facilement simulable sur PCE ou snes, sur pce dans la majorité des cas.
La snes peut scroller chaque tile sur X/Y, c'est plus flexible, mais plus gourmand en CPU aussi .

Comment tu reproduis ça sur PCE ??? Et sur SNES en pratique l'offset par tile est utilisé pour reproduire le même effet que sur MD (scrolling par colonne) sauf que c'est plus complexe à mettre en oeuvre :p
Y'a RR² qui l'utilise dans un niveau il me semble...

[Invité]

Définitivement je ne pense pas que ça soit dans un soucis de lenteur d'interruption mais simplement d'ajouter des capacités de scrolling "hardware" et très visibles pour les développeurs... et ça a marché, beaucoup de jeux MD exploitent ces capacités. Sur SNES, le HDMA, aussi flexible soit-il est plus tricky à utiliser pour les développeurs et bouffe aussi un peu de temps CPU. Et l'air de rien, tu monopolises assez vite les différents canaux HDMA dés que tu veux utiliser plusieurs effets à la fois (reprogrammation de palette, scrolling horizontal par line sur 2 plans etc...).

Tu compares hscroll de la Md, et possibilité de changer plein de choses, si on part juste avec le scroll horizontal, la hscroll table ne présente aucun intérêt par rapport au HDMA ou aux intérruptions .

Et si tu mixes plusieurs types de scrolls horizontaux dans une frame, la hscroll table est bien moins pratique .
Si tu utilises le HDMA pour la même chose que le hscroll de la MD, ce serra plus pratique et rapide avec le HDMA .

Comment tu reproduis ça sur PCE ???

Avec du swap de tiles, charles mac donalds a refait le niveau de musha comme ça .
Tu refaits pas tout, le chat ou le robot de contra serraient plus difficile, car y'a pas mal de tiles.

le HDMA, aussi flexible soit-il est plus tricky à utiliser pour les développeurs et bouffe aussi un peu de temps CPU

Bien moins que ce qui est consommé par le HSCROLL lors de la copie en VRAM, et moins aussi que de le faire via intérruptions .

Bref, c'est plus flexible mais ça a aussi ses limites

Comme bcp de fonctions, mais moins que le hscroll .

[upsilandre]

La HSCROLL table de la MD est une astuce (très bonne) de sega pour palier la lenteur des interruptions du 68k .
Mais c'est pas gratuit, tu dois avoir une table en RAM, que tu copies en VRAM à chaque vblank .
Tu perds donc de la BP DMA.

C'est vrai, ca doit bouffer dans les 15% du DMA du vblank (et moins de 1Ko de RAM) mais ca doit etre super pratique pour le codeur donc ca reste raisonnable comme cout et ca doit permettre d’économiser des ressources CPU (meme si c'est pas forcement de ca dont manque la MD), j'imagine que quand y a juste quelques parallaxes et pas de line scroll ou de découpage vertical il est préférable de s'en passer.
Je retiens la lenteur des interruptions ca c'est une bonne info qui donc j'imagine a du etre la premiere raison de cette feature mais c'est une belle feature (Je viens de découvrir Adventure of batman and robin sur le topic, purée c'est une tech demo de la table de scroll a chaque level, c'est plein de belles idées d'effet, je crois qu'ils ont fait le tour des possibilités, un vrai catalogue, faudrait que je fasse quelques gif)

je me demande si les tables de scroll de ce genre existe sur d'autre machines?

Oui le HDMA de la snes fonctionne comme ça, mais lui il peut changer tout un tas de registres, et pas seulement le H-scroll, en plus la table est en RAM .
Tout les effet horizontaux que tu donnes sont faisables aussi facilement sur snes ou PCE .

Du line scroll y en a meme sur NES :)
Le HDMA c'est sure que c'est super cool, ca permet plein de chose, j'adore, mais restons dans le cadre du scroll. Ce que je veut dire c'est que je me demandais si il existe des machines qui reprennent strictement le concept de la table de scroll? (En faite je pensais plutot a l'arcade)

Le vscroll toutes les 2 tiles est plus pratique sur Md, mais est aussi facilement simulable sur PCE ou snes, sur pce dans la majorité des cas.
La snes peut scroller chaque tile sur X/Y, c'est plus flexible, mais plus gourmand en CPU aussi .

Sur SNES effectivement avec le o.p.t. tu peux le faire avec meme une meilleur granularité (mais pas sur 2 plans simultanés du coup y a certain effet megadrive, tres rares, qui me paraissent compromis. Sur Megadrive on a quand meme jusqu'a 40 modification des V-scroll par scanline, c'est classe, ils ont ete obligé d'utiliser une memoire interne pour ca tel une cram)
Par contre sur la PCE je suis surpris. Meme sur son unique plan ca me parait compliqué le découpage vertical en software non? histoire d'etre concret y a un exemple de jeu qui utiliserait des parallaxes verticales? (pas de l'animation de tile bien sure :) )

Le problème du Hscroll de la Md c'est si tu veux mixer plusieurs type de scrolls sur une même frame .

C'est vrai que si t'as une portion en line scroll et une portion en parallaxe t'es obligé de traiter la partie parallaxe comme du line scroll mais au final le cout sur Megadrive c'est surtout le DMA donc ca change rien de ce point de vue et ca incite a faire du full line scroll plutot qu'un mixe des 2  

Je suis d'accord, tout sur Md a été pensé pour simplifier la programmation, comme sur PCE, la snes est vraiment tordue et complexe niveau hard .

C'est claire, quelle enfer cette SNES, passer de la Megadrive a la SNES ca a du etre un choc pour les devs de l'epoque, la SNES c'est 100x plus compliqué. Je me demande si c'est pas plus violent (en valeur relative, pas en valeur absolu) qu'entre Saturn et PS1 ou l'une etait bien plus accueillante aussi pour les devs.

[size=14]Je dis pas que la PCE peut sortir 32000 couleurs, y'a aucun trick pour ça, mais le VCE contient la table pour ça, mais seules les 512 premières entrées sont câblées .

Je pense comprendre a quoi tu fais allusion. Tu fais allusion a la table de conversion YUV qui est en 15bit mais si elles sort du 15bit en prenant comme entrée le 9bit RGB de la cram c'est surtout pour eviter de perdre a la conversion (qui serait inévitable si la table YUV etait 9bit), ca me parait plutot une bonne idée, c'est pas superflu. Mais la cram est bien 9bit et tout en interne semble cablé en 9bit. Je pense pas qu'on puisse dire que le VCE est pensé pour le RGB 15bit.

[size=14]Tout à fait, mais c'est quand même pas parfait, car le VPC ne sait pas reconnaître des sprites de priorité haute ou basse et ne peut pas jouer sur la priorité des fonds, le fond du VDC2 serra toujours derrière celui du VDC1.

C'est sur que niveau priorité y a pas de miracle dans cette configuration, ca pose des contraintes mais au moins ca a permit de le faire (doubler le GPU) ce qui n'aurait pas ete possible autrement.
D'ailleurs ces contraintes de priorité forcé on le voit sur Dai Makaimura. Ils ont pas reproduit l'effet d'averse du debut du jeu qu'on retrouve aussi bien dans la version arcade que la version Megadrive qui reprend la meme methode. Ca demandait soit un troisieme plan (CPS1) soit d'utiliser l'arriere plan en changeant la priorité en flickering (flickering qui n'est pas dérangeant ici car on est en plein orage donc ca colle) . Du coup comme on peut pas passer l'arriere plan devant sur SupergrafX ils ont ete obligé de faire l'effet de pluie avec des sprites et c'est moins reussit. C'est d'ailleurs le seul truc qui est moins réussit sur SupergrafX, tout le reste est largement devant (notamment la version megadrive est tres géné par l'utilisation du mode window pour le HUD au lieu d'utiliser des sprites comme sur SupergrafX). Ils ont juste eu un peu de mal aussi avec les ennemis nuages a la fin dans le chateau, ils ont mal géré la répartition des sprites entre les 2 VDC.

[upsilandre]

Ca c'est un super résumé des capacité de scroll de la MD

Sauf que je viens seulement de découvrir Adventure of Batman and Robin. Tout est dans ce jeu, j'aurais fais différemment.

En fait tu retrouves ce genre de chose sur d'autres machines, en tout cas sur MD tu as une sortie "digital" sur le VDP avec une pin SPR pour l'information de sprite/background, 4 pins pour la couleur et 2 pins pour la palette et une pin pour la priorité, le 32X utilise cette information pour blender son signal vidéo avec celui du VDP de la MD (et donc avec la possibilité de s'intercaler entre les plans et même de jouer avec les priorités).

Sympa ce VDP, ils ont pensé a tout, ca repond a ma question.
Sur SNES t'as ce genre de dialogue mais uniquement entre le PPU1 et le PPU2, je sais pas si ca pourrait servir a quelque chose (a priori on pourrait pas doubler les sprites qui sont géré dans le PPU2? mais on pourrait peut etre ajouter encore plus de background et d'autre combinaison avec le mode 7 mais ca serait encore plus de chips qui sont deja trop nombreux et encore plus de compliquation)

[upsilandre]

Tu compares hscroll de la Md, et possibilité de changer plein de choses, si on part juste avec le scroll horizontal, la hscroll table ne présente aucun intérêt par rapport au HDMA ou aux intérruptions .

Ces un peu vache de dire ca comme ca, rien que la simplicité d'acces et la visibilité pour les programmeurs ca a un interet. Et puis changer le H-scroll de 2 plans simultanément avec le HDMA c'est pas intégralement possible comme sur MD, faut a priori choisir entre les bits de poid fort ou de poid faible (meme si c'est pas vraiment genant dans la pratique je pense)  car les registres de Hscroll des 2 plans ne sont pas contigu .

Et si tu mixes plusieurs types de scrolls horizontaux dans une frame, la hscroll table est bien moins pratique .
Si tu utilises le HDMA pour la même chose que le hscroll de la MD, ce serra plus pratique et rapide avec le HDMA .

Je suis pas convaincu que ca puisse se trancher comme ca, y a du pour et du contre.

Avec du swap de tiles, charles mac donalds a refait le niveau de musha comme ça .

il a osé  
En tout cas ca répond a ma question de tout a l'heure, on peut pas faire de parallaxe en Vscroll sur PCE. Je trouvais ca curieux.  

Bien moins que ce qui est consommé par le HSCROLL lors de la copie en VRAM, et moins aussi que de le faire via intérruptions .

Niveau DMA vers la VRAM pendant le Vblank la Megadrive n'est pas meilleur? (c'est une question) car si le Hscroll prend 15% du DMA mais que la MD a +50% de DMA par rapport a la SNES on peut pas dire que ce soit un probleme. Ca reste un atout (de simplicité)

[Invité]

mais ca doit etre super pratique pour le codeur donc ca reste raisonnable comme cout et ca doit permettre d’économiser des ressources CPU

Si la table n'avait pas besoin d'être copiée en VRAM je te dirai oui, mais l'utilisation du DMA halte le CPU, donc tu perds des cycles CPU pendant la copie .
Et si en plus tu mixes différents scrolls dans une frame, tu perds aussi plus de cycles CPU pour modifier ta table contrairement au HDMA et aux intérruptions .

il a osé   
En tout cas ca répond a ma question de tout a l'heure, on peut pas faire de parallaxe en Vscroll sur PCE. Je trouvais ca curieux.   

J'ose rien du tout vu que la demo existe,et que le swap de tiles est une technique vielle comme le monde pour simuler des scrollings .
D'un point de vue du joueur, je vois pas comment tu peux dire si une technique est soft ou hard si le même effet existe sur 2 machines différentes .

Niveau DMA vers la VRAM pendant le Vblank la Megadrive n'est pas meilleur? (c'est une question) car si le Hscroll prend 15% du DMA mais que la MD a +50% de DMA par rapport a la SNES on peut pas dire que ce soit un probleme. Ca reste un atout (de simplicité)

En 256 pixels, non, si tu passes la réso de la MD en 320 (vs 256) oui .
50% non mais 25% en 320 .
En terme d'atout de simplicité je suis d'accord par rapport aux intérruptions, niveau HDMA pas du tout, car c'est aussi simple .

Ces un peu vache de dire ca comme ca, rien que la simplicité d'acces et la visibilité pour les programmeurs ca a un interet. Et puis changer le H-scroll de 2 plans simultanément avec le HDMA c'est pas intégralement possible comme sur MD,

Bien sur que c'est possible, tu as pas mal de jeu snes qui le font, et même si c'est pas du scroll horizontal mais vertical à la ligne, comment crois tu qu'est fait l'effet d'axelay ??

Je suis pas convaincu que ca puisse se trancher comme ca, y a du pour et du contre.

C'est comme je te le dis, le hscroll de la MD c'est 3 modes:
1- scroll tout l'ecran
2- scroll à la tile
3-scroll à la ligne

Donc si tu veux scroller des parties à la tile ou plus, et d'autres à la ligne, soit tu paramètres ta table en scroll ligne et tu modifies toutes les lignes, soit tu changes le scroll via interruptions à chaque foi .
Pas pratique du tout .

D'ailleurs ces contraintes de priorité forcé on le voit sur Dai Makaimura. Ils ont pas reproduit l'effet d'averse du debut du jeu qu'on retrouve aussi bien dans la version arcade que la version Megadrive qui reprend la meme methode.

L'effet y est ,il est fait via des sprites et non un clignotement d'un des fonds avec la pluie (franchement horrible), même l'arcade est moins bien, car il utilise la même technique que sur MD, mais fait clignoter le hud lui (car la borne dispose de 3 plans) en gros la SGX ne fait rien clignoter du tout, la pluie est composée de sprites, et je préfère cet effet,moins dense mais tu n'as pas le clignotement des fonds comme sur MD .
En plus sur Md tu n'as pas l'effet du vent sur les arbres du second plan,alors que sur SGX oui  .
Pareil pour le premier boss, la SGX conserve le second plan alors que la Md est obligé d'utiliser un plan pour le boss (a première vue) .

[upsilandre]

J'ose rien du tout vu que la demo existe,et que le swap de tiles est une technique vielle comme le monde pour simuler des scrollings .

Oui je peux effectivement moi meme citer des dizaines d'exemples d'animation de tile pour simuler de la parallaxe (ou du scroll au pixel) sur toutes les machines meme pré-NES mais ca répondait pas du tout a la question (et c'est bien plus limité). Y a comme un soupçon de mauvaise fois

En 256 pixels, non, si tu passes la réso de la MD en 320 (vs 256) oui .

Ca tombe bien c'est +95% des jeux Megadrive . (sans compter les jeux 256 qui le sont juste pour simplifier les portages comme New zealand story en 256 en arcade)

Bien sur que c'est possible, tu as pas mal de jeu snes qui le font, et même si c'est pas du scroll horizontal mais vertical à la ligne, comment crois tu qu'est fait l'effet d'axelay ??

J'ai pourtant bien dis que c'etait possible. Juste ajouté une nuance qui est qu'on ne peut pas modifier l’intégralité des 2 registres Hscroll. On peut modifier les 2 mais faut choisir poid faible et poid fort contrairement a la Megadrive (et j'ai précisé que c'etait sans doute pas vraiment embetant). C'etait juste pour etre exhaustif.

[Invité]

Oui je peux effectivement moi meme citer des dizaines d'exemples d'animation de tile pour simuler de la parallaxe (ou du scroll au pixel) sur toutes les machines meme pré-NES mais ca répondait pas du tout a la question (et c'est bien plus limité). Y a comme un soupçon de mauvaise fois  

Non, j'ai quand même précisé que c'était simple à faire dans le cas de Vscroll toutes les 2 tiles classique, dans le style le niveau de musha, mais que c'était plus difficile pour un effet comme le boss robot de contra ou le chat de B&R,alors que sur Md c'est "finger in the noze" .

J'ai pourtant bien dis que c'etait possible. Juste ajouté une nuance qui est qu'on ne peut pas modifier l’intégralité des 2 registres Hscroll. On peut modifier les 2 mais faut choisir poid faible et poid fort contrairement a la Megadrive 

Je suis pas du tout sur de ce que tu avances pour ça .
Comment scroller 3 plans, ou les 4 possibles sinon .
Tu as des registres des scroll 16 bits pour chaque plan,sinon impossible d'avoir des écrans virtuel de plus de 256 pixels .
Le HDMA ne bride rien du tout, c'est juste un DMA parfaitement synchronisé sur le H-sync, et de façon automatique sans avoir la latence d'une intérruption .

[Stef]

Je suis d'accord, tout sur Md a été pensé pour simplifier la programmation, comme sur PCE, la snes est vraiment tordue et complexe niveau hard .

C'est claire, quelle enfer cette SNES, passer de la Megadrive a la SNES ca a du etre un choc pour les devs de l'epoque, la SNES c'est 100x plus compliqué. Je me demande si c'est pas plus violent (en valeur relative, pas en valeur absolu) qu'entre Saturn et PS1 ou l'une etait bien plus accueillante aussi pour les devs.

Tu compares hscroll de la Md, et possibilité de changer plein de choses, si on part juste avec le scroll horizontal, la hscroll table ne présente aucun intérêt par rapport au HDMA ou aux intérruptions .

Ces un peu vache de dire ca comme ca, rien que la simplicité d'acces et la visibilité pour les programmeurs ca a un interet. Et puis changer le H-scroll de 2 plans simultanément avec le HDMA c'est pas intégralement possible comme sur MD, faut a priori choisir entre les bits de poid fort ou de poid faible (meme si c'est pas vraiment genant dans la pratique je pense)  car les registres de Hscroll des 2 plans ne sont pas contigu .

Tu vas vite comprendre que Touko a souvent un avis négatif sur la MD car intrinsèquement c'est une machine qu'il n'aime pas quoiqu'il en dise :p Moi j'avoue avoir une certaine aversion vis à vis de la SNES car de mon point de vue de développeur je trouve réellement que cette machine a connu un succès assez immérité (surtout par rapport à la MD) tant cette machine est mal fichue techniquement. Les développeurs ont vraiment du la détester comme tu le dis...
La Saturn est très complexe, et je pense qu'effectivement face à la PSX, on retrouvait le schéma SNES vs MD sauf que la Saturn est juste complexe et plutot orienté 2D (là où la PSX est quasi 100% fait pour la 3D)... elle n'est pas véritablement "bancale" comme peut l'être la SNES sur certains points.

[Invité]

Tu vas vite comprendre que Touko a souvent un avis négatif sur la MD car intrinsèquement c'est une machine qu'il n'aime pas quoiqu'il en dise :p

Pas du tout, mais bon quand je lis que le HDMA est limité, et que la hscroll table c'est génial, je peux pas vous laisser dire .
A part le côté simple selon les cas, je vois aucun intérêt à la hscroll table par rapport au HDMA ou aux interruptions  .

[upsilandre]

D'ailleurs ces contraintes de priorité forcé on le voit sur Dai Makaimura. Ils ont pas reproduit l'effet d'averse du debut du jeu qu'on retrouve aussi bien dans la version arcade que la version Megadrive qui reprend la meme methode.

L'effet y est ,il est fait via des sprites et non un clignotement d'un des fonds avec la pluie

Encore une fois c'est exactement ce que j'ai dis, pourquoi tu coupes chaque fois mes propos comme ca.

même l'arcade est moins bien, car il utilise la même technique que sur MD, mais fait clignoter le hud lui (car la borne dispose de 3 plans) en gros la SGX ne fait rien clignoter du tout, la pluie est composée de sprites, et je préfère cet effet,moins dense mais tu n'as pas le clignotement des fonds comme sur MD .

Question de gout, moi je préfere clairement l'effet sur Megadrive qui reproduit tres bien l'effet arcade, on se rend meme pas compte que le background disparaît dans cette ambiance d'orage, c'est le seul truc qui est mieux réussit je trouve. Sur SupergrafX on retrouve plus tout a fait cette ambiance sur cette scene particulière.
J'ai l'intime conviction que si y avait pas eu cette contrainte de priorité des plans ils auraient fait la meme chose sur SupergrafX pour mieux coller a la version arcade (comme il l'ont fait sur le reste du jeu). En arcade aussi ils auraient pu utiliser des sprites plutot que de faire clignoter le HUD mais ils ne l'ont pas fait.
C'est compliqué car tu m'a l'aire quand meme sensible sur le sujet.

Pour aller dans ton sens voila une petite image de comparaison du sprite du cochon que j'avais deja fais y a quelque temps et qui est tres a l'avantage de la SupergrafX (meme si ca reflète pas non plus tous les sprites), j'espere que ca te plaira

Arcade/SupergrafX/Megadrive


et encore avec les palettes de la supergrafX ils auraient pu sans doute faire plus fidèle sur ce sprite.

Pareil pour le premier boss, la SGX conserve le second plan alors que la MD est obligé d'utiliser un plan pour le boss (a première vue) .

Le boss est bien un sprite.
C'est vrai qu'il y a plein de passage ou il manque les scrolling differenciels sur 2 plans ce qui fait un sacré downgrade comparé a la version SupergrafX. C'est principalement a cause du mode window utilisé pour le HUD sur Megadrive. Comme y a un HUD aussi en bas de l'ecran ca empêche d'afficher le second plan dans cette zone et ca crée des glitch quand tu sautes ou que y a du scroll vertical (Je peux pas poster de lien malheureusement mais par exemple le debut du level 2 avec les moulins) donc ils evitent au max (la sur ce level on doit monter et descendre la colline avant d'arriver au boss). Ca les a bien emmerdé ce HUD en window en bas d'ecran.
A cela faut ajouter la faible capacité de la cartouche, 640Ko vs 1Mo. C'est toujours difficile de comparer des jeux de capacités differentes quand on sait l'impacte que ca a a cette epoque.
J'aurais aimé voir une version Megadrive 1Mo (voir plus) et qui utiliserait plutot des sprites pour la partie inferieur du HUD. (mais pareille pour la SupergrafX, j'aurais bien aimé voir aussi une version avec encore plus de maitrise de la machine et une cartouche plus grosse meme si ca necessite un mapper. La version arcade c'est quand meme 4Mo)

[Stef]

Tu vas vite comprendre que Touko a souvent un avis négatif sur la MD car intrinsèquement c'est une machine qu'il n'aime pas quoiqu'il en dise :p

Pas du tout, mais bon quand je lis que le HDMA est limité, et que la hscroll table c'est génial, je peux pas vous laisser dire .

La HScroll table c'est avant tout une visibilité de la capacité hardware de scroll par tile / line.
C'est à ce niveau que c'est génial... c'est hyper simple à utiliser. Même si le H-DMA en pratique permet de reproduire l'effet (et mêem plus), sa mise en oeuvre reste plus complexe.

[Invité]

Encore une fois c'est exactement ce que j'ai dis, pourquoi tu coupes chaque fois mes propos comme ca.  

Dsl, comme tu dis dés le début que l'effet n'y est pas, et tu précises bien plus bas qu'il y est mais avec des sprites,j'avais pas vu  
Justement, ce que je trouve bien,c'est que les 512 pixels sprites de la SGX permettent de faire l'effet de pluie, sans ce clignotement désagréable, pour moi c'est clairement un plus .

La HScroll table c'est avant tout une visibilité de la capacité hardware de scroll par tile / line.
C'est à ce niveau que c'est génial... c'est hyper simple à utiliser. Même si le H-DMA en pratique permet de reproduire l'effet (et mêem plus), sa mise en oeuvre reste plus complexe.

Si tu le dis, ça l'est surement pour toi, moi je trouve pas dés que tu veux faire des scrolls H multiples dans une fram(ligne+tiles ou plus) .
Sur PCE j'ai aussi une table qui va me faire tout le boulot (lignes à modifier+valeurs de scroll),c'est aussi simple .
En plus de bouffer du DMA et de la VRAM .

Question de gout, moi je préfere clairement l'effet sur Megadrive qui reproduit tres bien l'effet arcade, on se rend meme pas compte que le background disparaît dans cette ambiance d'orage

Faut pas pousser, sur arcade non car c'est le hud qui clignote donc peu perceptible, sur Md faut pas être épileptique .
Et tu perds les arbres qui se plient au vent du second plan, présents sur l'arcade et SGX.

et encore avec les palettes de la supergrafX ils auraient pu sans doute faire plus fidèle sur ce sprite

Niveau couleurs, c'est clair que la version SGX et pas optimale du tout, rien que celles d'arthur sont pourries.
Elle est loin d'être optimale aussi .
Mais bon vu que la version arcade fait 32Mb, c'était difficile de faire arcade perfect avec 8 ou 5 Mb.

A cela faut ajouter la faible capacité de la cartouche, 640Ko vs 1Mo. C'est toujours difficile de comparer des jeux de capacités differentes quand on sait l'impacte que ca a a cette epoque.

Ca n'a jamais gêné les pros Md pour comparer les SF2 

[upsilandre]

Je suis pas du tout sur de ce que tu avances pour ça .
Comment scroller 3 plans, ou les 4 possibles sinon .
Tu as des registres des scroll 16 bits pour chaque plan,sinon impossible d'avoir des écrans virtuel de plus de 256 pixels .
Le HDMA ne bride rien du tout, c'est juste un DMA parfaitement synchronisé sur le H-sync, et de façon automatique sans avoir la latence d'une intérruption .

Oui tu a des registres 16bit pour chaque plan (10bit effectif) j'ai jamais dit le contraire, c'est justement le probleme dans le cas d'un line scroll (ou distorsion) sur 2 plan.
Quand tu utilise le HDMA tu peux modifier au maximum 4 octets par scanline et a des adresses contigu (ou ecrire 2 fois 2 octet a 2 adresse contigu, c'est plutot ca dont on a besoin ici car pour les 16bit du Hscroll faut ecrire 2 fois a la meme adresse).
Le HDMA a different mode d'ecriture de ces 4 octets (y a 3 modes) mais y a aucun mode qui permet d'ecrire 2 fois a une adresse et ensuite 2 fois a une autre adresse qui n'est pas contigu a la premiere et c'est le cas ici. Le registre Hscroll des 2 plans ne sont pas contigu (ils sont séparé par les registre Vscroll) donc a priori le seul truc que tu peux faire c'est utiliser le mode qui permet d'ecrire un octet a 4 adresses consécutives ce qui permet alors de modifier les 8bit de poid faible du Hscroll des 2 plans (et t'oblige aussi a ecrire dans les Vscroll mais suffit de réecrire la valeur deja presente) mais pas l'integralité du Hscroll des 2 plans comme sur megadrive (qui sont sur 10bit aussi) mais comme j'ai dit je pense pas que ce soit génant. les 8bit de poid faible suffisant pour la plupart des cas a priori (genre effets de distorsion)

[Invité]

C'est 4 bytes /channels si les 8 channels sont actives donc en mode indirect.
Donc je pense que si tu utilises 1 seul channel (en mode direct) tu peux faire plus de 32 octets sans problème .

[upsilandre]

A priori c'est max 4 octets par acces HDMA meme si y a qu'un channel mais si on peut vraiment utiliser les 8 channels a chaque scanline et donc modifier 32 octets par scanline alors c'est tres intérressant.
Y a personne qui développe sur SNES sur le forum? (ce que je pourrais comprendre)

[Invité]

Oui

tu peux voir une doc là :
http://wiki.superfamicom.org/snes/show/DMA+%26+HDMA

Vous traduisez ça comment vous ??:

For each scanline during which HDMA is active (i.e. at least one channel is not paused and has not terminated yet for the frame), there are ~18 master cycles overhead. Each active channel incurs another 8 master cycles overhead (during which time $42xA is presumably loaded if necessary) for every scanline, whether or not a transfer actually occurs. If a new indirect address is required, 16 master cycles are taken to load it. Then 8 cycles per byte transferred are used. Thus, HDMA takes a maximum of 466 master cycles per scanline (if all 8 channels are active, require an indirect address load, and transfer 4 bytes).

Pour moi on dispose de 466 cycles / ligne, chaque bytes transferé prend 8 cycles + 26 cycles d'overhead / channel en mode direct, et 24 cycles de plus / channel en mode indirect.

[Stef]

Le problème n'est pas dans la quantité de byte à transférer mais plutot dans la manière dont c'est fait. En gros un canal HDMA ne transfère que dans 4 ports consécutifs, du coup ici pour modifier le scroll H de 2 plans tu dois utiliser 2 canaux HDMA.

[Invité]

Le problème n'est pas dans la quantité de byte à transférer mais plutot dans la manière dont c'est fait. En gros un canal HDMA ne transfère que dans 4 ports consécutifs, du coup ici pour modifier le scroll H de 2 plans tu dois utiliser 2 canaux HDMA.

Ok, mais on est pas dans la limitation décrite par upsilandre .
Sur la hscroll de la Md c'est pas tout rose non plus vu que les valeurs de scroll de chaque plan sont entrelacées.


Et bon on est quand même pas dans le cas de la nes non plus pour faire du hscroll .

[upsilandre]

Reste quand meme le découpage Vscroll sur 2 plans simultanés (pour l'instant Gynoug et Contrat)
Vous m'avez donné plein d'idée de gif (trop)

[Stef]

Ok, mais on est pas dans la limitation décrite par upsilandre .
Sur la hscroll de la Md c'est pas tout rose non plus vu que les valeurs de scroll de chaque plan sont entrelacées.

Certes mais tu dois configurer plusieurs canaux HDMA pour ça.
Et sur MD non tu n'as pas de soucis avec ça car chaque transfert DMA se fait sur un base de word, du coup avec l'auto incrémente à 4 (plutot que 2) tu ne peux que transférer la scroll table d'un seul plan. La même chose est vrai pour la table de scroll verticale :) Et d'ailleurs rien ne t'empêche de configurer l'auto incrément pour modifier le scrolling H que toute les 4 scanlines par ex, ainsi aucune perte CPU ni bande passante ! Et pour les tilemap tu peux updater qu'une "colonne" via le DMA grace à ça (il avait vraiment bien pensé la chose chez Sega).

[Invité]

Reste quand meme le découpage Vscroll sur 2 plans simultanés  (pour l'instant Gynoug et Contrat)
Vous m'avez donné plein d'idée de gif (trop)

Dans contrat je pense que le l'ofset / tile de la snes ne poserait pas de problème pour le niveau avec les avions, même via des tiles dynamiques (avec 2 plans hard bien sur, pas sur PCE donc) est facilement faisable .

Faudra que j'essaye de voir ce qu'on peut faire avec les tiles dynamiques sur SGX pour voir .

Certes mais tu dois configurer plusieurs canaux HDMA pour ça.

C'est vrai, mais ça revient plus ou moins à ta tables hscroll avec tes 2 plans, et en plus faut la transférer en VRAM .

[Stef]

Le tile dynamique ça ne remplace en rien le scroll verticale, je vois même pas pourquoi tu en parles... C'est une méthode software qui consomme beaucoup de bande passante et beaucoup de rom ou CPU, tout en te limitant beaucoup sur la répététivité du pattern. Bref, solution de pauvre qui est loin de donner les mêmes possibilités que le vrai scrolling par colonne.
Le niveau 5 de gynoug n'est pas reproductible sur SNES, les 2 scrollings par colonne étant différent...