[Pitt]

Pitt, intéressant ce que tu dis Donc en gros, je n'aurai 'pas du' corriger la déclaration de structure de t4ils et mettre mon typedef, il ne sert à rien ?

Et bien en gros, tu peux écrire ça sans problème en C99 :

Code

(c):
struct monType
{
    ...
};
 
monType maVar;

Perso je suis pas trop pour l'utilisation du C99, parce que ça dénature un peu le C à mon goût : supprimer les typedefs de struct/enum/union, pouvoir déclarer des variables locales à des boucles ou n'importe où, déclarer des tableaux de taille variable, etc je trouve qu'on s'éloigne vraiment du concept originel du C.
Après c'est sûr que ça ajoute un petit peu de facilité, mais bon, je trouve pas ça indispensable.

[Arcadia]

 

Et bien ma foi, y'a pas à dire, je dois une fois de plus saluer cette initiative. Je vais essayer une bonne fois pour toute de piger concrètement le principe des pointeurs  .

Merci Mollusk ! 

Ok, j'ai la palme du pire titre de section jamais écrit

Heu...non, je pense que j'ai fais pire, certes pas ici, mais j'ai fais pire  ...

[Toiletking]

Yop!

Voila un tuto super intéressant!

Et moi qui voulait lancer la vague des hombrews "pointer-free" (sans pointeur) et ben c'est raté! 
Avec la palib, on peut faire plein de chose sans pointer, et ca c'est vraiment fort que Mollusk simplifie le code à ce point!

Op, une valeur par ci, une valeur par là, et on bouge des scrollings, des sprites animés qui bougent dans tout les sens, au paddle et au stylet... sans pointeur!

Mais je me rend compte que dés que je veux géré des éléments de gameplay, et donc des données : impossible d'y couper!!!

Merci MOMO! 

[hlide]

Techniquement, je crois que tu as le droit d'écrire juste

Code

 (c):
struct Territoire_ {
...};

avec tout ce qu'il faut dedans... Pour une seule structure, ce n'est pas gênant. Dans le code de t4ils, par contre, j'ai vu pareil suivi de

Code

 (c):
Territoire_ Territoire[30]

Je ne sais pas dans quelle mesure c'est correct ou pas, mais dans ce cas, Territoire_ est pour moi utilisé comme un type, donc pour faire proprement il vaut mieux déclarer ça en typedef (définition d'un nouveau type, littéralement...).

typedef struct Territoire {
...}Territoire_;

Là pour moi ce n'est pas correct non plus . Typedef, tu fais typedef, le type (struct), puis tout de suite '{', le contenu, et le nom ne vient qu'à la fin => donc le 'Territoire' du début serait de trop.

edit : Master, oui, il va nous falloir un joli module de download. Il faut voir ce que SMF permet dans le portail par défaut, sinon j'ai mon idée sur un module 'freestyle' mais il faudrait que j'en parle avec X-Blaster

alors, compte tenu de la grammaire C, il y a des raisons pour laquelle il peut être obligatoire de mettre le nom après le mot réservé "struct" :

Code

 (c):
typedef struct my_struct_s {
  struct my_struct_s *next, *prev;
  ...
} my_struct_t;
 

au moment où l'analyseur gramaticale traite les membres next et prev le type "my_struct_t" lui est inconnu, par contre il connaît l'existence de my_struct_s qui est en cours de définition. Et puisque "next" et "prev" sont des pointeurs, l'analyseur peut déduire le nombre de d'octet à reserver pour ces deux champs et donc continuer l'analyse sur les autres membres de la structure.

Sans avoir nommer la structure, ce serait impossible de mettre "next" et "prev".

[Pitt]

Sauf que tout pointeur fait 32bits (ou 64bits sur les procs 64bits ) donc le compilo il s'en fout +/- à ce niveau là. Juste que bon c'est plus intelligent de savoir ce que le programmeur déclare, ça évite le backtracking ; c'est uniquement pour ça que le compilo veut à tout prix avoir des types déclarés avant, d'où le struct + nom

[Valryon]

Je suis plus de 120jours en retard mais peut importe, cette méthode est toujours valable.

J'ai bien assimilé le principe des pointeurs et je dois avouer que ça simplifie pas mal de bouts de code !

J'aimerais ajouter aussi un pointeur sur les backgrounds, mais ça ne marche pas aussi facilement
Quelqu'un pourrait-il me montrer un exemple ?

Voilà ce que j'ai et qui ne marche pas :

Dans un fichier aaa.h

Code:

typedef struct {
	//Backgrounds
	void *bg3;
} Niveau_;

Dans le aaa.c

Code:

const Niveau_ niveau1 = {
	level1bg3
};

Et l'appel dans le main :

Code:

PA_DualLoadPAGfxLargeBg(3, niveau1.bg3);

Mais ça ne compile pas, il cherche d'autres éléments qui ne sont pas dans ma structure. Y a-t-il un moyen de le faire accepter un truc pareil ?

[Mollusk]

Regarde les exemples BgPtr de PAlib, c'est fait pour

[Valryon]

Exactement ce qu'il me faut, merci !

[Valryon]

La fonction pour charger n'existe pas en Dual par contre
J'ai tenté de créer une macro en m'inspirant de ce que j'ai vu dans PAlib :

Code:

#define PA_DualEasyBgLoadPtr(bg_number, bg_name) \
PA_EasyBgLoadEx(0, bg_number, (u32*)bg_name->Info, bg_name->Tiles, bg_name->TileSize, bg_name->Map, bg_name->MapSize, bg_name->Palette); \
PA_EasyBgLoadEx(1, bg_number, (u32*)bg_name->Info, bg_name->Tiles, bg_name->TileSize, bg_name->Map, bg_name->MapSize, bg_name->Palette); \
PA_LargeScrollY (0,bg_number, 192+16);

192 : la taille d'un écran, +16 la taille du "screenspace".

On dirait que ça marche...