Re: MEGADRIVE vs SUPER NINTENDO : Fight !

[Invité]

En fait je parlais pas de résolution d'affichage, le 512x240 n'a effectivement aucun interet ici.
Je parlais uniquement en sprite-pixel/scanline. A cause de son archi la SupergrafX ne peut pas rivaliser réellement avec un vrai GPU 512sp/scanline comme celui du X68000 par exemple (mais bon c'est pas ce qu'on lui demande)

Mais comment veux tu atteindre 512 pixels /ligne sur une réso de 256 ou 320 pixels ??
C'est quasi impossible à moins de le faire exprès .

Tu dis ghouls'n ghost n'est pas du tout optimisé, j'ai joué a cette version en mode debug de bout en bout et en switchant les VDC pour voir la répartition et je peux te dire qu'ils ont plutot bien optimisé la repartition, c'est pensé pour la sgx, c'est pas un jeu PCE. Mais y a 2 ou 3 endroit ou ca n'a pas empecher l'overflow. A la fin contre les petits nuages c'est une cata complete, on est en dessous de la megadrive sur cette sequence, mais la y avait effectivement bien mieux a faire en terme de répartition (et en plus tellement confiant dans le potentiel de la sgx qu'il y a meme pas d'implementation de rotation de la liste de sprite donc ils disparaissent complètement     ). C'est la fin du jeu donc ils ont peut etre pas fait l'effort  mais ca montre que ca demande quand meme pas mal d'effort au cas par cas.

Il n'est pas optimisé dans le sens ou la répartition des sprites n'est pas bonne, elle est essentiellement sur le VDC1 d'où les clignotements .
La vram aussi mal utilisée, plein de vide, alors qu'ils auraient bien pu utiliser la place pour décompresser et avoir plus de détail,comme c'est le cas pour 1941 .
Le hud est minimaliste, alors qu'il aurai pu être comme l'arcade .

Pour certaines parties, la MD s'en sort grâce à ses priorités /tile, sur PCE/SGX tu es obligé d'utiliser des sprites, notamment le passage avec les guillotines,qui utilise des sprites du VDC1,en plus les guillotines sont des sprites de 32x64, alors que seul un 16x64 (pour le masquage) était nécessaire,donc forcement ça clignote .

C'est pas comme si des jeux mal ou pas optimisés n'existaient pas sur tout les supports .
Rien qu'a voir l'utilisation des palettes dans GnG, tu vois de suite que c'est pas optimisé du tout.Ca passait dans l'état,c'était mieux que la version MD (qui n'est pas optimale non plus), donc ils ont pas cherché plus loin .

Le Boss nuage du 3eme level la y a une bonne répartition des sprites mais ca n'a pas empecher d'avoir de l'overflow. C'est d'ailleurs une scene (avec celle de l'averse) ou la Megadrive s'en sort pas mal je trouve en comparaison (attention j'attaque le point sensible   ) alors c'est peut etre moins bien mais tres proche grace a une particularité de la Megadrive.

Si tu arrives à de l'overflow avec 512 pixels, alors que ça passe sur Md, y'a réellement un problème d'utilisation des sprites .
1941 est bien plus intensif dans l'affichage de sprites, et clignote pas et ce jeu est infaisable tel quel sur Md/snes avec une cartouche de 8MB .

Si y avait eu la possibilité de faire des sprite 24x24 y aurait pas eu d'overflow sur cette scene (et si c'etait un vrai GPU 512spps ca serait probablement passé aussi je pense). C'est finalement une scene qui profite bien des particularités de la Megadrive mais on peut pas dire que c'est parce que la conversion est raté sur sgx (meme si y a toujours moyen de faire mieux), d'autant qu'elle reste quand meme au dessus meme sur ce genre de scene.

C'est sur que les pas de 16 pixels n'aide pas, du moins pour la PCE, mais là c'est n'importe quoi, 512 pixels même dans le cas de la SGX, ça doit pas clignoter, sauf mauvaise utilisation .

Déjà pour l'adaptation de dragon ninja sur MD, tu es obligé de faire des concessions, alors que sur SGX non .

On peut pas dire ca, 512spps c'est loin d'etre trop, c'est jamais trop (le CPS1 c'est dans les 1024spps pour un affichage 384 et d'autre systeme vont encore plus loin pour du 320) 

Ca n'a aucun sens ce que tu dis, si 512 pixels c'est pas assez, je vois pas comment les 320 de la Md peuvent suffire ..
Avec 512 pixels tu couvres 1,5x un écran de 320, aucun intérêt d'afficher tout les sprites dans une partie non visible de l'écran si tu sais que tu risques d'être juste .
Et tu compares un système d'arcade qui doit coûter 8/9 fois le prix d'une SGX, faut pas déconner non plus .
La SGX est à comparer avec une MD/SNES, en arcade on compare avec du comparable, CAD des jeux qui peuvent être retranscrits sans problème GNG en fait partie,j'irai jamais te dire qu'un gros jeu CPS1 ou 2 est reproductible .

Forcement quand tout ton hard est démesurément puissant t'as pas de limite à prendre en compte, donc gâcher est monnaie courante.

[upsilandre]

Mais comment veux tu atteindre 512 pixels /ligne sur une réso de 256 ou 344 pixels ??
C'est quasi impossible à moins de le faire exprès .

