Re: Le point ... sur les pointeurs en C !

[Invité]

Whaouuuuuuuu les performances de dingues ! En fait, plus que les pointeurs, je crois que ce qui faisait grave galérer GCC, c'est que je ne déclarais pas les fonctions (oui je sais, c'est pas bien).

J'avais remarqué qu'en déclarant les fonctions, j'avais gagné un peu en performance, du coup, j'ai déclaré toutes les fonctions et là ultra fluide

EDIT : bon ok 50 ennemies, ça commençait à laguer un peu.

[Stef]

tiens bizarre, tet que ca lui permet de les "inliner"...

[Invité]

Possible, en tout cas c'est le jour et la nuit. Je n'avais remarqué de gros changements avec les pointeurs et je me suis dis qu'avant de vouloir optimiser, il faudrait déjà prendre en compte les "warnings" du compilateur et bien structurer le code.

J'ai aussi veillé à mettre certaines fonctions en static.

Je songe à m'acheter une livre pour vraiment apprendre le C, car à la base, j'ai appris le C++ sur le tas avec mes notions en programmation. On ne peut pas dire que je maîtrise le langage.

[Stef]

Le mot clé static sur les fonctions permet de les rendre locales à ton fichier (non partagées), ça aide donc le compilateur à optimiser ces fonctions en les inlinant quand c'est possible. Le notion de "locale" est vraiment importante pour l'optimisation ;-)

[ichigobankai]

Perso ce qui me choque c'est ca ^^

il faudrait déjà prendre en compte les "warnings" du compilateur

[Tryphon]

+1

En C, tant qu'il y a un warning, c'est qu'il y a un truc que t'as pas compris et qui va pas tarder à te péter à la gueule

[Invité]

XD et pourtant si, j'ai juste des alertes "à la con" du genre que je n'ai pas défini une fonction ou bien qu'une variable ou fonction n'est jamais utilisée etc.

Faut que je nettoie tout ce bordel

[Invité]

Je ne sais pas trop si j'ai bien assimilé les pointeurs, mais bon, maintenant je ne peux plus m'en passer. C'est vraiment le truc très pratique voir indispensable -_-

[Invité]

Me revoilà dans la tourmente des pointers.

Je voudrais créer une fonction retournant le pointer d'une structure. Jusque là pas de soucis.

Le problème c'est que je souhaite passer ce pointer dans un array de pointers de structure :

Code:



int* a[10];

int* myfunc_a() {
      int *x = 15;
      return x;
}

void myfunc_b() {
    a[0] = myfunc_a();
    a[0] = 10;
}


Le problème, c'est que lorsque je veux modifier la valeur de a[0] ou de ma structure, cela n'a aucun effet.

Une solution ?!

[Tryphon]

Alors :

* il n'y a aucune structure dans ce code

* je ne comprends pas du tout ce que tu veux faire

Déjà, es-tu sûr de vouloir un tableau de pointeurs sur des entiers ?

[Invité]

Alors :

* c'était un exemple si tu veux une structure en voici une :

Code:


typedef struct {
    u8 dead;
    u8 active;
    u8 initialized;
    fix32 posx;
    fix32 posy;
    fix32 speed;
    u8 type;
    u32 lastFrameShot;
    Sprite *sprite;
} Enemy;

Enemies* enemies[10];



Par la suite, je voudrais générer des ennemis et de pouvoir les modifier librement.

Par exemple je voudrais appeler la fonction Enemy* addEnemy(s16 type); qui va me retourner un enemy puis de le modifier à guise en faisant un enemy[0]->posx += FIX32(2.5); par exemple.

Le truc c'est que je veux créer une liste d'ennemie un à un puis des les modifier un à un sans devoir parcourir tout le tableau.

[Tryphon]

Si j'ai bien compris, ton tableau doit être de type Enemy (pas Enemy*) :

Code:

Enemy enemies[12];

En C, un tableau est un pointeur sur son premier élément.
Donc par exemple ta fonction addEnemy peut ressembler à un truc :

Code:

Enemy *addEnemy(s16 type) {
    Enemy *current;

    current = enemies;
    while (c'est pas fini) {
        if (c'est le bon) return current;
        current++;
    }
    return (un truc pour montrer qu'on a rien trouvé, NULL par exemple)
}


[ichigobankai]

en complement,
pour ta liste d'ennemis initiale de ta zone/level, il ne faut pas le faire 1 à 1 "à la main" mais plutôt via des datas mis en rom et charger d'un coup toutes les valeurs via un memcpy()
(à faire quand ton code est fonctionnel/propre, au départ pour tester/mettre en place "à la main" ca suffit ^^)

[Hpman]

Mouais ça se discute, dans la plupart des cas c'est fait derrière un écran de transition, une ou deux frames d'écran noir en plus ça va pas changer grand chose.

Si le but ici est de récupérer un handler d'ennemi libre, je conseille de faire une pile.
On dépile quand on à besoin d'un élément, on empile quand on en libère un.
Une autre pile pour lé éléments actifs et ça élimine tout les parcours de tableau ainsi que les flags actif/inactif.

[Invité]

Oui @Hpman je trouve que c'est très contraignant d'avoir une pile et devoir chercher une place libre surtout que les scripts sont au cas par cas.

Je pense que l'idéal comme tu le soulignes serait d'avoir plusieurs piles pour chaque vague d'ennemis, car les comportement sont tous très différents et je veux éviter d'avoir un truc générique.

Par exemple, j'ai besoin de dire que trois ennemis devront faire tel déplacement, à telle vitesse et à tel moment. Donc si je mélange ces ennemis dans une pile où d'autres ennemis font autre chose, c'est compliqué de s'y retrouver.

Sinon je devrais leur donner un ID pour les identifier avec en prime une indication sur leur numéro de vague.

[Hpman]

Bah le principe de la pile est justement de ne pas à avoir à chercher de place libre. Une pile "freeObjs" ne contient que des objets libres, tu prends celui du dessus et basta.

Il faut mettre un pointeur de fonction dans ta structure. Quand tu crée l'ennemi tu renseigne le pointeur avec la fonction correspondant au comportement de cet ennemi.
Ensuite tu parcours la pile des objets actifs pour appeler la fonction de comportement pointée par chaque objet. Que les objets soient différents n'a pas d'incidence.

[Invité]

Ah je savais pas du tout que c'était possible de faire ça !!

[Tryphon]

C'est pas de l'info "de base" Shingo, c'est des structures de données.

Tu dépasses le stade de codeur du dimanche quand tu connais les structures de base (pile, file, liste, tableau...) et leurs avantages/inconvénients en terme de complexité. Ça s'appelle l'algorithmique, et c'est indépendant du langage.

Mais sur ce forum, c'est souvent un peu tabou d'en parler.

Je plussoie fortement l'idée d'Hpman.

[Invité]

Ah je savais pas qu'on arrivait à ce stade

J'ai mis en place ce qu'à dit @Hpman et ça marche très bien. C'est très pratique du coup et je peux donc rapidement créer mes scripts puis de les affecter à des ennemis durant leur initialisation, donc d'un coup.



Merci les amis !

[Invité]

Voilà ce que donne la génération de mes ennemis :

Code:

void waveInit(u8 nbr)
{
    if(nbr == 1)
    {

        enemyAdd(1, FIX32(SCREEN_WIDTH), FIX32(80), FIX32(10), script_1);
        enemyAdd(1, FIX32(SCREEN_WIDTH), FIX32(80), FIX32(20), script_1);
        enemyAdd(1, FIX32(SCREEN_WIDTH), FIX32(80), FIX32(30), script_1);

        enemyAdd(1, FIX32(250), FIX32(230), FIX32(40), script_3);
        enemyAdd(1, FIX32(250), FIX32(230), FIX32(50), script_3);
        enemyAdd(1, FIX32(250), FIX32(230), FIX32(60), script_3);
    }
    else if(nbr == 2)
    {

        enemyAdd(1, FIX32(SCREEN_WIDTH), FIX32(65), FIX32(350), script_1);
        enemyAdd(1, FIX32(SCREEN_WIDTH), FIX32(65), FIX32(360), script_1);
        enemyAdd(1, FIX32(SCREEN_WIDTH), FIX32(65), FIX32(370), script_1);
        enemyAdd(1, FIX32(SCREEN_WIDTH), FIX32(65), FIX32(380), script_1);

        enemyAdd(1, FIX32(SCREEN_WIDTH), FIX32(165), FIX32(350), script_1);
        enemyAdd(1, FIX32(SCREEN_WIDTH), FIX32(165), FIX32(360), script_1);
        enemyAdd(1, FIX32(SCREEN_WIDTH), FIX32(165), FIX32(370), script_1);
        enemyAdd(1, FIX32(SCREEN_WIDTH), FIX32(165), FIX32(380), script_1);
    }
}

Vous aurez remarquez l'appel de la fonction qui est un pointeur de fonction ^^

Cela me simplifie la tâche comme pas possible.

[Stef]

Ah je savais pas qu'on arrivait à ce stade

J'ai mis en place ce qu'à dit @Hpman et ça marche très bien. C'est très pratique du coup et je peux donc rapidement créer mes scripts puis de les affecter à des ennemis durant leur initialisation, donc d'un coup.



Merci les amis !

Comme le dit Tryphon, c'est plus de l'algorithmie que de la programmation et c'est effectivement important de bien connaitre les structures de données efficaces selon les cas d'utilisation...
Tu peux toujours t'inspirer de ce qui est fait dans SGDK, souvent j'essai d'utiliser des structures pas trop débiles histoire que ça reste rapide (on est sur une Megadrive, pas sur un PC ^^). J'ai justement utilisé une pile pour l'allocation dynamique des sprites (que ce soit dans le sprite engine comme dans la gestion plus "bas niveaux", fonction allocateSprite / releaseSprite dans les 2 cas).

[Invité]

@Stef oui d'ailleurs saches que je m'inspire toujours du code source de SGDK. Quand j'ai un doute sur la façon de faire, je regarde ce que tu as fais ne serait-ce que pour garder la même convention. J'avais effectivement le "next" dans la structure Sprite.

Pour le moment j'utilise encore un array que j'ai limité à 10 pour ne pas faire de bêtises et faire planter le programme si je dépasse.

Sinon pour contrôler la liste, il faudrait une variable enemyCount afin de savoir où j'en suis.

[Stef]

@Stef oui d'ailleurs saches que je m'inspire toujours du code source de SGDK. Quand j'ai un doute sur la façon de faire, je regarde ce que tu as fais ne serait-ce que pour garder la même convention. J'avais effectivement le "next" dans la structure Sprite.

Pour le moment j'utilise encore un array que j'ai limité à 10 pour ne pas faire de bêtises et faire planter le programme si je dépasse.

Sinon pour contrôler la liste, il faudrait une variable enemyCount afin de savoir où j'en suis.

Oui exactement, il faut garder le nombre d'élément actuellement alloué / utilisé :)
C'est une bonne chose de garder une certaine cohérence en terme de convention aussi, bien sûr on a chacun nos conventions de nommage etc... mais être cohérent avec ce qui existe ça permet de s'y retrouver plus rapidement aussi pour quelqu'un d'extérieur au projet.