Re: Megadrive et Super Nintendo : parlons technique !

[upsilandre]

Y a pas de frame d'animation mais y a des motif de flocon différent.
Et a priori faut etre capable de traiter tous les flocons a chaque frame donc faut sans doute supporter une soixantaine d’interruption avec des intervalles variable.

[EPSYLON EAGLE]

Questions d'amateurs:



Quelle est en fait la technique de mutiplexation des sprites? 

Comment ça marche?


Pourquoi cela peut-il être fait sur Mega Drive, mais est-ce impossible sur Super Nes?

[Invité]

Questions d'amateurs:



Quelle est en fait la technique de mutiplexation des sprites? 

Comment ça marche?

Le multiplexage est une technique pour multiplier les sprites à l'écran sur une machine qui en dispose d'un nombre limité.
Par exemple le C64 qui dispose de 8 sprites hard, le multiplexage va permettre d'en afficher bcp plus à l'ecran .
La technique consiste à changer la table de sprites pendant l'affichage pour que la puce vidéo réutilise les sprites hardwares utilisés .

Par exemple(tjrs sur le C64) prends une image coupées en 2 parties égales, tu affiches tes 8 sprites dans la partie supérieure, donc normalement la puce vidéo ne peut plus en afficher dans la partie inférieure puisque tout tes sprites ont été utilisés,et bien en modifiant la table de sprites hors affichage, la puce va croire le contraire et afficher de nouveaux sprites comme si elle ne les avait pas affiché précédemment,visuellement tu auras 8 + xx sprites, mais au niveau hardware tu auras tjrs que tes 8 sprites hardwares.
Voilà .

Pourquoi cela peut-il être fait sur Mega Drive, mais est-ce impossible sur Super Nes?

