Discussion :

[ternel]

J'ai passé une vraie heure dessus.
Il y a plusieurs problèmes de logique et de conception.

Par exemple, tu attends volontairement la fin du cycle pour charger l'image suivante.
Tu initialises plusieurs tableaux très tardivement.

Il manque de nombreuses enum et vectors
Tu devrais avoir une map<int, Texture>, qui propose plusieurs fonctions comme count(id), et [], qui permettent de charger plus facilement les textures.

Je te recommande vraiment de suivre nos conseils de restructuration.

[Armulis]

Première remarque.
réduire main à un unique appel de fonction, qui est définie seule dans un unique fichier, c'est s'embetter pour rien.

Je sais bien que c'est complètement inutile, mais on m'a dit que c'était obligatoire ^^
En fait, personnellement je pars du principe que si je veux, je peux tout mettre dans le main. Je ne le fais pas pour que mon code soit plus facile à lire.
Cela-dit, plus j'ajoute des trucs à mon programme, plus j'ai de problèmes de droit d'accès. Je passe mon temps à passer des données des fonctions aux classes, des classes aux fonctions, et c'est hyper lourd!

Après, concernant la réécriture de mon programme, je veux bien une proposition de ta part (même si je n'en demandais pas autant), mais j'aimerais bien m'y retrouver aussi, alors essaie de ne pas aller trop loin pour l'instant. =)

Information: la variable entière "load" est justement là pour que les chargements s'effectuent en sautant les attentes. C'est tout à la fin de "MenuPrincipal", regarde mieux. J'ai essayé avec et sans, et je gagne des secondes rien que pour charger cette poignée d'images =D

Il y a beaucoup de détails sur lesquels je sais bien qu'on peut faire mieux. Mais je préfère ne pas spammer ce forum (et d'autres) en posant toutes les questions qui me viennent à l'esprit.

[ternel]

En fait, il faut quasiment réécrire la moitié de ce que tu as montré.
Ca fait trop de boulot pour l'instant, je suis au travail

Je t'invite à lire les deux articles suivants:

• le pattern état par pcaboche
• le pattern état par r0d

Ce dernier étant mon préféré.

Une autre chose est envisageable: avoir un thread dédié à l'animation.

[Armulis]

(Il y a quelques temps) J'ai un peu regardé comment fonctionnaient les threads, mais je préfère m'abstenir: c'est trop haut-niveau à mon avis.
Pour détailler un peu, j'ai compris que les threads permettaient grosso modo de faire fonctionner plusieurs programmes en même temps, et ce serait du genre autonome (donc j'en aurais pas le contrôle). Je préfère faire ma propre structure pour garder le contrôle total de ce qui se passe (ce qui marche déjà assez bien avec le chargement de mon menu principal).

Je regarde. Bon, après 5 minutes je suis déjà bloqué sur "this", donc ça commence bien ^^

[ternel]

this est un pointeur (constant) vers l'objet sur lequel est appelée la fonction membre.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
class Bidule() {
public:
    Bidule& f() {
        return *this;
    }
};
 
int main() {
    Bidule a, b;
 
    a.f(); //retourne a;
    b.f();// retourne b;
}

Pour être un peu plus complexe:
Quand le code est compilé, int Bidule::f() devient la fonction suivante: int "Bidule::f"(Bidule * const this).

De même, certaines classes ont des fonctions marquées const

Code :

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

1
2
3
4
5
6
class Bidule() {
public:
    int valeur() const{
        return 12;
    }
};

le code généré est l'équivalent de int "Bidule::valeur"(Bidule const* const this).

Ce const permet de manipuler un pointeur vers une valeur constante.

[Armulis]

Le premier exemple est d'une rare inutilité, mais ça aide à comprendre ^^

Il faut travailler avec des pointeurs pour en avoir l'utilité?

[ternel]

Pour les threads, non, ce ne sont pas des programmes autonomes.

C'est du code parfaitement maitrisé, parce que c'est le tien uniquement, mais exécuté en parallèle d'une autre partie de ton code.

En gros tu auras deux fonctions appelées en même temps.

Il y a alors la difficulté nouvelle de s'assurer que les deux codes n'aille pas faire des âneries dans le deux l'un de l'autre.

Oublie pour le moment.

C'était juste une suggestion pour l'avenir.
Tu aurais un thread qui s'occupe de l'affichage (dont la barre de chargement) et un autre qui charge effectivement les images.
Quand ce deuxième aura fini, le premier pourrait s'en apercevoir et passer à la suite.
Je dois dire que je n'ai pas encore codé ce genre de chose en C++, mais c'est tout à fait faisable.

