Re: Shinobi 1 sur MD

[Invité]

Pour l'effacement de sprites en effet, mais c'est subtil, car c'est masqué par le fait que le sprite juste après ait le même motif(ailettes blanches) .
Je sais pas si c'est fait exprès, mais si l'avant dernier sprite avait été le dernier, l'effacement ce serrait vu par contre .
Par contre si les éventails sont en 16 de large ou même 32, il me semble qu'ils comptent pour 1 seul sprite,donc c'est pas normal que ça clignote de toutes façons, c'est que tu dois avoir des sprites en overscan(et sur la même ligne) qui sont toujours dans ton link de sprites  .

[Tryphon]

J'ai peaufiné 2-3 trucs et fait une capture de la mission 4 (dans laquelle j'ai décelé un gros problème de hitbox, forcément). Je trouve que le stage 4-1 (peut-être le plus beau en arcade) rend pas mal :



Un truc qui m'agace un poil : sur la vidéo, on voit lors de l'écran de présentation de la mission (à 2:00) qu'il y a un problème dans le scroll du plan sur la première ligne, tout en haut :

Je ne sais pas d'où ça vient. Mon code est a priori OK, j'ai fait des modifs, recompilé plusieurs fois, et au bout d'un moment ça a disparu... J'ai annulé les modifs une à une pour voir quand le bug réapparaissait, et il n'a pas reparu

Il n'est pas exclus que ce soit un bug de la version de Gens que j'utilise (gens-r57shell).

[Paradis]

ça a sacrement de l'allure
Tu envisages un démo jouable prochaine ou pas du tout?

[Tryphon]

Y'aura une deuxième démo dans pas longtemps.

[Paradis]

Ah c'est chouette ça

[TotOOntHeMooN]

C'est toujours aussi plaisant de voir une nouvelle vidéo !

Après, un gros bémol quand même sur le premier acte... Les couleurs sont vraiment dégueu. Faut faire qqch. ^^
Les actes 2 et 3 sont par contre magnifiques et ça bouge vraiment bien !!!

[Tryphon]

T'es vache, perso je trouve que c'est assez proche de l'original :




(il faut afficher l'image de Gens à sa vraie taille, j'ai oublié de désactiver les scanlines, du coup ça fait dégueu en resizé)

