Re: MEGADRIVE vs SUPER NINTENDO : Fight !

[Invité]

Cool que tu ais avancé, je savais que tu etais sur ton projet de trad, mais pas que tu avais commencé d autres trucs en parallele de shinobi .
Sur SGx l avantage sera le nombre de palettes, et surtout le nombre de sprites sur la magie ou tout les ninja vont dans tout les sens.
J avais commencé a creer une routine de gestion des metas sprites et de mise en vram dynamiques des anims pour ce projet.
Je vais aller voir tes autres videos sur dailymotion,merci pour les infos

La NG ??,justement c est trop simple donc pas marrant 

[Stef]

Tryphon> je ne sais plus si tu utilises les méthodes bas ou haut niveau pour la gestion des sprites avec SGDK. Dans tout les cas je te conseille vivement de passer à la dernière version qui devrait être plus performante.

[Tryphon]

J'utilise le bas niveau, et j'ai codé mon propre gestionnaire de file DMA. En plus, j'envisage d'implémenter des sprites semi-statiques (certaines frames sont toujours en VRAM, tandis que d'autres sont chargées à la demande) (je ne crois pas qu'on puisse le faire avec ton gestionnaire de sprites haut niveau).

Par exemple pour Musashi, les demi-sprites haut et bas pour la marche, le saut reviennent souvent, ça vaut le coup qu'ils soient statiques. Par contre les pas de crabes ou les grands sauts non. Certains ennemis fonctionnent comme ça aussi (mais pas tous).

Le truc qui m'angoisse, c'est que dans tes versions récentes j'ai l'impression que tu as modifié la gestion de la file DMA dans la VInt, et j'ai peur du coup d'avoir du code redondant (c'est d'ailleurs vraisemblablement déjà le cas).

Pour tout dire, il est vraisemblable que quand le design de moteur sera terminé, je compilerai un SGDK minimal dans lequel je virerai ce que je n'utilise pas (si c'est possible). en attendant je mets à jour SGDK régulièrement :)

Au passage, pour une fois que je peux te le dire en Français : bravo et merci pour cette lib, c'est du boulot splendide :)

[Invité]

Tiens c est bon a savoir pour ces anims là de musashi.

[Stef]

J'utilise le bas niveau, et j'ai codé mon propre gestionnaire de file DMA. En plus, j'envisage d'implémenter des sprites semi-statiques (certaines frames sont toujours en VRAM, tandis que d'autres sont chargées à la demande) (je ne crois pas qu'on puisse le faire avec ton gestionnaire de sprites haut niveau).

Par exemple pour Musashi, les demi-sprites haut et bas pour la marche, le saut reviennent souvent, ça vaut le coup qu'ils soient statiques. Par contre les pas de crabes ou les grands sauts non. Certains ennemis fonctionnent comme ça aussi (mais pas tous).

Le truc qui m'angoisse, c'est que dans tes versions récentes j'ai l'impression que tu as modifié la gestion de la file DMA dans la VInt, et j'ai peur du coup d'avoir du code redondant (c'est d'ailleurs vraisemblablement déjà le cas).

Pour tout dire, il est vraisemblable que quand le design de moteur sera terminé, je compilerai un SGDK minimal dans lequel je virerai ce que je n'utilise pas (si c'est possible). en attendant je mets à jour SGDK régulièrement :)

Au passage, pour une fois que je peux te le dire en Français : bravo et merci pour cette lib, c'est du boulot splendide :)

Avec le Sprite Engine tu peux juste être static ou dynamique, dans ton cas il faudrait être en static et gérer toi même le chargement des tiles quand c'est nécessaire... Mais du coup ça m'interpelle, est-ce que ça a un intérêt de faire ça ?
Je veux dire, si par moment tu dois charger dynamiquement des tiles pour une animation en particulier (grand saut) et idem pour les ennemis, ça signifie que ta charge DMA est très variable par écran et j'aurais tendance à dire que ça n'est pas forcément une bonne chose. Imagine tu fais un grand saut avec musashi et les ennemis utilisent une animation dynamique au même moment... même si ça a peu de chance d'arriver en pratique ça reste possible, et ça signifie que tu pourrais avoir des ralentissements dans ce cas de figure si tu dépasses ton budget DMA pile poil sur ces frames.
Perso j'opterai pour une implémentation plus simple où tout les sprites sont en dynamiques mais tu te débrouilles pour que ça tienne dans la frame. C'est pas si compliqué car j'imagine que les animations de musashi comme celle des ennemis doivent être grand max à 20 FPS non ? du coup tu peux mettre à jour les animations de musashi toutes les 3 frames (frame 0-3-6-..) et idem pour les ennemis mais en décalé (1-4-7-..) et tu conserves les frames (2-5-8-...) pour le reste par exemple.
Ainsi tu ne dépasses pas ton budget DMA par frame...
Le nouveau Sprite engine est plus performant que l'ancien et je pense qu'il est suffisant pour gérer un jeu comme shinobi s'il est bien utilisé (tu as la possibilité de désactiver certaines fonctionnalités un peu couteuse comme le "auto visibility"). J'ai aussi mis à jour la gestion des sprites de bas niveau pour que ça soit plus rapide donc de toute manière c'est tout bénef de passer sur la dernière version

