Re: Megadrive et Super Nintendo : parlons technique !

[Tryphon]

Mais faudrait déterminer ce qu'est un BTA aussi. Parce que dans l'absolu, vu comment ça détourne le style, bientôt on va mettre Zelda 2 en BTA

Zelda à la limite, mais Kegend of Thor est pas loin d'un BTA (c'est un cross-over assez curieux).

Sinon je reviens sur les 2 banques de 8 ko pour les sprites sur SNES. Je suppose que ça permet de coder les offsets dans la SAT de façon plus condensée. Mais du coup, les bits gagnés, ils servent à quoi ?
En fait, la question que je me pose, c'est pourquoi Nintendo s'est imposé une contrainte aussi désagréable ? On obtient quelque chose en échange ?

[Invité]

non, je ne pinaille pas, je rectifie. Et pour info tu parlais de deux ennemis à l'écran, je m'en rappelle très bien, t'avais fait une phrase du genre "c'est lassant de se battre contre deux ennemis" sur l'autre topic. Je t'ai juste montré qu'il y en avait souvent trois. et tu parles de trois sprite qui sont toujours les mêmes

Bah écoute, oui, c'est lassant de devoir se battre contre deux ennemis, ce qui est souvent le cas au début du jeu. Ne m'en veut pas si l'IA des adversaires est tellement rudimentaire, que j'ai l'impression de me battre contre deux, voire un ennemi. Qu'il y ai, vers la fin, trois ennemis à affronter par vague, je trouve ça normal puisqu'on en retrouve tout autant dans Final Fight 2. Je ne sais pas si tu te rends compte du manque d'intérêt dans ce type de jeu. Déjà d'un point de vue technique, c'est pas terrible et je trouve que certains sprites sont juste dégueulasses avec des couleurs vomissables.



Sérieusement ? Qu'est-ce les gars ont voulu faire avec ce genre de sprites ? Alors attention, je ne dis pas que le jeu est "moche" dans son semble, mais il y a un manque cruel homogénéité qui se ressent régulièrement. Tantôt on a des décors pas trop mal, mais certains sprites sont hideux ou ont des couleurs ternes. J'ai plusieurs fois regardé le film étant gamin et dernièrement avec mon fils, mais je ne me souviens pas que les déguisements soient aussi ternes.



Sur cette capture, par exemple, le second plan est cruellement vide et on ne sait pas ce que vient faire ici l’homme ou la femme déguisé en indien (très mal réalisé au passage). J'aurais voulu voir plus d'éléments sur ce plan, comme le câblage électrique, des boîtes de relais, etc. enfin quelque chose qui tient la route plutôt qu'un fond noir avec toujours les mêmes luminaires.

De toute façon, je vais être clair avec toi, je ne comprends même pas ton positionnement. Tu déglingue un jeu que t'as essayé sur émulateur alors que t'es le premier à dire que c'est de la merde de jouer sur émulateurs, que tu supporte pas le moindre Lag. En plus tu déglingue tout ce qui est LCD comme quoi c'est moche, que les CRT sont un autre monde. Et là tu viens me comparer un jeu auquel t'as joué dans ce qui sont les pires conditions pour toi avec un Final Fight 2 que t'as joué dans les meilleures conditions pour toi. Et je te le redis, un jeu auquel j'ai joué 5mn sur émulateur, je m'abstiens de le déglinguer, même d'en parler. Je dis juste "joué 5mn, pas accroché".

Pour ta gouverne, Final Fight 2 et même Final Fight sur SNES, je les ais découverts il y a plusieurs années sur émulateur (début 2000). Dernièrement, avant d'acheter Final Fight 2, je l'ai rapidement testé en émulation pour voir s'il me plaisait, d'ailleurs, j'avais même ripper plusieurs sprites pour travailler sur un moteur de BTA, certains devraient se souvenir lorsque j'ai demandé comment repositionner un sprite après avoir fait un flip horizontal. Bref, Final Fight 3, idem j'ai fais quelques niveaux en émulation. Je me refuse généralement de finir un jeu en émulation, car je souhaite plutôt le faire sur le hard d'origine. Batman j'ai fais quelques niveaux et ça ne me plaît pas, mais je ferais l'effort de me procurer la cartouche. Bien entendu que l'expérience est mieux sur le hard avec un bon CRT, c'est beaucoup plus confortable et agréable, sauf que je ne vois pas comment cela gommerait l'absence d'ennemis, l'IA rudimentaire, la mauvaise réalisation de certains gfx, les couleurs ternes, etc. Je me trompe certainement et on en reparlera une fois que j'aurais acquis la cartouche.

