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

[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^^).

[Orion_]

exactement, le compilateur détecte que ton code ne fait rien dans tout les cas, et donc il le supprime tout simplement du programme final.
c'est clair qu'avec un processeur à 8Mhz, faire de la détection de collision de plein d'objets et en C, ça va ramer sévère, il va falloir optimiser le code ou bien réduire drastiquement le nombre d'objet si tu ne veux pas passer en assembleur.
Sinon, si tu connais l'assembleur, tu peu regarder le code généré par le compilateur C pour cette partie la, et voir si y'a pas moyen de donner des indices au compilateur pour qu'il génère un code assembleur moins lourds, par exemple, au lieux d'avoir des coordonnées sur "int" 32bits, tu peu les mettre en "short" 16bits, ou bien faire tes opérations directement dans la boucle plutôt que d'appeler une fonction à chaque itération (car un appel de fonction avec passage de paramètres ça ralenti)

Je sais pas a combien sont tes #define, mais dans le pire des cas tu a  MAX_ENEMIES * MAX_PLAYER_BULLETS * 2 appels de fonction
Pour avoir de la rapidité, il faut oublier la programmation "propre"

[Invité]

@Orion_ merci beaucoup pour ces explications, je crois avoir trouver le problème, en tout cas c'est fluide comme pas possible, mais dans ma fonction bulletUpdate(), il semble que je demandais deux fois la même action..

Je m'explique, j'indiquais qu'en cas de collision avec un ennemi, il fallait supprimer le projectile, hors je demandais également que si le projectile sort de la scène de combat, il devrait être supprimé.

J'ai dû d'abord vérifier si le projectile était sorti de l'écran puis faire une else pour vérifier la collision.

En fait le problème, je pense, c'est que comme je ne suis plus vraiment dans la boucle, le fait de supprimer la bullet puis après de faire une vérification de chaque collision avec les ennemis, bah ça consomme !

[Tryphon]

