Re: MEGADRIVE vs SUPER NINTENDO : Fight !

[Stef]

En effet c'est couillon. Je pensais que le dot clock et la fréquence du VDP étaient indépendants

Hélas non, c'est vrai que ça aurait été plus pratique...

Il se trouve que dans le temps, j'ai fait un DEA sur un sujet connexe, et je lis encore de temps en temps des trucs sur le sujet. Par exemple, ce papier m'avait semblé très intéressant dans ce genre de situation à l'époque, et je m'étais dit que ce serait l'occasion de tester. Mais bon, j'ai l'habitude que de très jolis algo théoriques marchent toujours dans les articles, et jamais tout à fait en pratique :)

Haha c'est marrant, je travaille dans la recherche en analyse et traitement d'image donc c'est un peu le genre de papier que je vois souvent (enfin moi c'est plus appliqué à la bio mais on brasse pas mal de chose). Après en effet dans les papiers ça a l'air génial et ça marche super sur leurs images mais dés que tu testes sur les tiennes tu te rends compte que c'est beaucoup moins magique d'un coup. Cela dit je trouve que ça reste un sujet de recherche interessant (le resize intelligent), d'ailleurs j'avais lu un papier assez proche du tien où ils isolaient les parties "structure" et les parties "remplissage" de l'image pour ensuite ne toucher qu'à la partie remplissage en préservant au mieux les parties structures. Là encore dans la théorie ça avait l'air cool mais en pratique ça ne fonctionnait que sur des images ciblées...

[Invité]

En effet c'est couillon. Je pensais que le dot clock et la fréquence du VDP étaient indépendants

D un côté c est logique vu que c est lui qui dessine l image a l ecran, il faut bien le synchroniser, je pense que c est le plus simple de faire comme ca, surtout avec des resolutions variables .

[Tryphon]

Haha c'est marrant, je travaille dans la recherche en analyse et traitement d'image donc c'est un peu le genre de papier que je vois souvent (enfin moi c'est plus appliqué à la bio mais on brasse pas mal de chose).

Je crois que j'ai eu l'occasion de te poser la question déjà (sur spritesmind je crois)

Le DEA que j'ai fait était le Mathématiques - Vision - Apprentissage (Paris 11, ENS, X, Télécom) et les profils des étudiants étaient variés, beaucoup ont appliqué à la bio par la suite (j'ai d'ailleurs envisagé la possibilité, mais pour diverses raisons pratiques je n'ai pas pu aller au bout).

Après en effet dans les papiers ça a l'air génial et ça marche super sur leurs images mais dés que tu testes sur les tiennes tu te rends compte que c'est beaucoup moins magique d'un coup. Cela dit je trouve que ça reste un sujet de recherche interessant (le resize intelligent), d'ailleurs j'avais lu un papier assez proche du tien où ils isolaient les parties "structure" et les parties "remplissage" de l'image pour ensuite ne toucher qu'à la partie remplissage en préservant au mieux les parties structures. Là encore dans la théorie ça avait l'air cool mais en pratique ça ne fonctionnait que sur des images ciblées...

J'ai aussi lu plusieurs papiers là dessus. La structure relevait de la détection de contours avec des techniques différentielles, tandis que le remplissage c'était de la génération de textures, souvent avec des méthodes discrètes plus brutales (genre copie de motifs similaires). J'ai lu assez récemment un papier qui m'a bien plus où l'auteur mélangeait les deux en un seul algo. J'ai pas vraiment eu le temps de tester mais là encore, sur les exemples de l'article, c'était miraculeux.

Ici, je me dis que supprimer 1 ligne dans chaque groupe de 6 en la sélectionnant sur certains critères (éviter de supprimer deux lignes trop proches, éviter les lignes intersectant des contours) peut donner un résultat sympa. J'ai testé avec un sprite, en faisant d'une part un plus proche voisin, et d'autre part en retirant des lignes "au jugé" (j'ai pas minimisé, juste évité les contours), c'était bien mieux. On obtiendrait certainement mieux encore en supprimant des zigzags, comme dans l'article, mais j'ai peur que ça déforme trop le sprite. Puis faut voir ce que ça donne sur une animation.

