Recoucou.

Ah oui. En fait j'avais même pas pigé que le JustBasic était une version restreinte mais gratuite de LibertyBasic.

Pour la gestion du clavier, effectivement, ça ne me semble pas possible en JustBasic. Toutes les docs que j'ai trouvées concernant la gestion du clavier ne mentionnent que la récupération des caractères, et non pas la récupération des événements de touche (c'est pas la même chose).

Et ce lien : http://justbasic.com/learnmore.html semble bien préciser qu'on peut accéder aux DLL et à l'API Windows uniquement avec Liberty Basic.

Pour les includes de fichiers dans un autre, ça ne semble pas non plus faisable en JustBasic. J'y croyais pas au début, tellement c'est une fonction basique. Mais apparemment, on peut pas. Je suppose que c'est fait exprès pour inciter les gens à acheter le LibertyBasic.

Source :
Ce qui est dit ici :
http://justbasic.conforums.com/index.cgi?board=code&action=display&num=1181321137

Et lorsque je cherche dans la liste des mots réservés de JustBasic, je n'y vois pas de "include", "import" ni aucune autre instruction de ce genre.

Bon eh bien, honnêtement, bon courage pour continuer ton projet en JustBasic.

Si je voulais troller, je dirais qu'il existe d'autres langages, totalement libre et gratuit, en version complète, et qui permettent de coder beaucoup plus facilement des jeux vidéos. Avec des includes, une gestion plus poussée du clavier, plus rapide, comportant pleins de petites librairies réutilisables, de la doc à foison sur internet, etc. Mais je ne m'abaisserais pas à tomber aussi bas dans le trollage.

À la prochaine !

Coucou !!

Ben, euh.... j'ai pas eu l'impression de faire de la pub. (Disons que je fais autant de pub pour github et git.framasoft que vous ne faites de pub pour Mega en utilisant des liens de téléchargement Mega). Mais c'est pas grave.

Je ne suis pas au courant de soucis sur github, à part que c'est pas 100% libre. (git est libre, mais pas github).

Concernant mon blog, j'ai vaguement essayé de le ranger. Il y a cette page de résumé :
https://recher.wordpress.com/about/
Elle liste toute mes "grosses" réalisations. Chacune d'elle comporte un lien de téléchargement.

Attention, je ne dis pas que le reste de mon blog est bien rangé, et je ne dis pas non plus qu'à l'intérieur de chacune des réalisations, c'est bien rangé. Mais je dis que le résumé global de toutes mes grosses réalisations est bien rangé. Donc voilà, tu peux les récupérer.

Ma dernière réalisation python ? Le jeu vidéo Kawax, pas vraiment terminé, mais c'est pas grave, c'est quand même jouable. Téléchargeable via un lien sur la page de résumé sus-citée.

Et sinon j'ai aussi fait la carte d'un jeu vidéo de la Motion Twin, avec QGIS (mais ça c'est une "petite" réalisation).

Pour l'instant, je fouille mes fonds de tiroir pour remplir mon github. Et ensuite, je me lancerais dans une "semi-grosse" réalisation. Un truc moitié javascript, moitié python, moitié site web. (Ça fait 3 moitiés, on n'est plus à ça près).

Chez Sam et Max, ils sont en semi-vie pour l'instant. De temps en temps ils se réveillent et balancent 10 articles d'un coup, puis ils s'endorment pendant plusieurs mois. Et ainsi de suite. Ils se réveilleront complètement peut-être plus tard.

Bisous à tes gens de chez toi, et peut-être à bientôt au détour d'un forum ou autre chose.

Ouah, c'est un boulot impressionnant ! Il y aurait encore pleins de petites choses à ajuster, mais ça fait quand même un jeu "présentable". Bosser pendant 4 ans sur un même projet, c'est un truc que je n'ai jamais réussi à faire. En général, au bout d'un an maximum, je passe à autre chose.

J'ai testé, et j'ai quelques remarques. (Fais en ce que tu veux).

1)

Il y a un bug dans l'équipement. Avec le guerrier (et peut être avec les autres personnages), lorsque j'équipe le pantalon, je gagne +1 points en défense, et lorsque je l'enlève, je perds 2 points ! Du coup, si on s'amuse à mettre et enlever le pantalon plusieurs fois de suite, on se retrouve avec une défense négative. (Et en plus on peut finir à poil).