Car la table de sprites de la snes (l'OAM) ne peut pas être modifiée pendant l'affichage sans corruptions,et puis c'est pas nécessaire vu que tu as 128 sprites dispos  .
Chaque machine est différente,et toutes ne peuvent pas le faire, ou le faire comme sur Md avec des contraintes particulières .

[Tryphon]

Ça me fait me poser une question (et une deuxième) :

* cette technique de multiplexage montre que le VDP de la MD peut, sans ajout de hw, gérer davantage de sprites. Du coup, pourquoi avoir posé une limite à 8O sprites (et pas à 256 par exemple, pour garder un link sur 8 bits) ?

* on me répondra peut-être que si on fait ça, on va avoir une grosse SAT, d'iù mon autre question :

si je code un jeu sur lequel je sais que j'utiliserai jamais plus de 4O sprites, ça veut dire qu'il y a 4Ox8 = 32O octets inutilisés. Puis-je stocker autre chose dedans ? ou alors est-ce que le mécanisme du cache interne au VDP va interférer ?

[upsilandre]

* cette technique de multiplexage montre que le VDP de la MD peut, sans ajout de hw, gérer davantage de sprites. Du coup, pourquoi avoir posé une limite à 8O sprites (et pas à 256 par exemple, pour garder un link sur 8 bits) ?

Ca nécessite du cache supplémentaire dans le VDP, tu préfères plus de sprite ou plus de CRAM?
Et puis la liste de sprite faut la trier a chaque scanline, si tu veux une SAT de 160 sprites au lieu de 80 faut un hardware 2 fois plus rapide pour trier la liste.
Et c'est un équilibre entre la limite de la liste et la limite réel d'affichage (20 par scanline) ca sert a rien d'avoir un trop grand décalage entre les 2.


En fait on parle de multiplexage mais faut bien comprendre que tout ces GPU sont deja basé sur le multiplexage hardware (invention de Texas Instrument avec le TMS9918). Une MD c'est un pipeline de 20 sprites et grace au multiplexage hardware intégré au VDP elle peut en gérer 80. Une NES ou une Master System c'est un pipeline de 8 sprites qui est étendu a 64 grâce au multiplexage hardware. Avant cela le multiplexage etait 100% software comme sur C64. La MD permet d'ajouter du multiplexage software en plus du multiplexage hardware.

[Stef]

Ça me fait me poser une question (et une deuxième) :

* cette technique de multiplexage montre que le VDP de la MD peut, sans ajout de hw, gérer davantage de sprites. Du coup, pourquoi avoir posé une limite à 8O sprites (et pas à 256 par exemple, pour garder un link sur 8 bits) ?

* on me répondra peut-être que si on fait ça, on va avoir une grosse SAT, d'iù mon autre question :

si je code un jeu sur lequel je sais que j'utiliserai jamais plus de 4O sprites, ça veut dire qu'il y a 4Ox8 = 32O octets inutilisés. Puis-je stocker autre chose dedans ? ou alors est-ce que le mécanisme du cache interne au VDP va interférer ?

Rachètes toi un clavier bon sang  
Bon sinon la limite des 80 hard c'est effectivement une limite par rapport à la taille de la SAT (surtout celle qui est cachée dans le die du VDP) mais c'est aussi une limite sur la vitesse de traitement, car ça signifie que le VDP doit être capable de parser les 80 sprites en 1 seule ligne (et en retenir que 20 au maximum qui seront afficher pour la prochaine ligne).
Si tu n'utilises que 20 ou 40 sprites, bien sur tu peux stocker ce que tu veux dans le reste de la SAT (emplacement 40 à 79) mais la SAT prend très peu de place en VRAM, c'est pas vraiment là que tu vas gagner

Edit: grilled par Upsi à 1mn prêt

[Tryphon]

L'argument du triage à chaque scanline me parle aussi, merci vous deux

(et bien sûr que j'aurais préféré plus de CRAM, mais je me demandais si ça pouvait se faire à hw constant)

Sinon, pour mon clavier, c'est un PC portable donc difficile de le changer.

Mais j'en ai racheté un autre (un Acer Swift), que j'attends pour dans la semaine

[Stef]

Pourquoi cela peut-il être fait sur Mega Drive, mais est-ce impossible sur Super Nes?

Car la table de sprites de la snes (l'OAM) ne peut pas être modifiée pendant l'affichage sans corruptions,et puis c'est pas nécessaire vu que tu as 128 sprites dispos  .
Chaque machine est différente,et toutes ne peuvent pas le faire, ou le faire comme sur Md avec des contraintes particulières .

Pas la peine d'essayer de minimiser le fait qu'on peut le faire sur MD et pas sur SNES. La MD est mieux foutue et plus puissante comme d'habitude point barre   Mais bon dans un sens tu as un peu raison, 128 sprites c'est déjà bien chaud à gérer avec le CPU de la SNES donc pas la peine d'essayer d'en faire plus

[Stef]

Sinon, pour mon clavier, c'est un PC portable donc difficile de le changer.

Mais j'en ai racheté un autre (un Acer Swift), que j'attends pour dans la semaine

Ah oui en effet ça craint si c'est sur un PC portable bon heureusement le nouveau arrive bientot (coder sans le 0 ça doit pas être évident )

[TotOOntHeMooN]

coder sans le 0 ça doit pas être évident

Je suis certain que dans son code, c'est bourré de (1-1) et d'adresses impaires ! 

[Invité]

Pourquoi cela peut-il être fait sur Mega Drive, mais est-ce impossible sur Super Nes?

Car la table de sprites de la snes (l'OAM) ne peut pas être modifiée pendant l'affichage sans corruptions,et puis c'est pas nécessaire vu que tu as 128 sprites dispos  .
Chaque machine est différente,et toutes ne peuvent pas le faire, ou le faire comme sur Md avec des contraintes particulières .

Pas la peine d'essayer de minimiser le fait qu'on peut le faire sur MD et pas sur SNES. La MD est mieux foutue et plus puissante comme d'habitude point barre   Mais bon dans un sens tu as un peu raison, 128 sprites c'est déjà bien chaud à gérer avec le CPU de la SNES donc pas la peine d'essayer d'en faire plus

Le troll c'est sur l'autre topic !!

[Tryphon]

coder sans le 0 ça doit pas être évident

Je suis certain que dans son code, c'est bourré de (1-1) et d'adresses impaires ! 

C'est terrible : je suis obligé de copier un zéro dans un document quelque part, et de le coller partout où j'ai besoin.

Et pour couronner le tout, les 2 touches Ctrl ne fonctionnent plus : Ctrl-V impossible

Et ça fait chier de devoir racheter un ordi juste parce que le clavier déconne

[Invité]

Mais non, t'achètes ça et c'est bon

[Tryphon]

Ça devient vachement moins portable du coup

[Invité]

Ah oui  

[Stef]

@tryphon> tu peux toujours changer le clavier de ton PC portable, souvent tu peux en trouver des neufs sur internet en pièce détachée et c'est pas compliqué à replacer ;-)

@touko> désolé mais c'était trop tentant :-D

[TotOOntHeMooN]

Puis bon... Tu parlais technique...

[Tryphon]

C'est un Asus Transformer (Le MS Surface du pauvre ) du coup c'est assez délicat...

[TotOOntHeMooN]

C'est un Asus Transformer (Le MS Surface du pauvre ) du coup c'est assez délicat...

Garantie ? SAV ?

[Tryphon]

Je tenterai de faire jouer le SAV une fois que j'aurai le nouveau PC (j'en n'ai pas d'autre).

[TotOOntHeMooN]

Je tenterai de faire jouer le SAV une fois que j'aurai le nouveau PC (j'en n'ai pas d'autre).

En attendant, si tu pouvais éviter de vendre tes bannières publicitaires à Gamopat ! 

Spoiler:

[Tryphon]

Oups, je suis démasqué

[thetricker24]

petite question d'amateur pour un champion :

la megadrive est doté d'un cpu 68000
le systeme CAVE 1ere génération est doté d'un 68000

en THEORIE : un portage de donpachi (ou dodonpachi) sur megadrive, c'est possible ?

[TotOOntHeMooN]

petite question d'amateur pour un champion :

la megadrive est doté d'un cpu 68000
le systeme CAVE 1ere génération est doté d'un 68000

en THEORIE : un portage de donpachi (ou dodonpachi) sur megadrive, c'est possible ?

L'intérêt d'avoir la même CPU réside surtout dans la possibilité de récupérer un éventuel code source ou d'arriver à désasembler le programme pour en isoler des routines de gameplay pour reproduire à la perfection le comportement d'un jeu... (ou réaliser une sorte d'émulation pour faire tourner le code d'arcade) Mais si rien de cela n'est fait, avoir la même CPU n'est pas forcément un prérequis. Surtout que c'est plutôt du coté des capacités d'affichages que se posent le plus souvent les limitations des conversions ! (et donpachi, en plus d'être en vertical, il envoie du bois)

[sengoku 2]

Ouch, Dodonpachi ça va carrément plus loin que le premier.
Parlons donc du premier qui est donpachi, ça canarde aussi dans ce jeu, surtout dans les derniers stages. Sur MD, ça ne serait plus le même jeu, car pas la même pêche pas les mêmes pattern de boulettes, donc pas les mêmes sensations.
Sur MD, il faudrait faire une version adaptée à la MD, c'est à dire diminuer les boulettes, peut-être la puissance des tirs et faire des choix comme un jeu à 1 player ou bien à deux players ?
L'intérêt de la version MD serait de mettre des motifs de boulettes typique des danmaku-manic shooter, c'est à dire un rideau de bullets à l'écran dans le but de garder le feeling danmaku.
Si le mode 2 players est activé, ça va être un peu + dur d'aller plus loin dans les motifs de boulettes à l'écran, voilà pourquoi certains programmeurs préfèrent le mode 1 player. C'est le cas des jeux ng dev team sur neo geo où sur Fast striker par exemple, on ne joue qu'à 1 joueur par exemple, mais ça permet d'aller loin dans l'affichage de boulettes à l'écran.
Et comme sur neo geo, on n'échappera pas à des effacements de sprites ( voire des ralentissements ) quand ça dépasse la limite des sprites par scanlines.
Mais bon, ces effacements de sprites ne sont pas gênants tant que le jeu garde toute sa pêche et son feeling danmaku.

En tout cas, beaucoup de personnes parlent des BTA à la Final fight ou Street of rage pour pousser à bout les consoles.
Mais je me demande, si un danmaku est le  test ultime donc au-dessus pour mettre à genoux nos chers consoles ?

[Tryphon]

Le danmaku n'est pas adapté aux consoles 16 bits, car on dépasse très vite soit le nombre maximum de sprites gérables, soit la limite de sprites par ligne.

On pourrait essayer des techniques bizarres, genre rendre les sprites par les décors (mais c'est très lourd, même s'ils sont petits) ou rendre les sprites 1 frame sur 2.

Un truc qui ressemble un peu, c'est Ixion, par nendo16, sur Megadrive :



Mais c'est pas à proprement parler un STU (tu ne peux pas tirer).

[TotOOntHeMooN]

Joli concept. Après, on en voit très vite les limitations à ne gérer que des bulets et le joueur sur un faux "256x224".

[thetricker24]

Je voterai donc pour un danmaku lors du prochain sondge pour financement participatif chez watermelon.
Plus sérieusement, les balles sont elles vraiment à proprement palrer des sprite ? Si oui, si la limite est 80 à l'ecran, on va dire avec le personnage principale plus 4 ennemis, il reste de la place pour 75 ballesp, de quoi faire quelque chose de quand meme tres enervé. Quand on y pense, la nervosité de alien soldier est la meme que celle d'un danmaku, a defaut de ne pas etre un STG et sans la prolifération de balles. Mais avec un tel investissement dans le dev,il doit y avoir fort moyeb de se rapprocher de quelque chose comme donpachi, voire meme plus nerveux et rapide.
Apres avoir un ralentissement avec le nombre de sprite maximal atteint ca peut aussi etre cool, je pense a l'ensemble des jeux cave sh3 où la limitation technique a ete integrée au gameplay.
Bref, si une team se lance dans un tel projet, je n'hesiterai pas à investir

[Tryphon]

Oui, les balles sont des sprites. Et pas qu'elles : le joueur, souvent les scores (encore que dans un shoot vertical on peut les mettre sur le côté).

Faudrait regarder combien un shoot classique (genre un TF3 ou un Aleste) utilise de sprites, mais ça doit déjà pas être loin.

Sans compter qu'il n'y a pas que les sprites comme limitation, il y a aussi :

* le nombre de sprites par ligne (1O)
* les tests de collision amis/ennemis (de l'ordre de grandeur du produit des deux)
* les "IA" des ennemis et des bullets

Mais ce serait un projet intéressant, clairement. Je serais moi aussi curieux de voit ce que les deux bécanes peuvent faire...

[TotOOntHeMooN]

Perso, j'aimerai bien que quelqu'un ose faire un shoot avec écran en TATE. Déjà, parce qu'on n'a plus de limitation de sprites par "ligne", et en suite parce qu'on n'est plus à une époque ou c'est "grave" de devoir incliner l'écran à 90°... Et ça serait une option sympa à faire rajouter aux émulateurs !

[Stef]

Je trouve que Omega Blast (du même auteur) est un meilleur exemple de ce qu'on peut faire sur MD :




C'est sympa mais je trouve le jeu trop speed... on y aurait gagné à ralentir le player, les bullets du player et certains ennemis mais je pense que c'était pour renforcer l'impression d'action. Aussi en ralentissant les bullets du player forcément tu peux en avoir plus à l'écran et là on est déjà à la limite en terme de nombre de sprites.

En fait je me disais que pour ce jeu de jeu, et surtout pour les bullets, le multiplexage de sprites pourrait aider un peu, mais ça résoudrait pas tout..