(message écrit en même temps que le tien, j'en ai donc pas tenu compte)

Je ne pense pas que ça soit ça, mais je ne déclarerais pas une variable (ennemy et a) à l'intérieur d'une boucle. Je déporterais tout ça au début de la fonction.

C'est quoi le code de bulletCheckCollision ?

Sinon on n'écrit pas :

Code:

if (bidule == TRUE)

mais

Code:

if (bidule)

(et if (!bidule))

(c'est purement esthétique)

[Invité]

@Tryphon, pourtant dès que j'ai mis une condition, le jeu est devenu tout de suite fluide ! Plus aucun problème sauf la vague où t'as 27 ennemis qui se promènent à l'écran ^^

Sinon pour le code de la fonction :

Code:


bool bulletCheckCollision(Bullet *bullet, Enemy *enemy)
{

    if((bullet->sprite->x >= enemy->sprite->x + enemy->box.w)
      ||(bullet->sprite->x + bullet->box.w <= enemy->sprite->x)
      ||(bullet->sprite->y >= enemy->sprite->y + enemy->box.h)
      ||(bullet->sprite->y + bullet->box.h <= enemy->sprite->y))
    {
        return FALSE;

    }
    else
    {
        return TRUE;
    }
}

[Hpman]

Ouais, utilises un tableau de pointeurs pour les boulettes et les ennemis actifs. (Quand tu pop un ennemi tu l'ajoutes à la liste et inversement quand il despawn)

Comme ça tu ne check que le contenu des listes et éjecte tout les "if bidule=condition"

Devrais donner quelque chose du genre:

Code:

Bullet *activeBullets[MAX_PLAYER_BULLETS+1];
Enemy *activeEnemies[MAX_ENEMIES+1];

//...

Bullet **bltPtr=activeBullets;
Bullet *blt;
Enemy **enyPtr;
Enemy *eny;

while(blt=*bltPtr++) {
 bulletUpdate(blt);
 
 enyPtr=activeEnemies;
 while(eny=*enyPtr++) {
 if(bulletCheckCollision(blt,eny)) {
 // do things
 }
 }
}

Ici les listes doivent êtres terminées par une entrée null.

Ensuite faut voir ce que fait la fonction de check, mais eviter l'appel et intégrer le code directement fera effectivement gagner pas mal de temps.

[Tryphon]

@Tryphon, pourtant dès que j'ai mis une condition, le jeu est devenu tout de suite fluide ! Plus aucun problème sauf la vague où t'as 27 ennemis qui se promènent à l'écran ^^

J'ai pas dit qu'il fallait pas mettre de condition, je dis qu'écrire "if (variable_booleenne == TRUE)" équivaut à écrire "if (variable_booléenne)" tout court.

Sinon pour le code de la fonction :

Code:


bool bulletCheckCollision(Bullet *bullet, Enemy *enemy)
{

    if((bullet->sprite->x >= enemy->sprite->x + enemy->box.w)
       ||(bullet->sprite->x + bullet->box.w <= enemy->sprite->x)
       ||(bullet->sprite->y >= enemy->sprite->y + enemy->box.h)
       ||(bullet->sprite->y + bullet->box.h <= enemy->sprite->y))
    {
        return FALSE;

    }
    else
    {
        return TRUE;
    }
}

Trop de ->. Tu devrais prévoir, dans ta structure de base (celle dont bullet, ennemy, player sont des instances), des champs left, right, top, bottom, que tu calcules une seule fois, lorsque tu fixes la position de l'objet.

Parce que là, pour chaque collision, tu recalcules les coordonnées des 4 bords.

[Invité]

Personnellement, j'ai ma solution "maison" pour le calcul de collision :

Code:


IntervalleX=12; // Ou bien tout mettre à 12 dans la condition si dessous.

IntervalleY=12;

Xc=abs(XObjet-XProj);

Yc=abs(YObjet-YProj);

if (Xc<IntervalleX && Yc<IntervalleY) // Ou if ( Xc<12 && Y<12)

{

 PanpanCulul();

}


C'est rapide, simple ... Fais des tests pour voir !
Après, c'est juste l'algorithme de base .. Faut l'adapter avec une structure ou pointeur de structure.
C'est ce que j'utilise pour tous mes jeux MD d'action et j'en suis toujours satisfait.

[Invité]

@Tryphon quand tu dis calculer une seule fois lorsque je fixe la position, tu parles bien à chaque fois que je fais un SPR_setPosition() ?

@Vetea je testerais ton algo ce soir, ça m'a l'air plutôt simple et fonctionnel !

Par contre, si je dois éviter de passer par des fonctions et tout mettre dans une fonction et/ou de tout mettre dans une boucle, les pointers sont vraiment utiles dans ce cas ?

[Hpman]

On peut aussi remanier le checkCollision pour éviter d’évaluer les 4 conditions à chaque fois:

Code:

bool bulletCheckCollision(Bullet *bullet, Enemy *enemy)
{
    if(bullet->sprite->x < enemy->sprite->x + enemy->box.w)
    if(bullet->sprite->x + bullet->box.w > enemy->sprite->x)
    if(bullet->sprite->y < enemy->sprite->y + enemy->box.h)
    if(bullet->sprite->y + bullet->box.h > enemy->sprite->y)
        return TRUE;

    return FALSE;
}


La on fout le camp dès la première condition fausse.

[Orion_]

Le compilateur optimise exactement de la même manière, même si on met plusieurs condition dans un If, dès qu'une condition est fausse on sort directement
la vraie optimisation ici serait de ne pas faire une fonction juste pour un IF, car l'appel a la fonction prend du temps, donc faire le IF directement dans la boucle, ou alors utiliser un #define ou un inline

[Invité]

Effectivement, j'ai déplacer le code de bulletUpdate() directement dans la boucle avec la détection de collision, la différence de performance est perceptible.

[Hpman]

Le compilateur optimise exactement de la même manière, même si on met plusieurs condition dans un If, dès qu'une condition est fausse on sort directement
la vraie optimisation ici serait de ne pas faire une fonction juste pour un IF, car l'appel a la fonction prend du temps, donc faire le IF directement dans la boucle, ou alors utiliser un #define ou un inline

J'ai pas confiance 

[Tryphon]

@Tryphon quand tu dis calculer une seule fois lorsque je fixe la position, tu parles bien à chaque fois que je fais un SPR_setPosition() ?

Dans ennemyUpdate, bulletUpdate, quand tu calcules la nouvelle position de l'ennemy, bullet, etc.

Je ne sais pas comment tu détermines bullet->sprite->x à partir de bullet->x (je suppose que bullet->x est au milieu de la boulette, alors que bullet->sprite->x est à gauche), mais moi je fais :

// calcul de bullet->x

bullet->left = bullet->x - bullet->offset_x ;
bullet->right = bullet->left + bullet->width

bullet->sprite->x = bullet->left // chez moi je soustrais camera->left

// pareil pour y, top, bottom

C'est un peu plus long lors de l'update, mais du coup tu ne recalcules pas les bords du sprite à chaque test de collision.

@Vetea je testerais ton algo ce soir, ça m'a l'air plutôt simple et fonctionnel !

Par contre, si je dois éviter de passer par des fonctions et tout mettre dans une fonction et/ou de tout mettre dans une boucle, les pointers sont vraiment utiles dans ce cas ?

La méthode de Vetea est plus simple et efficace, mais suppose deux choses :

1) ton sprite est centré horizontalement et verticalement (ce qui doit être le cas dans un schmup, mais pas dans un plateformer où le hotspot est en général en bas), ce qui lui permet d'utiliser un abs (je ne pense pas que ça accélère beaucoup cependant : un abs + une comparaison, ça doit être kif-kif avec deux comparaisons)

2) tes sprites font tous le même "rayon" (12 pixels ici). C'est surtout ça qui fait que sa méthode est rapide : calculer x + 12 est beaucoup plus rapide que calculer x + y.

Le compilateur optimise exactement de la même manière, même si on met plusieurs condition dans un If, dès qu'une condition est fausse on sort directement
la vraie optimisation ici serait de ne pas faire une fonction juste pour un IF, car l'appel a la fonction prend du temps, donc faire le IF directement dans la boucle, ou alors utiliser un #define ou un inline

+1 aux deux (le compil optimise des || et des && dans les tests et inliner la fonction). Mais je dirais que ça, c'est de l'optimisation de fin de cycle, quand ton code est bien structuré et propre.

[tetsuro]

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

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

C'est pas forcément mal sur PC, ça dépend surtout de ta modularité, de ton projet, de comment tu veux travailler avec tes fichiers et tes fonctions. Dans mon cas je les aient évitées au maximum dans un projet de shoot, en créant des fichiers séparés pour chaque grosses fonctions du jeu et je me suis retrouvé malgré moi obligé d'utiliser des globales pour articuler le jeu et ce faire interagir les différentes parties, enfin bon j'imagine qu'il y a toujours moyen, mais si elles existent c'est que dans certains cas elles sont vraiment utile, y'a pas de mal absolu si toi tu sais les utiliser et que tu t'y retrouve. Si tu lis un livre comme le K&R, tu ne lira jamais que c'est mal, ils t'expliquent juste comment les utiliser et à toi de voir :)

[Hpman]

Voila, on gagne un branch (10 cycles) pour un return false (cas le plus fréquent)

J'ai pas fait tout ça pour rien! 

[Tryphon]

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

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

C'est pas forcément mal sur PC, ça dépend surtout de ta modularité, de ton projet, de comment tu veux travailler avec tes fichiers et tes fonctions. Dans mon cas je les aient évitées au maximum dans un projet de shoot, en créant des fichiers séparés pour chaque grosses fonctions du jeu et je me suis retrouvé malgré moi obligé d'utiliser des globales pour articuler le jeu et ce faire interagir les différentes parties, enfin bon j'imagine qu'il y a toujours moyen, mais si elles existent c'est que dans certains cas elles sont vraiment utile, y'a pas de mal absolu si toi tu sais les utiliser et que tu t'y retrouve. Si tu lis un livre comme le K&R, tu ne lira jamais que c'est mal, ils t'expliquent juste comment les utiliser et à toi de voir :)

Les variables globales sont considérées depuis pas mal de temps déjà comme de mauvaises pratiques, pour des raisons plus ou moins d'enculage de mouches (certaines sont fondées).

Sur de vieilles machines, ça se défend pour des raisons de performances.

Le K&R n'est clairement pas un exemple de bonnes pratiques de programmation, il commence quand même à dater

[Invité]

J'ai testé le calcul de collision de @Vetea et ça marche très bien, je suis étonné qu'avec aussi peu de calcul ça marche au poil !

Le fait de mettre tout le code dans la boucle sans fonction externe est ULTIME, j'ai zéro lag avec une tonne de sprite à l'écran !

Par contre, c'est super, c'est fluide comme pas possible, mais c'est vraiment difficile de s'y retrouver quand même. Je me demande si ce n'est pas mieux de faire ce genre de chose vers la fin, parce que je crois que je vais m'arracher les cheveux lorsque je voudrais corriger ou ajouter du code.

[Tryphon]

Voila, on gagne un branch (10 cycles) pour un return false (cas le plus fréquent)

J'ai pas fait tout ça pour rien! 

Mais tu ne fais quand même pas tous les tests s'ils ne sont pas nécessaires dans les deux cas

Mais j'avoue que je ne comprends pas pourquoi ce n'est pas strictement équivalent.

Je ne comprends pas non plus le cmp.l a0, a2 à la fin.

Au passage, tester la collision horizontale (plus fréquente dans un shoot horizontal) avant la verticale est un poil plus efficace.

[Tryphon]

Par contre, c'est super, c'est fluide comme pas possible, mais c'est vraiment difficile de s'y retrouver quand même. Je me demande si ce n'est pas mieux de faire ce genre de chose vers la fin, parce que je crois que je vais m'arracher les cheveux lorsque je voudrais corriger ou ajouter du code.

C'est pour ça qu'il faut optimiser à la fin.

Sinon, utilise des fonctions inline !

[Invité]

Le problème c'est que pour comprendre l'intérêt d'utiliser des pointeurs, il fallait que je vois la différence niveau performance ^^

Voilà ce que ça donne avec l'essentiel dans la boucle update :

[Hpman]

Voila, on gagne un branch (10 cycles) pour un return false (cas le plus fréquent)

J'ai pas fait tout ça pour rien! 

Mais tu ne fais quand même pas tous les tests s'ils ne sont pas nécessaires dans les deux cas

Mais j'avoue que je ne comprends pas pourquoi ce n'est pas strictement équivalent.

Je ne comprends pas non plus le cmp.l a0, a2 à la fin.

Au passage, tester la collision horizontale (plus fréquente dans un shoot horizontal) avant la verticale est un poil plus efficace.

Euh en l’occurrence il se barre à la première occurrence fausse dans les deux cas.

La différence doit être dans l’encapsulation de la valeur de retour dans un else dans une des deux fonctions. Apres je sais pas ce qui se passe dans le cerveau malade de GCC 

le cmp à la fin c'est juste la 4eme condition. C'est vrai qu'a droite il met true, puis fait le 4eme test et avise. Moi je dis la drogue c'est mal.

[Tryphon]

Euh en l’occurrence il se barre à la première occurrence fausse dans les deux cas.

Oui, c'est ce que je voulais dire (et c'est ce qu'Orion_ disait).

La différence doit être dans l’encapsulation de la valeur de retour dans un else dans une des deux fonctions. Apres je sais pas ce qui se passe dans le cerveau malade de GCC 

Tu utilises quel GCC ? Celui que Stef a mis dans les derniers SGDK ou le vieux 3.3 qu'il y avait avant ?

le cmp à la fin c'est juste la 4eme condition. C'est vrai qu'a droite il met true, puis fait le 4eme test et avise. Moi je dis la drogue c'est mal.

Oui, j'ai confondu avec un cmpa.

[Hpman]

J'ai compilé ça vite fait sur neo, donc c'est un vieux GCC 2.95.2.

J'imagine que ça change pas grand chose dans l'absolu, vu la faible complexité de la fonction.

A vrai dire pour vraiment gagner du temps faut la refaire à la main, parce que la il push/pop 5 registres alors qu'on doit pouvoir la faire avec juste les registres scratch.

[Stef]

J'ai compilé ça vite fait sur neo, donc c'est un vieux GCC 2.95.2.

J'imagine que ça change pas grand chose dans l'absolu, vu la faible complexité de la fonction.

A vrai dire pour vraiment gagner du temps faut la refaire à la main, parce que la il push/pop 5 registres alors qu'on doit pouvoir la faire avec juste les registres scratch.

Pour cette fonction ça ne devrait pas changer grand chose en effet...

Sinon pour les différentes version de GCC :
GCC 2.X est assez performant pour le 68000
GCC 3.X un peu moins
GCC 4 et 5 c'est la cata
GCC 6 et > c'est beaucoup mieux et tu profites de certaines améliorations comme le lto, ce qui fait qu'il inline assez facilement (genre ici il pourrait le faire).

Voici le code sous GCC 6.3 sachant que nos structures n'ont pas la même tête j'imagine...

Code:

bulletCheckCollision:
    movem.l #60,-(%sp)
    move.l 20(%sp),%a1
    move.l 24(%sp),%a0
    move.l (%a1),%a5
    move.w 24(%a5),%a3
    move.l (%a0),%a4
    move.w 24(%a4),%a2
    moveq #0,%d0
    move.w 8(%a0),%d0
    add.l %a2,%d0
    cmp.l %a3,%d0
    jle .L5
    moveq #0,%d0
    move.w 8(%a1),%d0
    add.l %d0,%a3
    cmp.l %a2,%a3
    jle .L5
    move.w 26(%a5),%a3
    move.w 26(%a4),%a2
    moveq #0,%d0
    move.w 10(%a0),%d0
    add.l %a2,%d0
    cmp.l %a3,%d0
    jle .L5
    moveq #0,%d0
    move.w 10(%a1),%d0
    add.l %d0,%a3
    cmp.l %a2,%a3
    sgt %d0
    ext.w %d0
    neg.w %d0
    movem.l (%sp)+,#15360
    rts
.L5:
    clr.w %d0
    movem.l (%sp)+,#15360
    rts

[drludos]

Je prends le train en route, mais ce post est une mine d'or d'idées d'optimisations poussées, donc certaines auxquelles j'aurai pas pensées !

J'ai pas encore tester la megadrive, mais je vais essayer d'appliquer quelques unes de vos techniques pour mes projets SNES et GB ! :)