Et oui y'a un DMA queue dans le dernier SGDK (et la gestion des sprites l'utilise) donc fort possible qu'il y ai du code redondant... mais bon comme tu le dis tu pourras éliminer par la suite le code en doublon
Merci pour les commentaires sur SGDK, perso je suis très excité par ce projet de portage de Shinobi sur MD, enfin tu le sais déjà, du coup je suis ça de prêt

[tilou]

je ne doute pas que la megadrive peux restituer la qualité graphique de shinobi dans sa version arcade 
mais coté sonore ca risque d’être plus complexe genre ceci :

[Invité]

Mais du coup ça m'interpelle, est-ce que ça a un intérêt de faire ça ?

Oui ça évite d'avoir un trop plein de données à avoir à charger en VRAM pendant une frame trop chargée .
Ca permet de distiller les tiles par petits chunk à chaque frame,par contre ça demande un double buffer,mais permet du coup d'avoir bcp d'anim à l'écran.

je ne doute pas que la megadrive peux restituer la qualité graphique de shinobi dans sa version arcade 
mais coté sonore ca risque d’être plus complexe genre ceci :

C'est surtout niveau couleurs que ça va pêcher, sub palettes, et palette principale .

[Stef]

Mais du coup ça m'interpelle, est-ce que ça a un intérêt de faire ça ?

Oui ça évite d'avoir un trop plein de données à avoir à charger en VRAM pendant une frame trop chargée .
Ca permet de distiller les tiles par petits chunk à chaque frame,par contre ça demande un double buffer,mais permet du coup d'avoir bcp d'anim à l'écran.

Tu as lu la suite de ma phrase ? Car je ne pense pas que ça soit de ça dont il s'agit ici.

[Invité]

Oui, ton idée n'est pas mauvaise non plus, mais je pense que de petits chunk à chaque frame est le plus simple .
Surtout que la taille des anims à envoyer varie, donc c'est plus simple à gérer (pour moi du moins).

[Stef]

Pour les petits chunk à chaque frame, ça signifie que tu dois double bufferiser en VRAM chaque sprite, autant dire que tu sacrifies une bonne partie de la VRAM et divise par 2 potentiellement le nombre de sprites que tu peux avoir à l'écran. Si tu as ce luxe pourquoi pas, mais perso je trouve que découper les uploads sur différentes frames est plus simple à implémenter et te permet d'optimiser l'utilisation VRAM :)

tilou> Pour le son la MD et l'arcade en question sont très proches, je pense au contraire que c'est l'un des points plutot simple à régler Idéalement il faudrait un dump VGM des musiques arcade et faire un convertisseurs en VGM MD (ce qui ne doit pas être trop compliqué).

[Invité]

Pour les petits chunk à chaque frame, ça signifie que tu dois double bufferiser en VRAM chaque sprite, autant dire que tu sacrifies une bonne partie de la VRAM et divise par 2 potentiellement le nombre de sprites que tu peux avoir à l'écran. Si tu as ce luxe pourquoi pas, mais perso je trouve que découper les uploads sur différentes frames est plus simple à implémenter et te permet d'optimiser l'utilisation VRAM :)

Chaque solution a ses avantages et inconvénients, mais ici pour shinobi je pense pas que ça pose un problème, même sur MD avec 64ko de VRAM .
Y'a pas énormément d'ennemis différents à l'écran, et tous ne nécessitent pas d'être dynamique,de plus les décors sont pas non plus très gourmands en tiles .

[tilou]

C'est surtout niveau couleurs que ça va pêcher, sub palettes, et palette principale .