2)

Le événements de touche ne sont pas très bien gérés. Les appuis de touche se comporte comme dans un éditeur de texte normal. J'appuie sur la flèche de gauche, le héros se déplace une première fois, il faut attendre un peu, et ensuite il se déplace en continu. Ça fait comme dans notepad, word ou autre : on appuie sur 'A', ça écrit une première fois la lettre, et il faut attendre avant de voir d'autres 'A' s'afficher en continu.

J'imagine que le LibertyBasic ne permet pas facilement de piloter le clavier comme on voudrait. J'avais exactement le même problème avec mes premiers programmes de jeu en Turbo Pascal. Pour avoir un contrôle plus poussé du clavier, il faut exécuter des fonctions d'un peu plus bas niveau (appeler une DLL, ou des choses de ce genre). Je suis sûr que c'est possible avec le LibertyBasic, mais je ne saurais pas te dire comment faire.

Au pire, si tu ne veux pas te prendre la tête avec cette histoire de clavier, tu peux contourner le problème. Lorsqu'on clique sur l'aire de jeu, tu cherches s'il y a un chemin simple et sans obstacle entre le héro et le point cliqué, et tu fais déplacer le héros selon ce chemin.

3)

Le déplacement des chiens est bizarre, on a l'impression qu'ils sont bourrés. J'imagine que tu leur a donné un déplacement totalement aléatoire. À chaque cycle de jeu, une direction est choisie au hasard, et le chien se déplace d'une case dans cette direction. Ça fait pas naturel du tout.

Ce que je propose :
- Au début, tu choisis une direction et une distance au hasard (pas très grande, mais un peu quand même)
- Le chien se déplace dans la direction choisie, selon la distance choisie. Si il se cogne contre un mur, te prends pas la tête, tu peux le faire avancer sur-place. (Ça pourra toujours être amélioré plus tard)
- Lorsque la distance est parcourue, le comportement du chien revient au début de cette boucle : choix d'une direction et d'une distance au hasard, etc.

4)

J'ai regardé ton fichier de code, mais je ne pourrais pas t'être utile à ce niveau là, car je ne code pas en LibertyBasic. Je n'aurais qu'une seule remarque : sépare ton code en plusieurs fichiers !!

Si j'ai bien compris, tout le jeu est dans un seul fichier d'environ 8000 lignes. C'est extrêmement compliqué à consulter, à maintenir, à faire évoluer et à débuguer (aussi bien pour toi que pour d'autres personnes qui voudraient le réutiliser).

En LibertyBasic, comme dans tout langage de programmation qui se respecte, on peut découper son code, grâce à la possibilité d'inclure un fichier dans un autre fichier. L'instruction pour cela s'appelle "include". Il y a plus d'explications ici : http://alycesrestaurant.com/lbwhelp/Topic15.htm

J'ai vu que tu avais déjà fait des séparations dans ton gros fichier, avec des commentaires contenant des tirets. À priori, tu dois pouvoir garder à peu près les mêmes séparations, en mettant chaque bloc dans un fichier séparé. Et ensuite, tu as ton code principal qui inclue tous les autres fichiers, et qui contient uniquement les fonctions principales du jeu. Ce sera beaucoup plus simple à gérer ensuite.

Pour que ça reste pratique, il te faudra un éditeur de texte multi-fichiers, l'interface de LibertyBasic permet peut-être cela. Sinon, il y a toujours la possibilité d'utiliser Notepad++, Sublime Text, ou un autre logiciel dans le même genre.


Voilà, ce sera tout pour le moment. J'essayerais de repasser sur ce forum de temps et temps, pour voir comment ce jeu évolue (ainsi que les autres projets LibertyBasic), mais je te garantis vraiment rien, car j'ai, moi aussi, toujours plein de projets personnels en tête, et jamais le temps de les réaliser.

Bon courage à toi, et encore bravo d'avoir le cran de faire avancer ce projet depuis aussi longtemps.

C'est un programme qui simule le fonctionnement des machines Enigma. Des sortes de machine à écrire utilisées par les Allemands pendant la seconde guerre mondiale pour s'échanger des messages chiffrés.

