Re: MEGADRIVE vs SUPER NINTENDO : Fight !

[Invité]

Je crois que pas beaucoup ont compris la transparence sur SNES.
Si tu active la transparence , le sprite tu pourra changer la  priorité , alors priorité basse il sera en dessous de l'eau est donc t'aura l'impression que tout ton perso est sous l'eau , ce qu'on ne veut pas (le haut du corps est la partie émerge).
Et pour ça ben tu divise ton sprite en 2x2 par exemple, pour que le haut reste hors de l'eau et le bas dans l'eau.
Et je que je dit c'est vraiment la seule méthode pour gérer ce cas de figure (mais comme je me répète il est assez rare il est que dans 2 Action RPG).

tu n'as pas compris que le problème dans un BTA est moins le calcul (encore qu'il y a autant, sinon plus, de tests de collisions qu'avec un A-RPG) que la gestion des ressources, notamment du DMA. Ce n'est pas lire la table de metasprites qui limite, mais d'envoyer les tiles du metasprite courant en VRAM, à chaque frame.
Si tu avais programmé un BTA sur une 16 bits (à part la NeoGeo et peut-être la Supergrafx), tu te serais heurté à ce problème dans les premières heures de dev.

Et dans un A-RPG tu ne crois pas que tu dois renvoyer a chaque frame ?
Je te fait la liste ce que tu dois envoyer a chaque frame :
-la Palette BG et personnage (variable mais en moyenne 0x70 octet)
-les Perso (1 perso = 0x200 octet)
-les armes (1 arme = 0x100 octet)
-les ennemis (1 ennemi (0x200-0x400 octet)
-les magies (1 magie = 0x300 octet)
-les degats ( 0x180 octet max)
-le BG (tile map) ( en multi directionel 0xF00 octet)
-le BG (data pour les animations) (variable moyenne 0x200 octet)
-Le hud (variable moyenne 0x100 octet)

C'est ce qu'on appelle peu sûrement

Sur MD ou SNES, pour ce genre de jeu c'est bien plus complexe que tu dois composer avec des ressources limitées (sprite hard, limite scanline, peu de VRAM). Si tu fais tout en statique ton jeu sera plus pauvre car contraint directement. Si tu veux exploiter au max les ressources tu es obligé de faire une allocation plus dynamique mais aussi beaucoup plus complexe à mettre en oeuvre.

Je n'ai pas dit le contraire j'ai dit que tu met une table de meta sprite qui indique les sprite a charger , c'est pas ce qu'on peut appeler lourd en calcul (un peu complexe oui a mettre en place).

[Stef]

Euh non,ton sprite peut être composé de 500 sprites, niveau soft il serra vu comme 1 seul, tu vas pas faire des tests de collisions pour chaque sprites composant ton meta sprite .
Donc non un BTA niveau collisions c'est peanuts .

Y'a pas beaucoup de collisions dans un BTA mais on comparait à un A-RPG où y'a pas grand chose non plus, c'est comparable...

Bien sur qu'une gestion dynamique est galère à faire,mais à t'écouter tout est dynamiques sur MD ..
Pour un BTA, si tu penses ton jeu correctement tu n'en a pas besoin, du moins sur MD/PCE, sur snes je sais pas vu son système de banque pour les sprites .
J'ai fait un dump de la vram de SOR2, y a rien de dynamique dedans .

Je dis pas que tout est dynamique sur MD mais sur un bon BTA c'est le cas.
Y'a rien de dynamique dans SOR2 ? Ouvre le jeux dans Exodus, affiche les sprite box et regarde la SAT... mais après sinon tu as raison sur un point, ils arrivent à mettre tout les tiles des ennemis "standard" en VRAM et ne charge que les sprites persos / mi boss / boss dynamiquement... Par contre en cours de level ils mettent certains tiles de BG et de sprites à jour pour changer les ennemis et le décor. C'est une technique assez atypique, ils bouffent plus de 60% de la VRAM (environ 40 KB) pour les tiles de sprites, c'est absolument énorme. Encore une fois impossible d'en faire autant sur SNES avec sa contrainte de 16 KB pour la banque de sprite :p

[Tryphon]

Oui, pour moi dynamique, c'est charger les patterns à la volée. Je ne comprends pas ta définition en fait (allouer des slots VRAM aux sprites ?)

Dans Shadow Dancer, il me semble que TOUS les sprites sont dynamiques (à part les otages / bonus...)

Dans mon Shinobi, je fais un mix.

[Invité]

Je n'ai pas dit le contraire j'ai dit que tu met une table de meta sprite qui indique les sprite a charger , c'est pas ce qu'on peut appeler lourd en calcul (un peu complexe oui a mettre en place).

Perso pour un meta sprite de 4 sprites (en changeant tout les attributs), ca me prend 700/750 cycles max, mise en VRAM de la SAT comprise,et ma routine est assez générique donc pas optimisées au max .

[Tryphon]

Et dans un A-RPG tu ne crois pas que tu dois renvoyer a chaque frame ?
Je te fait la liste ce que tu dois envoyer a chaque frame :
-la Palette BG et personnage (variable mais en moyenne 0x70 octet)
-les Perso (1 perso = 0x200 octet)
-les armes (1 arme = 0x100 octet)
-les ennemis (1 ennemi (0x200-0x400 octet)
-les magies (1 magie = 0x300 octet)
-les degats ( 0x180 octet max)
-le BG (tile map) ( en multi directionel 0xF00 octet)
-le BG (data pour les animations) (variable moyenne 0x200 octet)
-Le hud (variable moyenne 0x200 octet)

Je sais pas comment se programme une SNES, mais j'ai l'impression que tu confonds les données statiques, qui sont chargées une fois à l'affichage de la map ou remises à jour rarement dans certains contextes particuliers, et les données qui doivent transiter à chaque frame.

Ou alors le format des tilemaps et des sprites tables est franchement dégueu sur SNES : sur MD une entrée tilemap c'est 2 octets, une entrée sprite c'est 8 octets.

[Invité]

Oui, pour moi dynamique, c'est charger les patterns à la volée. Je ne comprends pas ta définition en fait (allouer des slots VRAM aux sprites ?)

C'est à dire que tu cherches des emplacements vides dans ta vram (des slots) pour y caser des données et ainsi avoir une utilisation de la VRAM maximale, sans trous .
Donc des sprites qui peuvent avoir une position en VRAM dynamique ,et non statique,et vous vous parlez d'animations dynamiques et non de sprites .

Dans Shadow Dancer, il me semble que TOUS les sprites sont dynamiques (à part les otages / bonus...)

Oui mais ce genre de jeux utilisent un système de chrom (comme sur nes/NG) et non de la VRAM,donc c'est plus facile,juste une adresse de bank a changer(grosso modo).

[Tryphon]

Je parlais de la version MD. L'allocation dynamique sur 16 bits ? Ça existe ?

[Invité]

Je parlais de la version MD. L'allocation dynamique sur 16 bits ? Ça existe ?

Ca doit exister, pas que sur Md d'ailleurs, mais c'est assez complexe et lourd comme système,car il faut tenir a jour une sorte de carte de la VRAM,allouer/libérer des slots.
Par contre ça rend l'utilisation de la VRAM (ou une partie) très flexible.

[Invité]

Pour "-le BG (tile map) ( en multi directionel 0xF00 octet)"

Oui sûrement confondu (a force de faire les calcul des DATA , pour le hud je prend on compte que en envoie de gros bloc mais 0x100octet est plus logique , en plein combat y'a une fenêtre qui s'affiche) , bon le multi directionnel coûte donc en gros 0x80 octet.
Enfin ça n'empêche pas que pour le reste ça envoie énormément en VRAM.

[Invité]

Mais bon dans votre logique je vois pas en quoi une anim dynamique est spécialement intensive pour le CPU !!

C'est une technique assez atypique, ils bouffent plus de 60% de la VRAM (environ 40 KB) pour les tiles de sprites, c'est absolument énorme.

Bah ils utilisent la VRAM quoi,ça n'a rien d'atypique,c'est très classique, tu vas toujours faire en sorte de limiter les transferts le plus possibles,c'est d'ailleurs pour ça que les ennemis basiques des BTA ont peu de frames d'anims,parce qu'elles résident en VRAM ..
C'est ce que je te disais quand tu montrais SOR 1 et ses 10 sprites à l'écran(niveau du bateau), et vu que les ennemis étaient tous des clones, c'était évident que leurs anims étaient statiques,et non mises à jour a X frames .

[Stef]

Mais bon dans votre logique je vois pas en quoi une anim dynamique est spécialement intensive pour le CPU !!

C'est une technique assez atypique, ils bouffent plus de 60% de la VRAM (environ 40 KB) pour les tiles de sprites, c'est absolument énorme.

Bah ils utilisent la VRAM quoi,ça n'a rien d'atypique,c'est très classique, tu vas toujours faire en sorte de limiter les transferts le plus possibles,c'est d'ailleurs pour ça que les ennemis basiques des BTA ont peu de frames d'anims,parce qu'elles résident en VRAM ..
C'est ce que je te disais quand tu montrais SOR 1 et ses 10 sprites à l'écran(niveau du bateau), et vu que les ennemis étaient tous des clones, c'était évident que leurs anims étaient statiques,et non mises à jour a X frames .

Pour SOR1 je n'avais pas de doutes car les persos sont petits et mal animés mais j'avoue que je suis plus surpris pour SOR2 ou les ennemis me paraissent bien plus variés et mieux animés (en plus d'être plus grand). Et SOR3 c'est pareil au final, les persos principaux et mini boss / boss sont en dynamiques alors que les ennemis standards restent en VRAM.
En fait ce qui se passe c'est que les ennemis sont souvent rechargés lors du "GO" avec la flèche, tu changes d'ennemis souvent à ce moment. Mais du coup sur SNES avec tes pauvres 16 KB de tiles dédiés au sprite tu fais comment ? Car si SOR1 gache pas mal l'utilisation de la VRAM, SOR2 et SOR3 utilise un peu plus de la moitié de la VRAM rien qu'en sprites (et le reste est bien optimisé, les background prennent incroyablement peu).

Sinon bon j'ai regardé Aladdin ou Toy Story, ou les sprites sont hyper bien décomposés et dans ce cas tout est effectivement dynamique. C'est même impressionnant de voir la quantité de tiles balancés par frame dans Aladdin. Chaque pomme / item a son propre emplacement en VRAM, c'est impressionnant... Du coup je faisais plutot référence à ce genre de moteur de sprite. Je ne pensais pas que la VRAM pouvait contenir toutes les frames des ennemis standard dans un BTA comme SOR2, par contre j'ai voulu regarder Final Fight CD à nouveau car là je suis sur que la taille des sprites fait qu'il n'est pas possible de tout garder les ennemis en VRAM et que tout doit être en dynamique. Mais pas moyen de faire fonctionner l'émulateur avec le debug correctement :-/

C'est marrant aussi de voir la stratégie change d'un jeu à un autre, par exemple dans golden axe c'est l'inverse : les ennemis communs sont gérés en dynamique alors que les boss sont entièrement mis en VRAM, juste avant d'apparaitre (surement pour limiter les transferts DMA).

Je crois que pas beaucoup ont compris la transparence sur SNES.
Si tu active la transparence , le sprite tu pourra changer la  priorité , alors priorité basse il sera en dessous de l'eau est donc t'aura l'impression que tout ton perso est sous l'eau , ce qu'on ne veut pas (le haut du corps est la partie émerge).
Et pour ça ben tu divise ton sprite en 2x2 par exemple, pour que le haut reste hors de l'eau et le bas dans l'eau.

Ah ok mais dans ce cas il fallait expliquer ton cas pratique, en gros ça fonctionne car soit la moitié du perso est en transparence, soit rien, il ne peut pas rentrer "progressivement" dans l'eau du coup. C'est pour ça que je ne comprenais pas l'avantage de le découper en 2.

[Invité]

surpris pour SOR2 ou les ennemis me paraissent bien plus variés et mieux animés (en plus d'être plus grand). 

Oui plus grand c'est sur, mais la VRAM semble bien utilisée, avec peu d'espace vide,j'ai pas encore regardé pour SOR1 .

Et SOR3 c'est pareil au final, les persos principaux et mini boss / boss sont en dynamiques alors que les ennemis standards restent en VRAM.

Pour moi ça me semble normal de faire comme ça, sinon ça ferrait trop de donnée à transférer,et tu as pas mal de chances d'arriver sur une frame saturée en transferts(5 ennemis + 2 joueurs) et de dépasser du vblank .

On voit que le boss, eux ont bien plus d'anims que les classiques, donc surement eux aussi c'est dynamique .

Du coup je faisais plutot référence à ce genre de moteur de sprite.

C'est sur,mais tu peux pas faire ça pour tout les styles de jeux,perso je privilégie le plus possible l'utilisation de la VRAM qd c'est possible,et c'est toujours au cas par cas au final, selon ce que tu veux faire .

par contre j'ai voulu regarder Final Fight CD à nouveau car là je suis sur que la taille des sprites fait qu'il n'est pas possible de tout garder les ennemis en VRAM et que tout doit être en dynamique. Mais pas moyen de faire fonctionner l'émulateur avec le debug correctement :-/

Je serrai curieux de savoir aussi, pour moi aussi tout est dynamique vu la taille, mais je pense aussi que du double buffer est utilisé pour distiller les transferts sur plusieurs frames .

[Stef]

Des jeux comme Aladdin ou Toy Story arrivent à bien tout faire tenir alors qu'ils transfèrent tout et plus souvent (décompositions plus fluides). Et on peut pas dire que les sprites soient plus petits. Par contre y'en a peut être un peu moins même si dans le cas d'Aladdin y'a énormement de chose entre les explosions, les fumées, les effets quand tu prends des items... pas sur que ça fasse moins au final. L'astuce, c'est de décomposer les transferts sur plusieurs frames. Par exemple pour un jeu que tu vas animer en 20 images / seconde (ce qui est déjà beaucoup) tu peux faire ça :
frame 0: perso principal et ennemi type A
frame 1: ennemi type B et C
frame 2: items et le reste
Et du coup tu peux animer "15 KB" de sprites (et sans besoin de double buffer) ce qui est déjà beaucoup. Je pense que Aladdin décompose au moins sur 2 frames (30/25 FPS) et idem pour Toy story...

[Invité]

Ouai, mais ça veux dire que tu peux pas avoir une anim en dessous de 3 frames,ce qui peux poser un souci lors de changement de direction du perso par exemple, ou tu dois être à la frame pour éviter un effet sensible de flottement dans l'animation/commandes (déjà testé le cas,donc c'est pour ça) .
Mais bon c'est une idée qui peut marcher .

[Tryphon]

J'aime bien l'idée du double buffer. Y'a des jeux MD qui font ça ?

[Invité]

J'aime bien l'idée du double buffer. Y'a des jeux MD qui font ça ?

Le double buffer a pas mal d'avantages, comme pouvoir charger une anim par petits chunks à chaque frames, ça évite d'être en idle le temps que les frames passent, et tout faire à la dernière(ça évite d'avoir des frames chargées et d'autres vides) .
Tu évites l'engorgement du DMA et des frames, et économise du vblank (pour autre chose),et tu peux te permettre d'avoir des sprites plus gros .
Inconvénient, besoins en VRAM x 2,et code un peu plus complexe pour les transferts ..

Pour les jeux, je dirai FF,mais à confirmer .

[ace76]

La NES, la GB et la SNES, c'est de loin la meilleure période Big N ...

ils etaient omnibulé par le gain que le reste peu importe...

Dans ce cas le Mega CD et le 32X, c'est dans quel but? comment le justifier?

Je pense pas que l'apat du gain fut un leitmotiv chez SEGA.Il est de notoriété que chez Sega les cadres étaient
plus de doux reveurs accrocs de technologie que des requins du marketting.
En gros c'est comme Wozniak avait été le PDG d'Apple.
Sega a plus consolidé l'avance technologique ,voire fait une demonstration de leur savoir faire en sortant le 32x.
Le mega cd est pour moi indispensable ,je crois pas que cette machine fut une erreur.

[Stef]

Ouai, mais ça veux dire que tu peux pas avoir une anim en dessous de 3 frames,ce qui peux poser un souci lors de changement de direction du perso par exemple, ou tu dois être à la frame pour éviter un effet sensible de flottement dans l'animation/commandes (déjà testé le cas,donc c'est pour ça) .
Mais bon c'est une idée qui peut marcher .

Pour ça tu utilises le flip hardware, ça coute rien et donc c'est immédiat. Théoriquement pour un changement de direction tu peux être dans la continuité du mouvement précédent... Et si ce n'est pas le cas je pense que l'effet perçu (flip puis nouvelle frame plus tard) n'est pas si mauvais à partir du moment ou le perso se flip immédiatement.
Mais réellement je pense que ça peut poser soucis dans certains cas quand même pour le perso principale où il vaut mieux une réactivité immédiate pour chaque action pour un meilleur feeling. Je pense que tu peux forcer un slot de refresh au moins à 30 FPS pour ton perso (1 frame de retard ça doit être à peine perceptible) et pour les ennemis tu peux t'autoriser 2 voire 3 frames.
Je suis convaincu que pas mal de jeux sur SNES ont du abuser un peu de cette astuce (même pour les persos principaux) car il n'est pas rare que certains jeux multi plateforme (comprendre sortis sur MD et SNES) avaient comme une sorte de "input lag" sur SNES qui était absent de la version MD.

[Invité]

En fait ce qui se passe c'est que les ennemis sont souvent rechargés lors du "GO" avec la flèche, tu changes d'ennemis souvent à ce moment. Mais du coup sur SNES avec tes pauvres 16 KB de tiles dédiés au sprite tu fais comment ? Car si SOR1 gache pas mal l'utilisation de la VRAM, SOR2 et SOR3 utilise un peu plus de la moitié de la VRAM rien qu'en sprites (et le reste est bien optimisé, les background prennent incroyablement peu).

Ben tu fait tout en dynamique :)
Comme la plupart des jeux et comme SoM.

Pour moi ça me semble tout t'a fait normal de renvoyer a la VRAM en continu (les sprite /Palette/BG tile et DATA), tu met juste une variable qui limite les envoies (quand tu on fait trop) et voila , bref pas le plus complexe a implémenter en faite (ça peut être déroutant au début certes).

On plus j'ai oublier de dire que sur SNES il faut renvoyer l'OAM a chaque frame (qui fait 0x220 octet).

[Stef]

Pourquoi tu dis qu'il faut renvoyer l'OAM à chaque frame ? Si tu utilises que 40 sprites tu peux ne renvoyer que les 40 premières entrées de l'OAM ?
Sinon sur MD, l'OAM c'est 640 octets mais tu peux te limiter juste aux nombres de sprites actuellement utilisés :)