l'arcade sega system 16 ressemble beaucoup a l’architecture de la megadrive mais sa palette de couleurs est de plus de 6000
le pros sonore zilog 80 tourne a 6 mhz
c'est pas mal de contraintes

[Invité]

C'est surtout niveau couleurs que ça va pêcher, sub palettes, et palette principale .

l'arcade sega system 16 ressemble beaucoup a l’architecture de la megadrive mais sa palette de couleurs est de plus de 6000
le pros sonore zilog 80 tourne a 6 mhz
c'est pas mal de contraintes

Techniquement aucun soucis, sauf pour la magie ou musashi se démultiplie et fait apparaitre plein de ninjas sur l'écran .
1 musashi (arcade) est un sprite de 32x64, il y en a 15 à l'écran,donc si tu veux pas que ça clignote comme un jour de noel, faut baisser le nombre .
L'arcade a une palette principale sur 15bit je crois .

[tilou]

Techniquement aucun soucis, sauf pour la magie ou musashi se démultiplie et fait apparaitre plein de ninjas sur l'écran .
1 musashi (arcade) est un sprite de 32x64, il y en a 15 à l'écran,donc si tu veux pas que ça clignote comme un jour de noel, faut baisser le nombre .

moi je pense a plutôt a ca vu la taille des sprites

sachant que l'animation des statues faisaient ralentir le system 16 a outrance

[Invité]

sachant que l'animation des statues faisaient ralentir le system 16 a outrance

Oui ça aussi ça peux poser problème,sauf arriver à utiliser des sprites que qd c'est nécessaire .
Le system 16 ralenti, mais ça veux pas dire que c'est pas évitable,faut voir comment c'est codé .

Tu feras jamais une conversion 100% fidélle,mais même à 95% ça reste ultra impressionnant, surtout vu les conversions de l'époque .

[Invité]

L'original rame. Une conversion fidèle rame aussi. Question de principes.

[Invité]

L'original rame. Une conversion fidèle rame aussi. Question de principes.

LOL, bah si on peut éliminer les ralentissement, ça compense les trucs pas fidèles

[tilou]

Tu feras jamais une conversion 100% fidélle,mais même à 95% ça reste ultra impressionnant, surtout vu les conversions de l'époque 

d’après ce que j'ai pu voir le travail accompli sur ce projet est tout bonnement HALLUCINANT en tout cas

[Invité]

Oui c'est du bon boulot.

[Stef]

Techniquement aucun soucis, sauf pour la magie ou musashi se démultiplie et fait apparaitre plein de ninjas sur l'écran .
1 musashi (arcade) est un sprite de 32x64, il y en a 15 à l'écran,donc si tu veux pas que ça clignote comme un jour de noel, faut baisser le nombre .

moi je pense a plutôt a ca vu la taille des sprites

sachant que l'animation des statues faisaient ralentir le system 16 a outrance

Cette partie peut heureusement utiliser le second plan, avec quelques sprites pour les statues en mouvement c'est faisable :)

[Invité]

sauf que dans un cas comme celui là, ça va être marrant à faire :
https://youtu.be/lqScgMHVe3c?t=12m13s

[Stef]

Je connaissais cette astuce, je l'utilisais moi même en arcade
Sinon pour les statues je me demande même s'ils n'ont pas utilisé l'astuce du plan en arcade également. On voit clairement que les statues tombent une par une sur la colonne, du coup ça simplifie encore les choses :) Théoriquement tu n'as pas plus de 1 seule statue à mettre en sprite à la fois =)

[Tryphon]

Le sprite typique est plus ou moins en 32x64 (j'ai écrit un générateur de ressources qui découpe en général mieux que ça, quitte à utiliser plus de sous-sprites) et j'estime qu'en avoir 8 à l'écran, Musashi compris, serait optimal (théoriquement la borne en gère beaucoup plus, y'a qu'à voir ces vidéos où les ninjas verts respawnent "à l'infini", mais dans une partie "normale" ça ne doit pas se produire). Typiquement, Shadow Dancer sur MD est à 6 sprites dynamiques je crois. Si tu crois que le gestionnaire de SGDK peut maintenir ça, je ferai quelques tests.

J'étais en effet parti sur une solution à la Touko : quand une animation démarre je crée une liste des frames à charger avec un numéro de priorité (le nombre de frames avant qu'elles ne doivent être disponibles) et je ne charge que des petits chunks à chaque VInt. Si une nouvelle animation d'un autre perso vient démarrer en plein milieu, les frames viennent s'intercaler dans la liste.

