Re: MEGADRIVE vs SUPER NINTENDO : Fight !

[Invité]

Yabon. :)

Purée mes beaux parents (et parents) sont en Bourgogne, ma femme est née à Reims, etc.
Champagne, bon vin, etc.

Etc.

[Invité]

Sinon...ça va le HS? Peinard?

[Invité]

Sinon...ça va le HS? Peinard?

Pas peinard. Pinard.

Rha, faut tout expliquer.

[Invité]

[yodu861]

Une petite trêve sur le sujet de la bouffe ne fait de mal à personne.

Que déguste un bon joueur de SNES avec le jeu SUPER MARIO WORLD,

et un bon joueur de MD avec le jeu SONIC ?

1...2...3 FIGHT !

[Doc_Skunkovitch]

Je pense que le Nintedoll's mange du steak de nigloo pour pallier sa frustration.
Le Megadriveux lui c'est un homme, un vrai, un dur, IL MANGE DES CLOUS !!!

[lessthantod]

Une Porsche, une vache, une patate ... c'est bon

[Agathon]

Sinon...ça va le HS? Peinard?

Oué tranquille! Tu prends un verre?

[Invité]

Que déguste un bon joueur de SNES avec le jeu SUPER MARIO WORLD,

Aller, je me lance , DES SUCRES LENTS ?? 

[ace76]

ohh,maintenant ils s'autoflagellent les pro-n

[Agathon]

Que déguste un bon joueur de SNES avec le jeu SUPER MARIO WORLD,

Aller, je me lance , DES SUCRES LENTS ?? 

Il a osé, il a osé les mecs!!! Appelez le Doc, Touko à perdu les pédales 

[Invité]

Je savais que ça allait faire plaisir à certains 
Mais bon c'était trop tentant .

[Invité]

Que déguste un bon joueur de SNES avec le jeu SUPER MARIO WORLD,

Aller, je me lance , DES SUCRES LENTS ?? 

[Stef]

Même si je ne suis jamais contre un bon pinard, je recentre un peu le débat sur une éventuelle version SFA2 MD :p
J'ai pris la planche de Ruy, j'ai aligné les sprites sur une grille de 64*104 (ainsi la plupart des sprites rentrent dans les cases à 1 ou 2 prêt) et en prenant 1/4 du set environ j'arrive à une taille en non compressé de 100 Ko environ, et ce n'est vraiment pas optimisé au mieux, en coupant les tiles correctement (car là je prend même les tiles blanks) et en optimisant sur les parties doublées je pense qu'on peut vraiment réduire pas mal la taille (genre passer à 250 Ko pour la planche complète de Ruy en non compressé). Bien sur plus on optimise les tiles ainsi et plus la compression potentielle se réduit (moins de blank). Sur ma planche de 100 Ko j'ai une compression 35-40% de la taille d'origine en moyenne, et ce, en compressant indépendamment chaque sprite (donc utilisable in-game pour de la décompression à la volée). Je pense donc qu'avec un bon travail sur l'optimisation des données graphiques y'a moyen de faire tenir ça dans 4/5 Mo sur MD, avec de la décompression "soft" :)

[Invité]

Donc si tu arrives à la conclusion de 4/5 mo avec du lz, c'est bien que la version snes est codée avec les pieds et pas du tout optimisée..
enfin si capcom ne l'a pas fait à l'époque, c'est qu'ils n'étaient pas capable de le sortir avec cette taille,sans y passer bcp de temps .
Finalement c'est ce que montre star ocean qui une fois décompressé fait dans les 96 Mb .

Et stef(ou tryphon), au lieu de te plaindre de la snes,ça te dirait pas de convertir cannabalt C64 sur Md ??

[Stef]

Donc si tu arrives à la conclusion de 4/5 mo avec du lz, c'est bien que la version snes est codée avec les pieds et pas du tout optimisée..
enfin si capcom ne l'a pas fait à l'époque, c'est qu'ils n'étaient pas capable de le sortir avec cette taille,sans y passer bcp de temps .
Finalement c'est ce que montre star ocean qui une fois décompressé fait dans les 96 Mb .

Et stef(ou tryphon), au lieu de te plaindre de la snes,ça te dirait pas de convertir cannabalt C64 sur Md ??
<iframe width="560" height="315" src="https://www.youtube.com/embed/7I1zqkyIYC4" frameborder="0" allowfullscreen></iframe>

