Re: Shinobi 1 sur MD

[ace76]

Justement je crois que Stef connaît la combine, manquait pas grand chose pour pouvoir étendre la palette a 4096couleurs.

[Stef]

Non ça n'a rien à voir avec le Mega-CD qui passe toujours par le VDP de la MD. Et quand je parlais de 4096 couleurs, je parlais de la master palette (RGB444)... Quand tu programmes sur MD, tu vois qu'elle a été pensée initialement pour avoir 4+4 palettes (comprendre 4 palettes pour les background + 4 palettes pour les sprites) sur une master palette de 4096 teintes (RGB444) et que pour des raisons de cout ils ont coupé à 4 palettes partagées sur du RGB333. Le RGB333 passe encore mais les 4 palettes partagées c'est vraiment chaud :-/

D'ailleurs on a enfin des photos du VDP de la MD:



Ca fait longtemps qu'on veut savoir à quel point la CRAM consomme de l'espace à l'intérieur du chip :p

[philip]

C'est là le cœur de la MD, merci Stef ! Il existe une image plus grande ?

Pour Shinobi MD, ma recherche sur la mise en couleur est terminé,  bientôt le résultat ici !

[Tryphon]

Je suis impatient de voir ça ! J'espère avoir un peu de temps demain pour pouvoir travailler moi-même !

[upsilandre]

De toute facon prenez votre temps sur cette étape, c'est un point central du portage

[Stef]

Clair :) le point le plus critique assurément...

[Tryphon]

Non. Les points critiques c'est les performances du moteur et le gameplay.

Que le jeu soit beau ou moche n'arrive qu'après. Arrêtez de vous comporter comme des SNESophiles pour qui le fait de bien présenter sur les photos suffit à faire un bon jeu. Pas vous

[sebnec]

C’est formidable de suivre vos discussions sur les palettes de couleurs. En ignare total en développement, je trouve cela fascinant. Mes félicitations pour le boulot accompli jusqu’a présent, et merde pour la suite !

Tryphon, j’espère que tu pourras implémenter le bug sur les ennemis au bazooka (quand on les coince contre un mur, et qu’ensuite plus aucun ennemi ne peut utiliser d’arme de jet). Il m’a toujours fasciné :

[antifrog]

Tryphon, j’espère que tu pourras implémenter le bug sur les ennemis au bazooka (quand on les coince contre un mur, et qu’ensuite plus aucun ennemi ne peut utiliser d’arme de jet).

[Tryphon]

C'est prévu

[F.L]

C'est un peu dommage d'y integrer ce bug... mais bon je comprends la démarche: identique a l'original jusqu'au bout

[Tryphon]

Il ne sert que dans deux tableaux, et personnellement, je ne m'en sers plus. De plus, il ne sera pas présent dans tous les modes de jeu.

[Stef]

Tu as mal compris Tryphon :-p
Quand je parle de point critique, je veux dire par là que c'est la partie la plus difficile pour moi quand tu portes un jeu comme celui ci sur MD. Perso question performance, je dis pas qu'il n'y a pas de travail mais on est pas sur SNES et je pense qu'on peut espèrer un port assez fidèle sans de concessions sur le nombre de sprite ou leur taille, même en restant en C et sans passer par des astuces de sioux.. par contre graphiquement les 4 palettes sont un challenge quand même..

[Invité]

je suis curieux de savoir comment tu vas t'y prendre avec les magies, Tryphon. les caser dans une MD me semble être un sacré exploit.

[Tryphon]

Tu as mal compris Tryphon :-p
Quand je parle de point critique, je veux dire par là que c'est la partie la plus difficile pour moi quand tu portes un jeu comme celui ci sur MD. Perso question performance, je dis pas qu'il n'y a pas de travail mais on est pas sur SNES et je pense qu'on peut espèrer un port assez fidèle sans de concessions sur le nombre de sprite ou leur taille, même en restant en C et sans passer par des astuces de sioux..

Je peux me tromper mais je crois que tu sous-estimes franchement la situation.

J'essaie d'animer jusqu'à 8 sprites dynamiques (plus quelques statiques). Aucun homebrew à ma connaissance ne fait ça (la plupart des platformers homebrew MD que j'ai eu l'occasion de voir ne dépassent pas les 3/4 sprites à l'écran - projectMD, le Pingouin de chillywilly, et les quelques WIP - ; Papi fait plus mais les sprites sont petits - et c'est pas un platformer).

Le jeu commercial le plus proche est Shadow Dancer, et il affiche à ma connaissance 5 sprites dynamiques grand max, Musashi inclus (et ils sont plus petits : le moteur leur alloue 32 tiles par sprite, contre 48 pour moi, à cause des gardiens et bazookas). Et ils sont légèrement plus petits que ceux de Shinobi. Les SOR ont des sprites statiques, à part les joueurs (et c'est beaucoup plus facile à gérer parce que les niveaux progressent par blocs).

Non sérieusement, la phase critique (au sens de : "c'est maintenant qu'on saura si ça passe ou ça casse"), ça sera le moteur. J'ai bon espoir, mais je suis toujours pas sûr. Bon après c'est toi le pro et ça rassure quand tu dis que ça passe easy.

J'aimerais bien finir la mise en couleur vite fait pour pouvoir m'y atteler...

[Tryphon]

je suis curieux de savoir comment tu vas t'y prendre avec les magies, Tryphon. les caser dans une MD me semble être un sacré exploit.

Qu'est-ce qui te semble si difficile ?

[Invité]

Salut Tryphon,
Puisque tu te poses des questions quant aux performances du SgdK en full C et vue que tu mentionnes Papi Commando, je peux te réconforter sur la performance à envisager pour faire tourner ton projet.

Dans Papi Reload, j'arrive à animer plus de 8 sprites de 32x32 ( et même plus avec du 48x48 pour la Jeep et 64x64 avec le Train ), les projectiles ( 8x8 ), les grenades ( 16x16 ), le friendly fire, l'IA de base, les collisions etc ... Et en full C en utilisant que des pointeurs de structures. Stef pourra t'en dire plus la dessus, vu qu'il a collaboré avec moi sur ce projet.

Je ne connais pas assez le jeu d'arcade d'origine, mais vu ce que j'ai aperçu au grès de tes vidéos sous Python, c'est très largement faisable.

[fanoplusplus64K]

Je peux me tromper mais je crois que tu sous-estimes franchement la situation.

J'essaie d'animer jusqu'à 8 sprites dynamiques (plus quelques statiques). Aucun homebrew à ma connaissance ne fait ça (la plupart des platformers homebrew MD que j'ai eu l'occasion de voir ne dépassent pas les 3/4 sprites à l'écran - projectMD, le Pingouin de chillywilly, et les quelques WIP - ; Papi fait plus mais les sprites sont petits - et c'est pas un platformer).

Tu les animes à chaque frame (50/60 hz) ?

[philip]

Je récapitule les problèmes avec la version actuelle de Philip (parce qu'on les a peut-être perdus de vue) :

1) le découpage en deux palettes n'est pas possible (trop coûteux en VRAM) ; donc l'otage et le gardien rose sont à reprendre

2) il manque : le bazooka vert, le moine

3) peut-être éclaircir légèrement les marron(s).

research_colors-black.bmp

Salut, le bazooka vert est ici, à moins qu'il existe une deuxième version du même personnage ? Le moine et uniquement présent dans la mission 5-3, me trompe-je ? J'ai laissé l'oiseau vert, j'aime bien, mais tu as la version rose plus bas avec l'otage et le mogol.

research_colors-6f.bmp


testplayer-2a2.bmp

Finallement, je n'ai pas réussi à réduire la mise en couleur de joe, mais j'ai trouvé une solution simple, voir ci-dessous.
Rajout du chef Ken Oh, pour sa boule de feu voir l'image précedente.

test_bot2.bmp

Pour les décors background (du layer B), passage de 6, à 5 couleurs, cela reste très correct puisque ces fonds sont moins travaillés par rapport à d'autres jeux, comme dragon ninja par exemple.
Donc une nouvelle couleur, le blanc, utile pour la peau et le sabre, et j'ai remplacé la couleur rouge, devenu inutile ici, par un nouveau rose, et donc désormais le mogol rose est ici (et une autre version avec un pantalon marron). Pour la mision 1-1, la version avec le pantalon gris est donc tout indiqué.

test rapide devant/derrière la barrière, des personnages :
final-allpersonnages.bmp

[Invité]

Ca a vraiment de la gueule.
Super boulot Philip !!! 

[philip]

Ca a vraiment de la gueule.
Super boulot Philip !!! 