@touko : oui, ça paraît logique. Je n'ai aucune connaissance en électronique (j'ai appris ce qu'était le dot clock ici même le mois dernier). J'aimerais bien combler mes lacunes dans ce domaine mais je n'ai jamais trouvé de ressources claires à ce sujet, je ne vois même pas où commencer.

[Invité]

 oui, ça paraît logique. Je n'ai aucune connaissance en électronique (j'ai appris ce qu'était le dot clock ici même le mois dernier). J'aimerais bien combler mes lacunes dans ce domaine mais je n'ai jamais trouvé de ressources claires à ce sujet, je ne vois même pas où commencer.

Pas de soucis, on est tous en apprentissage sur un truc ou un autre,et on en apprend tout les jours 

[Stef]

Le DEA que j'ai fait était le Mathématiques - Vision - Apprentissage (Paris 11, ENS, X, Télécom) et les profils des étudiants étaient variés, beaucoup ont appliqué à la bio par la suite (j'ai d'ailleurs envisagé la possibilité, mais pour diverses raisons pratiques je n'ai pas pu aller au bout).

Oui en bio c'est pas mal utilisé, c'est un secteur où il y a beaucoup de recherche et donc de l'argent...
Moi à la base je ne suis pas du tout math / traitement image, je suis 100% informaticien et j'ai atterri là dedans un peu par hasard (enfin pas complètement) :)

J'ai aussi lu plusieurs papiers là dessus. La structure relevait de la détection de contours avec des techniques différentielles, tandis que le remplissage c'était de la génération de textures, souvent avec des méthodes discrètes plus brutales (genre copie de motifs similaires). J'ai lu assez récemment un papier qui m'a bien plus où l'auteur mélangeait les deux en un seul algo. J'ai pas vraiment eu le temps de tester mais là encore, sur les exemples de l'article, c'était miraculeux.

Ici, je me dis que supprimer 1 ligne dans chaque groupe de 6 en la sélectionnant sur certains critères (éviter de supprimer deux lignes trop proches, éviter les lignes intersectant des contours) peut donner un résultat sympa. J'ai testé avec un sprite, en faisant d'une part un plus proche voisin, et d'autre part en retirant des lignes "au jugé" (j'ai pas minimisé, juste évité les contours), c'était bien mieux. On obtiendrait certainement mieux encore en supprimant des zigzags, comme dans l'article, mais j'ai peur que ça déforme trop le sprite. Puis faut voir ce que ça donne sur une animation.

Bon je vais essayer de pas trop dévier le topic mais effectivement l'idée c'est de trouver le ratio et de supprimer 1 pixel sur N qui ne contient pas d'information structurante. Après je me demande s'il faut nécessairement faire ça par bloc (genre 7x7 où tu dois supprimer 1 ligne et 1 colonne en tout) ou tenter une approche plus globale avec la contrainte de respecter le ratio final de l'image... en tout cas je suis curieux de voir les résultats que tu obtiens, aussi si tu connais une application qui fait ce genre de chose je suis preneur :)

[upsilandre]

Haha c'est marrant, je travaille dans la recherche en analyse et traitement d'image donc c'est un peu le genre de papier que je vois souvent (enfin moi c'est plus appliqué à la bio mais on brasse pas mal de chose).

Je crois que j'ai eu l'occasion de te poser la question déjà (sur spritesmind je crois)  

Le DEA que j'ai fait était le Mathématiques - Vision - Apprentissage (Paris 11, ENS, X, Télécom) et les profils des étudiants étaient variés, beaucoup ont appliqué à la bio par la suite (j'ai d'ailleurs envisagé la possibilité, mais pour diverses raisons pratiques je n'ai pas pu aller au bout).

