Le point ... sur les pointeurs en C !

[Invité]

Salut tout le monde, j'aurais besoin de quelques explications au sujet des pointeurs en C que j'utilise très rarement. Bien entendu, j'ai compris le concept et concrètement, un pointeur permet d'envoyer l'adresse d'une variable, d'un tableau ou d'une structure à une fonction plutôt que d'en faire une copie dont les modifications de valeurs ne seront pas pris en compte.

Sauf que voilà, où j'ai du mal à comprendre c'est lors de l'initialisation du pointeur :

Code:

Player *player;

void initPlayer() {
    player->active = true;
    player->lives = 3;
}

Code:

Player *player;

void initPlayer(Player *player) {
    player->active = true;
    player->lives = 3;
}

Dans les deux cas, ça ne marche pas, ce qui est normal, car le pointeur n'a pas été initialisé. De ce que j'ai compris, il faudrait procéder de cette manière :

Code:

Player player;
Player *pplayer

void initPlayer() {
    player.active = true;
    player.lives = 3;
    
    pplayer = &player;
}

Hors ce que j'aimerais c'est de ne pas avoir deux variables, c'est à dire juste le pointeur Player *player;

Est-ce possible ?

Merci d'avance :)

[Tryphon]

Plusieurs remarques :

1) ton deuxième code est immonde, car player réfère à deux objets différents : une variable globale et le paramètre de initPlayer, a priori différent

2) si tu veux utiliser un pointeur sur une structure, il faut d'abord réserver une zone mémoire pour stocker les données :
Player *pplayer = malloc(sizeof(Player));

3) ce n'est pas plus économique qu'avoir deux variables

[Invité]

@Tryphon merci ! Pas grave si ce n'est pas plus économique, c'est juste que je préfère ne pas avoir deux variables :)

[Tryphon]

Niveau temps d'exécution, ta 3ème solution est plus économique que le malloc : c'est le compilateur qui se chargera de réserver la zone mémoire, alors qu'avec le malloc, tu exécuteras une fonction à chaque fois qu'il s'exécutera.

Bon, elle est très rapide normalement, puis je suppose que tu le feras une seule fois, au début de ton niveau, donc c'est négligeable.

Par contre, pour tes ennemis, réserve en une seule fois tout un tableau de structures, ne crée pas la zone mémoire en cours de jeu.

[Orion_]

les pointeurs servent surtout quand tu veut passer un argument a une fonction, il servent rarement localement sauf si tu veut eviter d'indexer un tableau que tu parcours de manière continue (certain compilateur ne font pas l'optimisation)

Donc c'est comme ça que ça s'utilise:

Code:

Player player;

void initPlayer(Player *ptr)
{
    ptr->active = true;
    ptr->lives = 3;
}

void main(void)
{
   initPlayer(&player);
}


Maintenant, si tu n'a qu'un seul objet Player, aucun besoin d'utiliser un pointeur, car de toute façon tu passera toujours "player" a tes fonctions, donc autant utiliser la référence originale.
Exemple: player.active = true; sera plus rapide que player->active = true;
car le compilateur va optimiser "player.active" en une seule adresse fixe, alors que "player->active" ira d'abord chercher l'adresse de "player" puis ajouter un offset pour l'objet "active".

Et si tu code sur console rétro, jamais de malloc, c'est pas du tout adapté au peu de mémoire dispo dans ces consoles

[Tryphon]