Merci, j'ai tout donné ! J'ai les yeux bien explosé aussi, hum.
(j'ai aussi le stage 5-1et le moine, mais est-il présent ailleurs dans le jeu ?... j'ai besoin d'une confirmation à ce sujet)

[Tryphon]

Uniquement en 5-3 le moine. On peut se débrouiller avec l'arrière-plan, vu que ce niveau est sur un seul plan.

(plus de précisions plus tard)

[Tryphon]

Bon, tout d'abord, merci infiniment

research_colors-black.bmp

Salut, le bazooka vert est ici, à moins qu'il existe une deuxième version du même personnage ?

Le bazooka existe effectivement en deux versions, l'une plutôt bleue (qui tire des roquettes horizontales), l'autre plutôt verte (qui tire des boules paraboliques ; on le trouve en seulement deux exemplaires, au 3-1 et au 3-2). Si on ne parvient pas à le rendre avec ces deux palettes, c'est un ennemi tellement rare que ça ne sera pas trop grave si on change sa couleur.

Le moine et uniquement présent dans la mission 5-3, me trompe-je ?

Point ne te trompes-tu. Comme dit plus haut, si c'est nécessaire, on peut utiliser la palette de l'arrière-plan, puisqu'il n'y a pas vraiment d'arrière plan ici.

J'ai laissé l'oiseau vert, j'aime bien, mais tu as la version rose plus bas avec l'otage et le mogol.

Parfait. Je préfère utiliser la version arcade, mais du coup j'utiliserai ta version comme ennemi supplémentaire dans un tableau exclusif à la version MD !

Rajout du chef Ken Oh, pour sa boule de feu voir l'image précedente.

test_bot2.bmp

Excellent. Je pourrai donc le faire apparaître en fin de mission (c'était une particularité de la version arcade que je ne pensais pas reproduire).

Pour les décors background (du layer B), passage de 6, à 5 couleurs, cela reste très correct puisque ces fonds sont moins travaillés par rapport à d'autres jeux, comme dragon ninja par exemple.

C'est moins vrai pour le 3-1, 4-1, 5-1 : ces 3 niveaux ont le même arrière-plan (les montagnes) avec des couleurs légèrement différentes, ce sera un peu plus difficile de le rendre en 5 couleurs, mais on va essayer.

Donc une nouvelle couleur, le blanc, utile pour la peau et le sabre, et j'ai remplacé la couleur rouge, devenu inutile ici, par un nouveau rose, et donc désormais le mogol rose est ici (et une autre version avec un pantalon marron). Pour la mision 1-1, la version avec le pantalon gris est donc tout indiqué.

test rapide devant/derrière la barrière, des personnages :
final-allpersonnages.bmp

Pour les autres missions, il y a des niveaux sans arrière-plan (donc on fait ce qu'on veut avec cette palette) et d'autres où l'arrière-plan contient une variété de gris, parfois plus clair, on essaiera de jouer avec. Puis quand c'est pas possible, on peut utiliser le mongo vert avec l'AI du rouge, dans la plupart des versions ils ne sont pas différenciés.

J'ai pas mal de boulot en ce moment, plus un déménagement en cours, mais je vais essayer de mettre en couleur les décors, et de faire une petite ROM de test.

[Tryphon]

Tu les animes à chaque frame (50/60 hz) ?

Théoriquement, oui. Certaines animations durent un nombre impair de frames, d'autres un nombre pair, ce qui fait qu'il peut arriver que tous les sprites aient besoin de changer de pose à la même frame.

Du coup j'ai implémenté une limite qui empêche à plus de trois sprites de changer de pose. Si on dépasse, la pose ne sera modifiée qu'à la frame suivante. C'est très peu visible en pratique.

Mais ce qui m'embête, c'est que la structure même du jeu (tu peux repartir en arrière) m'oblige à vérifier certains ennemis même s'ils ne sont pas présents à l'écran (car ils peuvent respawner, ou au contraire ils ne le doivent pas), ce qui fait que même s'il n'y a que 8 persos à l'écran, il peut y en avoir 16 qui sont "actifs" (sur environ 32 dans un tableau). C'est du temps CPU parce qu'un ennemi "actif" a une fonction callback qui est appelée, ce qui doit se traduire en asm par un "jsr xx(a0)", qui est certainement super lent. Quand j'implémenterai, je pense que les fonctions de respawning seront déportées de la fonction callback vers la partie du moteur qui l'appelle, pour éviter des jsr cracra.

Plus généralement, je me dis que beaucoup de trucs qui devraient se faire via :

Code:

void ma_fonction(...) {
    if (blabla) {
        /* fais des trucs */
    }
}

va devenir du :

Code:

void ma_vraie_fonction(...) {
    /* fais des trucs */
}

inline void ma_fonction(...) {
    if (blabla) ma_vraie_fonction(...);
}

histoire d'économiser un appel si pas nécessaire.

Bon, après, j'angoisse moyennement : si ça passe pas en SGDK, ça passera en ASM. Mais ça sera plus long !

[F.L]

Que c'est beau de suivre pas à pas un projet comme celui-ci !
C'est pas l'ami fonzarelli qui nous aurait fait ça !

[Metalik]

Petit HS, mais pas tant que ça.

Ce qui me surprend, c'est cette difficulté de faire Shinobi 1 sur Megadrive. Comment Shinobi 1 avec ses couleurs ternes, sont gameplay basique, et sont nombre de sprites si peu impressionnant peu poser problème à la Megadrive ?

Quand je constate les merveilles, et les prouesses technique qu'il y a eu sur Megadrive, je ne comprend pas pourquoi Shinobi 1 est si difficile à adapter.

Le plus impressionnant dans le débat actuel, c'est qu'il concerne maintenant le nombre de couleurs. Et là, je bug...

Comment la Megadrive, qui est capable d'accueillir des beautés graphiques, et technique, reste bloqué sur la palette de couleur de Shinobi 1, pourtant bien terne ?

Si vous regardez les jeux Disney, les Sonic, des jeux comme Rocket Knight, Ristar, Thor, Flink, etc... Jamais il ne vous viendrait à l'idée que Shinobi 1 puisse poser problème ne serait ce qu'en matière de couleurs... Pourtant ça semble le cas...

Je trouve le constat assez dingue.
-Shinobi 1 sous des allures de jeu terne et peu coloré utilise plus de couleurs que la Megadrive...
-La Megadrive avec ses limitations, est arrivé à faire au moins illusion pour proposer des tas de jeux bien plus coloré que Shinobi 1.

Le monde du hardware et de la programmation, est définitivement un mystère.

[corben]

tu as une mauvaise idée de shinobi, ce n'est absolument pas un jeu terne. Les niveaux sont très colorés. les couleurs choisies ne sont pas flashy mais elles sont bien là. plus on avance plus on sent des couleurs différentes. de plus leur utilisation est excellente dans le sens où il y a vraie harmonie tout en mettant en place des niveaux très différents les uns des autres

[Metalik]

tu as une mauvaise idée de shinobi, ce n'est absolument pas un jeu terne. Les niveaux sont très colorés. les couleurs choisies ne sont pas flashy mais elles sont bien là. plus on avance plus on sent des couleurs différentes. de plus leur utilisation est excellente dans le sens où il y a vraie harmonie tout en mettant en place des niveaux très différents les uns des autres

Sans doute. Mais attention, je n'ai qu'un regard de joueurs. Alors comparons:






Comment est ce possible Shinobi 1 paraisse aussi "basique" et "terne" Quand Shinobi 3 parait mieux en tout alors qu'il est soit disant moins technique ?

[Invité]

Sans doute parce que tu n'as, sans doute, jamais réaliser un jeu vidéo de A à Z ?
Je ne sais pas si c'est intentionnel ta manière de débattre et d'envoyer des pics qui sont au final peu productifs et provoquants.
Nous somme sur des projets amateurs avec tout ce que cela comporte souvent l'oeuvre d'une seule personne qui réalise ça sur son temps libre.
Oui les jeux produits dans les années 90 sur les 16 bits furent magnifiques réalisés par des studios Pros sous licence constructeur et on peine aujourd'hui à faire aussi bien sinon pire.
Ici, c'est un travail d'adaptation qui se veut le plus fidèle au jeu d'arcade original et non un remake inspiré de.

Alors un peu de respect de grâce Goofy ... ici on se sert les coudes, on s'encourage, on se chambre souvent mais au final, on fait les choses du mieux que l'on peut et on stimule cette synergie qui fait vivre notre passion.

[fanoplusplus64K]

Sans doute. Mais attention, je n'ai qu'un regard de joueurs. Alors comparons:

Ce n'est pas tant le nombre de couleurs, c'est juste que les gfx sur MD sont plus détaillés.

[upsilandre]

Sans doute. Mais attention, je n'ai qu'un regard de joueurs. Alors comparons:






Comment est ce possible Shinobi 1 paraisse aussi "basique" et "terne" Quand Shinobi 3 parait mieux en tout alors qu'il est soit disant moins technique ?

C'est en gros la différence entre un jeu calibré pour une machine ou tu construis tes palettes en connaissances de causes et avec ton expérience cumuler de pixelartiste sur la machine, ou tu choisie aussi la répartition des ennemis et la progression dans les levels de facon judicieuse pour contourner les limites. Et le portage d'un jeu d'une machine sur une autre complètement différente.
PS: et j'ai pas bien compris le rapport entre couleur terne et nombre de couleurs