[Armulis]

Je vois, merci. Pour l'instant je vais m'en passer. Je m'en sors déjà pas mal à ce niveau.
En fait, j'ai surtout peur des threads parce que ça pourrait trop en demander à la machine, et ça pourrait la ralentir.

Dans mon "MenuPrincipal.cpp", j'ai fait une structure qui "gère son temps" et qui affiche tout très correctement, donc pour l'instant ça va encore assez bien.

Vous remarquerez qu'au-delà d'être bêtement "illisible", mon programme fonctionne un peu comme un mécanisme (venant d'un mécanicien ça vous étonne?), et la "boucle Z" (while-switch-switch) fonctionne un peu comme un aiguillage. Passé cette constatation, le truc est pas difficile à lire, je trouve. En tout cas, ça permet de bien garder la vision d'ensemble et c'est très représentatif du programme tel qu'il doit apparaître à l'écran.

[ternel]

Ton programme serait beaucoup plus lisible avec des fonctions dédiées:

imagine l'en-tête suivant:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
name spacegame {
//une forward declaration, qui permet juste de déclarer que la classe existe sans la définir. Utile pour réduire les inclusions, et donc temps de compilation
class Game;
}
 
namespace application_states {
enum app_state {AS_INTRO, AS_HOME, ..., AS_MINIGAME}
 
app_state intro(Game&);
app_state home(Game&);
//...
 
}

Essaie juste de modifier ton code pour utiliser ca.

concernant le main.
Utiliser une seule fonction énorme, c'est exactement rejeter le probleme une case plus loin.

La réalité du principe derrière c'est:

Une fonction devrait ne faire qu'une seule chose, mais bien.

Ce qui implique des considérations sur la taille d'une fonction.
Personnellement, je considère qu'au delà de trois commentaires dedans, elle est trop complexe à comprendre, et que je devrais la diviser en fonction plus petites et précise.

ps: et arrête de me dire vous, je ne suis pas vieux du tout...

[Armulis]

Essaie juste de modifier ton code pour utiliser ca.

Heu... non, d'abord il faut que j'apprivoise ça, parce que même si je comprends vaguement à quoi ça sert (et c'est surtout parce que ça devrait faire la même chose que mon programme ^^), je suis pas au-clair avec une seule ligne de ce petit bout de programme. Il faut que je potasse, là, et apparemment c'est du lourd.

Mais j'ai une question importante, du coup: le temps de compilation est-il représentatif de la vitesse d'exécution?
Je demande parce que tu parles d'accélérer la compilation.
Actuellement, mon compilateur fait le tour de mon programme en 5 ou 6 secondes, et j'ai d'autres priorités que d'essayer de le faire faire la même chose en 4 secondes.
Je rejette pas ta solution, mais c'est juste que là, je crois qu'on s'intéresse à la couleur de la machine plutôt que de préoccuper de celle du produit...

[ternel]

En fait, je t'ai donné une raison, parmi plein d'autre.

J'aurai pu mettre directement #include "game.h".

C'est juste que j'en ai profité pour te montrer ca aussi.

le namespace sert à rendre le code plus propre.

Mets toutes tes variables "globales" dans une classe (ou struct) Game, et adopte ces fonctions.
Tu verras que ca ne change pas grand chose, mais ca te permetttra de réduire ton code et d'augmenter sa localité.

L'intérêt, c'est que du coup, ton code sera plus facile à débugger.

Le code de mon dernier exemple devrait remplacer le contenu de ton menu_principal.h

idéalement, tu aurais les fichiers suivants:

• main.cpp
• application_states.h
• app_state_intro.cpp
• app_state_home.cpp
• ...
• vignette1.h
• vignette1.cpp
• texte1.h
• texte1.cpp

J'en profite pour souligner que "texte1", c'est vraiment pas explicite comme nom.

[Armulis]

texte1 n'est pas explicite, mais au-moins c'est court. Le code-source c'est pas tout: j'ai une documentation manuscrite à-côté.

Une fonction ne peut faire qu'une chose... oui, et..?
C'est pas un principe ça, c'est juste la seule solution! La seule autre solution c'est de découper une fonction en 5 petites fonctions, mais si c'est pour faire 5 appels à la fois ça sert pas à grand-chose...
Je comprends pas le principe...

[moldavi]

Bonjour.

Le problème survient lorsque le programme lit ces deux lignes. Le programme crashe complètement et je suis obligé de le fermer.

Code :

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

texte1.setString(txt[0]);   texte2.setString(txt[16]); // J'utilise SFML pour ça

Le tableau est initialisé de la manière suivante:

Code :

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

string txt[32];

La fonction "setString" de la SFML attends un string en entrée : http://sfml-dev.org/documentation/2....sf_1_1Text.php


// Cela n'a pas de sens : "blablabla" est un tableau de char, pas un string
texte1.setString("blablabla");"

// Cela a plus de sens, szBlaBla est un string
string szBlaBla = "blablabla";
texte1.setString(szBlaBla);"

// La classe string a un constructeur pour cela, mea culpa.

J'imagine que "setString" de la SFML est contenue dans une dll. Je verrais bien un problème Debug/Release. L'exécutable est compilé en mode Debug et la dll est en mode Release. Il faut que l'exécutable et la dll soient dans le même mode de compilation. Enfin c'est une piste à suivre.

Sous Visual Studio, c'est fatal. Le type string compilé en Debug est incompatible avec le type string compilé en mode Release, et vice versa.

[Armulis]

Merci moldavi, mais je ne savais pas que les .dll existaient en version debug et en version release.
Mais je ne sais pas comment générer ces fichiers. On me les a donnés quand j'ai commencé d'apprendre à utiliser SFMl, et on m'a dit qu'après avoir compilé, ça créerait un dossier "bin" contenant un dossier "debug" ou "release", et que je devrait coller ces fichiers dedans.
Tu peux m'aider à résoudre ça?

[moldavi]

Re.

Ici pour Code::Blocks : http://sfml-dev.org/tutorials/1.6/start-cb-fr.php

Pour Visual Studio ici : http://www.sfml-dev.org/tutorials/1.6/start-vc-fr.php

Important : pour la configuration Debug, il est impératif de lier avec les versions de débogage des bibliothèques SFML, qui sont suffixées par "-d" (sfml-system-d.lib ou sfml-system-s-d.lib dans ce cas). En effet, mélanger configurations Debug et Release peut résulter en de multiples erreurs ou crashs.

Ce message est aussi valable pour les dll.

Tu peux récupérer les fichiers de la SFML ici : http://www.sfml-dev.org/download-fr.php

[Armulis]

Alors...
J'ai écrit quatre trucs à la main (-lsfml-graphics, -lsfml-window et -lsfml-system dans "Linker settings, et SFML_DYNAMIC dans "Compiler settings")
J'ai aucune idée de si c'est censé marcher ou pas, mais mon programme bug toujours pareil =)

[moldavi]

Re.

Je ne vois pas les -d pour Debug.

Devant un tel problème, il faut simplfier les choses :

Code :

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

1
2
3
4
5
6
7
8
 
 
void main(){
 
  sf::Text sfTest;
  string szTest = "test";
  sfTest.setString(szTest);
}

Ensuite, compiler en mode debug/Release, mettre les dll qui vont bien, dans les bons dossiers. Ensuite, attention, le fait de lancer le programme depuis l'éditeur peut nécessiter de mettre les dll dans le même dossier que la base du projet. Le mieux est de lancer l'exécutable depuis le répertoire Debug ou Release pour tester (click sur l'exe qui se trouve dans le répertoire debug ou Release).

[Armulis]

Attention: main doit toujours renvoyer un int! =)

Alors ça marche, mais c'est pas affiché (puisqu'on a pas créé de fenêtre =)
Je dois essayer de créer une fenêtre?

[moldavi]

Alors ça marche, mais c'est pas affiché (puisqu'on a pas créé de fenêtre =)
Je dois essayer de créer une fenêtre?

La bonne nouvelle, c'est que le programme ne plante pas. Donc il faut partir sur cette base pour corriger le reste, et trouver ce qui cloche.

Attention: main doit toujours renvoyer un int! =)

Oui. Mais vois-tu, lorsque je teste un programme, je me moque complètement qu'il retourne une valeur, car cela n'intéresse personne. Enfin sous Visual Studio, cette utilisation de "main" est possible, et lorsque je teste des programmes, j'en abuse...

[Armulis]

Je dois reconstruire complètement la classe "Vignette1" (qui bug), ligne par ligne?
Mais ça va juste me dire quelle ligne ne fonctionne pas, et je sais très bien laquelle c'est. Tu as vu le rapport de debuggage?