Papi Vetea et les pointeurs en C - SgdK.

[Invité]

Bonjour à tous,

Comme promis, je crée ce post pour toutes les personnes qui débutent en C depuis peu et veulent en savoir un peu plus sur ce qui fait la force du C : les pointeurs.

Par contre, ce n'est pas moi qui vous donne des conseils, c'est la communauté !
Moi je me situe comme un débutant et ce topic sera une suite d'exemples, d'interrogations et de corrections.

Voici donc mon premier exemple ( et premier problème ! ^^ )

Les pointeurs et les tableaux/Structures.

Voici donc ma structure de base :

Code:

  typedef struct
{
  Sprite* SpriteA;
  u8 Block;
  u8 BlockH;
  u8 BlockB;
  u8 BlockD;
  u8 BlockG;
  u8 Ready;
  u8 Coup;
  u8 Init;
  u8 TypeShoot;
  u8 Shoot;
  fix16 LongueurCoup;
  fix16  LongueurCoupM;
  fix16 CoordX;
  fix16 CoordY;
  fix16 TamponY;
  u16 TempoSprite;
  u16 TempoSpriteMax;
  u16 TempoCoup;
  u16 TempoCoupMax;
  fix16 OffsetX;
  fix16 OffsetY;
  fix16 Velocity;
  fix16 Vitesse;
  fix16 VitesseD;
  fix16 VitesseSprintD;
  fix16 Distance;
  u8 Sprint;
  u8 Animation;
  fix16 VitesseInit;
  fix16 VitesseSprint;
  u8 Priority;
  u8 Count;
  u8 ID;
  u8 IDZ;
  u8 TypeUnit;
  fix16 Lift;
  u8 Tampon;
  s16 Sens;        // 1 - Bas en Haut, 2 - Haut en bas
  u8 StandBy;      //1 : Non visible, 0:Visible
  u8 Direction;    //8 : H, 2: B, 4:G, 6:D  - 84 : HG, 86:HD, 24:BG, 26:BD  44 : Latéral Gauche 66 Latéral Droite
} Sprite_;

// Construction tableau principal
Sprite_ Sprites[60];

// Déclaration pointeurs
Sprite_ spr*,ptr**



Bon, c'est ma structure de base pour un Sprite.
Elle contient toutes les données nécessaire pour mes projets.


J'ai déclaré mes deux pointeurs suivant l'exemple de Hpman, sans trop comprendre ce que ça veut dire ...
Sprite_ spr*,ptr**

Question No1 :
Quid de cette déclaration ?
1/ spr* est pointé sur la structure Sprite_ ?
2/ ptr** est pointé sur le pointeur spr* ?


Maintenant, je désire déclarer un pointeur sur ce tableau dans mon

.

Code:

ptr=&Sprites[0];  // Ligne 189
spr=*ptr++;

Je compile, mais voila, le compilateur me renvoie un avertissement.


J'ai un problème d'incompatibilité apparemment.

J'ai repris le code de Hpman, car intéressant dans sa maitrise des pointeurs, mais il est vrai que c'est encore bloqué dans ma cervelle.
Je comprends les adressages mémoires des variables, les types Word, long, etc ...
Mais là, j'arrive pas à avoir ce putainG de déclic.

Merci de vos éclairages et de vos corrections.

[Hpman]

Ton tableau n'est pas composé de pointeurs donc faut virer un * à ptr.

Bon après faut voir ce que tu veut faire exactement, la correction dépend de l'objectif.

[Invité]

Merci je vais voir ça.

Ce que je veux faire ??

1/ Virer toutes mes appels de tableau en mode "Basic" de type
Tableau[x].Y=Z;
2/ Optimiser l'utilisation de ces tableaux par des pointeurs.
3/ Une fois ces notions maitrisées, refondre tout le code de Papi Commando Tennis avec l'utilisation de ces pointeurs.

Même si l'utilisation "Basic" fonctionne parfaitement, mais quitte à utiliser le C, autant pleinement en profiteR.

[Stef]

L'utilisation des pointeurs sur les tableaux est intéressante quand tu parcours le tableau de manière linéaire... pour des accés random bien sur ça ne sert à rien mais dans 95% des cas tu fais un parcours séquentiel.
Du coup dans ce cas c'est très simple :

Code:

Sprite *s;

s = &sprites[0];  // s pointe sur sprites[0] : premier sprite

// i = nombre de sprite à traiter
i = NB_SPR;
while(i--)
{
  // task on sprite using s->xxx
  s->x = ...;
  // pass to next sprite
  s++;
}

C'est la manière classique (et rapide ^^) de parcourir un tableau en C :)

[TotOOntHeMooN]

