-
Compteur de contenus
60 -
Inscription
-
Dernière visite
-
Jours gagnés
2
Messages posté(e)s par PypeBros
-
-
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.Oh, ça fait drôle de se dire que le dev de Bilou est terminé, je m'en vais tester ça ce soir :)
(Reste à retrouver ce bon vieux R4... et sa SD de 4Go, whaou !)
Merci. Amuse-toi bien ;)Félicitations pour l’aboutissement de ton projet.
Je vais tester ca rapidement, il a l’air vraiment sympa.
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.Je dirais 80% d'un jeu qui comptera 4 niveaux principaux et un niveau final en mode "normal" ou "hard". Il me manque principalement les bonus-tuto pour permettre aux joueurs de découvrir les variations du gameplay et les petits effets qui font que le joueur peut "ressentir" au mieux son personnage (petits nuages de poussière, bruits de lancer, etc.)
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.
-
Les Zelda-like
dans Les Tests
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.
-
toujours plaisant de voir le suivi, merci
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 ... -
La puce qui contient le jeu contient aussi d'autres infos propres à l'envoi de données. L'envoi se fait apparemment par paquets et non plus une à une... Bref, je n'y connais pas grand-chose à part que ça semble impossible à reproduire pour le moment. Pour les jeux N64, il y a un everdrive 64.
Pour les infos concernant l'impossibilité et l'adressage en parallèle (en anglais)
Infos glanées sur le net, il y aura sans doute des erreurs ou une mauvaise interprétation de ce que j'ai lu mais ce dont je suis sûr c'est qu'on attend toujours les hacks, la scène homebrew et les cartmods 64 et on a pas fini d'attendre...
ç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.
-
ça a l'air sympa ! quand j'aurai fini avec le papier peint les tournevis et le carrelage, j’essaierais la bête !
héhé. Justement, le graphisme DS, c'est un peu comme un de la mosaïque de carrelage ^_^
-
Je croyais qu'un registre était juste une mémoire à accès rapide et ne pouvait pas interagir avec d'autres circuits ?
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.
-
-
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.
-
Transistor pnp ou npn ?
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). -
-
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 ?
-
Porter bilou sur snes, il faudrait au moins utiliser le super fx pour faire les effets de balançoires des petits nuages jaunes...
T'es doué, c'est sur, mais il faudrait aussi revoir le nombre d'ennemis à l'écran à la baisse !
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]...
Bilou dans l'école en Folie
dans Générale
Posté(e) · Signaler la réponse
Merci.
Et clairement, un "cease & desist" est le dernier truc que j'ai envie de me prendre.