[upsilandre]

Encore une fois impossible d'en faire autant sur SNES avec sa contrainte de 16 KB pour la banque de sprite :p

Parmis tout les nombreux defaut de la gestion des sprites sur SNES c'est quelque chose que j'avais completement oublié (pourtant j'ai vérifié c'est bien inscrit dans mes notes). C'est quand meme embêtant (512 tiles de sprites c'est ce qui est potentiellement adressable aussi sur NES meme si pas exploitable dans la pratique) et du coup ca doit pousser sur SNES a l'utilisation de moteur avec double buffering pour le tileset des sprites (avec les avantages et inconvénient qui vont avec) plus que sur les autres machines.

[Tryphon]

Une question sur la transparence sur SNES : ça fait quoi exactement ?

Si un sprite transparent de couleur c1 se trouve sur un décor de couleur c2, le sprite va apparaître avec la couleur (c1 + c2)/2 ?

C'est forcément un sprite sur un background, ou ça peut être l'inverse ? ou un background sur un background, ou un sprite sur un sprite ?

[Invité]

Il me semble que la transparence sprites/sprites n'est pas possible .

[airdream]

la transparence a la sonic sur MD donne quand meme un rendu tres acceptable (niveau aquatique)
donc si j'ai bien suivi c'est un changement de palette en debut de scanline, on peut donc avoir sonic sur la tete hors de l'eau en couleur normale, et le corps submergé de couleur differente.
ce genre d'effet me semble rare sur MD, ca coute en CPU?
quel autre jeu a cet effet? 
aussi sur snes en effet jamais vu un sprite avec effet de transparence sur autre sprite (voir bouclier protection contra snes et GBA (cette derniere le peut)

edit: je viens de verifier, l'effet est different de la version GBA 
sur snes le sprite change de couleur mais pas le decor alors que sur GBA le decor et le sprite change de couleur.
rien de surprenant donc la GBA gere une transparence plus poussée.

GBA
https://youtu.be/8A9lFIDNIMs?t=1m50s

SNES
https://youtu.be/DoQBfWT4v28?t=2m54s

[Invité]

ce genre d'effet me semble rare sur MD, ca coute en CPU?

Un peu (si tu utilises le DMA pendant le hblank),car il faut utiliser les interruptions qui sont lentes sur le 68k, mais sur 1 ligne y'a rien de dramatique .
Et cet effet est bcp utilisé sur Md, et souvent les devs rajoutent des sprites sur la ligne pour masquer les artefacts à cause des changements de palettes .

[airdream]

oui c'est vrai a la surface il y a des vagues qui clignotent dans sonic.
mais souvent je vois plus du dithering sur MD pourtant

[Invité]

mais souvent je vois plus du dithering sur MD pourtant

CAD ??

[airdream]

niveau aquatique de quackshot


https://youtu.be/nrHZtnlLK10?t=19m54s

je vois plus ce genre la que celui de sonic

voir HOOK aussi au debut du jeu on traverse une etendu d'eau, la transparence est belle sur snes, mais facon quackshot pour le hook MD/MCD.

Oui desolé je parlait de l'eau et non de l'effet de surface je me suis mal fait comprendre

[Invité]

niveau aquatique de quackshot


https://youtu.be/nrHZtnlLK10?t=19m54s

je vois plus ce genre la que celui de sonic

Ah oui,mais c'est pas du dithering mais un effet damier sur les tiles(1 pixel sur 2 est vide).

Si tu vois cet effet plus souvent c'est juste qu'il est plus simple à faire .

[Tryphon]

Une question sur la transparence sur SNES : ça fait quoi exactement ?

Si un sprite transparent de couleur c1 se trouve sur un décor de couleur c2, le sprite va apparaître avec la couleur (c1 + c2)/2 ?

C'est forcément un sprite sur un background, ou ça peut être l'inverse ? ou un background sur un background, ou un sprite sur un sprite ?

Pardon de me quoter, mais en fait ça m'intéresse

[Invité]

Je pense que tout est bon sauf sprites sur sprites qui n'est pas faisable .