Mes difficultés d'apprentissage face au C++

[Radigo]

Le graphcet a l'air trop précis pour définir une architecture de jeu. Je l'utiliserais plus pour détailler une IA, ou la Main Loop de ton moteur par exemple.

J'ai l'impression d'être perdu entre 2 concepts de moteurs selon toi :
- moteur graphique
- moteur de jeu

Pour moi les 2 doivent être dissociés. Ton moteur graphique ne devrait gérer que les fonctions très basiques et réutilisable : affiche un truc à telle position, efface-le, tourne-le. La plupart du temps tu n'en n'as pas besoin avec des frameworks accessibles. Et donc, ton moteur de jeu va consister en une main loop que tu pourra détailler comme suit :
- efface l'écran
- capte les inputs joueur
- calcule les positions du joueur et de ses tirs
- calcul les position des ennemis et de leurs boulettes
- calcul les collisions (ou alors tu l'intègre aux boulettes / ennemis à chaque update)
- déplace le décor
- joue les sons (ou alors intègre ça aux objets ennemis, joueur...)
- affiche tout

Avec des fonctions start / stop dans ta classe moteur qui lance / arrête la main loop et tu as une structure. Ensuite ton interface, tu la fait à part et c'est elle qui lancera start / stop ainsi que les initialisations (charge niveau 1, etc...). Le concept de main loop paraît désuet et lourd mais c'est ce qu'il y a de plus solide et précis pour un shmup. Tu va te retrouver avec des tableaux de sprites à parcourir à chaque frame mais en optimisant un chouilla tu peux arriver à faire bouger et collisionner pas mal de monde.

Je te conseillerai également de gérer l'IA unitairement pour chaque ennemi / boulette, pas sous forme de "moteur" générique.

[Gunny]

Bah moi, je me sers du grafcet parce que c'est un outil que je connais contrairement à d'autres langages de modélisation type UML et compagnie. J'ai pas besoin de rajouter une couche apprentissage supplémentaire sur mon apprentissage du langage et de la POO.

Je me sers effectivement du grafcet pour modéliser le fonctionnement de la boucle principale ( je ne connais pas de méthode différente s'il y en a ).

Je peux m'en servir pour décrire aussi très précisément un moteur, quel qu'il soit.

Et le must du must qui ne me servira pas immédiatement, quand on veut simplifier un grafcet et les schéma de fonctionnement, on peut faire apparaitre le parallélisme.

Faut que je commence à coder moi... Faire tous ces dessins, schéma ca commence à m'ennuyer xD

[Gunny]

Bon... J'ai compris pourquoi j'avais des gros problèmes de compilation avec wxwidgets...
C'était plutot des erreurs de lien
C'est qu'il faut spécifier dans le linker dans le bon ordre une dizaine de "lib" spécifique à windows dans les libs dispo dans le dossier de mingw.

Donc autant prendre les trucs préconfigurer de codeblocks qui en mettent surement trop, mais j'aurai pas à me poser de questions du genre : "Pourquoi le linker me sort ces erreurs ?"

J'ai commencé à regarder un peu comment fonctionne wxwidgets, et je dois avouer que c'est assez perturbant au début...

Alors si j'ai bien compris les headers et les commentaires...
On utilise une macro qui va se charger de "faire la fonction main" ainsi que de l'initialisation et l'instanciation de la fenêtre principale.

Un peu perturbant quand on a l'habitude comme moi d'avoir la fonction main qui sert un peu de séparateur entre les entêtes/prototypes et les définitions dans le fichier principal.

Maintenant que c'est compris, je vais pouvoir m'attaquer à un peu plus de codage plutot que d'essayer de comprendre comment ce truc fonctionne xD

Ah, j'ai finalement touché aux variables d'environnement de windows et installé QT. Bah je sais pas ce que j'ai merdé, mais en essayant d'ouvrir un projet exemple et en lancant une compilation, il merdouille à la compilation...

Je verrai plus tard si wxwidget me prend trop la tete pour aller du coter de QT...

[Gunny]

J'ai voulu voir du coté de QT si l'herbe est plus verte

Ben... Les débuts, non xD

M'enfin bon... Jvais lire la doc et voir si ca me plait plus que wxwidgets.

[Gunny]

Bon... En utilisant QT framework, j'arrive à ce que je veux
Le fonctionnement de QT me parait plus "naturel" rapport à wxwidgets ( du moins, en C++ ).

wxwidgets utilise un tas de macro un peu partout, et jsuis pas fan de cette approche.

QT SDK j'aime pas vraiment... Pas moyen de faire un truc avec l'EDI si on joue pas avec qmake en ligne de commande. De l'autre coté, framework + codeblocks, aucun soucis pour le moment...

On verra plus tard si je dois repasser par le SDK, mais pas pour le moment.