Ce n'est pas parce que c'est un jeu SNES que je tape dessus, t'as The Punisher sur Mega Drive que je trouve pas terrible non plus.

[wiiwii007]

non, je ne pinaille pas, je rectifie. Et pour info tu parlais de deux ennemis à l'écran, je m'en rappelle très bien, t'avais fait une phrase du genre "c'est lassant de se battre contre deux ennemis" sur l'autre topic. Je t'ai juste montré qu'il y en avait souvent trois. et tu parles de trois sprite qui sont toujours les mêmes

Sur cette capture, par exemple, le second plan est cruellement vide et on ne sait pas ce que vient faire ici l’homme ou la femme déguisé en indien (très mal réalisé au passage). J'aurais voulu voir plus d'éléments sur ce plan, comme le câblage électrique, des boîtes de relais, etc. enfin quelque chose qui tient la route plutôt qu'un fond noir avec toujours les mêmes luminaires.

Et encore une fois, le stage est court et change 2, 3 fois d'arrière plan, il y a des obstacles à sauter et des ennemis en moto en fond qui balancent des bombes. Donc pour un demi stage, je trouve ça pas mal.

[Invité]

Sinon je reviens sur les 2 banques de 8 ko pour les sprites sur SNES. Je suppose que ça permet de coder les offsets dans la SAT de façon plus condensée. Mais du coup, les bits gagnés, ils servent à quoi ?

Tu as toutes les infos ici:
https://wiki.superfamicom.org/sprites

En fait, la question que je me pose, c'est pourquoi Nintendo s'est imposé une contrainte aussi désagréable ? On obtient quelque chose en échange ?

Pour moi ce sont les restes de la compatibilité nes qui était prévue et abandonnée .

[wiiwii007]

Je suis dac avec toi, mais alors pourquoi il y a des titres avec des sprites de taille moyenne mais toujours limité à 3, 4 ?

Seul Konami arrivait à faire mieux sur Snes ?

Parce que que même si les sprites sont plus petits, le devs ne pouvaient probablement pas caser au moins 2 sets d'ennemis en VRAM, si c'est pour avoir que des clones, je suis pas sur que ce soit mieux .
Car 2x8ko, si on compte les sprites des persos (joueurs+ennemis) + ceux pour l'affichage (si utilisés pour ça) et ceux pour les éléments du jeu(armes, items, etc ..) ça se rempli très vite,et les tailles carré des sprites n'aident pas .
A moins de faire des sprites 32x32, mais bon la mode était au sprites énormes en 90 .

Je vais passer pour un con encore une fois mais j'aimerais avoir une explication simple si possible de ce qu'est la VRAM. Possible ? 

Quand tu parles de "set ennemi", tu parles de la palette de mouvement qu'un ennemi possède ?

[ichigobankai]

la Vidéo RAM, là où tu stocks les tiles qui vont composer les sprites, le background etc.

[Invité]

Quand tu parles de "set ennemi", tu parles de la palette de mouvement qu'un ennemi possède ?

Voilà, en général tu gardes le DMA(transfert des datas qd il n'y a pas d'affichage,car il est limité)  pour les 2 joueurs + boss, les ennemis classiques ont leurs mouvements en VRAM, les SOR font ça, et tu bouffes entre 30 et 40 ko de VRAM (sur un total de 64) pour les sprites .
L'astuce simple aussi, et d'utiliser le même set avec des palettes différentes .

[Stef]

