Messages

1

Projets SFML / Re : lxgui - "Lua and Xml Graphical User Interface"

« le: Janvier 24, 2013, 11:07:08 pm »

Le 64 bit ne devrait pas poser de problème, puisque j'utilise toutes ces bibliothèques en 64 bit sous linux. Je ne sais pas où en est le support via MinGW par contre, vu que mon Windows n'est que 32 bit.

Ceci dit, souvent il est bien plus simple de re-compiler chaque bibliothèque plutôt que de chercher des binaires pas à jour, qui parfois ne sont pas compatibles avec l'ABI de ton compilateur (en effet, certaines versions de GCC ne sont pas compatibles entre elles, en particulier si on mélange 32 bits et 64 bits).

Pour chaque bibliothèque, tu vas donc chercher le site officiel et télécharger les dernières sources disponibles, en suivant les instructions d'installation fournies (README, ou sur le site).

Par exemple pour compiler zlib, tu copies le fichier Makefile.gcc (situé dans le dossier win32) dans le répertoire racine de zlib, et tu le renommes en Makefile tout court. Ensuite tu ouvres un invité de commande, tu navigues jusqu'à ce répertoire (ou alors tu installes le power toy "command line here" qui permet d'ouvrir une console par click droit sur le répertoire), tu tapes juste "mingw32-make libz.a" et c'est fini (après si tu ne veux pas modifier mes projets C::B, il faut aussi déplacer le fichier libz.a dans lib/libz.a).

Pareil pour libpng : tu déplaces /scripts/makefile.gcc vers /Makefile, tu modifies les premières lignes du Makefile pour mettre le bon répertoire pour les sources de zlib, et tu lances simplement "mingw32-make".

Pour Freetype c'est plus coton. À l'époque j'avais simplement importé le projet Visual 2008 avec Code::Blocks et compilé comme ça. Mais il y a une méthode un peu plus propre, qui consiste a utiliser MSYS. Tu l'installes avec MinGW (le plus simple étant avec "mingw-get install msys"), tu ajoutes "{répertoire de mingw}\msys\1.0\bin" au PATH, puis tu vas dans le répertoire de freetype. Tu tapes alors "bash", puis "./configure", puis "make". La bibliothèque est alors créée dans /objs/.libs/libfreetype.a.

Mais je suis d'accord avec toi : c'est un processus pénible, et toutes les bibliothèques ne sont pas égales sur le plan de la documentation pour l'installation (en particulier avec MinGW, puisque tout le monde pense que GCC = linux et Windows = Visual Studio ...), et c'est pour ça que j'ai essayé d'utiliser le moins de bibliothèque possible. Mais il faut quand même apprendre à le faire, à un moment ou un autre. Une fois qu'on s'est un peu cassé les dents (j'en ai vraiment bavé avant de bien tout comprendre), on peut installer tout ce qu'on veut.

L'idéal étant tout de même de programmer sous linux

2

Projets SFML / Re : lxgui - "Lua and Xml Graphical User Interface"

« le: Janvier 21, 2013, 07:48:17 pm »

L'option est sélectionnée dans les cibles qui utilisent explicitement GCC (c'est à dire : "Release_Win32", "Release_Linux", etc.), mais pas dans les options générales car j'ai aussi des cibles pour Visual C++ (qui lui ne comprend pas "-std=c++0x"). Je pense que mettre à jour ton compilateur à la version 4.6 (voir 4.7 si tu peux, ça ne coûte rien !) règlera une bonne partie des problèmes.

Quant à la SFML, je me base sur des snapshots récents de la version de développement (vieux de moins de deux mois, je dirais). Si tu as des erreurs, ça doit être au niveau du noms de certaines touches du clavier qui ont été légèrement modifiés à un moment.

3

Projets SFML / Re : Re : lxgui - "Lua and Xml Graphical User Interface"

« le: Janvier 20, 2013, 08:58:24 pm »

Par exemple, où dois-je écrire -std=c++0x ?