Ça dépend quand tu le fais (à l'initialisation, ça passe). Mais oui, perso, je préfère réserver de gros tableaux de structs par des :

Ennemy ennemis[30];

par exemple.

Au passage, en C, un tableau est en fait un pointeur sur son premier éléments (autrement dit dans le code ci-dessus, ennemis est un Ennemy*)

[Invité]

Ah je comprends mieux l'utilisation avec ton exemple @Orion_

Pour le joueur, effectivement, il n'y a pas trop d'intérêt, mais c'était pour l'exemple.

En revanche comme le souligne @Tryphon j'utilise un tableau de structure Enemy et là, ça me serait fort utile plutôt que d'envoyer à la fonction l'index, par exemple :

Code:

void removeEnemy(int position) {
    enemies[position].active = false;
    ...
}

Donc si j'avais un tableau de pointeurs de structure, cela donnerait :

Code:

Enemy *enemies[50]

void initEnemy(Enemy *enemy) {
    enemy->active = true;
    enemy->health = 1 ;
    
}

void main(void) {
  int i;
  for(i=0;i<50;i++) {
      initEnemy(&enemies[i]);
  }

}

void removeEnemy(Enemy *enemy) {
     enemy->active = false;
    ...
}

C'est bien ça ?

[Tryphon]

Ça ne sert à rien d'avoir un tableau de pointeurs (enfin si, mais pas pour ce que tu veux faire). De plus, le &ennemies[i] me semble faux.

Il vaut mieux avoir :

Code:

Enemy enemies[50]; // tu as donc 50 emplacements, chacun assez gros pour stocker un Enemy, réservés en memoire

void initEnemy(Enemy *enemy) {
    enemy->active = true;
    enemy->health = 1 ;
    
}

void main(void) {
  int i;
  for(i=0;i<50;i++) {
      initEnemy(&enemies[i]); // là le & est licite car ennemies[i] est une struct, or tu veux un pointeur
  }
}

void removeEnemy(Enemy *enemy) {
     enemy->active = false;
}



voire mieux :

Code:

void main(void) {
  int i;
  Ennemy *current;
  current = ennemies;
  for(i=0;i<50;i++) {
      initEnemy(current++);
  }
}


En effet, le ++ sur un pointeur l'augmente automatiquement de la taille de la struct.

À vérifier quand même parce que ça fait un moment que j'ai pas fait de C. En plus j'ai mal dormi, j'ai vraiment peur de dire des conneries

Encore mieux : parcourir la boucle à l'envers

[Invité]

Voir mon topic :
https://www.gamopat-forum.com/t93488-papi-vetea-et-les-pointeurs-en-c-sgdk?highlight=Papi+commando+pointeur

[Invité]

@Tryphon d'accord, alors si je comprend bien, inutile d'avoir un tableau de pointeurs, car je peux simplement envoyer l'adressage mémoire avec en ajoutant le & devant une variable ?

Donc en gros je me complique la vie depuis hier ?

 

Code:

struct Enemy {
  Sprite *sprite;
  bool active;
  u6 health;
}

Enemy enemies[50];

void initEnemy(Enemy *enemy) {
  enemy->active = true;
  ...
}

void main(void) {
  int i;
  for(i<0; i<50; i++) {
    initEnemy(&enemies[i]);
  }
}

J'ai tout bon ?

Quelle est l'avantage de ta seconde méthode?

[Stef]

Orion te montre effectivement le cas d'utilisation classique des pointeurs.
En gros tu as des objets statiques et tu envois juste la référence (l'adresse) en paramètre d'une fonction pour que ça soit plus rapide.
Aussi on utilise les pointeurs pour parcourir rapidement un tableau, comme le dit Tryphon un tableau est vu comme un pointeur en C.

Si tu veux parcourir rapidement ton tableau d'objet tu peux faire :

Code:

Enemy enemis[30];

// enemis = &enemis[0] = pointeur sur le premier élement du tableau
Enemy* enemy = enemis;
int i = 30;

while(i--)
{
  doStuff(enemy);
  ...
  enemy->done = TRUE;
  // passe au prochain ennemi dans le tableau
  enemy++;
}

Ensuite dire qu'on fait jamais de malloc sur une machine rétro, c'est un peu vrai si tu peux allouer tout tes objets en statique sans exploser la mémoire... mais dans certains (rares) cas tu peux quand même avoir besoin d'un malloc pour allouer temporairement un gros tableau, par exemple pour le mode bitmap software de SGDK (hors de question de bouffer en performance le double buffer en mémoire centrale qui consomme  environ 40 Ko de mémoire).
SGDK a des fonctions d'allocation dynamique de mémoire (MEM_alloc(..) et MEM_free(..)), elles sont utilisables in-game (c'est assez rapide, environ 50000 mallocs / seconde) mais en général tu en as pas vraiment besoin.
Le sprite engine utilise beaucoup d'allocation dynamique de ressources (mais plutot pour la VRAM / sprite hard).

Edit: bon il y a eu plein de réponses entre temps, j'écris trop lentement ^^

@shingosama> ta version est bonne, mais utiliser &enemis[i] est plus lent qu'avoir un pointeur qui est incrémenté. Pourquoi ? parce-que pour trouver l'adresse de enemis[i] le compilo doit prendre l'adresse du tableau (premier élement) et ajouter i * la taille de structure (Enemy), si ta structure fait 26 octets alors il devrait faire enemis + (i * 26) et une multiplication c'est super cher ! Et même s'il est capable d'optimiser la multiplication (en utilisant des shifts de bits) ca restera bien plus lent qu'un simple pointeur qu'on incrémente, ton enemy++ ça va simplement générer une addition en interne, on va ajouter la taille de la structure Enemy au pointeur soit +26 :)

[Tryphon]