@touko> je ne pense pas que ce soit juste pour des raisons de rétro compatibilité, le VDP de la MD conserve la rétro compatibilité avec la SMS est la SAT ne pose pas de soucis, il y avait mille manières de faire mieux de ce côté. C'est surtout que la SAT est dans le PPU (sur MD seule une portion de la SAT est cachée dans le VDP), c'est donc probablement pour économiser de précieux transistors sur le PPU que la SAT économise le moindre bit. Et clairement c'est un mauvais choix que d'avoir économisé ici, comme c'est un mauvais choix d'avoir économisé sur les palettes sur Megadrive.

[Invité]

Je vois pas comment il pourrait en être autrement, c'est trop contraignant et limitant pour avoir été pensé comme ça(on dirait vraiment la SAT nes),surtout séparer la SAT en 2 tables de 8 bits,ça n'a aucun sens .
Donc 2 solutions:
1 - Soit les ingés nintendo étaient mauvais, ce que je doute fortement .
2- Soit c'est pour la compatibilité nes .

[TotOOntHeMooN]

c'est surtout pour économiser de précieux transistors sur le PPU que la SAT economise le moindre bit.

Serions nous face au "chausse-pied" du VDP de la Megadrive pour permettre de faire tenir le design final, après avoir sabordé la CRAM & co?

[Tryphon]

Sinon je reviens sur les 2 banques de 8 ko pour les sprites sur SNES. Je suppose que ça permet de coder les offsets dans la SAT de façon plus condensée. Mais du coup, les bits gagnés, ils servent à quoi ?

Tu as toutes les infos ici:
https://wiki.superfamicom.org/sprites

Merci ! Pas encore tout lu mais :