Si tu utilises les projets C::B qui sont fournis avec le code source, tu n'as rien besoin de changer, ça doit compiler tout seul. Par contre si tu comptes utiliser cette bibliothèque dans un de tes projets, il faudra activer le c++11, comme l'a décrit Lo-X juste au dessus (Project -> Build options -> Compiler settings -> Compiler flags -> Have g++ follow the coming C++0x ISO C++ language standard [-std=c++0x]).

Par contre, il me dit maintenant que to_string est ambiguë.

À quel endroit du code précisément (fichier + ligne), quel est le message d'erreur exact, et quelle version de gcc as-tu installé ?

4

Projets SFML / Re : lxgui - "Lua and Xml Graphical User Interface"

« le: Janvier 20, 2013, 02:05:17 pm »

Exact. Minimum gcc 4.6 (avec -std=c++0x), ou visual studio 2010. Quel compilateur utilises-tu?

5

Projets SFML / Re : lxgui - "Lua and Xml Graphical User Interface"

« le: Janvier 05, 2013, 02:59:37 pm »

Je viens également de mettre en ligne une version pré-compilée du programme de démo fourni avec la bibliothèque (celui qui a été utilisé pour le screenshot du premier post). Vous pouvez le télécharger [ici], j'espère seulement qu'il ne manque aucune DLL.

Edit : la version 1.2.0 est sortie, avec au programme le support de MSVC 2010 pour la compilation sous Windows. J'ai aussi ajouté des fonctions raccourcis pour faciliter l'écriture du code en C++, ainsi que quelques fonctionnalités supplémentaires comme les couleurs au format HTML ("#RRGGBBAA") ou le filtrage des textures (aucun filtre, ou filtre linéaire). Les fichiers sont disponible sur sourceforge.net comme toujours.

6

Projets SFML / Re : lxgui - "Lua and Xml Graphical User Interface"

« le: Janvier 01, 2013, 11:45:05 pm »

Un rapide message pour vous présenter la version 1.1.0.

Cette nouvelle version contient en grande majorité des correctifs, quelques améliorations sur la qualité du code et/ou les performances (rien de folichon), mais elle a l'inconvénient d'avoir une API légèrement différente de celle de la version 1.0.0. Autrement dit : il faudra faire quelques ajustements mineurs sur votre code pour utiliser cette nouvelle version. En particulier, la classe gui::locale (qui s'occupait surtout de traduire les touches du clavier pour différents arrangements comme AZERTY ou QWERTY) a disparu, le travail étant maintenant délégué à la SFML. Cet petit changement induit une modification de l'initialisation du GUI, voici donc l'exemple modifié pour la 1.1.0 :

// On créé une fenêtre SFML
sf::Window mWindow(...);

// On créé un gestionnaire d'input (clavier, souris, ...)
utils::refptr<input::handler_impl> pSFMLHandler(new input::sfml_handler(mWindow));

// On initialise la classe principale gui::manager
gui::manager mManager(
    // On lui donne un gestionnaire d'input
    pSFMLHandler,
    // La langue qui sera utilisée par l'interface (purement informatif : c'est aux addons de se traduire eux-même en utilisant cette valeur)
    "frFR",
    // Les dimensions de la fenêtre de rendu
    mWindow.getSize().x, mWindow.getSize().y,
    // L'implémentation OpenGL du rendu
    utils::refptr<gui::manager_impl>(new gui::gl::manager())
);

// On lit ensuite les fichiers XML et Lua :
//  - d'abord en précisant le dossier dans lequel se trouve le GUI
mManager.add_addon_directory("interface");
//  - puis on créé un contexte Lua
mManager.create_lua([&mManager](){
    // Ce code peut être appelé plus tard, par exemple quand l'utilisateur
    // demande à recharger le GUI (le contexte lua est alors détruit, puis re-créé).
    //  - on spécifie les classes que l'on veut utiliser
    mManager.register_region_type<gui::texture>("Texture");
    mManager.register_region_type<gui::font_string>("FontString");
    mManager.register_frame_type<gui::button>("Button");
    mManager.register_frame_type<gui::slider>("Slider");
    mManager.register_frame_type<gui::edit_box>("EditBox");
    mManager.register_frame_type<gui::scroll_frame>("ScrollFrame");
    mManager.register_frame_type<gui::status_bar>("StatusBar");
    //  - on référence dans Lua des fonctions C++ si nécessaire
    // ...
});

//  - puis enfin on charge le tout.
mManager.read_files();

// Dans la boucle principale
while (bRunning)
{
    // On récupère les événements de la fenêtre
    sf::Event mEvent;
    while (mWindow.pollEvent(mEvent))
    {
        // ...

        // On transmet ces événements au gestionnaire d'input
        pSFMLHandler->on_sfml_event(mEvent);
    }

    // ...

    // On met à jour le GUI
    mManager.update(fDeltaTime);

    // ...

    // Puis on l'affiche à l'écran
    mManager.render_ui();

    // ...
}

Mis à part ce changement, tout fonctionne de la même façon.
Au menu des nouveautés, on notera en particulier :

• l'ajout de scripts CMake pour la compilation (facilite grandement l'installation sous linux)
• la mise à jour du gestionnaire d'input SFML pour coller aux derniers snapshots de la RC
• l'ajout d'un gestionnaire d'input pour GLFW (une bibliothèque de gestion de fenêtre pour OpenGL)
• il est maintenant possible d'utiliser des std::functions (ou des foncteurs, ou des lambdas) pour définir un "script".

