Un petit mot pour dire que je n'ai pas eu le temps de terminer le tuto d'aujourd'hui, mais que j'éditerai ce message dans la semaine à venir pour le mettre dans on intégralité.

Merci pour ce tuto. Je me suis souvent demandé comment les hacks des jeux sont créés, voilà la réponse. Par contre, j'ai essayé de faire la même démarche pour un jeu au pif sur Super Nintendo (ActRaiser) : en effet, faut vraiment connaître le jeu par coeur pour deviner où sont les morceaux de sprites que l'on souhaite changer.

A priori Tile Layer Pro lui meme ne peut pas connaitre la palette qu'utilisera tel ou tel sprite donc j'imagine qu'il ne t'empeche pas de le faire (si c'est le meme format de tile) d'ou les guillemets.

Merci pour ces deux explications claires et complémentaires.

Mais du coup ça me ramène à ma question de départ. Je ne comprends pas ce passage :


Puisque les palettes sont définie de manière dynamique à l’exécution, comment pourrait-il y avoir incompatibilité d'une tuile avec une ROM (hormis le fait qu'elle s'affichera avec les mauvaises couleurs).

Chaque sprite a le choix entre 4 palettes (que le programmeur a constitué) mais cette information la n'est effectivement pas inclus dans le tile lui meme mais dans une table d'attribut des sprites interne au GPU et donc quand tu fais ce genre de hack tu peux modifier l'agencement des pixels des tiles mais pas changer la palette car ce choix la est fait a un moment inconnu dans le programme. Cette information est noyé quelque part dans le code du jeu.
Donc oui a priori t'es obligé de faire avec la palette du sprite d'origine.

LA NES a tout instant à sa disposition 4 palettes de 4 couleurs (3+couleur transparente en fait) pour les décors et 4 palettes de 4 couleurs pour les sprites (donc 12+12+1 = 25 couleurs affichables à l'écran).
Les palettes de 4 couleurs sont définies en piochant parmi une palette générale de 54 couleurs.

Merci de partager avec nous ta connaissance de ces machines Upsilandre. Néanmoins dans le tuto d'Odysseus il n'est pas question de sprites SMS, mais uniquement NES, et il évoque bien un problème de compatibilité de couleurs.

Ce qui m'amène à me demander comment sont gérées les palettes sur la NES. Les 2 bits qui sont alloués pour chaque pixels permettent de piocher dans une palette, mais laquelle ? est-ce que chaque sprite possède sa propre palette ou s'agit-il de palettes partagées ? J'ai fait quelques recherches, mais je n'ai rien trouvé de limpide à ce sujet.

Je peux repondre aux questions si il y en a.
En tout cas ce genre de hack c'est ludique et en meme temps un bon moyen d'aborder le hardware.





je pense qu'il fait allusion au format du tile. chaque machine a sa facon de stocker l'information des pixels d'un tile en mémoire.
Par exemple sur NES c'est du 2bpp ca veut dire 2 bit par pixel soit 4 couleurs (ou 3 couleurs + transparence) alors que la Master system c'est du 4bpp (16 couleurs). Si tu veut récuperer un sprite SMS pour le mettre sur une ROM NES ca fonctionnera pas de cette facon meme si le sprite SMS utilise que 4 couleurs sur les 16 car c'est pas le meme codage.

Et d'ailleurs c'est pas seulement une question de bpp, 2 machines qui utilisent des tiles 2bpp peuvent stocker l'information dans un ordre tres different. Par exemple sur NES c'est du bitplan c'est a dire que les 8 premiers octets vont stocker le premier bit de tous les pixels du tile et les 8 octets suivant le second bit.
Mais on peut imaginer un autre format ou le premier octet contient le premier bit de tous les pixel de la premiere ligne du tile et le deuxieme octet le second bit, puis la meme chose pour les lignes suivante. Ou alors le premier octet contient les 2 bit des 4 premiers pixel de la premiere ligne et le deuxieme octet les 4 derniers pixels.
Donc meme en 2bpp on peut imaginer au moins 3 formats different de donnée et chaque fois c'est la meme information mais stocker dans des ordres differents qui empeche de pouvoir faire un simple copier-coller (mais y a sans doute moyen de convertir dans ce cas. Le plus embetant c'est quand meme de pas avoir le meme bpp)

Génial ce Groblog, merci Odysseus.

J'ai une info sympa pour ceux qui s'intéressent à ce type de hack : certaines consoles "low cost" qu'on trouve dans les magasins de jouet, supermarchés et autres solderies, vous savez ces machines laides qui embarquent des centaines de jeux, et bien elles intègrent souvent des hacks "évolués" dans le genre.
J'ai appris il y a pas très longtemps, grâce à l'excellent site Bootleg Games, que la plupart de ces bécanes étaient basées sur du hardware Famicom un peu boosté (affichage de 16 couleurs ...), la technologie Famicom / NES étant tombée dans le domaine public depuis plusieurs années déjà. Les jeux par contre sont sous copyright et il faut donc en développer de nouveaux, ce que font pas mal de compagnies basées en Asie, ou pour les plus malins / feignants faire du hack pour qu'on ne reconnaissent pas trop le jeu d'origine !

Concrètement, si vous allez dans un magasin VIMA en ce moment, vous trouverez parmi les jouets une console portable "Arcade Vision" à 15 euros. La console comporte 204 jeux, c'est une bonne affaire
Nombre de ces jeux sont des hacks : amusez vous à reconnaître le titre Famicom d'origine ! Dans les jeux d'action, il y a un sympathique jeu de plate forme mettant en scène un Panda qui saute et tape des coffres aux trésors pour recevoir des bonus. Il s'agit de Super Mario Bros (niveaux / jouabilité / gameplay 100% identiques) avec de nouveaux sprites, décors, sons et plus de couleurs. A découvrir !

Oui, voilà. Chaque ROM intègre un nombre maximum de couleur à afficher, et une palette avec des nuances précises qui peuvent varier d'un jeu à l'autre.

En gros, le jeu ne va pas pouvoir afficher une couleur qui n'existe pas dans les données de la ROM. Donc c'est la couleur par défaut qui est utilisée à la place.

En fait, il est davantage question de modifier la ROM que d'intégrer des données qui viennent de l'extérieur. Quand tu intègres un sprite externe, tu ne fais que modifier l'agencement des pixels, un peu comme des blocs de LEGO.