Quelle est l'avantage de ta seconde méthode?

&enemies[i] est lent : le compilateur doit récupérer la valeur de i, la multiplier par la taille de la struct Ennemy, et lui ajouter l'adresse de base du tableau.

si tu maintiens un pointeur "current" à jour, tu n'as qu'à ajouter la taille de la struct à chaque étape.

En plus, je trouve ça plus élégant, ça se rapproche d'une boucle foreach. Exemple en Python :

Code:

for current in ennemies

[Invité]

Merci les gars.

Je vais pouvoir m'amuser ce soir

J'espère gagner un peu en performance avec l'utilisation des pointeurs.

[Invité]

Je réitère ...
https://www.gamopat-forum.com/t93488-papi-vetea-et-les-pointeurs-en-c-sgdk?highlight=Papi+commando+pointeur

Je me suis poser les même questions que toi, et grâce a ce poste j'ai décuplé mes performances sur Papi Reload.

[Stef]

Effectivement ! je t'invite à consulter le topic posté par Vetea car ça parle exactement de la même chose

[Invité]

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.

@Vetea effectivement, pas mal d'informations également sur ton topic :)

Et dire que je fais que des boucles classiques en for

[Sylver78]

De ce que j'ai vu rapidement en parcourant ton code, c'est qu'il te manque quelques notions essentielles au niveau de la gestion de la mémoire !

Déjà il y a les variables globales : ce sont les variables que tu déclares en dehors de toute fonction ! En théorie ces variables sont accessibles depuis tout le code de ton application (via une déclaration avec le mot clé "extern" de la variable par exemple). Il est possible de restreindre l'accès de ces variables aux fonctions du fichier où elle est déclarée, mais ce n'est pas très important dans un 1er temps.
Dans ce cas, le compilateur alloue un espace mémoire de façon permanente pour ces variables. En effet elles doivent être accessibles en permanence depuis n'importe où donc pas le choix !
Ca veut dire que ça va prendre de la place même quand tu n'en as pas besoin ! Sur des machines avec plusieurs Go de ram, ce n'est pas bien grave, mais sur une machine avec quelques Ko de ram, ça devient critique ...