Exemple simpliste qui imite bêtement les scripts Lua du premier post :

float update_time = 0.5f, timer = 1.0f;
int frames = 0;

pFrame->define_script("OnUpdate",
    [&](gui::frame* self, gui::event* event) {
        float delta = event->get(0)->get<float>();
        timer += delta;
        ++frames;

        if (timer > update_time) {
            gui::layered_region* reg = self->get_region("FPSCounterText");
            gui::font_string* text = dynamic_cast<gui::font_string*>(reg);

            text->set_text("FPS : "+utils::to_string(floor(frames/timer)));
           
            timer = 0.0f;
            frames = 0;
        }
    }
);

C'est un peu moins agréable à utiliser que le code Lua, moins flexible aussi puisqu'il faut re-compiler le programme pour modifier le script, mais ça sera toujours plus rapide et plus rigoureux (impossible par exemple d'appeler une méthode qui n'existe pas). L'avantage des std::functions, c'est qu'on peut vraiment mettre ce qu'on veut. Si à la place du code ci-dessous, vous voulez que l'événement "OnUpdate" appelle une certaine fonction my_on_update_function(), alors il suffit d'écrire :

pFrame->define_script("OnUpdate", &my_on_update_function, "main.cpp", 255);

... si cette fonction a le bon prototype (c'est à dire qu'elle attend un pointeur vers une gui::frame (l'objet qui émet l'événement) et un pointeur vers un gui::event (qui contient les informations additionnelles liées à l'événement)).

Pour des informations plus détaillées, je vous invite à lire le changelog.

7

Suggestions de nouvelles fonctionnalités / [2.0] sf::Keyboard::getKeyName

« le: Juillet 31, 2012, 05:21:30 pm »

Suite à la discussion qui a émergé ici, j'ouvre un nouveau topic dédié à cette question.

Je me cite moi-même... :

Voici une fonction issue de OIS qui est très utile et qui semble manquer à la SFML : obtenir une chaîne de caractère qui décrive le nom localisé d'une touche du clavier (différent de TextEntered : on peut avoir "Esc.", "Del.", "F1", les touches d'accent "^", etc.). On peut s'en servir entre autre pour afficher un écran de personnalisation des touches.

J'ai écrit un patch (en pièce jointe à ce post) qui permet d'implémenter ce comportement dans la classe sf::Keyboard. L'implémentation Windows est fonctionnelle, mais celle pour Linux est incomplète : la chaîne retournée par la fonction est toujours en anglais, et les noms sont un peu moches... Je cherche en ce moment un moyen de contourner le problème. L'implémentation pour OSX est toujours manquante, mais Hiura se proposerait éventuellement pour s'en occuper.

[attachment deleted by admin]

8

Projets SFML / Re : Re : lxgui - "Lua and Xml Graphical User Interface"

« le: Juillet 31, 2012, 05:15:55 pm »

Et on ne devrait pas discuter de ça dans le topic qui concerne ton projet lxgui, là on est en train de le polluer. Si tu veux aller plus loin dans la discussion concernant la localisation des touches, tu peux ouvrir une nouvelle discussion.

Houla oui, tu as raison. J'ouvre un topic là pour poursuivre la discussion : click.

Salut,
   J'aime beaucoup ton projet, t'as fait du super boulot. J'ai le même genre de projet en tête et je me demandais si tu avais considéré l'utilisation du JSON à la place de l'xml qui est très verbeux. (cf QML qui est très proche de tout ça) ça donne un code plus claire et plus lisible.

Salut et merci beaucoup ! Pour le JSON non, pas du tout. À vrai dire je ne connaissais que de nom avant que tu en parles. C'est effectivement moins verbeux, et d'après ce que j'ai pu lire ça a l'air d'être possible de l'utiliser pour remplacer le XML. La seule chose qui peut éventuellement manquer (on peut faire sans mais c'est plus dur) c'est la notion d'héritage. Dans mon validateur d'XML, je peux dire qu'un type de block (exemple : Frame) hérite d'un autre type de block (exemple : UIObject). Il récupère alors toutes les définitions d'attributs et de blocs enfants de son parent. Ensuite, à tous les endroits du fichier XML où l'on dit qu'on attend un bloc UIObject, on peut mettre un bloc Frame à la place.

Je suis aussi d'accord avec Laurent pour la localisation je sais que je n'aurai pas envie de m’embêter avec ça

Je ne sais pas si tu as lu les posts précédents, mais je me suis déjà débarrassé du système de localisation manuel. J'utilise maintenant l'événement TextEntered de la SFML qui fait tout à ma place. Reste ce petit problème avec une éventuelle fonction getKeyName() dont on parle un peu plus haut...

9

Projets SFML / Re : lxgui - "Lua and Xml Graphical User Interface"

« le: Juillet 30, 2012, 10:53:14 pm »

Voilà le patch. J'ai pu tester la version linux (Ubuntu 12.04) et windows (Windows XP), mais je n'ai rien pour le Mac. Je pensais que le code pour ce dernier serait très similaire à celui pour linux, mais ça n'a clairement pas l'air d'être le cas. OIS ne propose pas d'implémentation, ce qui ne m'aide pas vraiment.
Peut être en utilisant IOHIDElementGetName? Je ne connaît vraiment rien en programmation Mac...

Sinon, pour windows les valeurs retournées sont assez jolies et correspondent en général à ce qu'on trouve écrit sur la touche du clavier (sauf pour les cas particuliers du style "1 (PAV. NUM.)" ou "ACCENT CIRCONFLEXE").

Pour linux c'est moins glorieux : le retour de XKeysymToString est pratiquement égal à l'identifier auquel on a retiré le "XK_" (i.e. "XK_Escape" devient "Escape"). L'inconvénient c'est que certains identifiers ont une casse incohérente ("XK_Escape" et "XK_space" par exemple). Les noms sont toujours en anglais quelle que soit la locale de l'ordinateur utilisé. Je pourrais ajouter un code "beautifier" pour rentre le tout plus joli (imposer une casse identique, etc.), ou est-ce qu'on devrait plutôt en laisser la responsabilité à l'utilisateur ?

J'en ai profité pour repérer deux problèmes : celui-ci sous linux (l'événement KeyPressed pour les touches numériques du haut du clavier en AZERTY donne un key.code == -1) auquel on peut rajouter les touches "^", "$", "ù", "*", ":" et "!" (toutes proches de la partie "AZERTY", pas sur le pavé numérique), et le même soucis sous windows pour la touche "!" seulement.
Serait-ce le "bug" de l'input dont tu parlais précédemment ?

[attachment deleted by admin]

10

Projets SFML / Re : Re : lxgui - "Lua and Xml Graphical User Interface"

« le: Juillet 30, 2012, 05:09:48 pm »

Pourquoi pas. Mais ça risque d'être compliqué, comme tout ce qui touche aux locales.

Eh bien j'ai trouvé GetKeyNameText dans l'API Windows qui a l'air d'être assez simple à utiliser. Je vais voir ce que je peux faire

11

Projets SFML / Re : Re : lxgui - "Lua and Xml Graphical User Interface"

« le: Juillet 30, 2012, 04:39:44 pm »

Oui mais c'est beaucoup trop verbeux, il faut créer une classe qui dérive d'une base bien définie, et surdéfinir des fonctions bien définies. Si je fais ça j'aimerais qu'on puisse utiliser les objects-fonctions (std::function) et les lambdas, pour avoir une totale flexibilité.

C'est vrai que le C++11 est une bénédiction : je l'utilise depuis qu'il est partiellement disponible sous gcc et c'est un vrai bonheur! Il me semble que pour ce qui est des lambda et des fonction objects, gcc et VC++ ont tous deux une implémentation stable. Tu préfères attendre un support total du C++11 par défaut dans les deux compilateurs ?
Dans tous les cas, je pense que tu n'auras jamais accès à un tel degré de confort en C, et qu'il faudra toujours se farcir les pointeurs sur fonction avec des structures adaptées.

C'est vrai. Mais pour le moment ce n'est pas dans mes priorités.

Dommage. Si je trouve le temps d'écrire un patch propre de mon côté, tu envisagerais de l'intégrer à la SFML ?

12

Projets SFML / Re : Re : lxgui - "Lua and Xml Graphical User Interface"

« le: Juillet 30, 2012, 03:18:55 pm »

Mais bon, je comprends ta remarque, je préférerais aussi avoir un meilleur système de gestion des événements. Le problème c'est que pour faire des callbacks il faut des choses qui ne sont pas dispo nativement en C++03 ; il faut soit boost soit tr1/C++11. De plus, ça compliquerait beaucoup l'écriture du binding C.

Pourtant avec un pattern observateur ça se fait très bien en C++03 standard non ? Et ça n'a pas l'air si difficile que ça à implémenter en C (c'est moins joli, mais bon c'est du C).

Quant à la gestion "real-time" du texte dans sf::Keyboard, ça n'est pas possible, ça ne colle pas avec le concept. Cette classe donne accès à l'état du clavier à un instant T ; que renverrais-tu dans une fonction getTextEntered ? Quand remettrais-tu à zéro ce qui est récupéré ? Comment ferais-tu pour que l'utilisateur ne voie qu'une et une seule fois tout nouveau caractère entré ? C'est juste pas possible.

Ce que je proposais dans mon post précédent c'est une accumulation de TextEntered dans un std::u32string par exemple. Celui-ci serait vidé à chaque appel à Keyboard::update(), fonction qui ne devrait être appelée qu'une seule fois au début ou à la fin de la boucle d'événément par l'utilisateur. Mais bon, ça déplace la responsabilité de la "pollution de la boucle principale" à la SFML, donc j'avoue que ce n'est pas une solution idéale...

Même remarque pour le delta de la molette, elle n'a pas de position absolue. Prendre la position initiale comme origine donnerait des valeurs complètement farfelues après de nombreuses utilisations, on pourrait facilement arriver à des valeurs à 3 chiffres dans un sens ou dans l'autre.

Qu'est ce que ça change ? Dans tous les cas tu peux avoir 20 000 classes à la fois qui font :

void SomeClass::update() {
    float wheel = sf::Mouse::getWheelPosition();
    myWheelDelta = wheel - myOldWheel;
    myOldWheel = wheel;

    // ...
}

et qui auront toutes une valeur correcte pour myWheelDelta. Mais je préfère quand même une solution à base de callback, c'est plus propre (je suis d'accord : la valeur de retour de getWheelPosition() n'a pas trop de sens).

Tant que j'y suis sur l'input, voici une fonction issue de OIS qui est très utile et qui semble manquer à la SFML : obtenir une chaîne de caractère qui décrive le nom localisé d'une touche du clavier (différent de TextEntered : on peut avoir "Esc.", "Del.", "F1", les touches d'accent "^", etc.). On peut s'en servir entre autre pour afficher un écran de personnalisation des touches.
Sous linux, la fonction utilisée est XKeysymToString, et sous windows il me semble qu'ils utilisent DirectInput (mais il doit y avoir moyen de faire sans ?). De ce que j'ai pu voir dans les projets de jeu utilisant la SFML (par exemple dans M.A.R.S. qui semble bien abouti), les gens utilisent leur propre système de localisation pour obtenir cette information (comme ce que je faisait : un fichier contenant le texte associé à chaque touche pour différents langages). C'est un peu dommage.

