PypeBros

Merci. Ce n'est pas encore au programme. D'abord parce que je n'ai encore jamais vu de cartouche "retro" pour la DS. Ce serait probablement plus facile avec du GBA dans la mesure où ce n'est pas illégal dans certains pays, mais pour la DS, les gens de chez Nintendo ont mieux étudié la législation internationale sur les contrefaçons. Et clairement, un "cease & desist" est le dernier truc que j'ai envie de me prendre.

pour la p'tite histoire, j'ai un peu parlé d'adaptation sur SNES avec les gens de nesdev ça serait quand-même bien chaud - un plan de décor de moins (et j'ai pas envie de laisser tomber mon hibou ni de passer à de l'encre toute plate - moitié moins de palettes - moitié moins de piste audio (enfin, ça, c'est l'affaire du frangin). Bref, c'est pas pour 2018.

Eh oui. Je vais me refaire quelques nouveaux outils et réviser deux ou trois trucs dans mon moteur de jeu maintenant. Merci. Amuse-toi bien ;) Les retours sont toujours les bienvenus, même si pour être franc il y a peu de chances que je m'attaque à de nouvelles modifications sur School Rush à ce stade.

et voici la version finale (lien direct). Après 5 ans de développement, il est enfin fini. Le jeu ayant été commencé en octobre 2013 et fini en novembre 2018, il me semble qu'on a une preuve empirique de plus pour la règle des 20-80.

le lien github a l'air un peu mort, malheureusement.

Tiens, au passage, vous connaissez la série de vidéo "splash wave / making of" ? Ils ont un épisode sur et sur , justement.

il doit y avoir une zone mémoire qui fait office de (dé)compteur du temps restant à afficher l'intro, à mon avis. Si tu trouves l'adresse de cette zone-mémoire, tu pourras identifier le code qui la met en place, et remplacer sa valeur initiale par 1 ou 2, de sorte que le jeu passe directement à la suite.

merci, ça fait plaisir à entendre. Avec la "communauté" des fans de Bilou aussi éclatée, c'est un peu crevant d'annoncer les nouvelles releases. Tiens, au fait, il est toujours d'actualité, ton compte twitter ?

Avant-dernière mise à jour avec un chronomètre et un pixelomètre pour se mesurer les uns aux autres. Entrainez-vous bien: la prochaine, il y aura moyen d'enregistrer ses scores ;) Ah oui. On sait reprendre des vies, aussi.

un pas en avant, mais loin d'être une solution, en somme.

ça ne compte pas, j'imagine ...

ça a piqué ma curiosité, donc je suis allé voir le lien. La technique décrite fait fort penser aux 'burst transfers" entre les DRAM et le CPU intel des PC de la fin des années '90. On ne transmet plus un mot mémoire, mais toute une ligne de cache à la fois. C'est effectivement difficile à reproduire avec une ROM ou une flash, mais par contre, ça fait penser aux linkers DS (et GBA?) qui étaient équippés d'une mémoire vive dans laquelle ils chargeaient le jeu à partir de leur carte SD avant d'en démarrer l'émulation. Mais oui, si l'idée est "je vais reprendre la cartouche de Superman 64 et changer cette puce-ci par un composant programmable pour me faire un Zelda:OOT à la place, ça paraît mal embarqué. Eventuellement un FPGA, mais je ne crois pas qu'il y en ait de la bonne taille, donc il faudrait un mini-pcb avec une flash et un FPGA ... façon "cpu modding d'amiga".

Bon, bien sûr, là, on est dans le cas idéal des "registres mappés en mémoire". La DS a un bus d'adresses 32-bit (4Go) contre seulement 4Mo de mémoire physique et moins d'1Mo d'adresses utilisées pour la communication avec le reste du hardware. Donc dès qu'on a besoin d'un registre pour la couleur du fond, la longueur d'un sample sonore ou le niveau de transparence du plan 2, on utilise une adresse rien que pour ça. Du coup on se retrouve avec des choses du genre BG_PALETTE_SUB[4]=RGB(16,0,16); SCHANNEL_LENGTH(4) = 0x42; REG_BLDALPHA = 0x1008; Même pour la mémoire vidéo, l'entièreté des 640Ko est directement accessible au CPU. Comparativement, sur les console 16-bits, La quantité de mémoire disponible se compte en poignées de 64K. On va donc retrouver quelques traces d'un "truc" indispensable sur les systèmes 8-bit: une paire "registre d'adresse, registre de données" pour chaque composant annexe. Ainsi, pas question d'écrire directement dans la palette de couleur de la Mega Drive depuis le 68000. On doit indiquer dans le registre de données du PPU notre valeur "RGB(16,0,16)", puis l'équivalent de BG_PALETTE_SUB dans le registre d'adresses du PPU (ou dans l'autre ordre, notez bien: je ne fais pas de la programmation MD pour de bon). Cette fois-ci, la logique derrière ces deux registres aura pour effet d'aller modifier un troisième registre du PPU pour qu'il retienne la bonne couleur.

héhé. Justement, le graphisme DS, c'est un peu comme un de la mosaïque de carrelage ^_^

C'est correct pour les registres internes de l'unité arithmétique du processeur. Les registres de calcul, en somme. Mais pour la plupart du reste d'une console (registres vidéo, registres d'entrée/sortie, registres son, etc), ils se trouvent en réalité en-dehors du processeur. On y a accès (depuis le processeur) à travers le bus mémoire. le CPU de la SNES ne sait pas s'il écrit dans un registre du chip graphique ou dans une cellule de sa RAM. Mais le registre dans le chip graphique a bel et bien une "face cachée" qui va être utilisée pour la logique de rendu des images. Sa valeur n'est pas utilisée uniquement par la logique "interface avec le bus mémoire" mais aussi pour les besoins internes du chip: activer ou désactiver les bons transistors. Ils utilisent la même technologie de mémoire à accès rapide, mais seulement du point de vue de la logique qu'ils contrôlent. Le PPU de la SNES doit pouvoir tester lire très rapidement (et très souvent) la couleur de fond, par exemple. Du point de vue du programme sur le CPU, il faut passer par le bus mémoire, attendre que la logique de gestion du bus dans le PPU réagisse, etc.