En effet, ça demande plus de VRAM (mais comme dit Touko les décors sont lights), mais toujours moins que de tout rendre statique (et ça permet une plus grande variété d'ennemis). Maintenant, j'ai pas tout étudié, mais il est possible qu'un Musashi dynamique et le reste statique soit envisageable, auquel cas plus de problèmes.

Le truc, c'est que je suis bloqué avec le hack de Lord Monarch. J'avais prévu de bosser sur Shinobi cet été, mais quand j'ai vu que deux gars avaient traduit le script complet de Lord Monarch sans personne pour ne serait-ce que réinsérer le script, j'ai craqué :) En plus le eu a l'air sympa (il y a une ambiance Shining Force / Landstalker pas déplaisante et c'est un Tactical) et j'ai l'impression qu'ils ont bien bossé.

[Invité]

J'étais en effet parti sur une solution à la Touko : quand une animation démarre je crée une liste des frames à charger avec un numéro de priorité (le nombre de frames avant qu'elles ne doivent être disponibles) et je ne charge que des petits chunks à chaque VInt. Si une nouvelle animation d'un autre perso vient démarrer en plein milieu, les frames viennent s'intercaler dans la liste. 

En fait je fais la même chose, juste que moi elles sont pre-crées .
j'ai une liste pour chaque frame d'anim,ou j'inclue aussi l'organisation du meta sprite.

Maintenant, j'ai pas tout étudié, mais il est possible qu'un Musashi dynamique et le reste statique soit envisageable, auquel cas plus de problèmes.

J'ai eu la même approche, mais bon c'est aussi parce que j'ai 128 ko de VRAM à dispo, donc plus simple pour mettre des ennemis en cache .

[upsilandre]

Le System 16 c'est semble t'il 800 pixels-sprite par scanline contre 320 pour la MD. De ce coté la l'arcade est toujours loin devant. Y a toujours une grosse marge sur les sprites. Je me demande d'ailleurs si y a des jeux arcade qui implémente le flickering de sprite dans leur code. A mon avis ils se contentent d'accepter qu'un sprite puisse s'afficher que partiellement en cas de tres rare overflow, les hardwares sont calibré pour pas avoir a s'embeter avec ca.

Meme le System 1 c'est deja 640 pixels sprite juste pour faire du choplifter, du Teddy boy, du Sega Ninja, du Wonder boy... Des truc qu'on a retrouvé ensuite tres bien sur Master System avec un budget 10x plus fiable (64 pixels-sprite)

[tilou]

si l'on s'en réfère a la version pc engine  (trés bonne au passage) bien plus limitée techniquement, les programmateurs ont étés obligés de limiter le nombres de sprites a l'écran (l'astuce du plan impossible dans ce cas la)
voir le fameux boss mandara 05:48 

[Tryphon]

C'est sans aucun doute la meilleure version console / micros, mais y'a quand même beaucoup de choses coupées au montage (certaines ne se justifiant pas vraiment en plus)

[Invité]

Oui la version PCE est pas trop mal(sans être exceptionnelle non plus), mais ils auraient pu faire mieux, surtout niveau couleurs .
Bon après les concessions étaient aussi obligatoires, manque d'un second plan et surtout taille de la cartouche .

Le System 16 c'est semble t'il 800 pixels-sprite

Si c'est exact c'est énorme,je crois que c'est quasiment ce que proposait le CPS1 de capcom .

[tilou]

j'ai trouvé ca sur un forum

Differences Between System 16A/B and SEGA MegaDrive/Genesis

A lot of people don't know the exact differences between a MegaDrive/Genesis and the arcade board it was based off - the System 16A/B.

So I thought I'd give you guys the rundown.

Here we go -

68000 CPU Speed: 
S16A/B 10 MHz 
MD/GEN 7.6 MHz

Max Sprites On Screen: 
S16A/B 128 
MD/GEN 80

Color Palette: 
S16A/B 4096 
MD/GEN 512

Max Colors On Screen: 
S16A/B 1536 
MD/GEN 64

Main Work RAM: 
S16A/B 128K 
MD/GEN 64K

VRAM: 
S16A/B 512K 
MD/GEN 64K

Hardware Scaling/Zooming: 
S16A/B YES 
MD/GEN NO

[Invité]

Bah, c'est de l'arcade quoi ..

[upsilandre]

Deja en arcade t'avais toujours 100 ou 200 palettes locales. Ils les utilisaient pas mais c'etait la.