La Place des Développeurs [TUTO] Un jeu MSX2 en basic avec perso animé et plusieurs tableaux. De la bonne utilisation de SET PAGE, BLOAD...S, COPY et BMP2MSX
Reprise du message précédent
Stapha :
Au départ je voulais simplement rebondir sur la leçon 3 du tuto pour dire qu'il y avait d'autres méthode que les IF et les sauts.
Je proposais simplement une autre façon de faire. On dirait que je me suis piégé...
EDIT : A noter que le plus grand avantage de cette méthode est qu'elle rend la gestion des diagonales gratuite. C'est aussi pour ça que je disais qu'elle ne devait pas apporter grand chose dans ce cas...
Je proposais simplement une autre façon de faire. On dirait que je me suis piégé...
Citation :
400 ' Code gérant les déplacement
401 S=STICK(0)+1
402 NX=X+DX(S):NY=Y+DY(S):NA=VA(S)
403 P=POINT(INT((NX+10)/16),200+INT((NY+41)/16))
404 Q=POINT(INT((NX+21)/16),200+INT((NY+41)/16))
405 IF P>6 AND Q>6 AND Y>-1 THEN X=NX:Y=NY:A=NA
406 GOSUB 1000
401 S=STICK(0)+1
402 NX=X+DX(S):NY=Y+DY(S):NA=VA(S)
403 P=POINT(INT((NX+10)/16),200+INT((NY+41)/16))
404 Q=POINT(INT((NX+21)/16),200+INT((NY+41)/16))
405 IF P>6 AND Q>6 AND Y>-1 THEN X=NX:Y=NY:A=NA
406 GOSUB 1000
EDIT : A noter que le plus grand avantage de cette méthode est qu'elle rend la gestion des diagonales gratuite. C'est aussi pour ça que je disais qu'elle ne devait pas apporter grand chose dans ce cas...
Mod Racolage "ON"
Salut Stapha!
J'ai volontier besoin de tes connaissances pour ma tentative d'adaptation du Moteur Winnie en un programme plus adapté au Shoot Them Up.
La possibilité de se déplacer dans les 8 directions est très intéressante.
Voici le lien, c'est pas loin juste après la mairie
=> http://www.msxvillage.fr/forum/topic.php?id=507&pt=7#m7204Mod Racolage "OFF"
Ta citation n'est pas fausse Venom. Un peu exagérée quand même... 
Il n'y a pas de "crack" en infomatique. Seulement des gens malins.
Cette citation complait à un frustré de la logique, mais pas à un pratiquant.
Stapha propose une méthode. Pas la solution absolue incontournable. Je suis d'accord sur le fait qu'il faut savoir aligner des instructions logiques à la suite, pour programmer en Basic. C'est la méthode que j'utilise. C'est lourd et pompeux, mais cela permet de progresser avec le temps.
L'optimisation d'un programme, c'est "la patte", de chacun. L'essentiel, c'est de comprendre ce que l'on écrit, pas de recopier.
Il n'y a pas de "crack" en infomatique. Seulement des gens malins.
Cette citation complait à un frustré de la logique, mais pas à un pratiquant.
Stapha propose une méthode. Pas la solution absolue incontournable. Je suis d'accord sur le fait qu'il faut savoir aligner des instructions logiques à la suite, pour programmer en Basic. C'est la méthode que j'utilise. C'est lourd et pompeux, mais cela permet de progresser avec le temps.
L'optimisation d'un programme, c'est "la patte", de chacun. L'essentiel, c'est de comprendre ce que l'on écrit, pas de recopier.
Venom,
Je ne suis pas totalement d'accord. Un code optimisé peut être très propre et inversement. La méthode que j'ai proposé (car au départ ce n'était que ça) s'appuie sur un algo différent, comme beaucoup d'optimisations. Dans pareil cas, un compilo ne pourra rien faire. Tout comme il ne pourra pas toujours réordonner un code de façon a mieux exploiter l'overlaping d'un processeur par exemple.
J'ai vu des programmes qui, non content d'être très mal optimisés, était remplis de variables globales, mal structurés, absolument pas modulaires et, au final, difficiles à maintenir... Quand au fait d'écrire dans une zone mémoire non allouée par l'OS : c'est non seulement idiot (car risque d'incompatibilité sur des machines avec une quantité de RAM différente ou adressée différement) mais ça n'apporte rien en terme de performance. Cela dit, c'est vrai que j'ai bel et bien vu ce cas plus d'une fois...
Et tu as raison quand tu parles d'apprendre d'abord à programmer proprement avant de penser à optimiser quoi que ce soit. Mais l'utilisation d'un tableau pour gérer des déplacement est une méthode très simple et non une optimisation difficile à comprendre.
Tu as d'autant plus raison que le basic n'est pas le meilleur langage pour apprendre à programmer proprement. Il faut donc, comme tu l'as dit, prendre des bonnes habitudes dès le départ.
Franck,
C'était effectivement juste une idée au départ. Mais il y a de quoi m'en vouloir car je n'ai pas respecté une règle d'or : on ne diffuse jamais un code non testé. Surtout quand il doit tourner sur une machine qu'on a jamais essayée. J'aurai du expliquer la méthode sans poster de code. Comme je le disais, je me suis piégé tout seul...
La leçon a porté : je ne posterai rien avant d'avoir installé un émulateur et trouvé de la doc. Je ferai ça ce week-end.
Venom a plutot été cool : j'aurai mérité qu'il soit bien plus virulent !
Mea Culpa...
Igal,
Aucun problème, ça me fera plaisir si je peux aider. Tu as bien compris que je ne donnerai pas de code avant ce week-end. Mais je vais jeter un oeil de suite.
Je ne suis pas totalement d'accord. Un code optimisé peut être très propre et inversement. La méthode que j'ai proposé (car au départ ce n'était que ça) s'appuie sur un algo différent, comme beaucoup d'optimisations. Dans pareil cas, un compilo ne pourra rien faire. Tout comme il ne pourra pas toujours réordonner un code de façon a mieux exploiter l'overlaping d'un processeur par exemple.
J'ai vu des programmes qui, non content d'être très mal optimisés, était remplis de variables globales, mal structurés, absolument pas modulaires et, au final, difficiles à maintenir... Quand au fait d'écrire dans une zone mémoire non allouée par l'OS : c'est non seulement idiot (car risque d'incompatibilité sur des machines avec une quantité de RAM différente ou adressée différement) mais ça n'apporte rien en terme de performance. Cela dit, c'est vrai que j'ai bel et bien vu ce cas plus d'une fois...
Et tu as raison quand tu parles d'apprendre d'abord à programmer proprement avant de penser à optimiser quoi que ce soit. Mais l'utilisation d'un tableau pour gérer des déplacement est une méthode très simple et non une optimisation difficile à comprendre.
Tu as d'autant plus raison que le basic n'est pas le meilleur langage pour apprendre à programmer proprement. Il faut donc, comme tu l'as dit, prendre des bonnes habitudes dès le départ.
Franck,
C'était effectivement juste une idée au départ. Mais il y a de quoi m'en vouloir car je n'ai pas respecté une règle d'or : on ne diffuse jamais un code non testé. Surtout quand il doit tourner sur une machine qu'on a jamais essayée. J'aurai du expliquer la méthode sans poster de code. Comme je le disais, je me suis piégé tout seul...
La leçon a porté : je ne posterai rien avant d'avoir installé un émulateur et trouvé de la doc. Je ferai ça ce week-end.
Venom a plutot été cool : j'aurai mérité qu'il soit bien plus virulent !
Mea Culpa...
Igal,
Aucun problème, ça me fera plaisir si je peux aider. Tu as bien compris que je ne donnerai pas de code avant ce week-end. Mais je vais jeter un oeil de suite.
MSXosaure :
On se calme dans les rangs et on se tient bien ! (J'ai raté ma vocation!) 
Salut Msxosaure.
Je viens de remarquer que certaines lignes de code comme celles ci dessous ne sont pas les mêmes qu'au départ!
1900 '
1901 ' SP gestion mouvement: HAUT
1902 '
2000 P=POINT(INT((X+10)/16),200+INT((Y+37)/16))
2010 Q=POINT(INT((X+21)/16),200+INT((Y+37)/16))
2020 Y=Y+4*(P>6)*(Q>6)*(Y>0):A=77:GOTO500
2400 '
2401 ' SP gestion mouvement: DROITE
2402 '
2500 P=POINT(INT((X+25)/16),200+INT((Y+41)/16))
2520 X=X-4*(P>6):A=39:GOTO500
2900 '
2901 ' SP gestion mouvement: BAS
2902 '
3000 P=POINT(INT((X+10)/16),200+INT((Y+45)/16))
3010 Q=POINT(INT((X+21)/16),200+INT((Y+45)/16))
3030 Y=Y+4*(P>6)*(Q>6):A=153:GOTO500
3400 '
3401 ' SP gestion mouvement: GAUCHE
3402 '
3500 P=POINT(INT((X+6)/16),200+INT((Y+41)/16))
3520 X=X+4*(P>6):A=115:GOTO500
Alors que l'ancien code est celui ci dessous.
1900 '
1901 ' SP gestion mouvement: HAUT
1902 '
2000 P=POINT(INT((X+8)/16),202+INT(Y/16))
2010 Q=POINT(INT((X+20)/16),202+INT(Y/16))
2020 Y=Y+4*(P>6)*(Q>6)*(Y>0):A=32:RETURN
2400 '
2401 ' SP gestion mouvement: DROITE
2402 '
2500 P=POINT(INT((X+8)/16)+1,202+INT((Y+8)/16))
2520 X=X-4*(P>6):A=16:RETURN
2900 '
2901 ' SP gestion mouvement: BAS
2902 '
3000 P=POINT(INT((X+8)/16),203+INT((Y-4)/16))
3010 Q=POINT(INT((X+20)/16),203+INT((Y-4)/16))
3030 Y=Y+4*(P>6)*(Q>6):A=64:RETURN
3400 '
3401 ' SP gestion mouvement: GAUCHE
3402 '
3500 P=POINT(INT((X+20)/16)-1,202+INT((Y+8)/16))
3520 X=X+4*(P>6):A=48:RETURN
Je comprends mieux pourquoi je n'arrivais pas à faire ma salade
Peux tu poster la disquette complète s'il te plait! Edité par igal Le 25/11/2010 à 21h12
Visiteur
Vagabond
Message : 0
Ce n'est pas parce que Venom c'est un gros vilain qu'il me faut pour autant endosser le rôle du méchant de service.
Donc juste pour préciser, ce que j'ai posté plus haut ne visait pas Stapha en particulier, même si son post m'a rappellé les problèmes d'optimisation prématurée (j'ai résisté à l'envie de parler d' "optimisation précoce", même si ça évoquerait un peu l'idée de satisfaction immédiate avec partenaire déçu (ahem) ).
Je n'ai pas dit qu'il ne fallait pas optimiser, mais qu'il fallait garder ses programmes simples le plus longtemps possible.
Ensuite, si ça rame, il est toujours temps de profiler (profiler, c'est long et pénible, alors autant garder ça pour la fin uniquement si c'est nécessaire). La modification de Stapha n'était pas compliquée au premier abord, et puis finalement, en gérant ce que faisait la version de MSXosaure , ça devient plus difficile à lire.
le "on goto" de MSXosaure n'est peut être pas le plus optimal, mais il est plus lisible et va éviter des fautes de frappes qui peuvent également provoquer des bugs assez frustrants (le seul truc que je reprocherais vraiment à la méthode est l'utilisation de "nombres magiques" dans le code, c'est à dire des réels plutot que des variables, qui induisent un comportement plus facile à modifier en bloc).
J'ai écrit énormément de code, puisque c'est mon boulot. Ca ne me donne pas forcément de légitimité, puisque dans ma carrière, j'ai rencontré beaucoup de personnes qui avaient écrit pendant 20 ans le même programme sans se remettre en question.
J'ai essayé d'évoluer en apprenant, et j'ai eu du mal à me débarasser des mauvaises habitudes acquises au départ. L'optimisation prématurée en faisait partie.
Penser que j'allais faire mieux que le compilateur en était une autre. Ce fut un vaste débat, ça ne l'est plus. Avec le futur placé sous le signe du multi-coeur, la question est tranchée. J'ai rencontré peu de personnes capables de faire mieux qu'un compilateur, et c'était à chaque fois dans des cas murement réfléchis, pour des problèmes isolés (comme l'écriture de codecs video dans des conditions bien définies, et vendus ensuite sous licence, ce qui justifiait l'investissement initial. Et encore, une infime partie du code était écrit en assembleur. Savez-vous que le système de freinage des TGVs est écrit en C++ ?).
Je ne poste pas de code ici pour ne pas pourrir plus le topic. Je tiens des désassemblages de cas typiques en C à disposition des plus sceptiques d'entre vous (MP)
(attention, c'est au format AT&T comme j'utilise la suite GNU).
Tout ça pour dire qu'il vaut mieux "penser" le programme, plutôt que l' "optimiser" dès la départ
Je n'ai pas écrit ça pour être distribuer les bons points, mais j'ai relu énormément de code par la force des choses, et j'ai aussi appris à écrire pour être compris des autres (c'est le plus important). Des horreurs "optimisées", j'en ai lu à me choper des migraines (j'en ai écrit aussi). C'est pour ça que j'ai réagi, même si je pense qu'il y a peu de chances pour que je relise du code MSX un jour. Par contre, si ça fait naitre des vocations, il vaut mieux étouffer le mal dans l'oeuf
Je n'oublie pas non plus que pour la plupart d'entre-vous, c'est un hobby.
Il n'y a pas de mal à s'amuser à bricoler un peu le Z80, ça donne même le sentiment assez agréable de maitriser complètement une architecture. Alors c'est vrai que je me suis un peu excité sur ce coup. Ce forum ne changera de toute façon pas le monde de la programmation, mais c'est mon côté perfectionniste qui m'a titillé.
J'ai cité Wulf à la fin, j'aurais pu citer Knuth qui est beaucoup plus connu, et qui dit la même chose ("l'optimisation prématurée est la racine du mal"). Knuth est l'auteur des fameux "art of computer programming", une des séries d'ouvrages les plus célèbres en info. Edité par Visiteur Le 25/11/2010 à 21h54
Donc juste pour préciser, ce que j'ai posté plus haut ne visait pas Stapha en particulier, même si son post m'a rappellé les problèmes d'optimisation prématurée (j'ai résisté à l'envie de parler d' "optimisation précoce", même si ça évoquerait un peu l'idée de satisfaction immédiate avec partenaire déçu (ahem) ).
Je n'ai pas dit qu'il ne fallait pas optimiser, mais qu'il fallait garder ses programmes simples le plus longtemps possible.
Ensuite, si ça rame, il est toujours temps de profiler (profiler, c'est long et pénible, alors autant garder ça pour la fin uniquement si c'est nécessaire). La modification de Stapha n'était pas compliquée au premier abord, et puis finalement, en gérant ce que faisait la version de MSXosaure , ça devient plus difficile à lire.
le "on goto" de MSXosaure n'est peut être pas le plus optimal, mais il est plus lisible et va éviter des fautes de frappes qui peuvent également provoquer des bugs assez frustrants (le seul truc que je reprocherais vraiment à la méthode est l'utilisation de "nombres magiques" dans le code, c'est à dire des réels plutot que des variables, qui induisent un comportement plus facile à modifier en bloc).
J'ai écrit énormément de code, puisque c'est mon boulot. Ca ne me donne pas forcément de légitimité, puisque dans ma carrière, j'ai rencontré beaucoup de personnes qui avaient écrit pendant 20 ans le même programme sans se remettre en question.
J'ai essayé d'évoluer en apprenant, et j'ai eu du mal à me débarasser des mauvaises habitudes acquises au départ. L'optimisation prématurée en faisait partie.
Penser que j'allais faire mieux que le compilateur en était une autre. Ce fut un vaste débat, ça ne l'est plus. Avec le futur placé sous le signe du multi-coeur, la question est tranchée. J'ai rencontré peu de personnes capables de faire mieux qu'un compilateur, et c'était à chaque fois dans des cas murement réfléchis, pour des problèmes isolés (comme l'écriture de codecs video dans des conditions bien définies, et vendus ensuite sous licence, ce qui justifiait l'investissement initial. Et encore, une infime partie du code était écrit en assembleur. Savez-vous que le système de freinage des TGVs est écrit en C++ ?).
Je ne poste pas de code ici pour ne pas pourrir plus le topic. Je tiens des désassemblages de cas typiques en C à disposition des plus sceptiques d'entre vous (MP)
(attention, c'est au format AT&T comme j'utilise la suite GNU).Tout ça pour dire qu'il vaut mieux "penser" le programme, plutôt que l' "optimiser" dès la départ
Je n'ai pas écrit ça pour être distribuer les bons points, mais j'ai relu énormément de code par la force des choses, et j'ai aussi appris à écrire pour être compris des autres (c'est le plus important). Des horreurs "optimisées", j'en ai lu à me choper des migraines (j'en ai écrit aussi). C'est pour ça que j'ai réagi, même si je pense qu'il y a peu de chances pour que je relise du code MSX un jour. Par contre, si ça fait naitre des vocations, il vaut mieux étouffer le mal dans l'oeuf
Je n'oublie pas non plus que pour la plupart d'entre-vous, c'est un hobby.
Il n'y a pas de mal à s'amuser à bricoler un peu le Z80, ça donne même le sentiment assez agréable de maitriser complètement une architecture. Alors c'est vrai que je me suis un peu excité sur ce coup. Ce forum ne changera de toute façon pas le monde de la programmation, mais c'est mon côté perfectionniste qui m'a titillé.
J'ai cité Wulf à la fin, j'aurais pu citer Knuth qui est beaucoup plus connu, et qui dit la même chose ("l'optimisation prématurée est la racine du mal"). Knuth est l'auteur des fameux "art of computer programming", une des séries d'ouvrages les plus célèbres en info. Edité par Visiteur Le 25/11/2010 à 21h54
Holà j'arrive tard 
Ils m'ont tout salopé mon Tuto 
ça va sévir 
Alors pour Stapha:
ça fait du bien d'avoir un œil d'un programmeur extérieur, ça permet de se remettre en question, on prend vite de mauvaises habitudes comme l'a dit Venom et on a tendance à oublier de préciser pourquoi on fait les choses d'une façon ou d'une autre.
Pour le choix de l'utilisation de la VRAM, je suis bien conscient qu'elle est bien plus lente mais il faut penser que le Basic MSX n'a que très peu de RAM (64K) pour se loger et il en occupe une bonne partie (32K
) + les variables + le contrôleur disque + la zone de travail, au final c'est avec moins de 28 Ko que l'on travaille, bah oui c'est pas un Amiga) alors que la VRAM (MSX2) propose (en théorie128 K) . Les tableaux sont une bonne idée à laquelle je n'avais pas pensé, mais là aussi il faut leur réserver une petite place en mémoire
Pour Igal: Détermine bien la zone "d'encombrement de ton vaisseau (qui là doit se résumer à un rectangle) et sonde les coins + une valeur de déplacement (-1) et ramène les à la valeur X et Y.
Ils m'ont tout salopé mon Tuto ça va sévir Alors pour Stapha:
ça fait du bien d'avoir un œil d'un programmeur extérieur, ça permet de se remettre en question, on prend vite de mauvaises habitudes comme l'a dit Venom et on a tendance à oublier de préciser pourquoi on fait les choses d'une façon ou d'une autre.
Pour le choix de l'utilisation de la VRAM, je suis bien conscient qu'elle est bien plus lente mais il faut penser que le Basic MSX n'a que très peu de RAM (64K) pour se loger et il en occupe une bonne partie (32K
) + les variables + le contrôleur disque + la zone de travail, au final c'est avec moins de 28 Ko que l'on travaille, bah oui c'est pas un Amiga) alors que la VRAM (MSX2) propose (en théorie128 K) . Les tableaux sont une bonne idée à laquelle je n'avais pas pensé, mais là aussi il faut leur réserver une petite place en mémoire Pour Igal: Détermine bien la zone "d'encombrement de ton vaisseau (qui là doit se résumer à un rectangle) et sonde les coins + une valeur de déplacement (-1) et ramène les à la valeur X et Y.
Le MSXien le plus à l'ouest
... ou presque 
MXSosaure,
C'est sympa. ça fait encore plus de bien de croiser quelqu'un qui prend la peine d'apprendre à ceux qui sont demandeurs. J'ai vu des communautés ou les gens gardent jalousement des routines qu'ils croient être révolutionnaire...
Merci pour l'explication sur la VRAM. En fait je trouvais que ton code était suffisament concis pour laisser la place nécessaire... Jusqu'à ce que je vois que ton code était adapté à pleins d'autres usages et que la place que tu as économisé était bienvenue (utilisée pour ajouter une musique par exemple). Je vois un autre avantage à l'utilisation de la VRAM : c'est plus visuel. Dans le cadre d'un tuto, ça suffit à justifier la méthode pour moi.
Oui, le coup des tableaux est pratique dans certains cas. Et vu le niveau que tu as, tu n'auras aucun mal à déterminer quand leur utilisation sera rentable.
Pour la place qu'ils utilisent, je ne sais pas à quel point ça peut être un problème. Ils prennent moins de place en RAM que le code qu'ils font économiser. Le problème est qu'il utilisent l'espace alloué aux variables par le basic. Il y a des interpréteurs avec lesquels ça ne posent pas de problème (réallocation dynamique ou manuelle de la pile) mais je ne sais pas ce qu'il en ait avec le basic MSX.
Une remarque sur ton code : ta méthode pour afficher afficher Winnie est très élégante. La méthode classique (copie du décor à la place de l'ancien sprite puis dessin du sprite à la nouvelle position) aurait généré d'horribles clignotements sans double-buffer. C'est dommage que seuls ceux qui s'y sont déjà essayé puissent se rendre compte de son efficacité...
En tout cas bravo pour ton tuto. C'est vraiment un gros travail que j'aurais été incapable de mener avec la même qualité.
S'il avait été mal fait, j'aurai quand même salué la démarche. Mais là je suis impressionné par la qualité de ce que tu as produit. Je n'ose imaginer le temps que je mettrai à faire un seul des dessins/schémas que tu as postés...
C'est sympa. ça fait encore plus de bien de croiser quelqu'un qui prend la peine d'apprendre à ceux qui sont demandeurs. J'ai vu des communautés ou les gens gardent jalousement des routines qu'ils croient être révolutionnaire...
Merci pour l'explication sur la VRAM. En fait je trouvais que ton code était suffisament concis pour laisser la place nécessaire... Jusqu'à ce que je vois que ton code était adapté à pleins d'autres usages et que la place que tu as économisé était bienvenue (utilisée pour ajouter une musique par exemple). Je vois un autre avantage à l'utilisation de la VRAM : c'est plus visuel. Dans le cadre d'un tuto, ça suffit à justifier la méthode pour moi.
Oui, le coup des tableaux est pratique dans certains cas. Et vu le niveau que tu as, tu n'auras aucun mal à déterminer quand leur utilisation sera rentable.
Pour la place qu'ils utilisent, je ne sais pas à quel point ça peut être un problème. Ils prennent moins de place en RAM que le code qu'ils font économiser. Le problème est qu'il utilisent l'espace alloué aux variables par le basic. Il y a des interpréteurs avec lesquels ça ne posent pas de problème (réallocation dynamique ou manuelle de la pile) mais je ne sais pas ce qu'il en ait avec le basic MSX.
Une remarque sur ton code : ta méthode pour afficher afficher Winnie est très élégante. La méthode classique (copie du décor à la place de l'ancien sprite puis dessin du sprite à la nouvelle position) aurait généré d'horribles clignotements sans double-buffer. C'est dommage que seuls ceux qui s'y sont déjà essayé puissent se rendre compte de son efficacité...
En tout cas bravo pour ton tuto. C'est vraiment un gros travail que j'aurais été incapable de mener avec la même qualité.
S'il avait été mal fait, j'aurai quand même salué la démarche. Mais là je suis impressionné par la qualité de ce que tu as produit. Je n'ose imaginer le temps que je mettrai à faire un seul des dessins/schémas que tu as postés...
Merci Stapha, je suis actuellement sur un éditeur de niveau que je vais essayer de faire le plus complet possible (calé sur 1 octet cette fois-ci) avec un exemple à la clé... Mais il faudra être patient, mon temps libre étant des plus limité actuellement.
Le tuto suivra etc...
Le tuto suivra etc...
Le MSXien le plus à l'ouest
... ou presque
Excellent ! C'est exactement ce que je cherchai. Pour les questions, ça attendra, j'en suis au début et pour l'instant tout marche comme sur des roulettes.
Faudrait juste prévenir les gens que le p'tit code de création de transparence sur MSX dans le premier tuto, dur très longtemps. La première fois, je pensai avoir planté.
Faudrait juste prévenir les gens que le p'tit code de création de transparence sur MSX dans le premier tuto, dur très longtemps. La première fois, je pensai avoir planté.
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie