logo

Ces pages ne sont plus mises à jour !

Mais restent ici quand même. Attention: tout est vieux, et parfois faux. Tout se passe maintenant sur la wiki NeoGeo Development Wiki

Préface et documents
Architecture
Spécifications résumées
Architecture, Memory Map
BIOS
Structure des ROMs
Structure des CDs
Registres RAM
Vidéo
Système vidéo
Les palettes
Le fix
Les sprites
Audio
Système audio
Communication Z80
YM2610: ADPCM et SSG
Les pistes CDDA
Developpement
L'ASM 68K
Outils
Devkit ASM
Erreurs courantes
Portage MVS / NGCD
Electronique
Electronique
Cartouche flash MVS
Problèmes de lecteur CD
Productions
Astrosmash
Unleashed
Knackiballs
Bootloader et cable NGCD

Test MVS #01

12) Making of d'Unleashed

"Making Of" écrit en même temps que le "Making"...
Journal de bord:

11/02: Oups, faut que j'avance...

21/01: Le moteur d'animation commence à être utilisable et la sortie vidéo commence à ressembler à ce que j'avais sur AE.
Les couleurs sont pas encore les bonnes puisqu'il va encore y avoir des changements de palettes, et certaines couleurs sont là pour aider au debug.

Le fix est d'ailleurs utilisé pour le debug, c'est toujours plus simple que de suivre ligne par ligne ce qui se passe dans le debugger qui n'a même pas de breakpoints, en cherchant où se trouve telle ou telle donnée (pas d'importation de symboles depuis JAS non plus).

20/01: Je suis resté un moment sur un problème avec la routine de chargement de sprite, elle chargeait toutes les valeurs sauf la hauteur du sprite (elle restait à zéro). Après avoir réglé ce problème, tout fonctionnait. Le moteur est capable de régler la vitesse de lecture de son script, charger des sprites selon des tables d'attributs, de lire des samples via le driver Z80 de MVSTracker, "nettoyer" des sprites, charger des palettes, et faire des fondus au noir sur n'importe quelle couleur.

Gros pitfall de merde: au moment de calculer l'adresse absolue d'une valeur dans une table de déplacement à partir de son adresse de départ et d'un offset, problème de décalage et mauvaises valeurs (décalage d'un octet sur des mots). Problème: données pas bonnes, valeurs pour les X des sprites pas <<7, ce qui faisait croire que l'octet bas était bon... Parfois c'est les données qui sont pourries, pas les routines.

19/01: Écriture des quelques routines qui risquent de servir pour le debug: affichage de texte et de valeurs en RAM sur le fix. Passé du temps sur une débilité dans le fix de SSideki: Voilà pourquoi des moments il faut pas remettre que sa routine d'affichage de texte en question.

Je sais pas trop ce qu'ils ont fabriqué... Soit ils ont jamais utilisé le "b" ni le "d" dans les textes du jeu, soit ils ont fait l'inverse dans les chaînes parce qu'ils pouvaient plus modifier le fix pour telle ou telle raison. Étrange mais ça m'a tenu 20 minutes à me demander ce qui allait pas dans mon code.

 

18/01: Longue nuit sur la synchro, qui a finit par marcher. Routine de lecture de table bien partie. Découpage et conversion des 8 samples terminée. Le moteur arrive juste à lire une table à vitesse constante (avec des pas plus courts que la durée entre deux VBL), mais des soucis de bruit dans les samples.

Batards d'overlap de samples qui font des "clics" bien forts. Peut être dû au pas de 256 octets du YM2610 ?
Il faudrait caler chaque mesure sur 256 octets alors (stretch ?)

(Sortie son de Kawaks)

 

15/01: Tombé sur une séquence bien méchante en écoutant di.fm/breaks: Bit On The Side - My Immortal, commencé à faire quelques brouillons.
16/01: Commencé un projet After Effects pour mettre à plat les idées et le découpage du sample pour gagner de la place.
17/01: Logo scanné et colorisé, 32 premiers beats remplis dans AE et quelques idées pour la suite. Commencé à écrire un petit moteur en asm.

Screenshot venant d'After Effects, techniquement réalisable sur NeoGeo.
Utilisation du fix pour la bordure noire.

Nombre de samples: 8 (V1 de 250Ko)
Longueur de la séquence: 16 segments de 8 beats (124 beats soit 32 bars) à 165BPM

footer
symbol symbol symbol symbol symbol