l'émulateur est disponible ici https://smaky.ch/infini/ et il fonctionne sous Wine (mais pas aussi correctement que sous Windows). J'aurais aimé l'adapté à Linux et macOS malheureusement "on" a "perdu" aussi son code source.
Utiliser une autre architecture que x86 c'est une autre question. Et forcément dans ce cas je n'irai pas chez Purism. Ca dépend si on doit encore utiliser des applications closed-source disponibles uniquement en x86 ou pas.
L'auteur du journal ne précise pas si l'architecture n'a pas d'importance dans son choix. J'ai donc supposé qu'il souhaite du x86. Et si on souhaite du x86, quel est le meilleur (ou le moins bon) ? Je n'ai pas trouvé mieux que Purism mais je suis très intéressé par des autres candidats.
Un très bon logiciel de composition que j'ai beaucoup utilisé en parallèle à Kdenlive afin de réaliser surtout les incrustations sur fond vert ainsi que le motion tracking. Mais il fait beaucoup plus que ça.
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…
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.
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.
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.
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
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.
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.
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: Slackbuild dans les tuyaux !
Posté par Mathieu Schroeter (site web personnel, Mastodon) . En réponse à la dépêche Libération du jeu Blupimania. Évalué à 2.
Merci à toi Yth.
J'apprécie énormément le travail que vous (les mainteneurs de paquets) faites pour "nos" distributions, quelles qu'elles soient.
[^] # Re: très chouette
Posté par Mathieu Schroeter (site web personnel, Mastodon) . En réponse à la dépêche Libération du jeu Blupimania. Évalué à 6.
Hello,
l'émulateur est disponible ici https://smaky.ch/infini/ et il fonctionne sous Wine (mais pas aussi correctement que sous Windows). J'aurais aimé l'adapté à Linux et macOS malheureusement "on" a "perdu" aussi son code source.
Dans cet article (récent), l'auteur original du jeu, Daniel Roux, parle de la réalisation graphique en passant par les outils qu'il a du inventer à l'époque et qui lui ont permis de finalement créer (entre autres) le jeu Blupimania : https://www.museebolo.ch/memoires_vives/une-aventure-vaudoise-de-l-interface-graphique/
Merci pour le retour
# 3dfx
Posté par Mathieu Schroeter (site web personnel, Mastodon) . En réponse à la dépêche Le rendu 3D, rétrospective. Évalué à 5.
Une petite pensée pour la 3dfx et Glide…
# archive.org
Posté par Mathieu Schroeter (site web personnel, Mastodon) . En réponse au message Disparition d'une image dans un article. Évalué à 1. Dernière modification le 09 février 2022 à 17:35.
J'ai pu au moins retrouver les images avec l'aide d'archive.org
https://web.archive.org/web/20210226155158/https://linuxfr.org/news/liberation-du-jeu-planete-blupi
Peut-être une piste à explorer quand le cache décide de faire la purge (que les liens en question pointent sur archive.org).
[^] # Re: Nitroshare
Posté par Mathieu Schroeter (site web personnel, Mastodon) . En réponse au journal Partage familial de fichiers (lecture seule, sans mot de passe). Évalué à 1.
Ohhh.. J'adore ce truc
Merci
[^] # Re: Nitroshare
Posté par Mathieu Schroeter (site web personnel, Mastodon) . En réponse au journal Partage familial de fichiers (lecture seule, sans mot de passe). Évalué à 3. Dernière modification le 17 juillet 2020 à 10:53.
A priori ça existe pour Android :
GitHub : https://github.com/nitroshare/nitroshare-android
F-Droid : https://f-droid.org/en/packages/net.nitroshare.android/
# Nitroshare
Posté par Mathieu Schroeter (site web personnel, Mastodon) . En réponse au journal Partage familial de fichiers (lecture seule, sans mot de passe). Évalué à 3. Dernière modification le 17 juillet 2020 à 09:49.
Nitroshare ?
[^] # Re: Purism : Librem 15
Posté par Mathieu Schroeter (site web personnel, Mastodon) . En réponse au journal Choisir un ordinateur portable en 2020. Évalué à 1.
Utiliser une autre architecture que x86 c'est une autre question. Et forcément dans ce cas je n'irai pas chez Purism. Ca dépend si on doit encore utiliser des applications closed-source disponibles uniquement en x86 ou pas.
L'auteur du journal ne précise pas si l'architecture n'a pas d'importance dans son choix. J'ai donc supposé qu'il souhaite du x86. Et si on souhaite du x86, quel est le meilleur (ou le moins bon) ? Je n'ai pas trouvé mieux que Purism mais je suis très intéressé par des autres candidats.
[^] # Re: Purism : Librem 15
Posté par Mathieu Schroeter (site web personnel, Mastodon) . En réponse au journal Choisir un ordinateur portable en 2020. Évalué à 1.
OK, je me suis mal exprimé.
Si ton intervention n'est pas juste là pour casser inutilement, je t'invite à lire le document à propos d'AMT.
# Purism : Librem 15
Posté par Mathieu Schroeter (site web personnel, Mastodon) . En réponse au journal Choisir un ordinateur portable en 2020. Évalué à 1. Dernière modification le 15 mai 2020 à 00:16.
Il existe la société Purism qui fait des ordinateurs portables libres même au niveau du processeur Intel : https://puri.sm/
Je réfléchi beaucoup au Librem 15 (pour en acquérir un) https://puri.sm/products/librem-15/ mais il est cher.
A propos d'AMT dans les CPU Intel : https://puri.sm/learn/intel-me/
(aucune idée à quel point c'est éthique ou non à propos du hardware, mais à propos de software ça me semble être un des meilleur)
[^] # Re: Un autre : NATRON
Posté par Mathieu Schroeter (site web personnel, Mastodon) . En réponse au journal Comparaison des logiciels de montage vidéo. Évalué à 1.
Les commits et les releases n'ont pas cessés.. il y a beaucoup moins bien en ce qui concerne la maintenance d'un projet.
https://github.com/NatronGitHub/Natron/commits/RB-2.3
https://github.com/NatronGitHub/Natron/releases
# Un autre : NATRON
Posté par Mathieu Schroeter (site web personnel, Mastodon) . En réponse au journal Comparaison des logiciels de montage vidéo. Évalué à 4.
Afin de compléter la liste…
Un très bon logiciel de composition que j'ai beaucoup utilisé en parallèle à Kdenlive afin de réaliser surtout les incrustations sur fond vert ainsi que le motion tracking. Mais il fait beaucoup plus que ça.
https://natrongithub.github.io/
[^] # Re: macOS et certificat
Posté par Mathieu Schroeter (site web personnel, Mastodon) . 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 Mathieu Schroeter (site web personnel, Mastodon) . 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 Mathieu Schroeter (site web personnel, Mastodon) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 4.
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 Mathieu Schroeter (site web personnel, Mastodon) . 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 Mathieu Schroeter (site web personnel, Mastodon) . 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 Mathieu Schroeter (site web personnel, Mastodon) . En réponse à la dépêche Libération du jeu Planète Blupi. Évalué à 2.
Cool, Merci
# Disponibilité sous Debian
Posté par Mathieu Schroeter (site web personnel, Mastodon) . 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 Mathieu Schroeter (site web personnel, Mastodon) . 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 Mathieu Schroeter (site web personnel, Mastodon) . 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 pasplanetblupi-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 Mathieu Schroeter (site web personnel, Mastodon) . 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 Mathieu Schroeter (site web personnel, Mastodon) . 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 Mathieu Schroeter (site web personnel, Mastodon) . En réponse à la dépêche Libération du jeu Planète Blupi. Évalué à 5.
C'est avec plaisirs :-)
[^] # Re: Portage
Posté par Mathieu Schroeter (site web personnel, Mastodon) . 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 deplanetblupi-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.