Après en effet dans les papiers ça a l'air génial et ça marche super sur leurs images mais dés que tu testes sur les tiennes tu te rends compte que c'est beaucoup moins magique d'un coup. Cela dit je trouve que ça reste un sujet de recherche interessant (le resize intelligent), d'ailleurs j'avais lu un papier assez proche du tien où ils isolaient les parties "structure" et les parties "remplissage" de l'image pour ensuite ne toucher qu'à la partie remplissage en préservant au mieux les parties structures. Là encore dans la théorie ça avait l'air cool mais en pratique ça ne fonctionnait que sur des images ciblées...

J'ai aussi lu plusieurs papiers là dessus. La structure relevait de la détection de contours avec des techniques différentielles, tandis que le remplissage c'était de la génération de textures, souvent avec des méthodes discrètes plus brutales (genre copie de motifs similaires). J'ai lu assez récemment un papier qui m'a bien plus où l'auteur mélangeait les deux en un seul algo. J'ai pas vraiment eu le temps de tester mais là encore, sur les exemples de l'article, c'était miraculeux.

Ici, je me dis que supprimer 1 ligne dans chaque groupe de 6 en la sélectionnant sur certains critères (éviter de supprimer deux lignes trop proches, éviter les lignes intersectant des contours) peut donner un résultat sympa. J'ai testé avec un sprite, en faisant d'une part un plus proche voisin, et d'autre part en retirant des lignes "au jugé" (j'ai pas minimisé, juste évité les contours), c'était bien mieux. On obtiendrait certainement mieux encore en supprimant des zigzags, comme dans l'article, mais j'ai peur que ça déforme trop le sprite. Puis faut voir ce que ça donne sur une animation.

@touko : oui, ça paraît logique. Je n'ai aucune connaissance en électronique (j'ai appris ce qu'était le dot clock ici même le mois dernier). J'aimerais bien combler mes lacunes dans ce domaine mais je n'ai jamais trouvé de ressources claires à ce sujet, je ne vois même pas où commencer.

Pourquoi pas faire un algo qui enleve au hasard (avec quelque parametre pour orienter le hasard) et qui te sort un sheet de 50 variantes du meme sprites sur le meme ecran et toi tu sélectionne a l'oeil celui qui te plait le mieux pour le valider (ou tu les balances a un panel sur le forum).

[Tryphon]

Il y a quand même environ 500 poses (quand je vous dis que la version SNES est ultra-simplifiée)

Si je peux automatiser, j'automatiserai, mais sinon c'est une option en effet.

À signaler que j'ai une autre idée à tester.

Mais bon, pour l'instant j'utilise la version SNES, et je suis en train de m'emm... à renommer les images pour qu'elles correspondent à celles de la version MUGEN (quand il en correspond une). Ça me permettra d'utiliser le fichier contenant les animations, ainsi que les collision box (ça c'est facile à resizer ).

[Invité]

Il y a quand même environ 500 poses (quand je vous dis que la version SNES est ultra-simplifiée) 

On s'en doutait quand même, car passer de 28Mo à 4, y'a pas de magie .

[Tryphon]

28 Mo seulement ? Je pensais que c'était beaucoup plus pour la version arcade...

Je suppose que la compression est d'environ un facteur 2/3 ?

Ce qui est marrant, c'est que certaines poses sont différentes : par exemple lorsque Ryu saute en faisant une pirouette (saut avant), il est de 3/4 dos en arcade et 3/4 face sur SNES

[Invité]

Je suppose que la compression est d'environ un facteur 2/3 ?

Grand maximum,mais on doit être dans ces eaux là  .

[Tryphon]

C'est gonflant, le rip sur spriters-ressources n'est pas complet

Vu que pour l'instant je veux n'implémenter qu'un moveset limité, je vais ripper les poses manquantes au screenshot, mais si je veux récupérer tout, ainsi que les autres persos, faudra que je m'intéresse à l'algo de compression du S-DD1 (j'ai trouvé une page qui le décrivait).

[Stef]

Je me demande s'il existe des émulateurs qui te permettent de ripper facilement les sprites (avec des fonctions vraiment fait pour ça)...
J'ai trouvé une doc sur la compression S-DD1 mais elle était assez mal fichue et pas très claire :-/

[Tryphon]

Si la doc c'est celle-ci, oui, c'est pas le texte le plus clair et concis que j'ai lu

