1

Salut !

Après avoir combattu durant une bonne partie de l'après midi ce qui s'apparentait à un méchant buffer overflow, je suis tombé sur un vieux topic (topics/9-138562-un-nouveau-glouton) ou Fadest indiquait qu'on était "obligé de spécifier l'emplacement mémoire d'un array car il est déclaré en extern".

J'ai donc placé mon array de 8ko (que j'utilise pour stocker des samples) juste en dessous des 2 screen buffers (vu que je n'utilise pas de collision buffer), et, oh miracle, tout semble fonctionner maintenant.
Pour info, ca ressemble à ca :
extern char g_buffer8192[8192 at 0xa030; /* MEMTOP - (8160 * 2 )- 8192 */
Etant un minimum curieux, j'ai essayé de trouver des infos à posteriori la dessus, mais je n'ai rien trouvé.
Et ca m'inquiète un peu en fait.

1) Pourquoi le compilo ne pouvait-il pas placer de lui même mon buffer à cette adresse ?
2) Doit-on faire cela pour chaque variable extern, ou seulement pour les gros tableaux ?

Merci !

2

je sais que le 65c02 est capricieux avec les tableaux mais j'ai pas rencontré ce type de pb, même pour ouragan où y'a des tableaux assez monstrueux...
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

3

Mais ton .o faisait combien de kb?
Là mon jeu fait 27kb, sachant qu'au dessus de 40kb (0xa000) c'est réservé aux buffers screen, render et collision (n'utilisant pas les collisions, je place mon tableau à cet emplacement), il ne me restait grosso modo que 13kb pour ce tableau de 8kb. Pour peu que la mémoire soit fragmentée et que le processeur alloue un peu à l'arrache (bon après c'est mon explication...ptet que je suis à côté de la plaque).

En fait c'est le commentaire de Fadest sur son propre code qui m'a donné l'idée d'essayer. Ca a résolu le problème instantanément mais...
1) Je ne suis pas non plus 100% sûr du "fix"
2) Je me pose du coup la question de devoir (ou pas) mapper mes tableaux à la main pour éviter tout effet de bord...

4

Mon jeu faisait plus de 40ko vu qu'il a fallu que je retire le buffer render sinon ça rentrait pas...
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

5

Ok je pense avoir trouvé la véritable source de mes problèmes et je mets la solution ici pour les 5 d'entre nous qui utilisent toujours BLL/newcc65 (apparemment tout le monde est passé sur tgi/cc65 sur atari age ^^).

Le problème donc, est que sizeof semble sévèrement buggé !

J'initialise mes tableaux, structures, et tableaux de structures en utilisant memset ou bzero. A l'ancienne donc, avec quelque chose de la forme :
struct StructMuche { // Some variables }; struct StructMuche myStruct; memset(&myStruct, 0, sizeof(struct StructMuche));
Sauf que, sauf que... sizeof ne fonctionne qu'avec des types primitifs (char et int) et des variables instanciées. Si on lui passe un type complexe (en l'occurence ici une struct), il renvoie irrémédiablement 28532 (Ce qui dans mon cas me faisait un reset d'une grosse partie de la RAM). En revanche si on remplace sizeof(struct StrucMuche) par sizeof(myStruct), tout rentre dans l'ordre.

6

Merci pour le retour smile
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

7

8

Je sais que tu es attaché à l'ancien compilo Vince, mais j'ai l'impression que tu te fais du mal quand même ^^
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

9

J'ai besoin de crier ma haine, les développeurs comprendront grin

for (i = 0; i < LYNKS_CONSOLE_MAX_REGISTERED; i++); { // Something }
Toi aussi perd 2h de ta vie et viens en à douter que cc65 ne sait pas compiler un for bang

10

Ça a l'air tout mignon comme ça, mais c'est traître, un point-virgule !
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

11

Que c'est mignon tout plein, j'aime beaucoup <3

12

Visual studio c'est le bien mais en fait c'est le mal. Ca checke tellement de truc pour toi que tu perds un paquet d'automatisme des anciens temps... (et avec les messages d'erreur de newcc65.. hmm hmm :/)

13

ultraedit for the win ^^
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

14

Je suis passé sur sublimetext depuis quelque mois, moins de fonctionnalités mais ca marche au top wink