Mathieu SCHROETER a écrit 120 commentaires

  • [^] # Re: macOS et certificat

    Posté par (page perso) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 0.

    Exactement, c'est ainsi que je signe Planet Blupi (blupi.org) et donc le .app est téléchargeable (enfin le .dmg en fait) directement depuis le site.

  • [^] # Re: macOS et certificat

    Posté par (page perso) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 0.

    Mon certificat est de 2017 et valable jusqu'en 2022. Donc si ca a changé c'est alors vraiment récent. Je te redirai après l'échéance en fin 2022 si c'est vraiment le cas 😳 Dommage…

  • # macOS et certificat

    Posté par (page perso) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 4.

    On peut diffuser des app par nos propres moyens. Mais si on veut qu’elles s’installent, ils faut qu’elles soient signées avec une clé… à 100€ par an.

    A propos de macOS, il n'est pas nécessaire de payer 100$ par an. Il suffit la première fois de générer le certificat pour signer ses app, il a une date de validité de 5 ans. C'est ce que je fait, je paie uniquement 100$ pour 5 ans car je ne diffuse pas mes .app sur l'AppStore. Bien entendu, si on désire passer par l'AppStore, il faut payer chaque année; mais c'est une autre question.

  • [^] # Re: Ahem...

    Posté par (page perso) . En réponse à la dépêche Zero-K, un jeu de stratégie temps réel. Évalué à 6.

    Je ne peux m'empêcher de rajouter Planet Blupi à ta liste 😃

  • # Un ragd Merci

    Posté par (page perso) . En réponse à la dépêche Meilleures contributions LinuxFr.org : les primées d’octobre 2017. Évalué à 2.

    Un grand Merci pour ce livre (La 3D libre avec Blender). Je me réjoui de m'attaquer à Blender; le livre est très beau et semble bien réalisé. Il ne me reste plus qu'à trouver du temps.

  • [^] # Re: Disponibilité sous Debian

    Posté par (page perso) . En réponse à la dépêche Libération du jeu Planète Blupi. Évalué à 2.

    Cool, Merci

  • # Disponibilité sous Debian

    Posté par (page perso) . En réponse à la dépêche Libération du jeu Planète Blupi. Évalué à 5.

    Planet Blupi est désormais disponible officiellement sous Debian (uniquement la sid pour le moment) :
    https://packages.debian.org/sid/planetblupi

    Un grand Merci à Didier Raboud pour le packaging.

  • [^] # Re: Portage

    Posté par (page perso) . En réponse à la dépêche Libération du jeu Planète Blupi. Évalué à 4.

    Oui merci, je connais vcpkg via mon job, c'est plutôt bien. En tout cas ça va dans le bon sens.

    Ce que je veux dire c'est que je fait mon build à l'aide de CMake aussi pour télécharger et compiler toutes les dépendances en static en gérant moi-même comment sont fait les ./configure, etc, … (via les ExternalProject CMake) En utilisant par exemple vcpkg, ça me rajoute du travail pour maintenir un build différent, ce qui n'est quasiment pas le cas avec un MSYS2 et CMake avec le générateur "MSYS Makefile".

    Et d'un point de vue purement personnel, je préfère GCC / Clang à MSVC (CL) qui reste un compilateur closed-source sans plus-values (à ma connaissance et je l'utilise bien trop souvent à cause de projets basés sur MFC) par rapport aux autres.

  • [^] # Re: x86_64

    Posté par (page perso) . En réponse à la dépêche Libération du jeu Planète Blupi. Évalué à 5.

    J'avais commencé un make dist mais je l'ai laissé en plan car il faut pouvoir pré-télécharger tous les ExternalProject du CMakeLists et je ne sais pas comment faire pour faire bien.
    Après si c'est juste pour faire du build dynamique (et donc uniquement le dépôt planetblupi et pas planetblupi-dev) sur GitHub il y a déjà tous les tarballs comme avec n'importe quel projet : https://github.com/blupi-games/planetblupi/releases

  • [^] # Re: Jeux vidéo vers un logiciel de compta

    Posté par (page perso) . En réponse à la dépêche Libération du jeu Planète Blupi. Évalué à 6.

    Oui, on est les mêmes. Les jeux ont principalement été réalisés par un seul des développeurs (certains ont un peu participés mais que sur des aspects très précis). Bien que Crésus soit le gagne pain de la société aujourd'hui, ce n'était pas le cas avant étant donné qu'Epsitec fabriquait des ordinateurs, les Smaky. Un marché qui s'est malheureusement arrêté car non concurrentielle par rapport au bulldozer IBM/ Microsoft.

  • [^] # Re: Great!

    Posté par (page perso) . En réponse à la dépêche Libération du jeu Planète Blupi. Évalué à 4.

    Merci
    Le français est également la langue originale; la voix de Blupi étant basée sur celle de l'auteur, Daniel Roux, qui ne parle pas non plus anglais.

  • [^] # Re: Merci !

    Posté par (page perso) . En réponse à la dépêche Libération du jeu Planète Blupi. Évalué à 5.

    C'est avec plaisirs :-)

  • [^] # Re: Portage

    Posté par (page perso) . En réponse à la dépêche Libération du jeu Planète Blupi. Évalué à 10.

    Merci, pour répondre un peu à ta question :

    J'ai travaillé dessus par bribes. Le remplacement de la boucle événementielle c'est assez facile car c'est presque du 1:1 entre les événements Windows et SDL2. Il y a quelques différences notables entre les deux en ce qui concerne les touches modificateurs comme Ctrl, Shift, etc,… mais rien d'insurmontable.

    Au tout début j'ai travaillé uniquement avec Visual Studio en gardant le code DirectX tout en ajoutant en parallèle une fenêtre SDL2 pour produire le même résultat graphique. Le lancement du jeu produisait alors deux fenêtres. Celle de DirectX continuait de recevoir les événements. Celle pour SDL2 se contentait de reproduire le dessin.
    Cette étape n'était pas très complexe au début, car les surfaces DirectDraw peuvent facilement être traduites en surfaces SDL2. Une fois que j'ai fait le 90% du travail (j'avais encore qques soucis avec la minimap qui travail au pixel et quelques incrustations qui foiraient), je suis passé des surfaces SDL2 au textures SDL2. Pour ceux qui ne connaissent pas trop SDL2. Les textures sont chargées dans la carte graphique, ce qui n'est pas le cas des surfaces qui restent en RAM principale. Cette différence est fondamental car ça exploite mieux la matériel, par contre ça complique un peu le travail si on désire accéder directement à une texture en écriture.

    En parallèle à tout ça, il y a eu le remplacement de DirectSound par SDL2_mixer. En résumé j'ai pu virer beaucoup de code car DirectSound reste plus bas niveau qu'SDL2_mixer. J'ai juste pris un peu de temps sur le panning (faire varier le son de gauche à droite et droite à gauche selon la position des objets qui génèrent des sons). Ca m'a pris un petit peu de temps à recalibrer tout ça car DirectSound travail en décibel et SDL_mixer en gain (0-100%). Honnêtement je n'ai jamais compris pourquoi DirectSound parle de décibel. L'API reste plus obscure qu'SDL2_mixer qui est très clair.

    Pour les traductions, le code original utilise des ressources Win32 (assez classique pour des win-app). Donc en gros c'était vraiment de la productique d'insérer les appels gettext partout où il y avait des LoadString(id) à l'origine.

    Une fois que j'ai remplacé tout ce qui était purement Windows par SDL2, j'ai viré le code Win32/DirectX et je suis enfin passé sous Linux (j'ai développé une forte intolérence à Visual Studio, et je dois tout le temps l'utiliser au job). Du coup je développe que sous Linux et avec Kdevelop (je ne publie pas les fichiers de projets Kdevelop, ils sont facile a régénérer).

    Finalement la première version utilisable a été pour Linux. Ensuite je me suis occupé de Windows est utilisant MSYS2. Je ne souhaite pas supporter MSVC à nouveau car pour gérer les dépendances c'est galère (nuget, non merci.. j'ai pas de temps à perdre avec ça). Avec MSYS2 je garde le même CMakeLists avec quelques conditions mais rien d'incroyable.

    Bref, les builds sont static autant que possible. La aussi, c'est personnel car je n'aime pas beaucoup le dynamique pour ce type de projet. Si vous regardez dans l'AppImage, il y a qu'un seul binaire, pour macOS également. Il y a juste sous Windows qu'il reste une DLL car je n'ai pas réussi à la linker en static sans que ça me rajoute d'autres liens dynamiques.

    Il est possible de faire du dynamique en utilisant directement le dépôt planetblupi à la place de planetblupi-dev. C'est par exemple nécessaire pour ceux qui génèrent les paquets des distributions. Je m'excuse d'avance de mes CMakeLists qui ne sont pas des oeuvres d'arts mais ils font le job sur les 3 plateformes et c'est ce qui m'importe.

  • [^] # Re: x86_64

    Posté par (page perso) . En réponse à la dépêche Libération du jeu Planète Blupi. Évalué à 10.

    En effet, l'ARM c'est une autre question. Je me suis même demandé si j'allais faire aussi un build FreeBSD. Et comme tu dis, j'ai supposé que l'auteur parle bien de l'architecture x86-32.

    Tu as tout compris car c'est pas le plus fun de pondre des binaires. Surtout que pour Windows je dois passer par une clef hardware pour signer les binaires et l'installateur (y a peut être moyen de faire supporter par Linux en cross mais je n'ai pas vraiment le temps et l'envie). Et pour macOS je suis toute façon obligé de booter le Mac exprès car c'est le seul moyen de signer un .app. Et le SDK Apple en cross c'est très compliqué (on le faisait il y a très longtemps avec le projet GeeXboX, que des builds cross pour macOS mais ce temps là est révolu).

    Le plus simple ça reste Linux avec une signature GPG sur l'AppImage. Un pote s'occupe du paquet Debian officiel un de ces 4.

  • [^] # Re: x86_64

    Posté par (page perso) . En réponse à la dépêche Libération du jeu Planète Blupi. Évalué à 10.

    Je ne vois aucun intérêt de faire du 32 bits en 2017. Je n'ai donc pas l'intention de compiler moi-même pour cette architecture que je considère personellement comme obsolète.

  • [^] # Re: x86_64

    Posté par (page perso) . En réponse à la dépêche Libération du jeu Planète Blupi. Évalué à 3.

    Il faut faire un :

    git clone --recursive https://github.com/blupi-games/planetblupi-dev.git
    

    pour prendre les sous-modules avec.

  • [^] # Re: Quid d'un peu d'aide ?

    Posté par (page perso) . En réponse à la dépêche Libération du jeu Planète Blupi. Évalué à 8.

    Principalement parce que j'ai envie de le faire tout seul.

  • [^] # Re: Renvoi en rédaction

    Posté par (page perso) . En réponse au message J'ai soumis une dépêche, je n'arrive plus a y accéder pour l'éditer. Évalué à 1.

    Merci

  • [^] # Re: La valeur de Linux est de 0 (pour toi).

    Posté par (page perso) . En réponse au journal Microsoft s'accroche jusqu'au bout. Évalué à 10.

    le design de l'UEFI n'est pas de la responsabilité de Microsoft

    C'est juste une question mais pourquoi les partitions de boot EFI doivent utiliser FAT32 ? Y'a vraiment aucun lien entre Microsoft et UEFI ?

    Je répète que c'est une question, ce n'est pas sarcastique.

  • # Test avec le compilateur CL de Microsoft en toolset vc140

    Posté par (page perso) . En réponse à la dépêche C++ se court-circuite le constructeur de copie. Évalué à 3.

    Hello,

    Pour le fun j'ai testé le code suivant avec le compilateur CL de Microsoft en toolset vc140.

    #include <iostream>
    
    int t[6] = { 0, 0, 0, 0, 0, 0 };
    
    struct A
    {
      A () { ++t[0]; }
      A (A const&) { ++t[1]; }
      A& operator=(A const&) { ++t[2]; return *this; }
    //#if __cplusplus > 201100
      A (A &&) { ++t[3]; }
      A& operator=(A &&) { ++t[4]; return *this; }
    //#endif
      ~A () { ++t[5]; }
    };
    
    A f () { return A (A ()); }
    
    int main ()
    {
      { A a = A (A (A (f ()))); }
    
      std::cout << "Dflt = " << t[0] << "\n"
        "Copy = " << t[1] << "\n"
        "CpAs = " << t[2] << "\n"
    //#if __cplusplus > 201100
        "Move = " << t[3] << "\n"
        "MvAs = " << t[4] << "\n"
    //#endif
        "Dtor = " << t[5] << '\n';
    }

    Résultats :

    Dflt = 1
    Copy = 0
    CpAs = 0
    Move = 3
    MvAs = 0
    Dtor = 4
    

    A priori CL ne sait pas faire l'élision aussi efficacement que g++ et clang++ dans ce cas de figure.

  • [^] # Re: Rien à voir

    Posté par (page perso) . En réponse au journal Wikileaks : prise de conscience pour la décentralisation ?. Évalué à 1.

    Et le lien sans la date pointe toujours sur le dernier:
    http://88.80.16.63/torrent/cablegate/cablegate.7z.torrent
  • [^] # Re: au pluriel, avec un s

    Posté par (page perso) . En réponse à la dépêche Sortie du projet OpenBricks: un framework pour Linux embarqué.. Évalué à 4.


    Question 2 : quel environnement de build utilisez vous ? Bon ok question idiote :) disons plutot "est ce un projet from scratch ou bien en collaboration avec par exemple BuildRoot ? )


    A l'origine le projet a été écrit "from scratch" et pour le plaisir de faire les choses par soi-même par les deux fondateurs du projet GeeXboX (dont l'auteur de la news). Puis le toolchain a été amélioré par beaucoup d'autres contributeurs. Jusqu'à OpenBricks il n'y avait aucune promotion de nos outils. Bien que parfois il y avait quelqu'un qui passait sur notre devel-list pour proposer des patchs parce qu'il utilisait le toolchain à d'autres fin que pour le multimédia par exemple. Un intérêt pour certaines personnes de passer par un toolchain GeeXboX modifié que par un buildroot, etc,... était donc bien réel.
    Personnellement j'ai utilisé le toolchain GeeXboX pour équiper un robot dans un labo. Néanmoins, faisant partie du team c'est "normal" que je ne sois pas passé par un autre outil.

    Un des gros avantages de GeeXboX c'est à mon avis sa simplicité. Sans documentation c'est facile à comprendre comment ça fonctionne. Puis un deuxième point que je considère très important par rapport aux autres solutions c'est qu'il est orienté shell script. Je trouve indigeste les toolchains orientés Makefiles (comme buildroot) ou Bitbake (comme OE). Mais c'est une question de goût je suppose.
  • [^] # Re: Source™ != source

    Posté par (page perso) . En réponse au journal Steam et source pour linux : c'est officiel. Évalué à 2.

    Si si.. les sources d'HL2 étaient bien sur le net.
  • [^] # Re: test rapide

    Posté par (page perso) . En réponse à la dépêche Sortie de GeeXboX 2.0-alpha1. Évalué à 1.

    C'est toujours possible de forcer une localisation dans le fichier de configuration.
  • [^] # Re: Retour vers le futur

    Posté par (page perso) . En réponse au journal Gimp: *coup de tonnerre* dans le Landerneau. Évalué à 3.

    Il n'y a aucune régression, mais uniquement plus de choix pour les utilisateurs. Le mono-fenêtre est optionnel.