J'ai encore rien écrit pour la MD, mais j'ai écrit quelques scripts pour manipuler des archives MUGEN.

J'ai aussi bricolé vite fait l'idée de resizer, j'ai pas encore trop testé mais ça semble pas mal. Je retire une colonne de pixels par groupe de 6 pixels (parce que 384 * 5/6 = 320), celle de moindre énergie du groupe.

Voici l'image de départ :



Voici l'image resizée en plus proche voisin (avec paint.net)



Et avec l'algo :



Il me semble qu'effectivement c'est mieux (le visage est mieux conservé, les muscles du bras aussi). J'ai testé aussi avec des réductions plus violentes (50%) et c'est encore plus flagrant je trouve :



Ci-dessus le plus proche voisin



Et là, l'algo. En zoomant les différences sont assez nettes !

[Stef]

Définitivement l'algo préserve mieux les détails mais je suis surpris par le résultat du plus proche voisin, je m'attendais a pire ;-) Heureusement les sprites de base sont assez plat ce qui évite trop de rupture. Je me demande si pour les pixels supprimés tu ne pourrais pas faire un blend avec le pixel enlevé mais en utilisant la couleur la plus proche parmi les existantes si possible (sinon tant pis).

[Tryphon]

Je m'attendais aussi à pire pour le plus proche voisin mais je suppose que ça vient du fait que le ratio est une fraction simple (5/6) ; il doit lui aussi retirer une colonne toutes les 6, mais il ne la "choisit" pas.

Blender puis reprendre la couleur la plus proche, ça marche assez mal. Déjà, ça a tendance a faire "baver" les contours, mais en plus, la notion de couleurs "proches" est assez difficile à définir. Par distance aux moindres carrés ça marche mal, tu peux te retrouver avec un bleu moyen pour approcher un gris.

J'ai implémenté un algo qui retire une "colonne zigzagante" de moindre énergie, les résultats sont bons pour ce genre de réduction, mais déforment de manière assez rigolote Ryu pour des grosses réductions.

Je vais essayer d'aller un peu plus loin et d'introduire un terme pénalisant quand on retire deux colonnes trop proches (pour éviter les déformations), mais après avoir testé sur plusieurs poses, je pense que c'est exploitable !