Ensuite il y a les variables déclarées dans une fonction. Ces variables ne vivent que le temps de l'exécution de la fonction et elles sont stockées en général dans une zone mémoire qui s'appelle la pile mémoire. Cette pile mémoire est une zone mémoire allouée à chaque fois que tu arrives dans une fonction, elle contient entre autres les paramètres passés à la fonction et l'adresse de retour (pour pouvoir retourner dans la fonction qui a fait l'appel une fois le traitement fini). La taille de la pile est souvent fixe (parfois modifiable au niveau des options du compilateur ou via l'utilisation de directives #pragma). En tout cas cette taille est limitée, du coup ce n'est pas le bon endroit pour déclarer de gros objets ...

Sur les pointeurs maintenant :

Il est possible d'obtenir l'adresse mémoire de n'importe quelle variable, comme tu le sais, ça permet de modifier le contenu de l'objet pointé via une autre fonction.
Un pointeur étant concrètement une zone mémoire contenant une adresse mémoire (celle de l'objet pointé), il est possible de faire des pointeurs de pointeurs par exemple (oui c'est parfois utile ). Sur certaines machines il existe des pointeurs de type near ou de type far, ce qui permet de limité la taille de la zone mémoire occupée par le pointeur en travaillant en adresses relatives, mais tu n'auras sûrement jamais à gérer ça donc passons

L'allocation dynamique, la déesse de la mémoire
Pour pouvoir allouer des objets uniquement quand tu en as besoin, il existe les fonctions alloc/malloc/calloc/... Ces fonctions vont réserver une zone mémoire de la taille demandée, cette zone mémoire tu en fais ce que tu veux comme l'associer dans ton code à une structure ! D'ailleurs en général les fonctions d'allocations retournent un pointeur non typé (void *), à toi de le "caster" dans le type voulu ! Par exemple :
Player *player_p = (Player *)malloc(sizeof(Player));
Sur cette ligne j'alloue une zone mémoire de la taille de la structure Player et je caste le pointeur en pointeur sur structure de type Player et je stocke ça dans une variable "player_p" de type "pointeur sur structure Player"
Donc voilà à partir de maintenant j'ai une zone mémoire allouée pour une structure de type Player et tu peux accéder à ses champs via
player_p->var1, ... ou (*player_p).var1
Par contre il y a une chose très importante à prendre en compte : la mémoire que tu as alloué, il faudra la libérer à un moment (via "free((void *)player_p);"), car si tu ne le fais pas, tu auras potentiellement un fuite mémoire (donc de la mémoire allouée que tu ne peux plus libérer car tu as perdu son adresse par exemple), et à force de perdre de la mémoire comme ça, à un moment ton malloc ne sera plus capable de trouver un bloc libre et il te retournera un pointeur "null" et manipuler un pointeur à 0 ça ne donne jamais rien de bon (c'est pour ça que l'on teste la valeur du pointeur retourné par un malloc si on est propre, mais si tu veux faire du code optimisé, tu peux t'affranchir de cette vérification car de toute façon si tu n'as plus de mémoire dynamique disponible, tu ne pourras plus rien faire de toutes façons

Le pointeur c'est un outils très puissant, mais il faut avoir les idées claires sur ce que l'on fait ! On peut même créer des pointeurs de fonction par exemple :) Du coup si on n'a pas bien pensé ses mécanismes ça peut vite devenir le bordel !

[Hpman]

De ce que j'ai vu rapidement en parcourant ton code, c'est qu'il te manque quelques notions essentielles au niveau de la gestion de la mémoire !

Déjà il y a les variables globales : ce sont les variables que tu déclares en dehors de toute fonction ! En théorie ces variables sont accessibles depuis tout le code de ton application (via une déclaration avec le mot clé "extern" de la variable par exemple). Il est possible de restreindre l'accès de ces variables aux fonctions du fichier où elle est déclarée, mais ce n'est pas très important dans un 1er temps.
Dans ce cas, le compilateur alloue un espace mémoire de façon permanente pour ces variables. En effet elles doivent être accessibles en permanence depuis n'importe où donc pas le choix !
Ca veut dire que ça va prendre de la place même quand tu n'en as pas besoin ! Sur des machines avec plusieurs Go de ram, ce n'est pas bien grave, mais sur une machine avec quelques Ko de ram, ça devient critique ...

Ensuite il y a les variables déclarées dans une fonction. Ces variables ne vivent que le temps de l'exécution de la fonction et elles sont stockées en général dans une zone mémoire qui s'appelle la pile mémoire. Cette pile mémoire est une zone mémoire allouée à chaque fois que tu arrives dans une fonction, elle contient entre autres les paramètres passés à la fonction et l'adresse de retour (pour pouvoir retourner dans la fonction qui a fait l'appel une fois le traitement fini). La taille de la pile est souvent fixe (parfois modifiable au niveau des options du compilateur ou via l'utilisation de directives #pragma). En tout cas cette taille est limitée, du coup ce n'est pas le bon endroit pour déclarer de gros objets ...

C'est pas tout à fait exact, si on regarde la plupart des jeux 8/16, quasi tout est en variables globales. La RAM était mappée à la main dans un fichier de defines asm. C'est beaucoup plus efficace en temps machine et dans la très grande majorité des applications ça fait le job sans poser de problèmes.

La taille de la pile n'est pas limitée sur le 68k, la seule limite c'est l'entrée en collision de la pile avec la zone mémoire allouée aux variables. Résultats surprise! 
Mais oui vaut éviter de déclarer des tableaux ou autres gros objets en local. Utiliser un espace mémoire de travail déclaré en statique si besoin.

[tetsuro]

Tout comme toi, je comprend le concept des pointeurs, mais pas assez utiliser. Parait-il qu'il faut beaucoup les manipuler pour bien les comprendre. Mais c'est vrais que c'est déroutant et on ne vois pas l’utilité de suite car on peut ne jamais les utiliser, les contourner.

[Invité]

+1 Hpman.

[Invité]

Alors, c'est bien ou c'est mal les variables globales ?

[Tryphon]

Quand tu programmes sur PC, c'est mal. Sur console 16 bits, c'est bien !

[Invité]

Excellent alors !

J'ai donc testé ce midi l'initialisation des ennemis en parcourant le tableau avec un pointer, mais ça va prendre du temps pour que j'adapte tout le code déjà écris.

Vivement ce soir !

[Sylver78]

Effectivement je n'ai jamais fait de programmation sur console, mon expérience vient du fait que je fais (entre autre) du développement temps réel embarqué depuis quasiment une vingtaine d'années !
Ma remarque sur la nécessité d'utiliser le malloc n'est peut-être pas généralisable à la programmation console, mais je reste persuadé que certains jeux usent et abusent des malloc/free
Le plus important c'est de comprendre ce que l'on fait et les impacts en terme de temps d'exécution et d'occupation mémoire !
Après clairement les opérations de malloc et de free ça à un coût en terme de temps de traitement, il faut faire attention à ne pas créer de fuite mémoire et la programmation optimisée c'est tout un art et souvent une question de compromis et d'adaptation en fonction des ressources physiques disponibles et de la tâche à accomplir !

Si le système est capable de contenir en "statique" l'intégralité des ressources mémoires dont on aura besoin pour le jeu, alors clairement tout déclarer en variable globale c'est la solution la plus efficace en terme d'exécution ! Tout les objets auront une place bien déterminée (décidée par le compilateur), et l'accès à une ressource se fera directement depuis le code sans passer par des variables !
Après le risque c'est de se rendre compte un peu tard que finalement ça ne va pas tenir, et de se retrouver à avoir à tout modifier pour utiliser de l'allocation dynamique, mais pour des jeux simples ça a peu de chance d'arriver effectivement

[Stef]

Quand tu programmes sur PC, c'est mal. Sur console 16 bits, c'est bien !

Je ne suis pas aussi catégorique ^^ Les variables globales ce sont uniquement pour les ressources partagées, genre ton tableau de sprites, les objets player et ennemis... mais toutes les variables de travail "temporaires" doivent rester locales ! Les variables locales sont optimisées par le compilateur (il va souvent les stocker dans un registre) alors qu'il ne peut pas le faire pour une variable globale (ou plus difficilement).

Imagine tu as 2 variables globales pour la position de ton joueur :

s16 playerX;
s16 playerY;

Si tu utilises la variable plus d'une fois dans une fonction alors c'est une bonne pratique de la mettre dans une variable locale. Un exemple (bon le code n'a aucun sens mais c'est juste pour l'exemple) :

Code:

void trucWithPlayerX()
{
  if (playerX > xx) doStuff();
  else if (playerX < xx) doOtherStuff();

  if (playerX < yy) playerX -= speedX;
  ...
}

Ici on utilise plusieurs fois la variable globale playerX, le compilo va très probablement la relire à chaque fois depuis la mémoire, alors que si tu fais ça :

Code:


void trucWithPlayerX()
{
  s16 px = playerX;

  if (px > xx) doStuff();
  else if (px < xx) doOtherStuff();

  if (px < yy) px -= speedX;
  ...
  playerX = px;
}

Alors tu peux être sûr que le code sera mieux optimisé, car px sera très probablement mis dans un registre le temps de travailler avec et à la fin il mettra à jour la mémoire contenant la valeur de playerX une seule fois :)

[Sylver78]

Effectivement pour des ressources non partagées et réutilisées plusieurs fois, ce n'est pas l'idéal de déclarer en variable globale.
Après si on sait que cette variable ne changera pas de valeur, on peut simplement déclarer des variables locales à la fonction auxquelles on attribue les valeurs des variables globales puis on manipule uniquement ces variables locales par la suite !
Mais bon je pense qu'on pourrait discuter des années sur les aspects optimisation tellement le sujet est vaste (et essentiel pour faire un jeu fluide sur des processeurs qui datent un peu)

[Hpman]

Je pense que globalement on parle surtout du fait de ne pas mettre par exemple tout les objets ennemis en local dans la fonction gameplay, sous prétexte qu'ils ne sont pas utilisés sur l'écran titre. Quelques variables de travail en local ne posent pas problème.

Ensuite, chaque fonction est  évidemment un cas particulier.

[ichigobankai]

Quand tu programmes sur PC, c'est mal. Sur console 16 bits, c'est bien !

et 8bits aussi

[Invité]

Quelqu'un pourrait-il m'expliquer ce qui ne va pas dans ce bout de code ?

Code:

Bullet *bullet = bullets;
    int i = MAX_PLAYER_BULLETS;

    while(i--)
    {

        if(bullet->active == TRUE)
        {
            bulletUpdate(bullet);

            Enemy *enemy = enemies;
            int a = MAX_ENEMIES;
            while(a--)
            {
                if(enemy->active == TRUE && enemy->dead == FALSE)
                {
                    if(bulletCheckCollision(bullet, enemy) == TRUE)
                    {
                        //bulletRemove(bullet);
                        //enemy->health -= 1;
                        break;
                    }
                }

                enemy++;


            }
        }

        bullet++;
    }

Dès que je met une action n'importe laquelle lorsqu'une collision se fait, le jeu rame à mort. Si je laisse vide, c'est très fluide.

[vingazole]

Je pense que ton compilateur est assez "intelligent" pour détecter qu'il n'y a 
rien à faire dans le corps de ta condition (quand tu ne mets rien) et que du coup il ne génère aucune instruction (ce qui va beaucoup plus vite^^).