SLE : un éditeur de niveau simple
Posté le 25/03/2021 13:24
Bonjour ! Je vous présente aujourd'hui SLE - Simple Level Editor - un éditeur de niveau conçu pour être simple d'utilisation et accessible à tous.
=>
Dépôt de SLE sur sourcehut
L'éditeur est séparé en deux fenêtres, voir le README sur le dépôt pour plus d'informations. Vous pouvez l'essayer dès maintenant, en éditant le fichier
sample.kble. Attention, le programme ne peut pas encore créer de nouveau niveau ! Le but de l'éditeur étant de rester simple, il devrait être terminé d'ici la fin de la semaine
La fenêtre de l'éditeur est de la taille de l'écran de la 90+E par défaut. Pour configurer l'éditeur, lisez README et modifiez include/config.h avant de recompiler.
Pourquoi SLE ?
Le but de ce projet est de remplir un objectif qui n'est pas ciblé par KBLE : je cherchais un éditeur extrêmement simple, léger et rapide pour faire un petit jeu à niveaux de taille fixe et graphique. KBLE est uniquement basé sur des
couleurs, SLE utilise un tileset passé en paramètre pour afficher les
textures de tuiles. Pour des jeux simples et reposant sur les graphismes, cet éditeur est plus approprié que KBLE.
SLE utilise le format de KBLE ! Tout programme utilisant des .kble supporte KBLE et SLE en conséquence. kble2lua pour une conversion simple d'un .kble en fichier Lua, fonctionne évidement très bien avec les niveaux créés par SLE (exactement le même format).
Le but ultime est de permettre aux éditeurs et outils liés à KBLE d'être utilisés de manière transparente.
SLE devrait être compilable sur tous les systèmes d'exploitation POSIX : Linux, les *BSD, OS X, etc. supportés par raylib.
Windows n'étant pas POSIX compliant, ce système d'exploitation n'est pas une cible supportée.
Détails techniques
SLE est configuré avec cmake, j'aurais préféré utiliser un Makefile mais c'est arrangeant pour les détails X11/wayland.
La codebase est écrite en C90, avec pas mal de warnings,
-pedantic inclut.
-Werror est activé.
Ce projet utilise le format de fichier de KBLE et est compatible avec les outils liés.
=>
KBLE
=>
kble2lua
Je développe sous Alpine Linux et la dernière version de Raylib. Si vous avez des problèmes sur d'autres systèmes dites le moi !
Fichier joint
Citer : Posté le 25/03/2021 17:36 | #
Intéressant !
J'ai testé et c'est vrai que ça ressemble à un éditeur de niveau simple permettant de faire du level-design efficace. L'interface est propre, les instructions sont claires, la prise en main est rapide.
Pouvoir sélectionner plusieurs tiles en même temps depuis le tileset serai une bonne fonctionnalité, un peu chiante à faire mais utile selon moi.
L'export en format .kble rend le tout compatible avec tes outils, et je pense notamment à une liaison KBLE x SLE permettant d'éditer son niveau avec le clavier de KBLE et voir en temps réel le design de celui ci
Très sympa bravo !
(Et de toute façon, vous pouvez pas dire le contraire)
MultipliCasio
RDM Calculs
Back Mirror
A Switch To The Top C
Citer : Posté le 25/03/2021 17:50 | #
Merci d'avoir testé Tituya ! Tes commentaires sont motivants
Pouvoir sélectionner plusieurs tiles en même temps depuis le tileset serai une bonne fonctionnalité, un peu chiante à faire mais utile selon moi.
Merci pour la suggestion ! Ce ne serait pas si long à faire, mais ça n'arrivera probablement avant la première version stable. Pour ne pas l'oublier, pourrais-tu rédiger un ticket résumant ton idée et son utilisation ? Tu peux écrire un mail à ~kikoodx/
Nul besoin de compte sr.ht !
Merci pour ton attention.
Citer : Posté le 25/03/2021 18:31 | #
Intéressant ! J'ai compilé le logiciel mais eu la surprise de ne pas pouvoir créer de nouveau fichier (et donc de l'utiliser, puisque je n'avais pas de copie de KBLE sur le moment).
Je comprends les aspects techniques mais j'ai plus de mal à voir où tu veux en venir (et pourquoi ce n'est pas une fonctionnalité de KBLE). Je comprends que KBLE chercher la « simplicité » mais la séparation me paraît floue. Et ce que tu gagnes en simplicité, tu le perds à faire clôner un dépôt git, lire un README et modifier un header à ton utilisateur. :x
Citer : Posté le 25/03/2021 19:18 | #
Intéressant ! J'ai compilé le logiciel mais eu la surprise de ne pas pouvoir créer de nouveau fichier (et donc de l'utiliser, puisque je n'avais pas de copie de KBLE sur le moment).
Je n'ai pas encore programmé la création de fichier, ça arrivera bientôt (ce soir si j'ai le temps). Le tileset assets/tileset.png et le fichier sample.kble sont fournis dans le dépôt pour les tests
Je comprends les aspects techniques mais j'ai plus de mal à voir où tu veux en venir (et pourquoi ce n'est pas une fonctionnalité de KBLE). Je comprends que KBLE chercher la « simplicité » mais la séparation me paraît floue.
Le public visé par SLE est complètement différent de KBLE. Je pense que je n'ai toujours pas réussi à te faire comprendre l'idée de KBLE ? Je ferai une comparaison d'utilisation type des deux programmes demain
Et ce que tu gagnes en simplicité, tu le perds à faire clôner un dépôt git, lire un README et modifier un header à ton utilisateur. :x
Désolé si il y a eu confusion. Je veux faire en sorte que le logiciel soit facile à packager, et accepte des paramètres sans avoir besoin d'être recompilé. Modifier le header pour la configuration est temporaire
Note que kble2lua est parfaitement utilisable et distribuable, j'avais créé un paquet Alpine pour le fun en cinq minutes.
Si ton message une critique plus générale envers les logiciels qui demandent de modifier les sources pour les configurer, tu n'as pas à les utiliser si ça ne te plait pas et la plupart du temps tu peux les patcher pour obtenir une configuration « classique ». C'est le pouvoir du choix.
Citer : Posté le 25/03/2021 19:30 | #
Ah mais je n'ai aucun problème avec toute cette histoire, je ne comprends juste pas ton plan de développement. Tu programmes deux éditeurs indépendants avec deux paradigmes différents mais le même format de fichier (heureusement versionné sinon bonjour les problèmes dès qu'un est mis à jour mais pas l'autre), le code étant pour l'instant copié de l'un à l'autre.
En gros, pour être franc, je ne comprends pas pourquoi tu lances un autre projet alors qu'aucune communication ne suggère que KBLE est mature ; je ne vois pas quel public tu vises puisque justement le pouvoir du choix fait qu'il y a plein d'alternatives alléchantes et une paire d'éditeurs bruts ne vaut pas un éditeur bien poli.
(Et oui, même si je n'ai rien contre configurer via un header, je hais la philosophie de suckless.org à tel point qu'être mentionné sur le site me donne envie d'esquiver un logiciel.)
(Edit : Ce message est plus sec que je ne l'aurais voulu, mais voilà.)
Citer : Posté le 25/03/2021 22:07 | #
Ah mais je n'ai aucun problème avec toute cette histoire, je ne comprends juste pas ton plan de développement. Tu programmes deux éditeurs indépendants avec deux paradigmes différents mais le même format de fichier (heureusement versionné sinon bonjour
les problèmes dès qu'un est mis à jour mais pas l'autre), le code étant pour l'instant copié de l'un à l'autre.
Je le répète une fois de plus : je ne compte pas modifier le format de fichier de sitôt. Cependant, l'octet est présent au cas où. Je ne l'ai ajouté qu'après ta remarque sur le topic de KBLE, mon idée est de rester minimal là-dessus.
Le seul code copié collé entre KBLE C et SLE est le chargement et la sauvegarde. Réécrire ce code aurait été complètement stupide, le format étant identique, tu l'as dit toi-même ! Je n'ai pas fait d'aller retour entre les deux depuis.
Si mon plan de développement t'inquiète pour une raison ou pour une autre, je vais te « rassurer ». J'avais cessé le développement de KBLE Zig car ai changé de distro et que le code ne compilait pas. J'ai aujourd'hui remarqué que la version de raylib présente dans les paquets d'Alpine avaient presque 9 mois de retard. Après avoir mis à jour le paquet (et poussé les changements upstream), KBLE Zig compile et fonctionne parfaitement. Sachant cela, je n'ai plus besoin de KBLE C. Je vais reprendre le développement sur KBLE Zig.
Tu demandes pourquoi deux éditeurs avec le même format de fichier ? Mon objectif depuis le début est de pouvoir utiliser le format dans un vaste eventail d'outils et langages, et de créer des outils spécialisés. J'ai voulu commencer un nouveau projet qui impliquerait du modding (complètement hors sujet mais bon on est plus à ça près), et je voudrais permettre aux utilisateurs d'éditer les niveaux avec SLE tandis que je travaille avec KBLE. J'ai bien compris que je suis le seul à apprécier et comprendre KBLE, je travaillerai pour que ce soit plus clair dans futur.
En gros, pour être franc, je ne comprends pas pourquoi tu lances un autre projet alors qu'aucune communication ne suggère que KBLE est mature ; je ne vois pas quel public tu vises puisque justement le pouvoir du choix fait qu'il y a plein d'alternatives alléchantes et une paire d'éditeurs bruts ne vaut pas un éditeur bien poli.
Je ne cherche pas à vendre un produit au premier gus venu. Comme je sais que tous les programmeurs ne chercheront pas l'éditeur parfait et s'arrêterons à Sublime, Atom ou VSCode. Mon avis est qu'un programme qui fait est toujours moins bon qu'un outil spécialisé. Imagine si Tiled avait séparé son système d'autotiling au projet. N'importe quel éditeur de niveau pourrait l'utiliser. Même argument pour les règles de LDtk. Ces opportunités sont gâchées.
(Et oui, même si je n'ai rien contre configurer via un header, je hais la philosophie de suckless.org à tel point qu'être mentionné sur le site me donne envie d'esquiver un logiciel.)
Je ne pense pas qu'une philosophie de création de (généralement bons) logiciles vaille la peine de déchainer de la haine. J'ai (première personne du singulier) beau détester le JS, si un programme sans alternative est proposé je l'utiliserai. Tu te plains des trolls, n'en
devient pas un par pitié.
(Edit : Ce message est plus sec que je ne l'aurais voulu, mais voilà.)
J'essaye de ne pas répondre de la même manière que toi mais je ne sais pas comment ça sort. Je préfère avoir des retours (devrais-je dire opinions ?) houleux qu'un silence sidérant. Mais je dois t'avouer que tu m'as pas mal énervé dans ta formulation. Tu peux poser des questions au lieu de faire des assertions, je pense que tu en as conscience.
Pas de @ RDP sur ce message OK ?
Citer : Posté le 26/03/2021 23:56 | #
Salut ! Après l'intervention qu'a fait Lephé hier, j'ai compris que je ne faisais pas forcèment de bons choix pour le grand public et la simplicité d'utilisation. En conséquence, j'ai décidé de me centrer sur le public utilisateur « moyen », tout en gardant une simplicité à l'utilisation. Même si je l'ai pris durement hier, merci Lephé, ça m'a motivé
J'ai passé six bonnes heures aujourd'hui et hier à me documenter sur les arguments de ligne de commande, à réécrire du code et débugger pour que toutes les options importantes configurées précédemment en éditant un header et recompilant le programme se fasse maintenant avec des arguments et flags. Merci getopt_long.
Voici quelques exemples de commandes :
$ # version courte
$ sle -t assets/tileset.png -l sample.kble
$ # met la largeur des tuiles à 2 pixels et la hauteur à 32
$ sle -t assets/tileset.png -l sample.kble -tile-width 2 -tile-height 32
$ # décale l'affichage de l'éditeur vers la droite de 3 pixels et active le mode verbeux
$ sle -t assets/tileset.png -l sample.kble -editor-off-x 3 -editor-off-y 0 -verbose
Il y a 12 flags au total. Je vous redirige vers le README pour avoir la liste. Les projets fictifs souhaitants utiliser da editor pourront fournir un script qui lance sle avec les bons flags
J'espère que cette solution correspond à ce que tu pensais Lephé. Je sais que je n'ai pas répondu à tous les problèmes, mais j'y travaille.
Note : il est toujours possible de changer les paramètres par défaut dans include/conf.h. Dans l'éventualité où un projet utiliserait l'éditeur, cela permettrait de livrer un binaire de SLE préconfiguré.
En plus de cela, j'ai fait deux boguefixes :
Je commence par le plus petit, l'affichage était cassé de manière assez sévère, je l'ai revu et il se porte comme un charme.
Plus grave, j'avais une boucle infinie à l'écriture des niveaux pour une raison qui m'était inconnue. J'ai passé une heure à déboguer le programme et j'ai fini par trouver que je faisais une suite de cast et avait manqué un unsigned. Ce qu'il se passait :
nombre entre 0 et 255 → nombre entre -128 et 127 (overflow) → entier non signé
J'ai rendu le char du milieu et le problème est réglé ! J'aurai aimé le trouver plus tôt, mais désormais l'éditeur se débrouille très bien avec un grand nombre de cases (j'ai testé avec des tuiles sur trois octets). Pour une raison mystique je pensais que les char étaient non signés par défaut en C.
Je ne sais pas si je continuerai de travailler 8 heures par jour sur ce projet, je dois dire que je ne suis pas encore confortable en C et complètement défoncé.
Je passe beaucoup plus de temps que prévu sur cet éditeur, je pensais passer deux jours dessus pour pouvoir faire un jeu rapidement. Heh.
Citer : Posté le 27/03/2021 09:45 | #
Je suis content que tu l'aies bien pris, j'aurais pu y mettre plus de tact mais j'ai toujours du mal à trouver le bon équilibre.
Honnêtement c'est pratique de ne pas avoir à changer la taille dans la configuration, comme ça on peut efficacement travailler sur plusieurs projets à la fois (genre une version mono et une version G90).
Pour le bug de signe, bien joué : c'est un genre clairement compliqué à trouver et comme tu peux le voir les conséquences sont assez casse-pieds. Pour info le standard C ne spécifie pas si le type char est signé ou pas, si bien que même s'il est signé la plupart du temps la « bonne » façon est d'utiliser signed char ou unsigned char seulement (ou int8_t ou uint8_t de <inttypes.h>). D'ailleurs en-dehors du stockage, quand tu passes des paramètres ou des valeurs de retour de fonctions, en général on met des int pour éviter ce problème (ça ne coûte rien).
Citer : Posté le 27/03/2021 15:27 | #
Dans la grosse majorité du code, je n'ai utilisé que des int. J'ai retenu ce que tu as expliqué, et en effet ça rend le code plus lisible. Dans cette section en particulier, vu que je manipulais des octets directement j'avais choisi d'utiliser des char pour tronquer les valeurs automatiquement. J'ai remplacé tous mes char dans le code lié par des unsigned char, même si ce n'est pas nécessaire partout au moins c'est clair et le comportement est identique.
Un ajout relativement important, j'ai ajouté la création de niveau. Ce n'est pas encore automatique, il faut passer le flag -create (ou -c) et un niveau aux dimensions -level-width et -level-height (nouveaux flags) est créé. J'ai aussi mis à jour le README et ajouté des exemples de commandes pour des aliases PICO-8, fx-CG50 et fx-9860G.
Cet ajout et le fait qu'il n'y ait plus de bugs à ma connaissance font que l'éditeur est maintenant utilisable
Le tag 0.1.0 a été créé pour cette première pre-release, je vais pouvoir commencer le projet pour lequel j'ai débuté cet éditeur.
https://git.sr.ht/~kikoodx/sle/refs
@RDP je suppose, je vous laisse faire le tri 8)
Citer : Posté le 27/03/2021 15:31 | #
J'ai l'impression que le tile 0 (vide) prend la place du premier tile dans le tileset, ce qui empêche de le placer sur la map.
Côté langage, du coup tu comptes rester sur du Zig ? C ?
Citer : Posté le 27/03/2021 15:40 | #
J'ai l'impression que le tile 0 (vide) prend la place du premier tile dans le tileset, ce qui empêche de le placer sur la map.
C'était le comportement voulu, c'est comme ça que les tilesets fonctionnent dans PICO-8 et d'autres moteurs. Je vais cependant ajouter une option pour que la valeur de la première tuile soit configurable, il n'y a aucune raison pour qu'elle soit fixe.
Côté langage, du coup tu comptes rester sur du Zig ? C ?
SLE est entièrement programmé en C, KBLE en Zig. Je vais laisser ça comme ça pour le moment, mais je pense que viendra un jour où je réécrirai KBLE en C (comme je l'avais prévu). C'est encore loin, et j'ai envie de faire un jeu dans l'immédiat.
Citer : Posté le 27/03/2021 15:44 | #
Oh, je vois. C'est logique après tout, il vaut mieux matérialiser le vide dans le tileset que le laisser implicite. Bon courage pour la suite
Citer : Posté le 28/03/2021 16:02 | #
Bonjour ! J'ai corrigé un bug (0.1.1), implémenté une suggestion de Masséna et ajouté une option pour pouvoir changer l'index de la première tuile du tileset pour obtenir le comportement qu'attendait Lephé (0.2.0).
Voici les nouveaux flags introduits avec la 0.2.0 :
La dernière version au moment où je poste ce message est la 0.2.1.
@RDP, cadeau Masséna
Ajouté le 10/04/2021 à 12:00 :
Bonjour ! Je suis sur un autre projet depuis deux semaines, j'en profite pour tester SLE en action.
Une fonctionnalité dont j'avais besoin est la copie de tuile (vous savez, la pipette). Je l'ai implémentée en quelques minutes et mis à jour le README. Ce changement rend l'expérience utilisateur plus agréable. J'ai aussi changé les valeurs par défaut, principalement pour que les projets qui utiliseraient ce programme créent leurs scripts avec les options plutôt que de s'appuyer sur les défauts.
Voici la glorieuse 0.3.0 et son (petit) changelog.
=> https://git.sr.ht/~kikoodx/sle/refs/0.3.0
À la revoyure
@RDP
Citer : Posté le 17/04/2021 17:35 | # |
Fichier joint
Bonjour ! J'ai ajouté le redimensionnement de fenêtres à SLE. C'est une fonctionnalité essentielle, et elle vient avec de nouvelles options pour définir l'upscale par défaut.
Voici le changelog de la 0.4.0.
=> https://git.sr.ht/~kikoodx/sle/refs/0.4.0
À la prochaine
@RDP
P@RD
DP@R
RDP@
Ajouté le 06/05/2021 à 13:25 :
Bonjour ! Après avoir découvert le système Meson, j'ai décidé de l'utiliser pour ce projet au lieu de CMake. En comparaison avec CMake, qui m'a pris plusieurs jours à comprendre comment l'utiliser correctement, j'ai grok Meson en moins d'une heure.
Le commit ne change pas que cela, mon CMake devait être cassé car j'ai eu beaucoup plus de warnings (pertinents et demandés) avec Meson, je les ai tous corrigés.
Je ne sais pas si ce changement vaut un bump de version, je laisse tout en 0.4.0 pour le moment. Le commit date d'hier, j'ai juste oublié d'en parler ici.
=> https://git.sr.ht/~kikoodx/sle/commit/53132075b8d7e9001f1905370d7736af2b7173e7
$ meson setup builddir && cd builddir
$ meson compile
# meson install
@RDP, vous en faites ce que voulez.
Citer : Posté le 22/11/2021 01:28 | # |
Fichier joint
Salut les gens !
Il est maintenant possible de remplir des zones rectangulaires en deux clics. Le fonctionnement est décrit dans le README, il suffit de maintenir la touche CTRL Gauche et cliquer.
Lephé a aussi contribué un fix il y a un petit bout de temps qui devrait permettre au programme de bien fonctionner sur les systèmes GNU/Linux, merci à lui !
=> https://git.sr.ht/~kikoodx/sle/refs/0.5.0