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.

Et donc voilà. Un registre, c'est ça. Quelque chose qui ressemble un peu à une zone de mémoire, mais qui en réalité est soit un chef d'orchestre soit un espion de ce qui se passe dans le HardWare.

On dirait bien que j'ai dessiné le "NMOS", qui "dort bouche fermée" alors que le PMOS, lui, dort "bouche ouverte" et ferme la bouche lorsqu'il voit des électoons. la technologie CMOS n'étant rien d'autre que la possibilité d'utiliser aussi bien l'un que l'autre sur le même chip de silicium.

plutôt CMOS, comme à l'intérieur des puces. PNP et NPN sont basé sur de la polarisation et plus utilisés en amplification analogique. CMOS sont plus basés sur une barrière de potentiel. Ils n'ont pas ce côté "sens unique": une fois qu'on a attiré assez d'électoons pour rendre la barrière conductrice plutôt qu'isolante grâce à la charge appliquée "sur l'oeil", je pense que les électoons peuvent traverser le "pont" dans un sens comme dans l'autre selon la différence de potentiel appliquée. (attention, je ne suis pas électronicien).

En attendant de pouvoir "montrer" le fonctionnement des registres, voici toujours le transistor ;)

même avec le texte de la version Google Drive ?

Pour ceux que le mot "registre" effraie déjà, j'ai un petit sketch de Bilou et Bouli échoué sur les plage d'adresses mémoire de la DS. La version avec le texte (manuscrit, désolé) est sur google drive. (et la page 2)

Hmm. Intéressant. C'est presque le même formattage que celle pour DS ^_^ Par contre, 2101h - OBSEL - Object Size and Object Base (W) 7-5 OBJ Size Selection (0-5, see below) (6-7=Reserved) Val Small Large 0 = 8x8 16x16 ;Caution: 1 = 8x8 32x32 ;In 224-lines mode, OBJs with 64-pixel height 2 = 8x8 64x64 ;may wrap from lower to upper screen border. 3 = 16x16 32x32 ;In 239-lines mode, the same problem applies 4 = 16x16 64x64 ;also for OBJs with 32-pixel height. 5 = 32x32 64x64 6 = 16x32 32x64 (undocumented) 7 = 16x32 32x32 (undocumented) Mais je ne saurais pas encore dire si c'est un réglage global ou local.... ah ? ... After above 512 bytes, additional 32 bytes follow, containing 2-bits per OBJ: Bit7 OBJ 3 OBJ Size (0=Small, 1=Large) On a donc droit à deux tailles par mode, et chaque sprite peut choisir l'une ou l'autre. Il faudrait que j'en lise plus avant d'annoncer que "bien sûr, on peut utiliser le truc de la reporgrammation pendant les interruptions pour augmenter le nombre de sprites à l'écran", vu qu'un des registres pour l'accès à la mémoire des sprites a l'air d'avoir un comportement un peu bizarre.

avec mes outils de tests, je compte jusqu'à 70 objets (/128 pour DS, et on dirait bien que c'est pareil sur SNES) PS: il n'y a vraiment pas moyen d'éditer ses posts, ici ?

Pour les cordes des éponges, je pense à un système avec quelques sprites avec des angles pré-rendus ... soit ça, soit des petits pointillés. Tu connais la limite de sprites affichables à l'écran ? Je sais qu'il y a une limite de 10 objets (ou quelques) dans Super Mario World, mais ça n'avait pas l'air lié au hardware vidéo lui-même ...

Pas mal de choses sont très proches entre les deux, mais c'est clair que sur SNES, ce serait beaucoup plus chaud. - le choix des langages est plus limité. Il y a bien un compilateur C, mais sinon c'est assembleur. Rien qu'assembleur et pas particulièrement pour le processeur le plus sexy. - on a nettement moins de mémoire, donc il faut ruser nettement plus. - on a moins de couleurs (des palettes de 16 alors que la DS nous en donne jusqu'à 256 par palette). - aucune idée de la façon dont on programme le son, mais ça semble moins confortable que la DS (qui fait penser à un quatuor d'Amigas survitaminés). Entre les deux, il y a la programmation GBA... Mais oui, régulièrement je me dis que si je pouvais faire tourner mon p'tit jeu sur SNES, ce serait quand même un fameux achievement. 'faudra que je regarde un peu du côté de [url=https://github.com/alekmaul/pvsneslib]ce qu'a fait l'ami Alekmaul[/i]...