Discussion du développement

Tu veux dire que tu as lu plein de trucs sur la programmation mais encore rien écrit ? Dans ce cas du point de vue de l'apprentissage de la programmation la prochaine étape est à mon avis de tenter d'écrire un programme de 15 lignes qui marche, pas modifier un programme existant. C'est déjà bien assez compliqué comme ça comme tâche. Le problème d'un programme existant c'est qu'il vaut mieux bien comprendre ce que fait un bout de code et comment il s'agence avec le reste pour le modifier, alors qu'un petit programme autonome c'est plus simple. Après je comprends que ça peut être moins motivant qu'un projet de jeu qui tourne déjà un peu, mais essaie aussi la voie simple, au moins en parallèle, ça t'aidera .

Parce que quand le compilateur va commencer à t'envoyer des messages d'insulte parce que tu as mal écrit quelque chose, il vaudrait mieux que le programme ne fasse que 5 lignes pour comprendre plus facilement les conneries que tu fais. Au moins le temps de l'apprivoiser et que ses messages d'insulte deviennent comme par magie des informations utiles sur ce que tu as mal écrit (ça a peut-être l'air d'une plaisanterie ou d'une honteuse irruption de l'irrationnel dans le monde bien rangé de l'informatique, mais en vrai c'est probablement à ça que ça ressemblera : il faut un peu apprendre à interpréter les messages d'erreur et à relire ton code pour déterminer la probabiité que telle ou telle partie soit correcte, pour ton concentrer sur la bonne ; d'autant plus en C que les messages d'erreur du programme en cours d'éexécution qui plante se résument à pas grand chose d'utile en fait).

Pareil pour les notions que tu as apprises : à mon avis une fois tout mélangé dans un vrai programme ça fait pas mal de choses à comprendre. Alors que les utiliser une par une et commencer à les mélanger progressivement peut être plus facile.

Pour ce qui est de la lecture de code dans l'apprentissage de la programmation : je ne sais pas trop, j'imagine qu'il y a quelque chose à en tirer mais bon... je ne me rends pas trop compte de ce que ça peut apporter. Ça fait longtemps que je code des trucs, mais je n'ai toujours pas d'avis précis sur cette question. Je suppose que ça peut servir, donc si ça te plaît pourquoi pas, mais c'est un complément au reste.

Et pour commencer la lecture du code de Yoha, il faut choisir un petit morceau. Par exemple tu peux exécuter le programme et te demander comment marche telle ou telle partie. Et si tu viens ici quelqu'un va t'expliquer où ça se trouve dans le code, pour te guider. Avoir le truc qui marche sous les yeux / à l'esprit pour lire le code c'est pas mal : ça te permet de greffer les détails de ce que tu lis sur un fonctionnement que tu as déjà compris, sans avoir eu besoin de lire tout le code source pour ça. Pareil pour ajouter une petite fonctionnalité.

Bon, il n'y a pas de doc d'architecture et pas tellement de commentaires, donc ce n'est pas évident. Mais par exemple dans le code (répertoire src) il y a un répertoire "world", qui semble contenir le coeur du jeu : ce qui permet de modéliser le monde et son fonctionnement, quelque chose d'assez facilement observable dans le jeu.

Dedans il y a des fichiers comme character.h, qui liste les informations dont on dispose sur un personnage (est-il vivant, direction, inventaire, compétences, ...) et les actions que le programme peut réaliser sur un personnage (lui dire de s'arrêter, d'attaquer, de manger, ...). Le fichier character.c contient le code des fonctions permettant de créer un personnage, de lui dire de s'arrêter (character_stop), de manger (character_eat), ... Ce code est déjà un peu conséquent est assez concret, c'est peut-être un bon endroit pour commencer ta lecture : tu devrais y trouver facilement des éléments du jeu observables quand tu le lances.

Jeter un oeil sur les .h te donnera aussi une idée des données manipulées par le programme, sans forcément regarder tout le code qui s'applique dessus : comment tel ou tel élément du jeu est nommé dans le code, quelles sont les données qui constituent l'inventaire (dans inventory.h), ...

Comme je le disais plus haut, ce n'est pas facile de lire du code et de tout comprendre du premier coup quand on a encore des idées floues sur la programmation. En fait pour être tout à fait juste c'est même difficile quand on s'y connaît bien en programmation mais qu'on n'est pas très à l'aise avec le langage utilisé. Et même quand on le connaît bien mais qu'on n'a pas écrit soi-même le code (ou il y a longtemps) ce n'est pas si simple. Donc si tu ne comprends pas tout du premier coup ce n'est pas grave... À mon avis tu devrais plutôt essayer de comprendre un peu des bouts du code, sans t'inquiéter si tu ne comprends pas chaque ligne : arriver à se retrouver dans le code d'un projet est une première étape quand on veut lire son code (effectivement, ça n'a rien à voir avec un livre...). Et n'oublie pas de commencer à essayer de coder des programmes plus petits, je pense que ça t'aidera pour la suite.

Si ça peut te rassurer sur mon cas, j'ai fait les exos proposés dans le cours, qui permettent d'écrire une centaine de lignes en un ou deux fichiers, en réfléchissant à quelles instructions utiliser et que signifient les 15 lignes en rouge dans la zone de notification (Build log)
Simplement, on me demande d'implémenter des fonctionnalités précises, c'est pas comme si je décidais "de mon propre chef" de créer le programme de mes rêves (j'ai peut-être été ambigu sur ce point-là).

Je suppose que le conseil de Yoha est du même genre que "regardez des films anglais pour être plus fort en anglais". Tu t'habitues à la syntaxe impitoyable de la programmation, tu vois comment un développeur chevronné peut écrire des bouts d'algorithme élémentaires...

Donc voilà, j'avais essayé il y a peut-être un an de me plonger dans le code, et j'avais rien compris. Depuis, j'ai pratiqué, compilé, fait des erreurs et je crois avoir suffisamment compris comment ça marchait pour pouvoir comprendre ce code. Manquait plus qu'à trouver l'angle d'attaque, et du coup je vais suivre ton conseil et commencer par les fonctionnalités les plus visibles.

D'accord . N'hésite pas à passer par ici si tu as des questions.

De retour après avoir essayé de compiler. Le debugger signale une erreur à la troisième ligne:

...\vendetta\src\world\draw.c|196|    error: initializer element is not constant             |
...\vendetta\src\world\draw.c|196|    error: (near initialization for 'states.blendMode')  |

Le morceau concerné:

À la troisième ligne, vire le "static". A priori ça sert à dire que la variable ne devrait pas être recalculée à chaque passage dans la fonction (une sorte de constante), donc ça ne devrait pas changer le déroulement du programme (à la limite des questions de performances, mais bon...). Maintenant je ne suis pas un grand expert en C...

Note que je ne sais pas pourquoi ça marche chez Yoha et pas chez nous. Donc pour la réponse il faudra attendre un avis de l'intéressé.

Pour Yoha : j'ai fait comme indiqué dans le wiki : "make -C src" depuis le répertoire racine du projet. Et j'ai un système récent (Archlinux, donc sans doute les dernières versions d'un peu tout, dont gcc 4.9.2). Ça ne marche pas non plus en enlevant les drapeaux de compilation (j'ai gardé juste "-std=c99").

Merci ! Il n'y a désormais plus aucune erreur de syntaxe (si c'en était une, je maîtrise pas encore le vocabulaire...)

J'ai pu passer à l'étape suivante, la cinquantaine d'erreurs en rapport avec l'étape des fichiers *.o (et encore, cinquante c'est parce que le débuggeur m'a dit qu'il ne pouvait pas en afficher plus, et que sinon, il se serait pas privé...)

C'est un problème avec des "_imp_", c'est-à-dire qu'il ne trouve pas où elles sont implémentées, d'après ce que j'ai pu trouver sur internet. J'ai pas beaucoup plus cherché, mais je suppose qu'il va falloir que je regarde au niveau des #include.

C'est plus ou moins une erreur de syntaxe, mais comme c'est là depuis pas mal de versions je suppose que ça fonctionne chez Yoha et donc je ne sais pas à quoi c'est dû.

Je pense que ce serait mieux de créer un nouveau sujet pour ça par contre... Parce que là on va commencer à polluer celui-ci avec des questions qui n'intéressent pas trop ceux qui veulent savoir si le développement avance .

As-tu essayé de nettoyer les fichiers intermédiaires ? Avec "make clean". Avant de relancer la compilation complète.

Si le problème existe toujours, tu pourras poster dans l'autre sujet les messages d'erreur ? Chez moi tout se compile une fois le "static" enlevé.

Et aussi : tu es sous Linux ? Sous Windows ?

Pour l'anecdote, même la console de Windows n'arrive pas à afficher toutes les erreurs...

Pour ceux qui ont testé la 3.6, est-ce que vous avez un bug quand vus détruisez le bâtiment d'une IA ?

Sur un premier bâtiment : après l'avoir un peu endommagé il semble être repassé dans un état étrange (? ; comme s'il était en construction, je ne sais pas trop).

Et sur un autre que j'ai réussi à détruire le jeu a planté.

ouaip, c'est ça. Well, first bug spotted. Let's fix it...

Peut-être une image non-trouvée ?

j'espère que la fonction est dans building.c, parce que sinon, je crois que je vais avoir du mal à trouver...

Là je suppose qu'il faut commencer à regarder comment les fonctions s'enchaînent. Si tu trouves le code de combat, tu devrais arriver assez facilement à suivre ce qui se passe à partir de là.

La fonction world/building.c -> building_attacked est sans doute un bout de ce code.

Note que ça pourrait être un autre bout du code qui est perdu parce que le bâtiment n'existe plus. Il y a sans doute un débogueur dans ton environnement de développement, si tu ne trouves pas rapidement "à la main" ça peut être intéressant de regarder comment il marche : il te permettra d'exécuter le code jusqu'à un certain endroit puis d'exécuter les instructions (ou fonctions) une par une pour voir ce qui se passe. C'est aussi un bon moyen d'explorer dynamiquement le code, de voir comment les fonctions s'enchaînent, au-delà de ta première lecture pour situer un peu les morceaux.

Oui,j'ai essayé ça avant de trouver mon problème avec la police qui chargeait pas. J'ai vu les breakpoints et l'exécution instruction par instruction. Mais j'ai pas vu comment repérer à quelle instruction on se trouve exactement. À part peut-être avec "Run to cursor".

En principe tu places un point d'arrêt quelque part, l'exécution s'arrête à cet endroit et ensuite tu as sans doute des boutons du genre 'instruction suivante", "fonction suivante", des choses comme ça.

Quand tu fais ça, le code exécuté / la ligne en cours ne défile pas ? La vue reste la même ?

Comment on place un point d'arrêt ?

Là je ne sais pas, ça dépend du logiciel que tu utilises. Le mieux est de faire une recherche dans le manuel ou sur la Toile ("point d'arrêt", ou "breakpoint" en anglais).