Je ne vois pas pourquoi tu dis que si on arrive à 4/5 Mo avec du LZ avec Capcom s'est foutu du monde ? La compression sans perte n'est jamais extraordinaire (surtout que le format des données sur SNES fait que la compression marche en général un peu moins bien), ici ça marche pas trop mal du fait du style des graphismes mais ne va pas croire que le SDD1 va compresser beaucoup plus que le LZ de base... La différence c'est qu'il va faire ça vite et surtout le CPU de la SNES peut continuer à bosser pendant ce temps là Le but à mon avis c'était de faire rentrer la cartouche dans 4Mo pour limiter les couts et sans compresser les sprites (ce qui composent 80% des données graphiques) c'était impossible. Et le CPU de la SNES n'est clairement pas capable de décompresser les sprites à la volée donc je dirais que le SDD1 fait son job, il rend ça possible et donc globalement réduit le cout de la cartouche (même si le SDD1 en lui-même a surement un certain cout). Après là où ils se sont foirés pour moi, c'est plutot dans la gestion des samples, je pense qu'ils auraient du faire un driver spécifique capable de recharger les samples plus rapidement (en streaming ça aurait été hardu vu qu'ils utilisent massivement le DMA) histoire d'éviter ces lags ridicules.

Sympa le jeu C64, je me demande vraiment comment ils ont fait ça sur un simple C64 (je connais pas bien la machine cela dit). Après sur MD, ça passe quand même sans trop de difficulté (en devant quand même utiliser des sprites pour le 3eme plan ^^)... mais c'est vrai que sur NES ou SMS par exemple, je vois pas trop comment tu pourrais le reproduire (il faut au minimum 2 vrais plan hard)

[Tryphon]

Je suis pas super fan des running games donc ça me tente pas plus que ça, mais je reconnais que la version C64 est très réussie.

Les niveaux sont générés aléatoirement ?

[Invité]

Les niveaux sont générés aléatoirement ?

Non je pense pas, sinon ça rendrait (je pense) le jeu trop difficile .

Je suis pas super fan des running games donc ça me tente pas plus que ça, mais je reconnais que la version C64 est très réussie.

Je voyais ça comme une adaptation sympa à faire sur Md,car par trop difficile, donc tu peux avoir un jeu addictif sans y passer trop de temps en dev .

[Tryphon]

Pas faux, mais tu sais bien que dans ce genre de projet il est indispensable d'avoir un certain affect avec le jeu.

En plus ça me gêne pas de partir sur un projet long. De toutes façons n'importe quel projet sera long pour moi : entre le boulot et les gamins, si j'arrive à trouver une heure pour coder dans la journée, c'est déjà une bonne journée

Le plus chiant c'est les fins de projets : là ça fait un bon mois que je finalise Lord Monarch, et je commence vraiment à avoir sacrément envie que ça s'arrête. Heureusement que je bosse en team de 4 personnes, sinon j'aurais laissé tout en plan...

[Invité]

Je connais les longs projets, j'en ai un sur le grill depuis un bail, mais des fois un projet court 1/2 mois pour changer et te remotiver pour reprendre ça le fait aussi .
J'ai repris mon gros projet depuis quelques semaines, et j'ai jamais autant avancé.
En plus y'a toujours des parties que l'on aime moins faire que d'autres .

[Agathon]

Street fighter zéro 2 MD, ça c'est du projet 

[Tryphon]

Le plus dur, c'est l'IA. Parce qu'à part ça un Versus, c'est pas monstrueux algorithmiquement...

[Agathon]

Au moins une démo avec Ryu et Chunli (j'aime pas Ken) dans un premier temps, avec un stage, genre celui de Sakura, la musique du stage, histoire de voir la faisabilité de la chose.

N'oubliez pas qu'il y a un couscous à la clef!!! Lol

[Tryphon]

Ben tu sais coder un combat, ça revient quasiment à coder le jeu :)

Cela étant dit, je n'aime pas le couscous mais j'aime bien SF Zero. Éventuellement, je veux bien tenter de coder deux combattants avec un moveset réduit (mettons un marche avant/arrière, saut, accroupi, poing, pied, un hadouken) si j'arrive à mettre la main sur des ressources.

Ça me donnera l'occasion de tester le sprite engine de SGDK :)

Je vais voir ce qu'on peut trouver du côté de MUGEN.

Pour la musique par contre, je sais pas faire.

[Tryphon]

J'ai trouvé des versions MUGEN de Ken et Ryu sur SFZ3, donc ça c'est cool parce que, outre les gfx, ça donne les timings des animations.

Par contre, niveau gfx, c'est tiré de la version arcade, donc plus de frames, et plus gros persos.

D'ailleurs je me pose une question niveau réso : le CPS3 a une résolution de 384x224 (comme le CPS1 et le CPS2 d'ailleurs) et la SNES de 256x224. Les sprites ont été redessinés pour la version SNES (assez joliment d'ailleurs) : ils sont plus étroits (ce qui est normal vue la résolution horizontale), et plus petits (ce qui par contre n'était pas nécessaire). Par contre, il semble que les couleurs soient les mêmes.

J'aimerais bien voir ce que ça donne en 320x224, mais que prendre ? Les sprites arcade paraîtront trop larges (mais seront grands, peut-être trop et la machine pourra pas suivre), et les sprites SNES seront trop étroits (mais plus petits, donc plus rapides à envoyer). Je suppose qu'une réduction des sprites arcade en plus proche voisin sera horrible...

Vaut-il mieux passer en 256 ? Et du coup perdre un des avantages de la MD ?

Pour comparaison, de gauche à droite :
la version GBA, la version SNES, la version MD de SF2CE, la version arcade de SFZ3 et la version MUGEN (le sprite a l'air trop large, je soupçonne que le gars a mal rippé la version arcade).

[Stef]

Il faut reconnaitre que le travail de conversion des sprites est énorme.. C'est pour ça qu'on a hérité des sprites SF2 SNES sur MD, ça aurait couté cher d'adapter au 320x224 spécifiquement pour la MD alors que celle-ci supporte aussi la résolution de la SNES. Dans un sens ça aurait été mieux qu'il sorte d'abord en exclusivité sur MD (et donc avec des sprites adaptés à la résolution de la MD) et ensuite de le porter sur SNES où il aurait été encore une fois adapté.

Rescaler en "nearest" serait horrible, le mieux serait donc effectivement de reprendre les sprites SNES pour s'éviter trop de travail :-/
Je pense que si tu les cases tels quels en 320x224 ils vont paraitre trop fins, du coup tu es effectivement obligé d'utiliser le 256x224 ce qui est un peu dommage sur MD. Par contre la version SNES a des bandes noires en haut et en bas de l'écran pour augmenter la bande passante DMA, il existe un patch game génie pour les réduire mais il y a quelques bugs graphiques lorsque tu as 2 gros sprites à l'écran (genre 2 Zangief) car le DMA n'a plus assez de temps pour tout transférer. Sur MD tu pourrais très bien passer en résol H40 (320) juste le temps du blank pour accélérer le DMA, et peut être ainsi éviter la nécessiter d'étendre le blank comme sur SNES.

[Tryphon]

Le DMA est plus lent en 256 ? Ça s'explique comment ?

Fût une époque où je m'étais pas mal intéressé au resizing. J'ai peut-être quelques idées pour automatiser le processus, mais on verra dans un deuxième temps...

[Stef]

Oui le DMA est plus lent en 256 car le dot clock est réglé sur la fréquence du VDP, en H40 (320 pixels) le VDP fonctionne à sa vitesse nominale alors qu'il fonctionne au ralenti en quelque sorte en mode H32 (256 pixels).
D'où l'intérêt de définitivement rester en H40 sur MD... le H32 n'a que des désavantages (dans le même genre le VDP gère aussi moins de sprites dans ce mode en proportion par rapport au nombre de pixel en moins).

Pour du resizing auto, c'est quand même bien chaud car évidemment tu ne vas pas utiliser d'interpolation ici sinon tu crées plein de nouvelles couleurs, ce qu'on veut éviter ici. En gros il faut un algo de resizing intelligent qui conserve les structures de l'image en préservant la colorimétrie originale et je pense que ce genre d'algo est encore au stade expérimental / recherche...

[TotOOntHeMooN]

Le mieux serait d'utiliser les sprites d'arcade de SF2 sur MD.

[Tryphon]

Oui le DMA est plus lent en 256 car le dot clock est réglé sur la fréquence du VDP, en H40 (320 pixels) le VDP fonctionne à sa vitesse nominale alors qu'il fonctionne au ralenti en quelque sorte en mode H32 (256 pixels).
D'où l'intérêt de définitivement rester en H40 sur MD... le H32 n'a que des désavantages (dans le même genre le VDP gère aussi moins de sprites dans ce mode en proportion par rapport au nombre de pixel en moins).

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

Pour du resizing auto, c'est quand même bien chaud car évidemment tu ne vas pas utiliser d'interpolation ici sinon tu crées plein de nouvelles couleurs, ce qu'on veut éviter ici. En gros il faut un algo de resizing intelligent qui conserve les structures de l'image en préservant la colorimétrie originale et je pense que ce genre d'algo est encore au stade expérimental / recherche...

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 :)

@Toto : non pas possible, ils seraient trop larges (la MD c'est 320, l'arcade c'est 384). D'où le fait que je cherche une façon de les resizer automatiquement (parce que oui, la version SNES est ultra-simplifiée par rapport à l'arcade).

[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...