Il y a beaucoup de type U8 dans ta structure de sprite. A chaque fois tu utilises 256 valeurs ?
Je ne sais pas si SgdK sait gérer les champs de bits, mais ça pourrait-être utile pour économiser de la mémoire.

[Hpman]

Oh bah déjà en l'état si tu déclares pas ta structure en packed, tes u8 prennent 2 octets pièce 

[Invité]

Stef :     

Tu as le don de m'éclaircir mes neurones tel un lagon sous un lever de soleil. 

Ca fonctionne parfaitement !

Donc après correction :

Les pointeurs et les tableaux/Structures.

Code:

  typedef struct
{
  Sprite* SpriteA;
  u8 Block;
  u8 BlockH;
  u8 BlockB;
  u8 BlockD;
  u8 BlockG;
  u8 Ready;
  u8 Coup;
  u8 Init;
  u8 TypeShoot;
  u8 Shoot;
  fix16 LongueurCoup;
  fix16  LongueurCoupM;
  fix16 CoordX;
  fix16 CoordY;
  fix16 TamponY;
  u16 TempoSprite;
  u16 TempoSpriteMax;
  u16 TempoCoup;
  u16 TempoCoupMax;
  fix16 OffsetX;
  fix16 OffsetY;
  fix16 Velocity;
  fix16 Vitesse;
  fix16 VitesseD;
  fix16 VitesseSprintD;
  fix16 Distance;
  u8 Sprint;
  u8 Animation;
  fix16 VitesseInit;
  fix16 VitesseSprint;
  u8 Priority;
  u8 Count;
  u8 ID;
  u8 IDZ;
  u8 TypeUnit;
  fix16 Lift;
  u8 Tampon;
  s16 Sens;        // 1 - Bas en Haut, 2 - Haut en bas[size=12][/size]
  u8 StandBy;      //1 : Non visible, 0:Visible[size=12][/size]
  u8 Direction;    //8 : H, 2: B, 4:G, 6:D  - 84 : HG, 86:HD, 24:BG, 26:BD  44 : Latéral Gauche 66 Latéral Droite
} Sprite_;

// Construction tableau principal
Sprite_ Sprites[60];

// Déclaration pointeurs
Sprite_ *spr;

Ensuite dans le Main :

Code:

       // Affichage Sprite
        i=MaxSprite;
        spr=&Sprites[0];
        while (i--)
        {
          ...
          ...
        spr++;
        }

Et par la suite dans mes routines d'appel :

Code:

   // Gestion Déplacement Sprite //
    if (spr->Direction==8 && spr->Block==0) spr->CoordY-=spr->Vitesse;
    if (spr->Direction==2 && spr->Block==0) spr->CoordY+=spr->Vitesse;

Compilation.
Ca fonctionne !!   

Moralité : ne pas chercher à comprendre un code très optimisé mais qui te semble trop obscur pour débuter.

[Invité]

Mea culpa.
Personne n'est parfait.

En fait, non ...
Dites moi clairement ce qui ne vas pas, et corrigez moi, ça sera mieux que des  .
Merci.

[Invité]

