Discussion :

[Askerat]

Bonjour,

Comme dans mon précédent post, je suis toujours sur mon petit jeu de vaisseau. Actuellement le vaisseau (un carré bleu pour le moment ) se déplace bien. Seulement maintenant j'en suis à gerer les tirs ( shoots ) de celui ci. Et là j'ai un petit problème.

Le premier, c'est que durant le tir j'ai quelques soucis de lenteur. Comment je geres le tir ? Si on appui sur Espace, j'émet un signal shootAsked() qui va demander le tir à ma classe Weapon. Et là je lance un QTimer qui tourne, à chaque timeout() j'émet un signal qui envoie sur un slot qui lui incrémente un compteur, recalcule la nouvelle position du projectil et réactualise l'affichage du QRect ( le shoot ) via update(QRegion).

Je pense que cette méthode ne doit pas être la bonne vu comme ça rame lors du tir. Si quelqu'un a une autre facon de voir le truc, j'ai pensé à lancer un thread à la demande du shoot, mais le soucis c'est que si je tires plusieurs fois, je lance plein de threads du coup. Hors avec cette methode, je pensais juste modifier mes methodes/slots/signaux en ajoutant un indice qui sait quel projectil on met à jour. En gros l'idée c'était qu'au shoot on fait un new Projectil(); à l'impact on fait un delete le_projectil;. Bien entendu, il faudrait une gestion dynamique des tableaux du coup, pour pouvoir faire varier le nombre de tirs à l'écran.

Voilà, j'ai un peu avancé l'état de ma reflexion en plus du probleme actuel, ça permettra éventuellement à mes sauveurs de me rediriger si je fais fausse route.

Askerat.

[Askerat]

En fait, apres 4 heures de travail là dessus, je pense avoir trouvé la solution, je vais donc me répondre, et en profiter pour poser une autre question.

Le soucis je pense, venait du fait que je ne limitais pas les calculs, ça tournait pour recalculer tout le temps la position. J'ai donc ajouté un timer sur le déplacement du vaisseau, comme pour les projectils, et maintenant ça tourne. J'ai meme reussi à autoriser le lancement de projectils multiples. Cependant j'ai un soucis d'allocation mémoire.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
void Weapon::addAutoShootTimer()
{
int i;
 
    if(nbreProj == 1)
    {
        autoShootTimer = new QTimer[1]; // si c'est le premier proj on a besoin que d'une place dans le tableau.
        autoShootTimer[0].setParent(this); 
        autoShootTimer[0].start(5); // on lance le timer.
        return;
    }
 
    autoShootTimer = new QTimer[nbreProj]; // on change la dimension du tableau, la source du probleme est ici.
    for(i=0; i<nbreProj; i++)
    {
        autoShootTimer[i].setParent(this);
        autoShootTimer[i].start(5);
    }
}

Je sais que ce n'est pas bon, seulement en C j'aurai utilisé un realloc, là je n'arrive pas à l'utiliser convenablement, il s'agit là d'une solution temporaire ( c'était juste pour tester le tir multiple ). J'ai également tenter de passer par un tableau temporaire qui récupérait mes QTimer(), ainsi je pouvais utiliser un delete autoShootTimer; puis en recréer un de bonne dimension par la suite, seulement ça ne fonctionne pas non plus.

En esperant trouver secours, Askerat

[ZouBi]

Pourquoi faire un jeu avec Qt?

Pourquoi n'utilise tu pas d'autres librairies plus specialisé dans ces types d'application comme SDL?

[Askerat]

Eh bien mon but n'est pas forcément de faire un jeu, mais surtout d'apprendre le C++ et Qt via un aspect ludique. Puis le tutoriel de trolltech prend un petit jeu pour exemple, j'ai continué dans la lancée.

[IrmatDen]

Salut,

Les new/delete sont très couteux si tu n'utilises pas tes allocateurs qui agissent en réalité sur une mémoire pré-allouée... et encore. Donc fais un seul timer qui déclenche la mise à jour de tout les objets inclus. Sinon, tu inondes Qt sous un flot de timers event qui vont se marcher les uns sur les autres, décaler les temps etc...
Et comme tu ne delete[] même pas le tableau précédent, tout les timers précédent reste actifs: si tu tires 4 missiles, tu auras 10 timers actifs :/
Et le code associé au timeout sera effectué ce nombre de fois. Je te laisse imaginer les dégâts et la raison de la lenteur que tu peux constater
Tu n'as pas besoin d'autant de timer et surtout pas d'un tableau pour les stocker.

[Askerat]

Effectivement, entre temps j'ai un peu avancé, je n'ai plus que deux timers, un pour les déplacements du vaisseau, et un pour gerer les tirs. Cependant, si je met une fréquence de rafraichissement trop rapide, ça rame toujours.

Au dessus de 50ms ( pour le timer des tirs ) c'est correct, en dessous ca commence à ralentir.

[Gulish]

Salut,

Pour reprendre IrmatDen, je pense qu'un seul timer suffit. Tu peux faire un truc du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
connect(timer, SIGNAL(timeout()),maPartie, SLOT(update()))
(...)
void maPartie::update()
{
updateMouvement();
updateTirs();
updateBonus();
etc...
}

En faisant ça, je pense que tu augmenteras un peu tes performances, et tu simplifieras grandement la structure de ton programme.

A tester.

g.

[IrmatDen]

+1 pour un seul timer tant que tu n'utilises pas de threads.

Ensuite, pour les ralentissements, ça dépend de comment tu codes. Ta routine de dessin doit être optimisable, mais pour te donner des pistes faut qu'on en sache plus.
* As-tu des maps énormes?
* as-tu beaucoup d'objets à l'écran?
* Les redessines-tu tous à chaque frame?
* y'a-t-il une étape d'IA dont les calculs sont bruts?
Parce que 50ms c'est suffisant, mais ça ne devrait pas ramer en dessous.