(et du coup je vois une différence avec l'arcade : c'est le bleu qui apparaît par-dessus le rouge ; tant pis, pour une fois qu'on voit un rouge, je le laisse )

[upsilandre]

C'est juste le niveau qui est moche de base

[Tryphon]

C'est mon préféré

Avec ce ciel d'un bleu tellement JV des années 80

[TotOOntHeMooN]

Je ne dis pas que la conversion est mauvaise, elle est très proche... C'est juste que c'est moche aussi en arcade et que ça dénote du reste du jeu. Du coup, il serait vraiment bien de pouvoir faire quelque chose dans ce sens. Et ça ne serait pas trahir que de trouver une palette mieux adaptée, faute de retoucher les gfx. (le ciel est plus vert que bleu quand même )

[Tryphon]

Oui, le fameux bleu ciel Sega arcade de l'époque. Tu l'as dans Wonderboy aussi

[Tryphon]

Je reviens au Bonus stage et je reprends l'idée de Stef :

Pour résoudre ça, tu ne peux pas tout laisser en priorité basse pour le début (la main de musashi est en sprite j'imagine, du coup elle reste devant le grand ninja) ? Ensuite au baissé / levé de rideau (qui se fait par tile), tu passes le plan progressivement (en même temps que l'affichage du rideau) en priorité haute, qui du coup va recouvrir la main de musashi qui est toujours en prio basse ?

Et en fait non, ça marche pas. Pour l'instant, j'ai ça :

plane B low : décor
plane A low :
Sprites low : ninjas et shurikens
plane B high :
plane A high : grand ninja
Sprites high : main

Je suis contraint par le fait que les ninjas et les shurikens doivent être derrière le grand ninja, donc le grand ninja est forcément en priorité haute, du coup la main aussi pour apparaître devant le grand ninja...

Ou alors j'ai raté un truc

[TotOOntHeMooN]

Tu n'as pas vraiment le choix là... D'ailleurs, c'est comme si le joueur se retrouvait en arrière une fois le grand Ninja sur lui, sachant que tu ne peux plus rien faire. Tu pourrais donc même faire baisser les mains à ce moment "sénarique" pour éviter le soucis avec le rideau. (ca renforcerai même le fait qu'il t'ai touché)

[Tryphon]

C'est ce que j'ai fait dans la vidéo postée y'a 2 pages. Oui, je vois pas de meilleure solution.

Et concernant le bout d'éventail manquant, l'overflow n'est pas dans le nombre de sprites sur la scanline, mais le nombre de pixels... Chaque éventail nécessite un poil plus de 40 pixels de large, donc 48, il y en a 7, donc 336 pixels, oups, overflow.

Je peux gérer ça en redessinant les deux derniers éventails je pense...

[TotOOntHeMooN]

Voilà. (pour ça que je n'y avais pas porté attention)

[Stef]

@Tryphon> ah oui effectivement je n'avais pas pensé au fait que la main reste devant le Ninja qui se trouve lui même devant les autres sprites... Dans ce cas la main est forcément en high priority.

Sinon au pire tant pis tu passes le gros ninja en sprite, à priori ça devrait passer (j'ai juste une petite crainte d'overflow sur la ligne en bas avec les mains) :-/

[TotOOntHeMooN]

La solution de Tryphon (plan avec la main qui se retire vers le bas) est bien plus classe qu'en arcade...
Du coup, pourquoi se prendre la tête à faire pareil pour que se soit moins bien ?

[Stef]

Juste pour être au plus proche de l'original 
Mais effectivement la solution de enlever la main discrètement me va aussi, c'est juste qu'on a du mal à comprendre "pourquoi ?" quand on connait bien la version d'origine ^^

[TotOOntHeMooN]

Pourquoi : Parce qu'on t'a sauté à la gueule, t'as perdu, pu ne peux plus tirer. (il faut chercher une cohérence sénarique aux impasses techniques)
Une alternative étant de la faire disparaitre d'un coup quand le Ninja est au premier plan, comme s'il avait projeté en arrière le joueur... Plus proche de l'original, quand on a une solution qui en plus rend mieux pour compenser ce genre de détails, ça n'a pas vraiment de sens.

[Invité]

Je reviens au Bonus stage et je reprends l'idée de Stef :

Pour résoudre ça, tu ne peux pas tout laisser en priorité basse pour le début (la main de musashi est en sprite j'imagine, du coup elle reste devant le grand ninja) ? Ensuite au baissé / levé de rideau (qui se fait par tile), tu passes le plan progressivement (en même temps que l'affichage du rideau) en priorité haute, qui du coup va recouvrir la main de musashi qui est toujours en prio basse ?

Et en fait non, ça marche pas. Pour l'instant, j'ai ça :

plane B low : décor
plane A low :
Sprites low : ninjas et shurikens
plane B high :
plane A high : grand ninja
Sprites high : main

Je suis contraint par le fait que les ninjas et les shurikens doivent être derrière le grand ninja, donc le grand ninja est forcément en priorité haute, du coup la main aussi pour apparaître devant le grand ninja...

Ou alors j'ai raté un truc

Tu peux aussi effacer les mains au fur et à mesure que le fond les recouvre .

[Tryphon]

J'y ai pensé, mais c'est difficile parce que le sprite n'est pas aligné (donc faudrait le bouger latéralement sans intervention du joueur, ce qui est étrange), et les sprites hard qui le composent ne sont pas non plus alignés entre eux (je peux le modifier, mais bon, est-ce que ça en vaut la peine ?)

J'ai le même problème avec les transitions (avec les carrés progressifs qui recouvrent l'écran) : ça marchera mal avec les sprites, qui ne sont pas alignés.

[Stef]

En fait ces tout ces effets de transition qui te pose problème..
du coup je me dis que tu devrais les faire moitié sprite / moitié BG.
Pour le bord de la vague tu utilises des sprites (genre une bordure de 32 pixels de large) et derrière tu as background qui se met à jour. Ainsi tu peux recouvrir les autres sprites de manière smooth (que tu supprimes au fur et à mesure qu'ils sont recouverts). Pour être plus tranquille il te faudrait peut être une bordure de 64 pixels de large en sprite... Ca te permet aussi d'avoir des transitions smooth au pixel (et non plus au tile comme la version arcade), idem pour le "dessin" de la transition. Après oui ça dénature un peu l'original...

Edit: ah ouais non tu peux pas du tout utiliser ça pour les transitions dans les niveaux où tu as un recouvrement/découvrement type "random"... La pas le choix, c'est un plan à utiliser et tu ne peux pas avoir de sprite en high priority à ce moment (d'ailleurs sur l'arcade j'ai l'impression que c'est comme ça).

[TotOOntHeMooN]

ah ouais non tu peux pas du tout utiliser ça pour les transitions dans les niveaux où tu as un recouvrement/découvrement type "random"... La pas le choix, c'est un plan à utiliser et tu ne peux pas avoir de sprite en high priority à ce moment (d'ailleurs sur l'arcade j'ai l'impression que c'est comme ça).