13

Projets SFML / Re : lxgui - "Lua and Xml Graphical User Interface"

« le: Juillet 30, 2012, 02:36:34 am »

Bonjour Laurent,

J'ai pris le temps ces derniers jours d'adapter ma bibliothèque pour utiliser TextEntered. Ca marche super bien, et c'est bien plus simple à maintenir que ma solution originale "à la main" ! Par contre, je suis assez embêté par le fait qu'on ne peut récupérer cette information qu'en passant par les événements.

Si j'ai bien compris, j'ai l'heure actuelle deux méthodes différentes pour injecter cet événement dans ma bibliothèque :

• soit je créé ma propre classe de fenêtre qui dérive de sf::Window, et je traite en interne l'événement pour le transférer à ma classe d'input. L'utilisateur doit alors utiliser ma classe de fenêtre au lieu de sf::Window, mais n'a pas d'autre manipulation à faire (je crois que c'est ce que font les autres bibliothèques de GUI que j'ai pu voir par ici).
• soit je décharge la responsabilité à l'utilisateur entièrement, c'est à dire que c'est lui qui, dans sa boucle d'événement, va envoyer l'information à la classe d'input. La manipulation est un peu plus complexe (il ne faut pas se gourer dans l'ordre d'appel des fonctions : envoi de l'événement, mise à jour de la classe d'input, et l'utilisateur peut oublier de le faire), mais pas besoin d'utiliser une classe Window personnalisée.

Comme tu peux le constater, ces deux approches ont des inconvénients, et aucune des deux ne me satisfait vraiment.

Dans le premier cas, je trouve un peu stupide conceptuellement d'avoir une classe "gui::window". Ça donne l'impression que seul un GUI peut exister dans une même fenêtre (ce qui n'est pas le cas), et ça créé un couplage assez fort qui, je pense, n'a pas raison d'être. En effet, si l'utilisateur de ma bibliothèque souhaite utiliser une autre bibliothèque qui a elle aussi sa propre classe "other::window", que doit-il faire ? Créer lui-même son "my::window" qui hérite à la fois de "gui::window" et "other::window" ? :-\ Pour le coup, ça me semble de l'héritage un peu artificiel, conceptuellement bancal, et surtout pas très sympa pour l'utilisateur qui ne devrait pas avoir à se soucier du comportement interne des deux bibliothèques.

Dans le second cas, le problème est évident : je ne veux pas laisser tant de responsabilité à l'utilisateur (c'est pourtant la solution que j'ai choisie, par dépit pour le moment).

Dans tous les cas, je cherche aussi à rendre ma bibliothèque aussi peu invasive que possible (i.e. une fonction update() dans la boucle principale c'est très bien, mais imposer une structure particulière pour transférer un seul événement, c'est bof).

Pour régler mon problème, je te propose deux suggestions différentes :

• intégrer un système de callback à sf::Window. Pour moi c'est l'idéal : je définis mon callback à la création de la classe d'input et c'est fini. C'est d'ailleurs la méthode qui a été retenue pour OIS. L'utilisateur ne voit rien, et tout fonctionne sans qu'il ait à modifier son code d'une quelconque manière. Maintenant, je crois comprendre que, de ton point de vue, soit on mise sur l'event polling (une boucle d'événement unique, et on se débrouille avec ça), soit on mise sur les callbacks, mais pas les deux à la fois. Je me trompe ? Je dois avouer être un peu allergique au concept de boucle d'événement "exclusive" : ça force à écrire du code intrusif et je n'aime pas ça.
• étendre sf::Keyboard pour permettre une gestion "instantanée" (non basée sur les événements) en ajoutant une fonction du style getTextEntered(). L'inconvénient est qu'il faudra probablement ajouter aussi une fonction update() comme pour sf::Joystick (cf. code ci-dessous). Là aussi, je crois que tu n'aimes pas trop ça, vu que ce n'est pas vraiment dans la philosophie de l'input "instantané", et je comprends.

std::u32string Keyboard::getTextEntered() {
    return myTextEntered;
}

void Keyboard::update() {
    myTextEntered.clear();
    // remplir myTextEntered avec les nouveaux caractères qui auront été reçus depuis le dernier appel à update()
}

Qu'en penses-tu ? Y a-t-il de meilleures solutions auxquelles je n'aurais pas pensé ?

PS : dans le même ordre d'idée, on n'a pas accès aux informations sur la molette de la souris dans sf::Mouse. Il faut aussi passer par les événements, avec les mêmes soucis que ceux décrits ci-dessus. Dans ce cas précis tu peux conceptuellement traiter ça comme de l'input instantané en attribuant à la molette la position zéro absolu à l'initialisation, puis en incrémentant cette valeur au gré des mouvements de la molette. En soi cette valeur n'a pas tellement de sens, mais elle permet à quiconque de calculer le "delta" par rapport au dernier appel de la fonction de son côté.

14

Projets SFML / Re : Re : lxgui - "Lua and Xml Graphical User Interface"

« le: Mai 25, 2012, 08:29:21 pm »

En pratique c'est plus que négligeable, surtout dans ce contexte.

Moui, probablement. Ce sont principalement de petites images.

Tu veux plutôt dire "corriger les bugs du système actuel" ?

C'est moins diplomatique

15

Projets SFML / Re : Re : lxgui - "Lua and Xml Graphical User Interface"

« le: Mai 25, 2012, 03:41:48 pm »

Bref je ne veux pas t'embêter avec ça, c'était juste pour te dire de faire très attention avec les encodages, ça peut vite devenir l'enfer à gérer si tu n'es pas attentif. Souvent ça marche "out of the box" mais ce n'est qu'un coup de chance, et pas représentatif de ce qu'il faut faire pour rendre le code robuste.

C'est toujours gênant quand quelqu'un met le doigt sur une faille dans son code, c'est sûr, mais c'est pour la bonne cause. Ici, le tout est de savoir si je veux considérer ça comme un bug ou une fonctionnalité. Il faut que j'y réfléchisse. Merci en tout cas de me faire partager ton expérience sur le sujet

Ah par contre pour le PNG, tu peux faire mieux à peu de frais : au lieu de libpng, tu peux utiliser ce que SFML utilise : stb_image. C'est totalement libre (domaine publique) et c'est un seul fichier intégrable directement dans ton code source ; donc pas une vraie dépendance. Et ça gère le png, tga, bmp, jpg, ...

Ça peut être intéressant... libpng fonctionne très bien, mais elle ajoute deux dépendances : libpng bien sûr, mais libz aussi. Après avoir regardé comment stb_image s'utilise dans ton code, je vois que le principe est relativement proche de libpng mais en plus simple.
Par contre c'est dommage d'avoir à faire une copie des pixels après avoir chargé l'image. Avec libpng, on peut les écrire directement dans le buffer final, en évitant la copie (~ on fournit à libpng le pointeur vers la zone mémoire pré-allouée où écrire les pixels, donc éventuellement dans un std::vector::data()). Si j'avais une critique à faire, c'était celle là. Sinon ça a l'air très bien !

Donc en gros, pour résumer, si SFML supporte l'alpha prémultiplié c'est tout bon pour toi ?

Ah, et j'avais oublié : il manquerait aussi la gestion non formatée de l'input pour le clavier.