Je saurais pas expliquer le programme, mais il y a un article assez détaillé sur ces machines dans Wikipédia : https://fr.wikipedia.org/wiki/Enigma_%28machine%29

Pour les espaces, c'est normal. Les machines Enigma ne chiffraient que les lettres, pas les autres caractères. Les espaces n'étaient tout simplement pas écrits dans les messages. Les personnes qui déchiffraient les messages se débrouillaient pour les remettre une fois qu'ils avaient reconvertis les lettres.

Ça mériterait un petit traitement au début de la boucle, soit pour enlever tous les caractères qui ne sont pas des lettres (espaces et autres), soit pour les remettre tel quel dans le message chiffré.

Pour stocker du code, je vous invite à utiliser des logiciels de gestion de version en ligne. Le plus connu, c'est github https://github.com/ et sinon il y a celui de framasoft (garanti libre et sans OGM) https://git.framasoft.org

- Stockage illimité (en théorie)
- Rangement par projet (comme ça on peut laisser des vieux trucs et les reprendre des mois plus tard)
- Possibilité de consulter directement les fichiers de code sur le site sans télécharger
- Historique des modifications effectuées
etc.

C'est un peu moins pratique pour stocker les fichiers binaires (les .exe compilés) mais c'est quand même possible.

Il faut installer un logiciel spécifique, et c'est un peu compliqué à prendre en main au début. Mais après, ça aide vraiment. Il y a plein de tutoriel en français sur le net.

Et quand on sait bien s'en servir, ça aide beaucoup pour coder des choses à plusieurs. Quelqu'un fait une première version d'un programme, une autre personne le reprend, fait une amélioration et la propose à l'auteur original, qui ensuite l'intègre (ou pas) dans une nouvelle version, etc.

Voilà, je vous invite à essayer.

Coucou tout le monde.
Je ne viens pas souvent ici, mais un petit peu quand même.
(À noter que je ne programme pas en LibertyBasic, alors tout ce que je dis peut être inexact).

Il ne faut pas faire de flush à chaque tour de boucle, ça ralentit tout et ça mange plein de mémoire. Il faut faire le flush uniquement à la fin de la boucle principale. Ton image apparaîtra d'un seul coup. Elle mettra peut-être un peu de temps à apparaître, mais le temps d'attente total sera beaucoup plus court que de réafficher à chaque pixel.

J'ai lu quelque morceaux de documentation de LibertyBasic (désolé, c'est en anglais).
http://lbpe.wikispaces.com/SegmentsAndFlushing
http://basic.wikispaces.com/FlushConserveBMP
http://www.libertybasicuniversity.com/lb4help/0D14N5.htm

Apparemment, une Graphicbox, c'est pas simplement un carré plein de pixels qu'on colorie. C'est un objet qui permet de stocker des intructions de dessins, de les regrouper en "segment", de réafficher un segment, etc.

L'instruction "flush" effectue deux choses différentes : rendre l'image persistante (sinon elle disparaît quand on minimise la fenêtre) et stocker les instructions de dessins en cours dans un segment. Je trouve ça bizarre qu'une instruction fasse deux choses, mais c'est pas grave, on va faire avec.

Si tu fais plein de flush, la machine doit stocker plein de segments, ça prend plein de mémoire, c'est lent et ça ne sert à rien. Un seul flush tout à la fin de la génération de l'image, ça suffit.

Pour plus tard, si tu veux faire une application génèrant plusieurs images aléatoires (par exemple, une nouvelle image à chaque fois que tu appuies sur un bouton), il faudra faire attention de supprimer les segments précédents. Sinon tu vas à nouveau remplir la mémoire pour rien. L'instruction pour tout vider (l'image en cours et les segments précédents), c'est

Code VB :

Ou sinon, tu dois pouvoir faire des trucs plus subtils : supprimer le segment précédent avec DelSegment et dessiner une nouvelle image par dessus l'autre. Ou bien bidouiller quelque chose avec des Discard et des Redraw. Ou même préparer ton image en mémoire, et l'afficher en une seule instruction avec un DrawBmp. Mais là je ne m'y connais pas assez pour t'expliquer en détail comment faire.