@shingosama: ton jeu prend de plus en plus forme. La dernière vidéo, avec triple bullet et plein d'ennemis, rend vraiment bien. Je me répète, mais il me tarde de voir le premier boss :). Au fait, tu as prévu un mode "2 joueurs" ou jeu uniquement solo ?

@Hpman: serais-tu par hasard l'auteur de la DATlib pour Neogeo?

[Hpman]

Soit c'est ça soit j'ai payé pour mettre mon nom dessus 

[drludos]

Lol, c'est juste que j'avais pas fait le lien avant que tu ne mentionnes des tests de ton code ASM sur neogeo

Quand on y pense, c'est quand même rigolo de se dire que les trois meilleures librairies pour développer du homebrew sur console 16 bits sont toutes faites par des français (Stef sur SGDK, Alek sur PVSNESlib et toi sur DATlib).

Et du coup tu as des projets de jeux néogéo en cours ?
(si oui, je les ai pas vu sur ce forum !)

[Hpman]

Ouais ça fait beaucoup. Le made in France. 

J'ai rien de particulier dans les tuyaux a vrai dire je me suis replongé un peu dedans pour finir une maj qui traine depuis bien longtemps.

[Templeton]

Quand on y pense, c'est quand même rigolo de se dire que les trois meilleures librairies pour développer du homebrew sur console 16 bits sont toutes faites par des français (Stef sur SGDK, Alek sur PVSNESlib et toi sur DATlib).

Raaahh les 3 librairies m’intéresse, elles sont superbes ! Quand j'aurai terminé mes projets sur Atari, il va bien falloir faire un choix !

[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.