Forum TI-Planet.org

Autres choses :
- En affichant 2n fois (ici, n = 1250) ton sprite en SPRT_XOR, tu l'affiches et l'effaces, donc c'est normal que tu ne le voies pas.
- VTI émule toujours une HW1, même avec des ROMs 2.0x
- Je ne comprends pas très bien de quoi tu parles quand tu dis "Tu parles du Graph buffer qui s'affiche sur l'écran qu'avec une fonction?"

Je parlais de l'écran qui n'est pas visible directement et qu'il faut copier sur le "vrai" écran. Je sais faire ça en Axe mais pas en C (j'ai toujours utilisé LCD_MEM).

Ok. En fait, quand tu récupères les adresses des plans pointés par LIGHT_PLANE et DARK_PLANE, tu as deux adresses en mémoire pointant vers des zones qui font la taille de l'écran. Et c'est le handler de niveaux de gris, mis en place dans l'auto-int 1, qui se charge d'effectuer la recopie de ces buffers vers l'écran réel (situé de manière fixe à 0x4C00). Ca, c'est sur HW>=2. Sur les HW1, c'est autre chose, de beaucoup plus simple d'ailleurs.

Donc quand tu affiches une image en niveaux de gris, il faut écrire dans ces buffers (pointés par LIGHT_PLANE et DARK_PLANE), et non directement à LCD_MEM alias 0x4C00. Et si tu veux utiliser des fonctions du TIOS (BitmapPut() etc...), il faut au préalable les rediriger avec GraySetAMSPlane(), qui est grosso-modo un alias en plus simple du romcall PortSet().

up!

Je suis allé voir dans quelques programmes et j'ai vu des variables qui étaient déclarées hors d'une fonction, au début du code. Donc je voudrais savoir si c'est possible de déclarer une variable au début du programme et si oui, quelle est sont accessibilité.
Merci!

Ce sont des variables globales, elles peuvent être utilisées n'importe où dans ton code, mais dans la mesure du possible, il faut les éviter (en fait y a des situations où on ne peut pas s'en passer, pour le reste on peut par exemple passer par des pointeurs ou des choses du genre)
Pour avoir un code propre il faut limiter le nombre de variables globales, ça peut rendre le debug plus difficile (avec une variable locale à une fonction par exemple on limite grandement la recherche du problème alors que le problème peut se situer potentiellement n'importe où avec une variable globale) (pis y avait une autre raison qu'avait évoquée Lionel mais j'm'en souviens plus ^^") ... enfin à ton niveau t'as pas trop à t'en préoccuper ...
cf mon post si tu veux plus de détails/conseils

EDIT : pour la déclaration c'est la même chose que n'importe quelle autre variable, la seule différence étant que la ligne n'est dans aucune fonction :


#include

int var_globale = 666;

void _main (void)
{
int var_locale = 42;

printf("var_locale vaut %d et var_globale %dn", var_locale, var_globale);
}

Output :
var_locale vaut 42 et var_globale 666

Les variables globales ("communication par mémoire partagée") sont en général bonnes pour l'efficacité (surtout si on utilise des switches compilateur, assembleur et linker produisant des binaires plus optimisés que les switches génériques par défaut), mais en effet pas pour le debug.

Sauf exception, les variables globales non initialisées (mises dans une section appelée "BSS", allouée au démarrage du programme) sont catastrophiques pour l'efficacité. Les variables globales initialisées, mises dans la section data, ne présentent pas ce problème.

Merci.

Pourquoi les variables en bss sont catastrophiques ? Elles sont adressées absolument, c'est très rapide, non ? Surtout qu'une BSS peut être entièrement mise à 0.

Bonjour, je voudrais savoir s'il serait possible de faire une pause d'une durée déterminée.
Merci

Pourquoi les variables en bss sont catastrophiques ? Elles sont adressées absolument, c'est très rapide, non ?

L'adressage absolu des BSS est effectivement plus lent que l'adressage PC-relatif (souvent possible avec les data, en lecture et un peu moins en écriture), mais ça n'est pas tellement à  ça que je fais référence par "catastrophique" :
C'est parce que par rapport aux data adressées en PC-relatif, les BSS référencés en absolu coûtent deux octets + la relocation par référence.

J'ai optimisé une trentaine de programmes d'autres personnes. Sauf exception, l'initialisation explicite des BSS pour les transformer en data, ou le merge de la section BSS avec la section data, étaient des optimisations taille et vitesse, parfois de plusieurs KB :
Il fallait que les BSS soient gros (plusieurs KB) pour que le passage des BSS en data augmente la taille du programme. Auquel cas, l'utilisation de l'allocation manuelle (comme c'était nécessaire pour les programmes AMS native sous TIGCC