Le principe des sprites c'est qu'ils se superposent meme quand on s'en rend pas compte visuellement (puisque les box sont toujours plus que ce qu'on voit, surtout sur des petits sprites genre bullet, et ils peuvent ne pas etre visuellement sur la meme ligne alors que leur box si). Les tires, explosions, ennemis, hud... c'est plein de superpositions, suffit de voir justement le boss nuage de ghouls'n ghost (et qui est tres bien géré contrairement a ce que tu dis, la moitié des nuages dans un VDC et le reste dans l'autre, le boss est divisé en 2, meme répartition entre le joueur et ses tires qui sont réparties. C'est juste que les sprites sont plus gros et nombreux que sur MD et que la répartition ne permet pas d'atteindre les 100%).

Quand tu superposes 2 sprites de 32x32 tu as une charge de 64spps, ca s'additionne, tu peux tres bien avoir 1000spps sur 32 pixels d'affichage (ca serait debile mais c'est pour illustré qu'il y a pas une corrélation direct avec la résolution d'affichage, la corrélation est indirect).
Le CPS1 a 3 plans donc pas besoin de sprite pour le HUD ou autre effet et pourtant il a plus de 1000spps a dispo pour les sprites et c'est pas de la HD et c'est pas ce qu'on fait de mieux.
La NeoGeo c'est du 1536spps juste pour affiché du 304, alors elle l'utilise aussi pour le background mais ils ont facile un budget x3 la resolution de l'affichage juste pour les sprites. La sgx en mode 340 ca donne du 1.5 theorique mais impossible a atteindre du a la répartition, donc plutot du 1.3x. C'est pas difficile a atteindre, c'est mieux que les 16bit mais pas du tout un truc qui te met a l'abris de l'overflow.



Et pour tes propos sur 1941 et Ghouls'n ghost je suis tellement pas d'accord avec toi.  
Y a clairement plus de boulot sur Ghouls'n ghost. La répartition est tres bien géré. Prenons le premier level.
- Le joueur et ses tires/pouvoir sont réparties dans 2 VDC different.
- Les zombies et les vautours qui sont 2 ennemis qui peuvent attaquer en nombre sur la meme ligne sont aussi répartie dans 2 VDC different.
- niveau décore t'as par exemple les pierres tombales et coffres dans un VDC et les guillotines dans un autres.
- encore plus subtile, la partie inferieur du HUD qui peut entrer en conflit avec les sprites du jeu a ete répartie dans les 2 VDC (si ca c'est pas un signe qu'ils ont bien réfléchie et optimisé?)
- autre exemple, la mort d'un zombie c'est a la fois sa décomposition et une explosion et bien ca a ete répartie dans les 2 VDC.
- ou la sequence de la pluie avec la pluie dans un VDC et les ennemis dans l'autre.
- les Boss toujours reparties motié/moitié entre les 2 VDC
ect...  On peut difficilement faire mieux.

ils ont super bien bossé. Y a meme plus de sprite dans la VRAM du VDC2 (contrairement a ce que tu dis) vu que le background prend moins de place (mais des sprites moins stressant pour l'affichage pour equilibré) du coup meme la VRAM est plutot bien exploité (et c'est pas facile car tu peux pas juste mettre la ou il reste de la place, faut que ca colle avec tes besoins de répartition des sprites) d'autant qu'ils font meme plusieurs loading pendant le level (2 loading de sprite et 2 loading de background dans le VDC1. le VDC2 lui a de l'animation de tile en continu pour le joueur) et avec 1Mo de cartouche tu peux pas non plus remplir indéfiniment 128Ko de VRAM donc la limite c'est plutot la cartouche que leur mauvais usage de la VRAM.
et surtout le jeu utilise le mode video 7.16mhz! c'est autre chose en terme de contrainte.
Vraiment pour un jeu de lancement on peut pas dire qu'ils ont pas bossé, on peut toujours faire mieux avec plus de temps mais c'est une vrai version sgx.


A cote t'as 1941 qui nous sort un vieux mode 5.37mhz en 256 donc rien que la deja c'est incomparable en terme de contrainte et comme démonstration sgx le 256 c'est bof.
Niveau répartition c'est plus basique que ghouls'n ghost, la plupart du temps c'est juste tous les ennemis dans un VDC et tout le reste (hud, joueur et tire/explosion) dans l'autre et ensuite des boss qu'on répartis.
Alors je pense que c'est probablement le bon choix, j'ai pas de critique a faire mais c'est moins de boulot que sur ghouls'n ghost surtout sans le stress du mode 7.16mhz. Et niveau VRAM je vois pas trop en quoi c'est mieux exploité.

[upsilandre]

En plus un shoot vertical c'est l'ideal comme contexte. Ca répartit assez naturellement la charge sur toutes les scanlines.
Un jeu comme GnG qui est un side-scroller avec un personnage soumis a la gravité a tendance a concentrer l'action sur une bande horizontal ou se trouve le joueur et donc sur peu de scanline. Et GnG c'est pas qu'un platforming, c'est aussi du shoot.

[sengoku 2]

Toujours aussi intéressant ce topic, j'avoue ne pas tout saisir avec vos termes techniques.
Comme le spps ? ( sp pour sprite ? )

Upsilandre, je suis partant pour une autre série de gif animés et aussi si tu parles de NG.
Cela nous fait un troisième gros connaisseur en compagnie de Stef et Touko.

Justement dans cette page, ça parle du 3 ème plan sur certains jeux md . ( possible avec des sprites )

http://www.sega-16.com/forum/showthread.php?22265-Advantages-of-SNES-hardware-vs-Genesis-hardware/page144

[Invité]

Le principe des sprites c'est qu'ils se superposent meme quand on s'en rend pas compte visuellement (puisque les box sont toujours plus que ce qu'on voit, surtout sur des petits sprites genre bullet, et ils peuvent ne pas etre visuellement sur la meme ligne alors que leur box si). Les tires, explosions, ennemis, hud... c'est plein de superpositions, suffit de voir justement le boss nuage de ghouls'n ghost (et qui est tres bien géré contrairement a ce que tu dis, la moitié des nuages dans un VDC et le reste dans l'autre, le boss est divisé en 2, meme répartition entre le joueur et ses tires qui sont réparties. C'est juste que les sprites sont plus gros et nombreux que sur MD et que la répartition ne permet pas d'atteindre les 100%).

Si tu arrives à l'overflow parce que trop de sprites se superposent c'est que tu as un soucis de design dans ton jeu .
Si on parlais de faire tourner un jeu en 512 pixels là ok, mais vu la marge que tu as à dispo en 320, c'est un soucis côté devs .
Surtout dans des jeux du style GnG, ou y'a pas de quoi arriver à cette limite,sauf un gros problème de design évident .

Quand tu superposes 2 sprites de 32x32 tu as une charge de 64spps, ca s'additionne, tu peux tres bien avoir 1000spps sur 32 pixels d'affichage (ca serait debile mais c'est pour illustré qu'il y a pas une corrélation direct avec la résolution d'affichage, la corrélation est indirect).

Oui si tu as de la BP à perdre pourquoi pas, en arcade ça n'empêche pas des jeux et même cps1/2 d'avoir des clignotements .
Quand c'est mal géré,c'est mal géré, même sur un hardware de la mort .

La NeoGeo c'est du 1536spps juste pour affiché du 304, alors elle l'utilise aussi pour le background mais ils ont facile un budget x3 la resolution de l'affichage juste pour les sprites

La NG est une machine d'arcade pas une console, et je te signale qu'elle écrase aussi bien la snes que la MD en terme de sprites .
Et la NG n'a pas de plan, tout est fait de sprites,donc encore heureux qu'elle ai cette limite .

Et pour tes propos sur 1941 et Ghouls'n ghost je suis tellement pas d'accord avec toi.   
Y a clairement plus de boulot sur Ghouls'n ghost. La répartition est tres bien géré. Prenons le premier level.
- Le joueur et ses tires/pouvoir sont réparties dans 2 VDC different.
- Les zombies et les vautours qui sont 2 ennemis qui peuvent attaquer en nombre sur la meme ligne sont aussi répartie dans 2 VDC different. 
- niveau décore t'as par exemple les pierres tombales et coffres dans un VDC et les guillotines dans un autres.
- encore plus subtile, la partie inferieur du HUD qui peut entrer en conflit avec les sprites du jeu a ete répartie dans les 2 VDC (si ca c'est pas un signe qu'ils ont bien réfléchie et optimisé?)
- autre exemple, la mort d'un zombie c'est a la fois sa décomposition et une explosion et bien ca a ete répartie dans les 2 VDC.
- ou la sequence de la pluie avec la pluie dans un VDC et les ennemis dans l'autre.
- les Boss toujours reparties motié/moitié entre les 2 VDC
ect...  On peut difficilement faire mieux.

Ah bon et tu trouves normal que des elements sur le même niveau que le joueurs soient sur le VDC1 ??
Et en plus en utilisant des tailles de 32x64 où juste 16x64 était suffisant ??
Je persiste sur ce fait, et je peux te garantir qu'il ne devrait pas y avoir de clignotement.
Et franchement à ton avis quelle est la probabilité que des sprites soient sur la même ligne que le HUD par rapport à des sprites en plein champs du joueur ?? ,vaut quand même mieux que ce soit le HUD qui clignote rarement plutôt que souvent sur des éléments en plein milieu du jeu non ??
Je dis pas qu'il est foiré, juste pas optimal,et que tu peux aisément faire mieux .  
Un jeu complètement foiré, c'est strider sur PCE .

le VDC2 lui a de l'animation de tile en continu pour le joueur) et avec 1Mo de cartouche tu peux pas non plus remplir indéfiniment 128Ko de VRAM donc la limite c'est plutot la cartouche que leur mauvais usage de la VRAM.
et surtout le jeu utilise le mode video 7.16mhz! c'est autre chose en terme de contrainte.
Vraiment pour un jeu de lancement on peut pas dire qu'ils ont pas bossé, on peut toujours faire mieux avec plus de temps mais c'est une vrai version sgx. 

Ne me fais pas dire ce que j'ai pas dit, j'ai jamais dit que le jeu était bâclé, mais non optimal, et même sur 1 Mo tu pouvais faire mieux, bien sur toujours pas arcade perfect, mais mieux surtout niveau couleurs et clignotements, et même plus de détails .
le 320 n'apporte pas plus de contraintes, si ce n'est de taille de rom.
Comme dit, GnG était reproductible sur SGX et sur MD avec plus d'espace, la rom arcade fait 4Mo,donc même avec 1 Mo on est loin du compte .

A cote t'as 1941 qui nous sort un vieux mode 5.37mhz en 256 donc rien que la deja c'est incomparable en terme de contrainte et comme démonstration sgx le 256 c'est bof.
Niveau répartition c'est plus basique que ghouls'n ghost, la plupart du temps c'est juste tous les ennemis dans un VDC et tout le reste (hud, joueur et tire/explosion) dans l'autre et ensuite des boss qu'on répartis.
Alors je pense que c'est probablement le bon choix, j'ai pas de critique a faire mais c'est moins de boulot que sur ghouls'n ghost surtout sans le stress du mode 7.16mhz. Et niveau VRAM je vois pas trop en quoi c'est mieux exploité.

1941 en arcade est en écran à 90°, si tu veux garder les proportions sur un écran classique t'as pas le choix  .
Et détrompes toi, ce jeu à demandé bcp plus de taf que GnG, regarde bien la version arcade, tu verras le truc bien plus poussé que GnG qui devait surement être un des premiers jeux CPS .
Convertir 1941 sur SGX est un sacré boulot, y'a bcp plus de choses à gérer à un rythme soutenu,ce que n'a pas GnG .

[upsilandre]

Toujours aussi intéressant ce topic, j'avoue ne pas tout saisir avec vos termes techniques.
Comme le spps ? ( sp pour sprite ? )

C'est une abréviation que j'ai improvisé un peu par nécessité de répétition et qui est effectivement détaillé seulement dans le premier post.
c'est pour "sprite-pixel per scanline". C'est a dire le nombre de pixel de sprite (meme invisible) qui sont sur la meme ligne d'ecran car c'est la principale contrainte d'affichage des sprites (sachant qu'ils peuvent se chevaucher/superposer). Chaque GPU a sa limite. Ce qui est compliqué avec la sgfx c'est qu'il y a 2 GPU en parallèle donc tu peux atteindre la limite sur l'un et pas sur l'autre donc la limite effective ne s’évalue pas aussi facilement que pour les autres machines.

Upsilandre, je suis partant pour une autre série de gif animés et aussi si tu parles de NG.

J'aime bien faire des gif pixel perfect, dans la resolution original, sans perte (d'autant qu'en général il y a moins de 256 couleurs a part pour la neogeo) et avec toutes les frames. Ca permet d'avoir quelque chose de précis qui n'est pas possible sur youtube ou parfois ca rend différemment.
Mais bon la j'ai un peu la flemme (je voudrais en faire sur Batman&Robin MD et quelques uns sur SNES car j'en ai pas). Par contre j'en ai plein sur SMS et NES.
La NeoGeo c'est tres intéressant et singulier comme machine (et tres simple d'une certaine facon) car c'est vraiment de l'archi arcade.
J'ai ca si tu veux en Gif NeoGeo



Animation de tile full screen (enfin demi car y a une symetrie horizontal) sur 32 frames. De la video lossless  

Cela nous fait un troisième gros connaisseur en compagnie de Stef et Touko.

J'ai pas autant d'experience. Je me suis toujours intéressé aux technologies des consoles mais ca fait seulement 2 ans que je suis vraiment dedans et que je décortique les machines et les jeux en mode débug pour le plaisir de comprendre (frustration de l'enfance, ce monde cruel sans internet).
Au debut beaucoup les machines des années 70 car plus c'est archaique plus y a des curiosités qui surprennent (ChannelF, StudioII, Astrocade...). j'ai programmé en assembleur un peu sur Atari2600 (et un peu sur NES) et ca c'est une experience vraiment intéressante tellement c'est singulier comme machine mais la programmation c'est malheureusement trop chronophage.
Petit a petit je suis remonté jusqu'a la PCE,MD,SNES,NeoGeo mais j'ai pas une grosse expérience (du coup ca m'intéresse d'autant, surtout que si on prend la SNES ca devient vraiment complexe, on franchit un gros pallier).
En plus la je suis en congés et je viens seulement de trouver ce forum    (pas si facile a trouver pour un gros forum, pourtant j'ai plusieurs fois fait des recherches de forum de ce genre, bizarre)

Justement dans cette page, ça parle du 3 ème plan sur certains jeux md . ( possible avec des sprites )

A partir des 16bit y a beaucoup de possibilité de trick. Faut etre ingénieux.
Deja sur NES y a ca par exemple:


2 vrais plans indépendants avec un vrai scrolling multidirectionnel. En terme d'animation de tile c'est lourd pour simuler ca, ca necessite 64 versions du motif de ce second plan (pour simuler tous les offsets horizontaux et verticaux 8x8). Ce simple motif de second plan occupe 4 fois plus de place sur la cartouche que tout les backgrounds du jeux Super Mario Bros  (mais c'est seulement 1/16eme de la cartouche donc ca passe)

Voila c'etait juste pour balancer des Gif et remplir le quota

[upsilandre]

Si tu arrives à l'overflow parce que ...

Je suis tellement pas d'accord sur quasiment aucun point que j'imagine qu'on arrive a la fin de cette discussion .
Tanpis on peut pas etre daccord sur tout, c'est pas grave .

[Invité]

Non, ce n'est pas grave d'avoir des avis divergents c'est ce qui est intéressant,tu soulèves pas mal de points très pertinents .
Après je te parle de mon expérience de codeur sur SGX, mais bon j'ai pas explorer tout les cas non plus, mais je peux t'affirmer que le système n'est pas du tout pratique par contre pour des BTU à la SOR .
Où là on rentre dans quasiment toutes les problématiques que tu as soulevé .

Après pour rentrer dans des détails comme ceux que l'on a évoqués, il faut coder pour voir réellement ce que tu peux ou ne peux pas faire, la théorie a ses limites . 

Au niveau de la flexibilité des sprites la MD reste devant, juste qu'avec la SGX on peut s'affranchir des limites de la PCE et avoir plus de possibilités .

La NeoGeo c'est tres intéressant et singulier comme machine (et tres simple d'une certaine facon) car c'est vraiment de l'archi arcade.

Elle a un hard intéressant c'est vrai, mais n'oublies pas qu'elle n'a pas de plan (bon je compte pas la fix), tout est fait de sprites, d'où la limite impressionnante de 96 sprites/ligne .

[sengoku 2]

Moi qui suis la NG, je me rappelle enfin où je t'avais lu Upsilandre, c'était ici et avec un magnifique Gif de Batman Nes :

http://mag.mo5.com/a-la-une/68128/les-podcasts-de-mo5-com-32-la-neo%C2%B7geo-a-25-ans/

Et aussi sur Youtube où tu avais dit cela sur la NG :


Si tu trouves les effets de zoom bizarres c'est parce qu'il n'y a pas de zoom sur NeoGeo. La seule fonction qu'elle possède c'est le "shrinking" qui permet de sauter des lignes lors de l'affichage d'un sprite pour réduire sa taille (mais effectivement de facon un peu crado car un vrai downscale ca se fait pas juste en enlevant des lignes, faut les mélanger pour pas perdre toute l'information). Donc chaque fois que tu vois un zoom dans un jeu NeoGeo c'est en fait juste un sprite qui reprend sa taille originelle tel qu'il est dans la cartouche. D'ailleurs meme ce shrinking basique elle ne le supporte pas réellement en hard. Y a une ROM de 64Ko dans la console qui contient la table de shrinking qui indique au GPU pour chaque ligne du sprite si il faut afficher cette ligne ou pas selon sa valeur de shrinking donc c'est cette ROM qui contient quelques dizaines de milliers de valeurs précalculées qui fait tout le boulot, pas vraiment le GPU qui n'est pas capable de calculer ces valeurs en temps réel. Le GPU est tres rudimentaire. En fait la Neogeo est une console au GPU tres basique, elle ne gère pas de background ni de scrolling, pas de zoom, rotation ou autre effet et une résolution plus faible qu'une Megadrive. Par contre c'est un monstre a cracher du sprite, elle est uniquement conçu autour de cette aptitude hors norme (au point donc qu'elle peut construire ses backgrounds uniquement avec des sprites) et elle a aussi vraiment beaucoup de palettes a disposition des programmeurs et donc de liberté artistique. Coupler a des cartouches enormes directement connectés aux differents processeurs de la console ca permet des miracles.Ca en fait une machine au hardware assez exotique qui sort du shema des consoles tel qu'il existe depuis l'Intellivision jusqu'a la SNES mais comme on pourrait s'y attendre finalement d'une machine d'arcade.

[upsilandre]

Le probleme c'est que je suis partout mais pourtant personne ne m'a jamais parlé de ce forum, vous garder bien vos secret

[sengoku 2]

Dans mon dernier message, j'ai posté l'intégralité de tes messages que j'avais lu.
Je te prenais pour une sorte de Douglas Alves, un genre de spécialiste qui se fait rare dans les forums mais que l'on voit plus souvent en Vidéo.
Puisque tu es accessible, on sera  nombreux à te harceler pour avoir d'autre gif animés.

[upsilandre]

Ah bon et tu trouves normal que des elements sur le même niveau que le joueurs soient sur le VDC1 ??

Je me suis refais encore une partie    (je l'ai peut etre pas dit ici mais je suis gros fan des Makaimura, c'est mon jeu d'arcade préféré) et a titre indicatif la guillotine est dans le VDC2, alors oui c'est la que se trouve le sprite du joueur mais dans le VDC1 y a deja les tires et les zombies (et une partie du hud qui dépasse). Je t'ai fais l'addition juste pour info: Les tires peuvent a l'extreme prendre jusqu'a 240spps de budget (on atteins presque les limites mais c'est vraiment le cas extreme avec les pouvoirs) et les Zombies c'est jusqu'a 144spps (quand y en a 3) + 32spps du HUD (qui entre seulement en conflit avec les zombies) donc 176spps, donc ca c'est juste pour le VDC1.
A coté de ca dans le VDC2 le sprite du joueur c'est juste 48spps (80 quand il a l'armure d'or avec la cap) donc rien d'idiot a mettre les guillotines sur le meme layer vu que l'autre est deja pas mal chargé. Le probleme c'est la scene de l'arbre aux vautours car ils sont tres lourd (en VRAM et en spps) et donc ils les ont pas mis dans le meme layer que les zombies qui attaque en meme temps durant tout le niveau, du coup il se retrouve dans l'autre layer et donc avec les guillotines et la ca peu coincé sur cette scene de l'arbre (d'autant que les vautours mort laisse un paquet de plume qui mettent longtemps a disparaître) mais vraiment de facon tres discrete et breve. Non le seul vrai probleme dans le jeu c'est les 2 scenes avec les nuages.

J'ai relancé ma savestate au boss nuage (d'ailleurs juste avant y a le passage de plateforme sur les langues et chaque langue est coupé en morceau, la moitié dans un VDC et l'autre dans le second) et rien a faire, je vois pas comment améliorer. ils ont parfaitement répartie les differents type de nuage entre les 2 layers pour equilibrer avec le sprite joueur et ses tires eux meme repartis entre les 2 layers. Ils ont meme dupliqué le gros oeil central et le font switcher d'un layer a l'autre selon la pattern du boss pour mieux equilibrer donc on sent bien l'effort qu'ils ont fait sur cette scene mais ca overflow de partout malgres tout.
En fait leur seul tord c'est d'avoir voulu reproduire strictement la version arcade (ils auraient pu enlever quelques sprites) et sur cette scene c'est juste pas possible, ca peut pas passer.

Mais la dessus au moins on peut se rejoindre. Le manque d'optimisation en quelque sorte c'est d'avoir reprit strictement les sprites de l'arcade (meme si perso j'aime bien l'idée) pas la facon dont ils ont répartit.
Sur la version arcade ils cherchent pas systematiquement a exploiter au max une box de 16pixels ou de 32pixels. Y a une libérté artistique grace au perf de la machine, si ils ont besoin d'un element graphique de 22 pixels ils se gènent pas (et ca sera dans une box 32). Si ils ont besoin d'un element de 36 pixels pareille (ca sera dans une box de 48). Sur Megadrive ils ont refait tous les sprites et parfois juste grignoter quelques pixels pour faire rentrer du 48 dans du 32 (par exemple les sprites du joueurs ou des zombies).
Sur sgx a part quelques boss ils ont reprit strictement les sprites de la version arcade (sachant qu'en plus ils ont pas de 3eme plan et donc aussi le hud en sprite) donc le seul truc qu'on peu leur reprocher c'est ca, c'est d'avoir reprit les sprites arcades (mais moi j'aime plutot bien meme si y a un prix a payer, la plupart du temps ca passe bien)

[Invité]

Je me suis refais encore une partie    (je l'ai peut etre pas dit ici mais je suis gros fan des Makaimura, c'est mon jeu d'arcade préféré) et a titre indicatif la guillotine est dans le VDC2, alors oui c'est la que se trouve le sprite du joueur mais dans le VDC1

Les premières oui, mais pas celle après l'arbre où sont les oiseaux et qui clignotent
Là tu as le joueur, les tirs, les oiseaux et les guillotines sur le même VDC,sans parler qu'un sprite de 32x64 est utilisé pour chaque guillotine ce qui est une perte de BP, puisque une partie (16x64) aurait pu être en tiles,et sans rien toucher à l'agencement, éviter le clignotement . .
pour les nuages c'est surement pareil, tout est sur le même VDC (faut absolument que je patch la rom pour avoir le mode debug ).

[upsilandre]

Dans mon dernier message, j'ai posté l'intégralité de tes messages que j'avais lu.
Je te prenais pour une sorte de Douglas Alves, un genre de spécialiste qui se fait rare dans les forums mais que l'on voit plus souvent en Vidéo.
Puisque tu es accessible, on sera  nombreux à te harceler pour avoir d'autre gif animés.

Des gif tout le monde peut en faire, j’espère bien justement en trouver ici et les récupérer gratos

[upsilandre]

Je me suis refais encore une partie    (je l'ai peut etre pas dit ici mais je suis gros fan des Makaimura, c'est mon jeu d'arcade préféré) et a titre indicatif la guillotine est dans le VDC2, alors oui c'est la que se trouve le sprite du joueur mais dans le VDC1

Les premières oui, mais pas celle après l'arbre où sont les oiseaux et qui clignotent
Là tu as le joueur, les tirs, les oiseux et les guillotines sur le même VDC .

Donc tu parles juste de la toute dernier guillotine geante avant le pont?
Mais justement celle ci est nickel, y a rien a cette endroit la, comment t'arrives a la faire clignoter? dans le pire des cas si tu passe en speedrun t'as une meute de vautour au cul et ils sont justement dans l'autre layer (celui du joueur) donc c'est bien vu d'avoir mis la guillotine geante dans l'autre layer car le layer du joueur est deja saturé par les vautours (et fait deja de l'overflow sur le joueur), c'est ce qu'il fallait faire.
J'arrive pas a te suivre.

[upsilandre]

Là tu as le joueur, les tirs, les oiseaux et les guillotines sur le même VDC

J'avais pas bien assimilé cette phrase, non la tu dis des choses vraiment erronées. Sur cette scene t'as les tires et la guillotine geante dans le VDC1 et le joueur et les vautours dans le VDC2. C'est ce qu'il y avait de mieux.

pour les nuages c'est surement pareil, tout est sur le même VDC (faut absolument que je patch la rom pour avoir le mode debug ).

Si tu parles du boss nuage non comme j'ai expliqué c'est parfaitement répartie. Par contre le level final avec les 3 petits nuages ca c'est vraiment la scene raté du jeu en terme de répartition (ils auraient du dupliqué le sprite des nuages pour les répartir) mais c'est la seule.


Je sais pas comment tu testes mais moi je switch les layers VDC (chaque layer de sprite et chaque layer de bg individuellement) directement avec le stick droit du pad en jouant  donc je vois bien comment ca se passe (en plus de jeter un oeil sur le tileset)

[Stef]

Tu auras toujours du mal à suivre Touko :p
Il a un avis assez subjectif quand il s'agit de parler de la PCE et de ses "dérivés" (qu'il a tendance à défendre) et la MD (qu'il a plutot tendance à enfoncer)... mais bon ça je pense que tu l'as déjà remarqué.

Sinon votre conversation m'a donné envie de m'intéresser d'un peu plus près à ce ghouls'n ghosts. J'avoue ne pas être un grand fan de ce jeu, j'ai "grandi" avec son petit frère ghost'n goblins (sur arcade) et je garde une nette préférence pour celui-ci mais après avoir regardé quelques vidéos je me rend compte que les versions consoles ne sont pas si mauvaises (même la version MD, passé le premier niveau qui est franchement moche et mal animé au possible le reste est plutot correct).
Sinon y'a un point dans l'argumentation de Touko que je n'ai pas compris, tu dis que c'est quasi impossible d'avoir de l'overflow avec 512 pixels de sprite par ligne sur une résolution horizontale de 340 sauf si on le fait exprès... mais t'es vraiment loin du compte ! C'est hyper simple de dépasser cette limite et la preuve avec G'nG SGX qui visiblement a été plutot bien optimisé sur ce point quoique tu en dises. Surtout quand la taille des sprites est en granularité de 16 pixels. Sur MD il est déjà assez difficile d'éviter les clignotements quand tu as pas mal de sprites pourtant la limite est quand même de 320 pixels et la machine est super flexible en terme de taille de sprite ce qui permet de minimiser le gaspillage (comparé à une SNES ou un SGX/PCE). Du coup je pense que vu l'organisation des 2 VDC de la SGX, il n'est pas forcément évident d'avoir moins de clignotements en 340 pixels sur SGX que sur MD en 320. Tu as un peu plus de marge mais je pense que la différence n'est pas énorme et ça demande un développement plus complexe.

[Invité]

Donc tu parles juste de la toute dernier guillotine geante avant le pont?

Non de celles juste au niveau et après l'arbre où il y a tout les oiseaux, ce sont celles qui clignotent, et pour cause tout est sur le même VDC, oiseaux compris .

qu'il a plutot tendance à enfoncer

Mais oui, c'est vrai que depuis qu'il est là on débat sur la MD ... 

mais t'es vraiment loin du compte ! C'est hyper simple de dépasser cette limite et la preuve avec G'nG SGX qui visiblement a été plutot bien optimisé sur ce point quoique tu en dises.

Mais putain ce qui m'énerve c'est que tu connais rien aux nec, et donc tu sais pertinemment que le jeu est bien optimisé ??  
Ca fait 2 plombes que j'explique pourquoi c'est pas le cas, tu as lu mes explications ??
Tiens relis juste 2 posts plus haut ..

Tu as un peu plus de marge mais je pense que la différence n'est pas énorme et ça demande un développement plus complexe.

Un peu ??, non mais faut que tu arrêtes le fanboyisme là, 512 pixels ça représente plus de 1,5x un écran de 320 en couverture (la réso de GnG), si t'arrives pas à ne pas faire clignoter,c'est que tu as un problème .
C'est pas comme si GnG débordait de sprites de partout, faut pas pousser non plus .
Sur Md normal que ce soit difficile, tu peux juste couvrir l'écran .

[upsilandre]

Donc tu parles juste de la toute dernier guillotine geante avant le pont?

Non de celle juste au niveau et après l'arbre où il y a tout les oiseaux, ce sont celles qui clignotent, et pour cause tout est sur le même VDC .

Mais celle la j'en ai parlé et quand j'en ai parlé tu m'as repondu que non toi tu parlais de celle apres l'arbre qui n'est pas dans le meme VDC que les autres guillotines précedentes or la seul guillotine apres l'arbre qui n'est pas dans le meme VDC que les autres c'est la guillotine geante. Tu t’emmêles les pinceau du coup c'est dure a suivre .

Du coup celle la j'en ai deja parlé et j'ai deja expliqué la répartition (non tout n'est pas dans le meme VDC, les 2 plus grosses autres charge que sont les tires et les zombies sont dans l'autre VDC) et pourquoi selon moi c'etait répartie comme ca (Durant tout le debut du level t'as a la fois les zombies et les vautours qui attaques qui sont 2 grosses ressources en VRAM et en spps, ils les ont donc répartit dans des layers differents, les faucons avec les guillotines qui jalone aussi le level, et les zombies avec les tires).
Mettre la derniere petite guillotine (donc celel avant la grande) dans l'autre VDC ca aurait nécéssité de dupliquer les sprites en VRAM pour un interet tres faible car dans l'autre layer aussi ca peut saturer a cause des tires et des zombies. Mais tu remarquera que pour la guillotine geante comme c'est un autre sprite ils en ont profité justement pour la changer de VDC car ici dans le pire des cas il reste que des vautours, on sent la reflexion la dessus encore une fois.

Non vraiment a aucun moment c'est illogique (a part les 3 petits nuages du dernier level, y a peut etre une explication logique mais je vois pas et je doute) . Je pense que t'as une idée érronée de l'effort sur ce jeu (meme si ca reste un jeu de lancement et qu'on peut faire mieux je suis daccord)
Ce qui est drole c'est qu'a force de m'obliger a verifier et rejouer, je vois de nouveau truc et je suis du coup encore plus convaincu de l'effort sur le jeu (toute proportion gardé) qu'au debut de la discussion et ca c'est grace a toi

[Invité]

Mais celle la j'en ai parlé et quand j'en ai parlé tu m'as repondu que non toi tu parlais de celle apres l'arbre qui n'est pas dans le meme VDC que les autres guillotines précedentes or la seul guillotine apres l'arbre qui n'est pas dans le meme VDC que les autres c'est la guillotine geante. Tu t’emmêles les pinceau du coup c'est dure a suivre  .

Je viens juste de faire le test, et les seules qui clignotes sont celles sur le même VDC que le joueur, je m'emmêle pas je te dis ce qui en est .
Je parle de celles et seulement celles qui clignotent, les autres je m'en fou vu qu'elles clignotent pas .
Et même, elles sont composé de 3 sprites, 1 pour le poteau en bckgnd et derrière le joueur,1pour la lame,et 1 pour le poteau en foregnd, le poteau en bckgnd pouvait être fait de tiles et non d'un sprite, tu bouffes à chaque foi 16 pixels de BP, rien qu'avec ça tu évites le clignotement .

EDIT:je confirme que toutes les guillotines classiques sont sur le même VDC que le joueur et les oiseaux dans le gros arbre .
Donc celles avant la grosse guillotine pour atteindre le pont .

Ce qui est drole c'est qu'a force de m'obliger a verifier et rejouer, je vois de nouveau truc et je suis du coup encore plus convaincu de l'effort sur le jeu (toute proportion gardé) qu'au debut de la discussion et ca c'est grace a toi 

Je pense que tu confonds effort, et réelle optimisation .
Bien sur qu'il y a un effort, j'ai jamais dis que le jeu était bâclé,il est bien porté mais pas de façon optimale, les clignotements sont rares et pas gênants, donc ils ne sont pas fait chier pour ça .
Tu te lances dans de longues explications, alors que je te donne des solutions simples pour y remédier,mais bon comme tu es sur d'avoir raison, je vais pas te contrarier, je code dessus, mais j'y connais rien

Ca te va comme dessin ça ??:




Comme tu peux le voir j'ai désactivé les sprites du VDC1, et merde, il manque le joueur, les guillotines, et les oiseaux de l'arbre .
Sur ce , bonne nuit .

[upsilandre]

Je viens juste de faire le test, et les seules qui clignotes sont celles sur le même VDC que le joueur, je m'emmêle pas je te dis ce qui en est .

si si tu t'es emmêlé en me répondant que celle dont tu parlais etait pas sur le meme VDC que les premières, relis toi. Alors qu'on parlait bien des memes au depart.

EDIT:je confirme que toutes les guillotines classiques sont sur le même VDC que le joueur et les oiseaux .
Donc celles avant la grosse guillotine pour atteindre le pont .

oui exactement ce que je dis depuis le debut. Et tandis que les tires et les zombies (2 grosses charges) sont dans l'autre VDC qui est donc bien chargé aussi.

Et même, elles sont composé de 3 sprites, 1 pour le poteau en bckgnd et derrière le joueur, de la lame,et du poteau en foregnd, le poteau en bckgnd pouvait être fait de tiles et non d'un sprite, tu bouffes à chaque foi 16 pixels de BP, rien qu'avec ça tu évites le clignotement .

Les guillotines ont des contours complexes (pas rectiligne) donc avec de la transparence et sont en surimpression sur des portions de background differents donc c'est pas si simple d'autant que a part sur la dernière je vois pas trop ou ca coince (comparé au probleme des nuages c'est rien).
Non vraiment je trouve tes arguments pas convaincant.

[Invité]

Les guillotines ont des contours complexes (pas rectiligne) donc avec de la transparence et sont en surimpression sur des portions de background differents donc c'est pas si simple d'autant que a part sur la dernière je vois pas trop ou ca coince (comparé au probleme des nuages c'est rien).
Non vraiment je trouve tes arguments pas convaincant.

Mais n'importe quoi, dans les guillotine tu as seulement besoin que les éléments qui doivent être devant le joueur soient composé de sprites de priorité plus haute ok ??
le poteau du fond lui est derrière le joueur, donc n'a aucun intérêt à être en sprite,c'est pas difficile à comprendre .
Et de toutes façon je te montre sur les images plus haut ce que je dis depuis le début, c'est toi qui à du mal à (ou ne veux pas )comprendre .
LE JOUEUR + LES GUILLOTINES + LES OISEAUX QUI SONT TOUS DANS L'ARBRE SONT SUR LE MEME VDC, c'est clair là non   
ou je m'emmêle encore ??

oui exactement ce que je dis depuis le debut. Et tandis que les tires et les zombies (2 grosses charges) sont dans l'autre VDC qui est donc bien chargé aussi.

Tu te fous de moi ou quoi là ??
J'arrête pas de te dire que c'est à cause de ça que ça clignote (entre autre), et tu me dis que non car tout est bien reparti sur les 2 VDC !!!
Les zombies n'ont rien à voir dans le clignotement, eux il sont sur l'autre VDC, mais pas le reste.

[upsilandre]

Tu te lances dans de longues explications, alors que je te donne des solutions simples pour y remédier,mais bon comme tu es sur d'avoir raison, je vais pas te contrarier, je code dessus, mais j'y connais rien

Ca me rappelle quelque chose. Mais comme on parle de GnG oui apres coup je pense que j'ai passé plus de temps dessus et que j'ai mieux décortiqué GnG que tu ne l'avais fait d'ou les malentendu.

Ca te va comme dessin ça ??:




Comme tu peux le voir j'ai désactivé les sprites du VDC1, et merde, il manque le joueur, les guillotines, et les oiseaux de l'arbre .
Sur ce , bonne nuit .

hheuuu c'est une blague?
C'est ce que j'ai expliqué depuis le debut, a part que tu inverses encore VDC1 et VDC2 mais peu importe, c'est exactement ce que j'ai expliqué (avec donc les tires et les zombies dans l'autre VDC pour la millieme fois), a l'aide

[Invité]

hheuuu c'est une blague?  
C'est ce que j'ai expliqué depuis le debut, a part que tu inverses encore VDC1 et VDC2 mais peu importe, c'est exactement ce que j'ai expliqué (avec donc les tires et les zombies dans l'autre VDC pour la millieme fois), a l'aide 

Alors je me permets de te dire que c'est toi qui t'emmêles, parce que si t'arrives pas a voir que c'est justement à cause de ça que ça clignote, tu ne m'aurais pas soutenu que la répartition était optimale.
Et on s'en branle du VDC1 ou 2, l'important c'est qu'à l'endroit du clignotement tout est sur le même VDC ..
Et je répète,GnG est bien converti, mais pas optimal pour les palettes, et les quelques clignotements .

PS: j'ai parlé de VDC1 parce que mednafen (l'emul) appelle les VDCS, VDC 0/1.

[upsilandre]

Juste hallucinent. Je te remet mon premier poste dont tu t'es empressé de contredire les elements purement factuels (comme par exemple dire que les tires aussi etait avec les guillotines, joueurs, vautours) pour finalement redire ce que j'avais deja ecrit au debut.
Tu parles d'une discussion. T'es vraiment gonflé.

Tiens voila mon premier post la dessus. Y avait tout (et toutes les informations sur la répartition sont strictement juste donc je vois pas pourquoi avoir contredit cela) avec mon avis sur cette répartition.

Je me suis refais encore une partie    (je l'ai peut etre pas dit ici mais je suis gros fan des Makaimura, c'est mon jeu d'arcade préféré) et a titre indicatif la guillotine est dans le VDC2, alors oui c'est la que se trouve le sprite du joueur mais dans le VDC1 y a deja les tires et les zombies (et une partie du hud qui dépasse). Je t'ai fais l'addition juste pour info: Les tires peuvent a l'extreme prendre jusqu'a 240spps de budget (on atteins presque les limites mais c'est vraiment le cas extreme avec les pouvoirs) et les Zombies c'est jusqu'a 144spps (quand y en a 3) + 32spps du HUD (qui entre seulement en conflit avec les zombies) donc 176spps, donc ca c'est juste pour le VDC1.
A coté de ca dans le VDC2 le sprite du joueur c'est juste 48spps (80 quand il a l'armure d'or avec la cap) donc rien d'idiot a mettre les guillotines sur le meme layer vu que l'autre est deja pas mal chargé. Le probleme c'est la scene de l'arbre aux vautours car ils sont tres lourd (en VRAM et en spps) et donc ils les ont pas mis dans le meme layer que les zombies qui attaque en meme temps durant tout le niveau, du coup il se retrouve dans l'autre layer et donc avec les guillotines et la ca peu coincé sur cette scene de l'arbre (d'autant que les vautours mort laisse un paquet de plume qui mettent longtemps a disparaître) mais vraiment de facon tres discrete et breve. Non le seul vrai probleme dans le jeu c'est les 2 scenes avec les nuages.

Y a pas de choix idéal, l'autre VDC est deja bien chargé (Tires et zombies, 2 grosses charges). Les guillotines et les vautours sont pas juste la sur la derniere scene mais jalonne le level donc faut tout prendre en considération et faire des compromis. Et a part la dernière guillotine ca passe tres bien.

[Invité]

Bon ok je passe ...

A+

je m'auto cite :

LE JOUEUR + LES GUILLOTINES + LES OISEAUX QUI SONT TOUS DANS L'ARBRE SONT SUR LE MEME VDC, c'est pour ça que ça clignote, ce qui clignote ce sont justement les sprites de ce VDC.

Je peux rien dire de plus .

Y a pas de choix idéal, l'autre VDC est deja bien chargé (Tires et zombies, 2 grosses charges). Les guillotines et les vautours sont pas juste la sur la derniere scene mais jalonne le level donc faut tout prendre en considération et faire des compromis. Et a part la dernière guillotine ca passe tres bien.

Aaah, c'est vrai qu'ils pouvaient pas répartir les sprites de 1 sur l'autre et vice versa !! .
C'est sur que mettre des sprites sur le même VDC en sachant que ça va être critique c'est un signe de pur design .. 
Surtout qu'il reste pas mal de place en VRAM sur l'autre VDC pour changer, même temporairement .

[upsilandre]

le poteau du fond lui est derrière le joueur, donc n'a aucun intérêt à être en sprite,c'est pas difficile à comprendre .
Et de toutes façon je te montre sur les images plus haut ce que je dis depuis le début, c'est toi qui à du mal à (ou ne veux pas )comprendre .

Oui ca j'ai compris. Ce que je t'explique c'est que les guillotines s'affichent par dessus des portions de background differents donc si tu veux transformer le sprite du poteau du fond (qui n'est pas juste uen forme rectilignes et pleines sans transparences mais avec des contours un peu torturé) dans le background ca implique d'utiliser plus de tiles differentes (ROM et VRAM) donc c'est pas forcement illogique de faire comme ils ont fait d'autant que en l'etat ca passe plutot bien a l'exception de la dérniere guillotine. Et encore une fois l'autre VDC est aussi bien chargé.
D'ailleurs ce dont tu parle c'est ce qu'ils ont fait sur la grande guillotine donc ils sont pas idiot.

[Invité]

Et ils ont fait comment sur MD ???
ils ont utilisé des tiles ..

D'ailleurs ce dont tu parle c'est ce qu'ils ont fait sur la grande guillotine donc ils sont pas idiot.

J'ai rien dis de tel, mais juste que les clignotements leur paraissaient suffisamment acceptables pour laisser tel quel, c'est tout .

[upsilandre]

Bon ok je passe ...

A+

je m'auto cite :

LE JOUEUR + LES GUILLOTINES + LES OISEAUX QUI SONT TOUS DANS L'ARBRE SONT SUR LE MEME VDC, c'est pour ça que ça clignote, ce qui clignote ce sont justement les sprites de ce VDC.

Je peux rien dire de plus .

oui apres que je l'ai dit 3 fois et apres avoir contredit tes premiers messages. Tu m'as fait perdre mon temps.

[Invité]

Non mais sérieux, t'es gonflé, je te dis la même chose depuis le début,que tout est sur le même VDC sur ce passage, et tu me soutenais que non, en me parlant de zombies, moi je t'ai toujours dit la même chose, joueur, guillotines, oiseaux de l'arbre même VDC=clignotements, rien de plus .
Si tu as voulu comprendre autre chose, c'est pas de ma faute .

[upsilandre]

Et ils ont fait comment sur MD ???
ils ont utilisé des tiles ..

Oui grace a un poteau de guillotine simplifié avec des contours droit sans transparence, du coup c'est facile ils ont besoin d'une seul version des tiles du poteau du fond pour l'intégrer dans le background.
La version sgx reproduit les graphismes arcade.