Je ne sais pas de combien tu es "short", mais essayes ce flag pour réduire la taille de la stack, par défaut elle est à 1k je crois ce qui est excessif
link65 -m -s256
Disons qu'une fois compilée, la musique fait 6ko et que pour l'instant j'installe les modules chipper environ 4ko sous les buffets... Et que l'air de rien, le jeu prend pas mal de place aussi (36ko compilé).
Il faut que je me trouve 3 ou 4 heures de libres consécutives pour regarder plus avant le problème.
Oui, après, je peux aussi essayer sans le double buffering, mais les animations lorsqu'on marque des points risquent de faire bizarre.
Par contre, je dois pouvoir au pire faire comme Ynxa (jaisser les menus en simple buffering et utiliser le 2° buffer pour charger les assets).
Bref, plein de trucs à essayer en plus de l'optimisation de code, il me faut juste un après-midi tranquille.
Sous tes 2 buffers écrans tu dois pouvoir mettre sans trop de problème un buffer de 8k
#define LYNKS_SCREEN_ADDRESS 0xe010 /* MEMTOP - 8160 */
#define LYNKS_RENDER_ADDRESS 0xc030 /* MEMTOP - 8160 * 2 */
#define LYNKS_MAX_FILE_SIZE 8192
#define GAME_BUFFER_ADDRESS_8192 (LYNKS_RENDER_ADDRESS - LYNKS_MAX_FILE_SIZE)
Hormis si tu garde les images d'intro et de hiscore en RAM, vu que ce sont juste des petites tiles qui constituent le jeu, tu devrais avoir assez de RAM pour une grosse zik.
Autre possibilité, c'est relativement facile de "compresser" les zik chipper en coupant des patterns ou un channel. Ce qui prend le plus de place ce sont surtout les changements d'instrument à la volée.
Oui je pense que ça devrait aller (bon déjà vendredi, j'ai vu que sur ce PC, je n'avais pas modifié MEMTOP dans lynx.h donc je gagne quasi 1ko de mémoire)
Je dois surtout modifier les routines chipper car là, elle utilisent 0xAC00 comme adresse, donc ça ne laisse pas 6ko jusqu'à l'adresse du 1° buffer écran
Hésites pas à utiliser la vue RAM dans Felyx, ca m'a pas mal sauvé la vie pour optimiser les placements mémoires.
- première partie)