Autre remarque : au début de la boucle, tu génère un nombre aléatoire (la variable "valor") qui n'est utilisée que si spectreValor vaut 0 ou 1. Il vaut mieux mettre cette génération directement dans le "case 0 , 1". Ça ne changera rien de significatif pour la rapidité d'exécution du code, mais ce sera plus clair.

Et je ne suis pas sûr que le "+1" dans la génération de nombre aléatoire soit nécessaire. L'instruction "color" demande trois valeurs entre 0 et 255. Si tu mets +1, ça génère des valeurs entre 1 et 256.

Pour conclure, ta boucle de génération de l'image, je la verrais comme ça :

Code VB :

Je ne voudrais pas prêcher pour ma paroisse ou lancer du troll, mais pour un langage qui fonctionne sur Windows, Mac, Linux, [Amiga, systèmes embarqués, ...], qui est vraiment pas compliqué à apprendre, et qui contient plein de librairies et d'utilitaires, il suffit de prendre le python.

Et y'a même pas besoin de compiler en bytecode, ça marche tout de suite avec le code source. Youpi !


Sur ce, j'y retourne, à ce fameux python. À bientôt !

Coucou !

Ça a l'air rigolo ce truc. Bon j'ai pas installé le LB alors je peux pas tester. Mais je le ferais peut-être à l'occaz'.

Juste pour info, concernant les compressions : il y a des formats d'images un peu mieux que le bmp, pour ça. J'ai vu que les images du personnage étaient doublées : une première fois en noir et blanc, une seconde fois l'image réelle. Je suppose que c'est pour gérer la transparence.

Le format .png est compressé au max, sans perte d'informations (contrairement au jpg), et peut contenir des infos de transparence.

Je t'aurais bien conseillé d'utiliser une dll qui lit/écrit les format png et qui fonctionne avec LibertyBasic, dans ce cas, je t'aurais dit par exemple d'aller voir ce site : http://basic.wikispaces.com/DLLs, et de cliquer sur le lien "simplepng.dll", sauf que le lien ne marche plus.

Il y en a peut-être une autre ailleurs. Ou c'est peut être déjà intégré dans le LB de base. Bonne recherche !

Ah ok. Pas de soucis. Je ne doute pas que tu te sois amélioré dans tes talents de programmation depuis !

Sur ce, je vais aller me coucher. Il se fait un peu tard. C'est rigolo d'être en ligne ensemble sur le forum. Mais là j'ai les yeux qui se ferment tout seuls.

À+

Coucou !

Dans les langages de programmation que je connais, ce genre de technique a un nom. Ça s'appelle les threads, ou l'exécution multi-processus. Je ne sais pas si c'est possible en JB/LB, mais en python, ça se fait les doigts dans le nez.

Je ne suis pas trop surpris que le code qui lit n'ait pas trouvé le fichier. Sauf bidouilleries particulière, le système d'exploitation ne permet pas la lecture d'un fichier en cours d'écriture / de création.

Pour communiquer entre deux processus, la solution la plus simple c'est d'utiliser des sockets. Non, ce ne sont pas des chaussettes, mais une fonctionnalité gérée par le système d'exploitation, qui permet d'envoyer des octets entre deux applications différentes. "En python, ça aussi ça se fait les doigts dans le nez".

Si tu ne peux pas utiliser de socket, tu peux faire le bourrin avec des échanges de petits fichiers. Tu as un processus "générateur" qui crée des fichiers de petite taille, tous dans le même répertoire. Par exemple : fichier001.txt, puis fichier002.txt, etc. Et à côté, tu as un processus "consommateur" qui lit les fichier dans l'ordre, exécute ce qui est demandé dedans, et les efface au fur et à mesure.

Si tes deux processus ont besoin de communiquer dans les deux sens, tu crées un autre répertoire, avec d'autres petits fichiers, mais la génération-consommation se fait dans l'autre sens.

Ça peut être amusant à faire, mais à mon avis, ça ne va pas améliorer la rapidité d'exécution. L'écriture/lecture de fichier, c'est lent. Par contre, avec des sockets, ça devrait bien marcher, car tout reste dans la mémoire vive.

Amuse-toi bien !