Pour les transitions "random", a un moment je proposais d'aligner au tile le FG et le BG (scroll lors de la mort du joueur qui tombe en arrière) et de copier les tiles du FG en BG pour n'avoir qu'un seul plan pour les deux... Enfin, d'utiliser le FG libéré pour faire l'effet par dessus... Mais c'est quand même un beau bordel !

[Invité]

J'y ai pensé, mais c'est difficile parce que le sprite n'est pas aligné (donc faudrait le bouger latéralement sans intervention du joueur, ce qui est étrange), et les sprites hard qui le composent ne sont pas non plus alignés entre eux (je peux le modifier, mais bon, est-ce que ça en vaut la peine ?)

J'ai le même problème avec les transitions (avec les carrés progressifs qui recouvrent l'écran) : ça marchera mal avec les sprites, qui ne sont pas alignés.

C'est pas grave vu que tu effaces tes sprites par tiles de 8x8 pixels .
Un tableau avec les adresses VRAM des tiles à effacer,je vois pas où est la difficulté .

[Tryphon]

Tu parles du rideau rouge du bonus-stage ou des transitions en damiers ?

[Tryphon]

Edit: ah ouais non tu peux pas du tout utiliser ça pour les transitions dans les niveaux où tu as un recouvrement/découvrement type "random"... La pas le choix, c'est un plan à utiliser et tu ne peux pas avoir de sprite en high priority à ce moment (d'ailleurs sur l'arcade j'ai l'impression que c'est comme ça).

Oui, je pense que l'arcade utilise un troisième plan.

ah ouais non tu peux pas du tout utiliser ça pour les transitions dans les niveaux où tu as un recouvrement/découvrement type "random"... La pas le choix, c'est un plan à utiliser et tu ne peux pas avoir de sprite en high priority à ce moment (d'ailleurs sur l'arcade j'ai l'impression que c'est comme ça).

Pour les transitions "random", a un moment je proposais d'aligner au tile le FG et le BG (scroll lors de la mort du joueur qui tombe en arrière) et de copier les tiles du FG en BG pour n'avoir qu'un seul plan pour les deux... Enfin, d'utiliser le FG libéré pour faire l'effet par dessus... Mais c'est quand même un beau bordel !

Ça marchera pas parce que certaines tiles ont des priorités et doivent fusionner avec celles du dessous du coup. Je pense pas que ça soit faisable en temps réel.

[Invité]

Tu parles du rideau rouge du bonus-stage ou des transitions en damiers ?

Pour le niveau bonus .

Pour les transitions ça risque d'être dur de la faire sur Md si tu veux être 100% identique à l'arcade .
Il faut le faire avec  des sprites, et donc sans hud (comme l'arcade), et sans le sprite du joueur (présent sur arcade,et donc le faire apparaître à un moment ou de la BP suffisante est dispo lors de la transition) ou sacrifier le second plan le temps de la transition . .

[Tryphon]

Alors pour les bonus, le problème est multiple :

1) la main n'est pas forcément centrée, alors que le rideau si. Du coup, si je fais des tableaux, il en faut un par position horizontale possible du sprite (la moitié en fait, par symétrie, mais ça fait quand même 160 tableaux)

2) d'autre part les tiles 8x8 des sprites ne sont pas alignées avec les tiles du background (qui sont celles qui guident le rideau)

3) si je veux effacer un bloc 8x8 d'un sprite, il faut que je réécrive le bitmap de la tile (alors que dans un background j'ai accès individuellement à chaque index de tile)

La solution la plus simple me semblerait de créer des sprites rouges que je passe par dessus la main, en plus de dessiner le rideau dans le plan. Je risque un sprite overflow cependant...

[TotOOntHeMooN]

Les transitions en arcade, de toute façon c'est juste pour se faire mousser avec un 3ème plan !

[Tryphon]

Je crois qu'il y en a 8 sur le system16 (c'est dingue les specs de ces systèmes pour l'époque mine de rien...) (et encore, le system16 est pas le plus impressionnant)

[TotOOntHeMooN]

Si tu détectes un 32X, tu fais les transitions !