Sympa ce topic , je vais suivre ça :)
Pour u8 ou autre, cela dépend de ce que tu veux en finalité niveau taille de variables. Ne pas oublier aussi que les compilo ont dés fois la fâcheuse manie à faire "des trous" dans des structures si les variables ne sont pas alignés sur 8 bits ... (ex: 3 bits et ensuite un 16 bits, y'aura peut être un trou après les 3 8 bits ...), d'où l'utilisation de la directive de compilation #pragma pack dans les déclarations de structures / variables

[Tryphon]

Qu'est-ce qui ne marche pas exactement ? C'est quoi l'erreur ?

Déjà, ton dernier code est désagréable à lire (soit dit sans vouloir t'offenser) : y'a des tags "size" partout, t'as dû faire une erreur de quote.

Un conseil : utilise des conventions de nommages différentes pour les struct, les types, les variables... Là, on a des Sprite, Sprite_, et un tableau Sprites, pas évident de s'y retrouver. Une "règle" classique est de faire démarrer les noms de struct ou de typedef par des majuscules, mais pas les noms de variables ou de champs dans tes structs, c'est déjà plus agréable.

Dans ton premier code, tu écris :

Code:

Sprite_ spr*

Je suppose que tu voulais dire :

Code:

Sprite_ *spr

Tu écris aussi :

Code:

ptr = *spr++;

Est-ce que tu veux que ptr pointe sur le Sprite_ courant ? Dans ce cas ptr est inutile, spr pointe déjà sur le sprite courant (et tu accèdes à tes champs en faisant spr->Block).

Ou alors tu veux récupérer le sprite lui-même ? Dans ce cas n'appelle pas la variable qui le reçoit ptr, c'est trompeur, mais plutôt sprite_courant (en fait t'as peut-être mélangé spr et ptr) et tu écris :

Code:

sprite_courant = *(spr++);

et tu accèdes aux champs via sprite_current.Block
note les parenthèses : elles ne sont (peut-être) pas obligatoires mais ton expression est ambigue :

Code:

*(spr++)

te renvoie l'objet pointé par le pointeur spr, puis incrémente ce pointeur de sorte qu'il pointe sur le sprite suivant. Alors que :

Code:

(*spr)++

regarde l'objet pointé par spr, tente de l'incrémenter (et te balance une erreur dans la tronche parce qu'on ne peut pas incrémenter un Sprite_) (mais ça marcherait si spr était un pointeur sur un entier) et le renvoie.

Je ne sais pas laquelle des deux versions est équivalente à *spr++

Pour autant que je puisse le lire, le deuxième code a l'air correct.

Un truc, je pense (pas sûr) que tu peux remplacer :

Code:

spr = &Sprites[0];

par :

Code:

spr = Sprites;

Il me semble bien qu'en C un identificateur de tableau est un pointeur sur son premier élément (à confirmer). Ça mange pas de pain.

Autre chose : un bon réflexe quand tu galères, c'est d'écrire un Exemple Complet Minimal (ECM) : tu simplifies ton code à fond (vire les variables, les champs des struct, etc.) jusqu'à avoir un programme de moins de 10 lignes qui contient l'erreur. Souvent, rien qu'en réduisant, tu trouves l'erreur. Sinon, quand tu demandes à un gars qui s'y connaît en C (genre StackOverflow ou developpez.net), c'est plus facile pour lui

[Stef]

Oh bah déjà en l'état si tu déclares pas ta structure en packed, tes u8 prennent 2 octets pièce 

Heureusement non dans le cas de SGDK ^^ Je pense que ça doit dépendre de la configuration de ton compilo par défaut

Il y a beaucoup de type U8 dans ta structure de sprite. A chaque fois tu utilises 256 valeurs ?
Je ne sais pas si SgdK sait gérer les champs de bits, mais ça pourrait-être utile pour économiser de la mémoire.

Le champ de bit existe en C mais clairement c'est assez lent et je préfère m'en passer, surtout dans les structures où les alignements sont importants !

[Tryphon]

Le champ de bit j'ai jamais vu l'intérêt. Je préfère avoir un champs u8 flags et gérer mes flags à la main.

[Stef]

Le champ de bit j'ai jamais vu l'intérêt. Je préfère avoir un champs u8 flags et gérer mes flags à la main.

Pareil, à l'écriture c'est plus sympa certes mais le problème c'est que le compilo n'est pas toujours très efficace pour le gérer du coup il vaut mieux jouer avec les & / | à la mano...

[philip]

@vetea
Pour moi un pointeur est très utile pour les animations, car un pointeur évite d'utiliser de multiples conditions. 
(Plus il y a de conditions, plus le 68000 travaille)

Dans ton code tu met un pointeur à l'intérieur de condition, je ne trouve donc pas cela pertinent.

[Invité]

Merci de vos conseils.

@Tryphon :
Désolé de tout ce fouilli, j'ai corrigé.
J'oublie tout ce que j'ai rédigé en premier lieu, car sans trop comprendre ce que je faisais.
Heureusement, Zorro Stef est arrivé.

@philip :
Comment un pointeur évite d'utiliser de multiples conditions ?
Mon code est truffé de if & then, pour moi c'est l'essence de la programmation !!

Code:

   // Gestion Déplacement Sprite //
    if (spr->Direction==8 && spr->Block==0) spr->CoordY-=spr->Vitesse;
    if (spr->Direction==2 && spr->Block==0) spr->CoordY+=spr->Vitesse;

Ici comment pourrai je me passer de ces multiples conditions grâce aux pointeurs ??
Je pensais que les utiliser accélère les traitements justement.

Bon c'est 4h45, j'ai la cervelle dans un champs de bit ... 

Bonne journée !

[Tryphon]

Je pense que Philip fait référence aux pointeurs sur fonction, qui permettent effectivement de rendre ton code plus rapide, plus lisible, et d'éviter des if/then.

C'est un sujet un peu différent de celui de ce post. On peut en parler dans un autre post, d'autant plus que la situation de celui-ci ne s'y prête pas vraiment...

[Invité]

Mon code est truffé de if & then, pour moi c'est l'essence de la programmation !!

Non, en C en terme de lisibilité il vaut mieux utiliser des switch/case qui sont bcp plus propres,mais plus lents aussi,bon sur PC ça se voit pas du tout .
Et puis là je vois déjà une optimisation:

Code:

// Gestion Déplacement Sprite //
 if ( spr->Block == 0 )
 {
    if (spr->Direction == 8 ) spr->CoordY -= spr->Vitesse;
    if (spr->Direction == 2 ) spr->CoordY += spr->Vitesse;
 }


On évite de faire 2x le même test .

[Invité]

Merci Toukonet.
Sinon question, rien à voir avec les pointeurs ( quoique )
Je suis sur MArseille ce week-end, y aurait moyen de se boire un ( ou plusieurs ) pastis ensemble ???

[TotOOntHeMooN]

Donc... Tu pointes ou tu tirs ? 

[Invité]

Je suis sur MArseille ce week-end, y aurait moyen de se boire un ( ou plusieurs ) pastis ensemble ??? 

Ca aurait été avec plaisir, mais je suis rarement sur marseille, vu que j'habite au mans maintenant   .

Donc... Tu pointes ou tu tirs ? 

[the_gast]

Je comprends pas trop l'intérêt d'itérer sur un tableau avec des pointeurs, vu que l'incrémentation du tableau fonctionne comme le pointeur ?
Mais y'a certainement une subtilité en C que je ne maîtrise pas...

sinon, je ne saurais que conseiller de trier tes variables membres par taille dans ta struct Sprite_

[Tryphon]

Qu'appelles-tu incrémentation du tableau ? La boucle :

Code:

for (i = 0 ; i < SIZE ; i++) {
   tab[i] = ...
}

?

Si oui, la technique du pointeur est plus rapide parce que, quand tu tapes tab[i], en interne le compilateur va :

* rechercher l'adresse de début du tableau

* multiplier i par la taille d'une entrée du tableau (ce qui est effroyablement lent)

* ajouter le résultat à l'adresse de début du tableau

Si tu enchaînes les tab[i].x = truc et tab[i].y = muche, c'est une catastrophe. J'ai eu l'occasion d'utiliser cette optimisation sur mon moteur pour Shinobi y'a quelques temps et l'accélération est sensible.

[Invité]

Ahh génial de savoir ça !!
Merci Tryphounet !

[Hpman]

Disons qu'avec un pointeur tu laisses moins de marge au compilateur pour faire de la merde .

Quand je parcours un tableau de manière classique, j'ai aucune garantie que le compilo "voie" l'optimisation et incrémente un pointeur, au lieu de partir dans un savant calcul d'adresse à partir de l'index.

[Stef]

Les compilateurs modernes sont plus intelligents mais bon là vu la machine on se contente d'un vieux compilo GCC qui n'est pas très malin car les derniers GCC pèsent lourd en plus de produire un code foireux pour ce genre d'architecture complètement dépassée (et GCC n'a jamais était excellent en ce qui concerne les optimisations de toute façon).

[ichigobankai]

Non, en C en terme de lisibilité il vaut mieux utiliser des switch/case qui sont bcp plus propres,mais plus lents aussi,bon sur PC ça se voit pas du tout .

normalement les switch/case devraient etre convertis en jump table... enfin faut verifier dans l'asm généré !

[Invité]

J'adore les Switch/Case - Select/Case !!!
C'est la meilleure invention après les Goto !! 

En tout cas, ce topic créer un débat fort utile et agréable à lire. :)

[Invité]

Coucou,

Hier soir, j'ai pu modifier mon code de test grâce à votre aide, divers tutoriels et surtout, la pratique et encore la pratique !
J'ai pu observé un gain de fluidité sur la démo précédente.
Je suis surtout content d'avoir eu ce "déclic" hier en codant, en travaillant sur l'index d'un tableau grâce aux pointeurs.
Ca devient plus clair dans mon esprit.

Je poursuis encore mes petits travaux dans ce sens, jusqu'à la refonte du code source de Papi Tennis.

Merci encore et bon week-end à tous !

[Invité]

Non, en C en terme de lisibilité il vaut mieux utiliser des switch/case qui sont bcp plus propres,mais plus lents aussi,bon sur PC ça se voit pas du tout .

normalement les switch/case devraient etre convertis en jump table... enfin faut verifier dans l'asm généré !

Oui, si c'est effectivement le cas c'est top .

J'adore les Switch/Case - Select/Case !!! 
C'est la meilleure invention après les Goto !!     

Non mais c'est sur, juste que si ton compilo 8/16 bits te compile ça comme une merde, je peux t'assurer que leeeeeent   .

[Invité]

Asm68k.exe de Bex est extraordinaire de puissance !!
Faut voir la librairie de Bex en asm, c'est vraiment super mal optimisé, buggé et pourtant le code compilé est vraiment rapide ... faut voir mes jeux Bex, ceux de FL et Bonaf pour s'en rendre compte.