* C'est pire que ce que je pensais au niveau des tailles de sprites : tu n'en as pas 4 possible mais 2x2 (tu choisis d'abord un mode pour TOUS les sprites puis 2 tailles dans ce mode ?)

* Sinon les entrées dans la SAT sont 2 fois plus courtes que sur MD, mais tu n'as que 8 palettes possibles pour les sprites ?

[Tryphon]

sur MD seule une portion de la SAT est cachée dans le VDP

?????

Quelle partie ? et où est l'autre ?

[TotOOntHeMooN]

et où est l'autre ?

DTC ?   (je n'ai pas compris nonplus ce que voulais dire Stef)

[Tryphon]

Oh c'est fin !

(Je crois me rappeler que Stef avait dit un jour qu'il y avait un cache secret de la SAT, ce qui faisait que changer la SAT en Hblank n'était pas si évident. Peut-être qu'il fait allusion à ça)

[Invité]

c'est surtout pour économiser de précieux transistors sur le PPU que la SAT economise le moindre bit.

Sérieux j'y crois pas à ça,si tu voulais économiser de la place tu réduisais le nombre d'entrées, et tu passais tout ou une partie en 16 bits .
La SAT de la PCE fait 512 octets pour 64 sprites en 16 bits(la snes c'est 544), et il reste pas mal de bits inutilisés, je pense qu'il y avait moyen de faire bcp mieux que ça,si c'était une histoire de place .

Quelle partie ? et où est l'autre ?

La SAT de la Md est en VRAM, seules certaines données de cette SAT sont parsées(Y/link/size) à chaque Hblank dans un buffer du VDP .

[Stef]

Je vois pas comment il pourrait en être autrement, c'est trop contraignant et limitant pour avoir été pensé comme ça(on dirait vraiment la SAT nes),surtout séparer la SAT en 2 tables de 8 bits,ça n'a aucun sens .
Donc 2 solutions:
1 - Soit les ingés nintendo étaient mauvais, ce que je doute fortement .
2- Soit c'est pour la compatibilité nes .

Non mais oui clairement ils ont "étendu" la SAT de la NES, ce qui était la solution la plus facile. Après ils ont cherché à économiser la taille de la SAT car elle est directement intégrée dans le die d'un des PPU, et c'est d'ailleurs la seule mémoire intégrée dans le PPU sur SNES (le reste est en VRAM ou CGRAM). Du coup c'est normal de vouloir la faire la plus petite possible surtout qu'il y a quand même 128 entrées. Ici ça donne une SAT de 512 bytes + 32 bytes, ce qui bouffe un paquet de transistor comparé aux circuits logiques.
Je pense malgré tout que des contraintes de temps (à cause du succès de la MD qu'ils n'avaient pas anticipé) a du jouer aussi...
Sur MD le VDP embarque la CRAM, la VSRAM et une partie de la SAT (la partie minimum nécessaire pour construire la liste des sprites de la prochaine ligne), toutes ces tables prennent une bonne partie de l'espace du VDP (les BUS internes consomment aussi beaucoup d'espace).

[Stef]

Sérieux j'y crois pas à ça,si tu voulais économiser de la place tu réduisais le nombre d'entrées, et tu passais tout en 16 bits .
La SAT de la PCE fait 512 octets pour 64 sprites en 16 bits(la snes c'est 544), et il reste pas mal de bits inutilisés, je pense qu'il y avait moyen de faire bcp mieux que ça,si c'était une histoire de place .

Ben c'est quand même bien plus plausible que ces raisons de retro compatibilité, aujourd'hui on sait que la retro compatibilité a été abandonné assez tot dans le projet SNES (dés octobre 1988). 64 sprites sur SNES, je pense qu'avec la MD qui en avait 80 c'était juste impensable... clairement quand tu regardes comment la SNES est fichue, t'as l'impression que Nintendo voulait avant tout afficher de plus gros chiffres que la MD : plus de sprites, plus gros, plus de couleurs, plus de plans, résolution plus élevée... même si en réalité les différentes contraintes font que c'est souvent pas le cas (voire l'inverse). C'est comme la RAM, à la base visiblement la SNES devait avoir seulement 8 Ko de RAM (comme la PCE), puis ils sont passé à 32K pour finalement monter à 128K histoire de dire "2 fois plus que la MD" alors que l'intérêt est limité.

La SAT de la Md est en VRAM, seules certaines données de cette SAT sont parsées(Y/link/size) à chaque Hblank dans un buffer du VDP .

Oui c'est ça, ces 3 champs de la SAT sont "cachés" en interne dans le VDP, je dis caché car c'est réellement un espèce de cache type "write through". Quand tu vas écrire en VRAM, le VDP détecte si tu écris dans la zone réservée à la SAT (que tu peux modifier sur MD) et plus particulièrement dans un des champs mentionnés ci dessus, si c'est le cas alors il met à jour le cache interne également.
Cette manière de faire fait que si tu déplaces l'adresse de la SAT en cours de frame, alors une partie de la SAT ne sera pas correctement mise à jour car le cache n'aura pas été ré-écrit (le jeu Castlevania bloodline utilise cette "feature" pour faire l'effet de réflection des sprites dans l'eau dans le niveau 2).

[Invité]

64 sprites sur SNES, je pense qu'avec la MD qui en avait 80 c'était juste impensable.

Je donne comme exemple la PCE, mais tu pouvais clairement mettre 100 sprites, et optimiser la SAT pour ne pas avoir,ou pas trop, de bits perdus
la PCE en a pas mal(6 dans les attributs, 7 si tu comptes le bit pour les 16 palettes) 6 bits inutilisés pour X et 6 pour Y, et 6 autres pour l'adresse(tu peux encore gratter un bit car les sprites sont prévus pour 128 ko de VRAM), donc il y avait largement de la marge pour faire plus propre.

clairement quand tu regardes comment la SNES est fichue, t'as l'impression que Nintendo voulait avant tout afficher de plus gros chiffres que la MD

Ca c'est possible, car les gros chiffres dans les specs ça fait bien, mais bon là le sprite engine est tellement sacrifié, que je suis sceptique ..

[Stef]

Je pense que sur PCE ils ont privilégié le confort de développement de ce côté, sur MD c'est pareil, tu as beaucoup de bit perdus (en VRAM au moins car dans le cache il n'y a aucun bits perdus). Aussi mettre 100 sprites (ou 128) ça ne sert à rien si derrière la limite par ligne est celle qui va te poser le plus de problème (c'est 16 sprites par ligne sur PCE il me semble ?). Sur MD par exemple tu as 80 sprites (ou 64 en H32) et c'est rarement cette limite là qui pose problème.
Sur SNES les 128 sprites ont une certaines utilité car tu vas souvent utiliser de petits sprites (8x8 et 16x16) pour ne pas gacher de VRAM et le budget par ligne.. mais d'un autre côté ça fait souffrir le CPU ^^
Je pense que la PCE a plutot un bon équilibre malgré tout même si la MD reste la plus équilibrée et la plus performante des 3 machines sur cet aspect (les sprites).

[Invité]

Je pense que sur PCE ils ont privilégié le confort de développement de ce côté, aussi mettre 100 sprites (ou 128) ça ne sert à rien si derrière la limite par ligne est celle qui va te poser le plus de problème (c'est 16 sprites par ligne sur PCE il me semble ?). Sur MD par exemple tu as 80 sprites (ou 64 en H32) et c'est rarement cette limite là qui pose problème.

Oui clairement, par contre je pense que le buffer interne du VDC était surement prévu pour avoir 512 pixels sprites(le VDC était aussi prévu pour l'arcade), ce qui concorderait avec la réso de 512 pixels, et la taille min de 16 pixels des sprites me fait pencher aussi pour ça .
Pour des raisons évidentes de coûts pour une console, il a été réduit à 256 .

[Invité]

Et après c'est moi qui pinaille.

Sérieusement ? Qu'est-ce les gars ont voulu faire avec ce genre de sprites ?

bah mettre le clown qu'il y a dans le film

J'ai plusieurs fois regardé le film étant gamin et dernièrement avec mon fils, mais je ne me souviens pas que les déguisements soient aussi ternes.

c'est sûr que c'est un film qui respire bon le fluo des 80's




t'es sûr que tu t'es pas trompé de Batman?

[Stef]

Tu a aussi Spiderman animated séries 
Shadow blaster (en u.s) ?

Tout comme SpiderMan versus The Kingpin (mon premier jeu MD ) j'ai du mal à les placer en BTU ces jeux là quand mêm, d'ailleurs dans ma liste de BTU sur un seul plan il y en a quelqu'uns que je supprimerai bien de la liste aussi.

[TotOOntHeMooN]

Une résolution de 512 c'est vraiment super pour un logiciel et pourtant MarioPaint ne l'utilise même pas (ne serait-ce pour l'éditeur de musique) ... Je pense surtout qu'avec ou sans sprites, c'était là pour pouvoir indiquer dans un tableau comparatif qu'ils font "mieux" que les 320 de la Megadrive.

[Tryphon]

La SAT de la Md est en VRAM, seules certaines données de cette SAT sont parsées(Y/link/size) à chaque Hblank dans un buffer du VDP .

Oui c'est ça, ces 3 champs de la SAT sont "cachés" en interne dans le VDP, je dis caché car c'est réellement un espèce de cache type "write through". Quand tu vas écrire en VRAM, le VDP détecte si tu écris dans la zone réservée à la SAT (que tu peux modifier sur MD) et plus particulièrement dans un des champs mentionnés ci dessus, si c'est le cas alors il met à jour le cache interne également.
Cette manière de faire fait que si tu déplaces l'adresse de la SAT en cours de frame, alors une partie de la SAT ne sera pas correctement mise à jour car le cache n'aura pas été ré-écrit (le jeu Castlevania bloodline utilise cette "feature" pour faire l'effet de réflection des sprites dans l'eau dans le niveau 2).

OK. Donc si je comprends bien, on peut dépasser la limite de 80 sprites en modifiant la SAT durant le Hblank, mais on ne peut que déplacer un sprite verticalement, changer sa taille (ce qui me semble inutile vu qu'il est censé utiliser les mêmes tiles), et, je suppose, le flipper (si c'est utilisé pour des reflets).

Ça me paraît donc limité.

Sinon mon étonnement venait du fait, que, allez savoir pourquoi, je pensais que la VRAM était située DANS le VDP.

[wiiwii007]

Et après c'est moi qui pinaille.

Sérieusement ? Qu'est-ce les gars ont voulu faire avec ce genre de sprites ?

bah mettre le clown qu'il y a dans le film

J'ai plusieurs fois regardé le film étant gamin et dernièrement avec mon fils, mais je ne me souviens pas que les déguisements soient aussi ternes.

c'est sûr que c'est un film qui respire bon le fluo des 80's




t'es sûr que tu t'es pas trompé de Batman?

Laisse tomber, Shingo est à l'ouest et il s'en rend même pas compte.

Shingo, si tu n'aimais pas ce jeu où l'ambiance qui s'en dégage sans prendre partie pour une marque tu dirais simplement : "J'aime pas ce style graphique mais ça respecte le film donc c'est normal". Là tu mets en avant un "défaut" à tes yeux, et tu zappes que ça provient d'un film...   Ce serait un peu comme dire que tu n'aimes pas la direction artistique de Turtle parce que ça ressemble à un DA 

Le seul truc que ça fait c'est que ça démontre ton fanatisme Sega et ta haine envers Nintendo. Si tu veux que ça passe inaperçu, fais-le différemment 

Merci pour vos réponses les gars sur la technique, je vais tenter d'y voir un peu plus clair, j'aimerais comprendre un minimum.

[Invité]

Si tu veux que ça passe inaperçu, fais-le différemment 

ou le fait pas

[TotOOntHeMooN]

OK. Donc si je comprends bien, on peut dépasser la limite de 80 sprites en modifiant la SAT durant le Hblank, mais on ne peut que déplacer un sprite verticalement, changer sa taille (ce qui me semble inutile vu qu'il est censé utiliser les mêmes tiles), et, je suppose, le flipper (si c'est utilisé pour des reflets).

Pour représenter des ennemies qui attendent dans un BTU par exemple.

[Tryphon]

[Mais je maintiens que ça me rappelle pas vraiment Burton...

pourtant les ennemis viennent du film, essentiellement du début où tous les clowns envahissent la place de Gotham. Et les stages proviennent des scènes du film.

Oui, ça je n'en disconviens pas. Mais quelque chose dans la direction artistique ne va pas avec celle du film.

J'ai du mal à déterminer quoi. Le choix des couleurs ? Le contraste ? L'effet de volume que je trouve trop prononcé ? Difficile à dire, vraisemblablement subjectif, mais quelque chose fait que je ne me sens pas chez Burton (déjà, Burton et la baston ).

[Tryphon]

OK. Donc si je comprends bien, on peut dépasser la limite de 80 sprites en modifiant la SAT durant le Hblank, mais on ne peut que déplacer un sprite verticalement, changer sa taille (ce qui me semble inutile vu qu'il est censé utiliser les mêmes tiles), et, je suppose, le flipper (si c'est utilisé pour des reflets).

Pour représenter des ennemies qui attendent dans un BTU par exemple.

Il faudrait qu'il soit sur la même verticale et leur animation synchronisée... Et puis à un moment faudra les désolidariser. À moins qu'ils ne viennent un par un.

C'est un peu artificiel mais pourquoi pas... Tu crois que c'est le sens des 94 sprites de Fonzie ?

[Invité]

bah je sais pas Tryphon, on parle d'un JV 16bits aussi, t'es pas sur un film interactif sur PS4. T'as les ennemis, les décors et les musiques du films donc à un moment si tu veux vraiment Burton, tu regardes le film Et puis bon, toi-même tu disais que tu connaissais pas le jeu, donc là encore c'est pareil, faudrait que t'y joue pour être aussi tranché. Au contraire, pour une fois je trouve que c'est un jeu qui respecte bien la licence dont il vient (et globalement, ils s'en sont plutôt bien sorti avec Batman sur 8-16bits).

[Invité]

Ouais bien sûr, c'est vrai que le déguisement en rouge est aussi sombre dans le film, je suis aveugle !!!

Batman Returns est un film sombre, mais loin d'être terne.