Petits problèmes avec - Page 2

content que ca marche

(et si tu as pris le temps de faire comme je t'ai dit (code dans des .c) tu y gagneras vraiment, ca sera plusrapide à recompiler et tu pourras mieux organiser ton code)

oui, je sais, tu viens pour un problème et je te donne une solution pour un autre problème

Au contraire ca permet d' ameliorer mon code !

Hum en fait a la fin (pour le.c .h et autre), j' ai viré toute les include dans mes .c (sauf celle du.h ) pour les mettre dans CHAQUE .h (je me retrouve donc avec 3 include pour chaque.h), si je ne le faisait pas mon fichier app.h ne reconnaissait plus les sprites . C' est la bonne solution ou y en a des meilleurs ?

uploade moi tout ca plutot ^^
je pourrai mieux te répondre

Ok: http://membres.lycos.fr/nanarduff/fly.tar.gz

ca ne sert à rien de séparer dans des dossiers differents les h et les c, ca ne fait que compliquer les inclusions
on fait plutot les séparations par modules

met aussi tes sprites dans un .c, ce ne sont pas des déclaration mais des données !
en gros tu ne dosi mettre dans un .h que ce qui ne génèrera pas un seul octet dans ton programme (contrairement à du code ou des données)

sinon oui tes inclusions sont correctes

Mais:

extern unsigned char Svaisseau[];

n' est pas une declaration ?

Nu :
tu ne dois mettre dans un .h que ce qui ne génèrera pas un seul octet dans ton programme

Donc plus précisément, toutes les déclarations de fonctions, de variables "extern", de types, de structures et d'énumérations, et les définitions de macros et de fonctions "static inline".

Nanar_duff :
Mais:

extern unsigned char Svaisseau[];

n' est pas une declaration ?

oui c'est bien une déclaration

heu je viens de regarder ton archive, tu l'as changée depuis ? parceque si ca se trouve je t'ai dit une connerie car il y a bien un sprite.c et un sprite.h
(j'ai du ouvrir une ancienne version qui trainait sur mon, bureau)

Non, c'est bon, j' ai rien changer

bon ben j'ai regardé une ancienne version, j'ai rien dit donc

Donc tout est bon ? (a part les dossiers mqais je laisse ca comme ca pour l' instant c'est plusclair pour moi )

oui, c'est mieux
mais n'utilise des variables globales que quand c'est vraiment nécéssaire, là elle le sont toutes...

Bof, les globals ne sont en général pas une mauvaise idée. C'est beaucoup plus efficace que de tout passer à chaque appel de fonction (TI-Pinball - surtout NE PAS faire ça).
L'option de compilation -freg-relative-an (n=4 ou 5) est ce qui donne en général le code le plus efficace, mais ça ne fonctionne pas si les BSS ne sont pas mergés avec la section data (mais sauf exception - programme mal écrit - les BSS sont mauvais en taille et vitesse).

Pour faire un petit programme tout seul les variables globales ça peut être rigolo, mais le code perd en lisibilité et maintenabilité, en général. Après travailler à plusieurs sur du code truffé de variables globales c'est pas glop. Sans parler de l'élégance du code
(et aussi ça génère du code moins réentrant)

Certes, mais n'étant pas multitâche, on n'a pas de réentrance sur nos machines.
L'élégance du code, on s'en fiche légèrement - si on devait faire de la programmation structurée en permanence, ça serait triste...

Lionel Debroux :
Certes, mais n'étant pas multitâche, on n'a pas de réentrance sur nos machines.

Si, avec Opale
Enfin, ça reste une mauvaise habitude à ne pas prendre s'il souhaite coder sur autre chose que sur AMS plus tard...

L'élégance du code, on s'en fiche légèrement - si on devait faire de la programmation structurée en permanence, ça serait triste...

Je ne suis pas d'accord ici non plus ; je trouve plus agréable de lire un joli code. Même si élégance ne va pas toujours de pair avec performance...

Multitâche ou pas on peut toujours vouloir faire du récursif par exemple.