Ça serait génial, ça voudrait dire que je peux partir carrément des assets arcade (enfin, MUGEN, mais elles sont faites à partir de l'arcade). Et bosser en 320 !

Si le DMA MD est suffisamment puissant, ça pourrait rendre très très bien ! Penses-tu que la hauteur des sprites d'arcade peut être gérable (environ 100 pixels en comptant gros, quoique Sagat dépasse sûrement) ou vaut-il mieux réduire en hauteur (j'ai pas encore essayé l'algo sur des réductions verticales) ?

[Invité]

Etant donné que les anims sont pas à 60 fps avec du double buffer ça va passer sans problème .

[Tryphon]

J'ai pensé au double-buffer, mais comment je fais avec les anims qui doivent être immédiatement dispos comme les anims où tu es touché ?

[Invité]

C'est pareil, à 2/4 frames près ça se voit pas,tu n'as pas besoin de changer l'anim de suite .
Entre le moment ou le joueur a fini l'anim de son coup et l'anim du toucher, il y a quelques frames d'écart .
Le tout est d'éviter de mettre les 2 anims complètes dans la même frame, donc au pire 1 frame de décalage est largement suffisante .

[Invité]

j'ai pas tout suivi..vous allez refaire un street fighter?

[Invité]

Pas moi en tout cas .. 

[Agathon]

j'ai pas tout suivi..vous allez refaire un street fighter?

Disons que le défi, serait de voir si sf zéro 2 tournerait en l'état sur MD. Voir sil est possible de faire une démo qui tourne aussi bien, voir mieux que sur SNES.

[Stef]

Perso pour le cas de street fighter ça me semble assez simple à gérer, on peut se contenter d'alterner les update entre les 2 persos. Soit 30 FPS et 1 frame de lag max ce qui est, je pense, pas perceptible ou à peine. Par contre reprendre la hauteur des sprites arcade, ça va pas clocher en terme de ratio ?

[Tryphon]

Non, la réso verticale de l'arcade est 224, comme sur MD. C'est la réso horizontale qui change (384 contre 320). D'où le resize par colonnes.

Par contre, malgré la réso verticale identique, Capcom a clairement réduit verticalement les sprites sur les versions MD et SNES de SF2. Y'a peut être une raison. On verra bien...

[Invité]

Disons que le défi, serait de voir si sf zéro 2 tournerait en l'état sur MD. Voir sil est possible de faire une démo qui tourne aussi bien, voir mieux que sur SNES.

Tourner ça va tourner c'est pas le problème, le problème est de voir qu'elle taille de cartouche il faudrait pour avoir au minimum la version snes en terme de gfx ,musiques et sons sans puce .

Y'a peut être une raison. On verra bien...

Le plus probable est pour réduire le plus possible la taille de la cartouche, surtout que capcom n'a fait aucune compression sur les versions snes/md de sf2 (toutes versions) .
Donc je pense que c'est pour ça qu'aucune version MD de SF2A n'est sortie, la snes le doit à la présence du SDD-1 pour la compression parce que capcom ne semble pas être du style à se faire chier pour trouver un algo de compression efficace et de dépenser bcp de temps à l'optimisation des datas.

@tryphon: déjà faut que tu trouves le pattern d'anim le plus lourd en taille pour savoir si tu peux éviter le double buffer,ce qui est sur c'est que tu pourras pas transférer 2 patterns pendant le vblank.
Ensuite voir quel est ton budget DMA qui te reste aussi un fois la SAT et la H-scroll table transférées,et si tu dois absolument faire du traitement dans le vblank .

[Tryphon]

Si je peux éviter le double buffering, je l'eviterai car mine de rien, avec deux persos ça boufferait certainement autour de 500 patterns et je risque de me retrouver ric rac avec le décor, la GUI et les projectiles. Je me demande juste si un l'AG d'une frame, ça passera réellement inaperçu...

Sinon rien n'empêchait Capcom de sortir un SFZ sur MD, avec ou sans SDD-1. C'est juste qu'à l'époque de sa sortie, la SNES était en fin de vie, mais la MD était déjà morte, Sega était passé à la Saturn. Je suis pas sûr que la N64 était sortie par contre...

[Invité]

Un double buffer ici te prendrait au max 16ko pour les 2 persos .
Sinon tu peux essayer pour éviter le DB de décaler les transferts de chaque pattern d'1 frame,voire augmenter le vblank pour gagner en DMA.

Sinon rien n'empêchait Capcom de sortir un SFZ sur MD, avec ou sans SDD-1. C'est juste qu'à l'époque de sa sortie, la SNES était en fin de vie, mais la MD était déjà morte, Sega était passé à la Saturn. Je suis pas sûr que la N64 était sortie par contre...

Mais je dis pas le contraire, techniquement bien sur que c'était largement faisable, mais pas avec le style de dev capcom .
Pour moi si capcom l'a sorti sur snes c'est bien grâce au SDD-1 (fort taux de compression sans bcp d'efforts).
Capcom aurait très bien pu aussi le sortir sur une cartouche de 6MO(comme star ocean) pour que ce soit bcp plus fidèle à l'original.
Améliorer les transferts de samples vers la SRAM pour éviter les loadings lors des annonces,etc ..

Donc tout ce que tu peux faire aujourd'hui pour l'optimiser sur MD, c'était aussi valable pour la snes,car les SF2 snes étaient tout aussi mal optimisés que sur MD niveau datas .

[Tryphon]

Un double buffer ici te prendrait au max 16ko pour les 2 persos .
Sinon tu peux essayer pour éviter le DB de décaler les transferts de chaque pattern d'1 frame

C'est l'idée de Stef. J'espère juste que le décalage ne sera pas perceptible.

voire augmenter le vblank pour gagner en DMA.

Non, si les gros sprites ne passent pas, je préfère encore resizer verticalement.

Mais je dis pas le contraire, techniquement bien sur que c'était largement faisable, mais pas avec le style de dev capcom .
Pour moi si capcom l'a sorti sur snes c'est bien grâce au SDD-1 (fort taux de compression sans bcp d'efforts).

Capcom aurait très bien pu aussi le sortir sur une cartouche de 6MO(comme star ocean) pour que ce soit bcp plus fidèle à l'original.
Améliorer les transferts de samples vers la SRAM pour éviter les loadings lors des annonces,etc ..

Donc tout ce que tu peux faire aujourd'hui pour l'optimiser sur MD, c'était aussi valable pour la snes,car les SF2 snes étaient tout aussi mal optimisés que sur MD niveau datas .

Je ne suis pas tout à fait sûr que l'on parle de la même chose. Pour moi, il est évident que 2 ans plus tôt, Capcom l'aurait sorti sur MD, parce qu'il y avait de la demande.

De plus, le SDD-1 pour moi n'a rien à voir avec la décision de Capcom de porter le jeu sur SNES (il y est, tant mieux. Il n'y aurait pas été, ils auraient sorti une cartouche de 8 Mo si nécessaire).

Enfin, je ne suis pas du tout dans une optique "Sega does what Nintendon't" (et donc un peu HS dans ce topic, mais bon), un versus fighting est clairement faisable sur les deux machines, SF2 l'a montré (niveau gameplay les deux versions sont équivalentes). Si je peux utiliser de la compression, juste pour voir, je le ferai, mais ce n'est pas mon objectif prioritaire. En fait, c'est davantage voir à quel point je peux automatiser une conversion MUGEN -> MD qui me plaît.

[Invité]

De plus, le SDD-1 pour moi n'a rien à voir avec la décision de Capcom de porter le jeu sur SNES (il y est, tant mieux. Il n'y aurait pas été, ils auraient sorti une cartouche de 8 Mo si nécessaire).

Sincèrement je crois pas, une cartouche de 8 Mo sur snes c'était peut être pas possible (n'oublies pas que c'est BIG N qui fournissait les cartouches), surtout que le max qui soit sorti à l'époque c'était 6mo(48Mb) .
Pour moi le SDD-1 représentait juste la facilité de sortir SFA2 sans trop se soucier d'un algo soft efficace et d'optimisation des données, la puce le permet facilement avec un résultat bien meilleurs qu'en soft,donc un gros gain de temps sur le dev et surtout sortir le jeu assez rapidement sur une machine en fin de vie .
Ce n'est pas un constat technique, juste la fainéantise légendaire de capcom sur console .

Enfin, je ne suis pas du tout dans une optique "Sega does what Nintendon't"

Mais moi non plus, je suis pas en train de dire que le jeu ne pouvait pas sortir sur MD puisque techniquement il pouvait .
Je dis juste que pour moi capcom n'avait pas envie de se prendre la tête dans un dev long et coûteux sur des machines en fin de vie(snes et Md comprises) .
D'où pour moi l'intérêt de capcom pour le SDD-1,pouvoir faire comme d'hab, CAD ne pas se casser le cul,et sortir un portage rapidement à moindre frais,rien de plus .

je dis juste que même aujourd'hui, le faire sur 6Mo seulement, c'est difficilement faisable(a moins bien sur d'un boulot énorme,et encore), avis perso bien sur .

En fait, c'est davantage voir à quel point je peux automatiser une conversion MUGEN -> MD qui me plaît.

Mais je suis aussi curieux que toi de voir le résultat, mais tu sais comme moi qu'il y a un boulot énorme derrière pour adapter un aussi gros jeu, sur une cartouche limitée à 6Mo(comme à l'époque) .

[killergreg]

A cette époque je ne faisais pas de jalou j'avais les 2 moi!
Enfin, je préférais tout de même ma SNES pour les RPG US en or (mon 7TH SAGA a tourné de longues heures)

[dc103chaos]

Niveau Technique et graphisme est il possible de faire un sfa2 sur Megadrive ?

[Invité]

bah vu comment est présenté Project Y ... oui, largement.