Planète Blupi est un jeu réalisé en 1997 par la société suisse Epsitec SA. Il met en scène un petit personnage jaune nommé Blupi dans un jeu d’aventure proche d’un RTS (real‐time strategy, jeu de stratégie en temps réel).
Blupi vit tranquillement sur sa planète jusqu’à l’arrivée d’une étrange météorite qui tombe dans une région désertique. Ce n’est que bien plus tard que Blupi s’aperçoit que ses cultures sont saccagées par de grosses araignées. Eh bien, l’étrange météorite est en fait un vaisseau spatial qui transporte un robot très spécial. En effet, celui‐ci construit des usines, qui produisent à leur tour différents ennemis. Blupi doit dès lors exploiter à fond les ressources de sa planète pour parvenir à chasser ces intrus…
Le jeu a été libéré cette année (pour son vingtième anniversaire) et est désormais librement téléchargeable pour toutes les plates‐formes majeures (GNU/Linux, Apple macOS et Microsoft Windows).
Blupi, mais qu’est‐ce que c’est ?
Des jeux Blupi existent depuis bien plus longtemps (le personnage était nommé Toto avant de devenir Blupi). Un des premiers jeux, Toto à la maison est sorti en 1988 sur Smaky. On trouve ensuite Toto s’amuse en 1990, Blupi explorateur, en 1993, et Blupimania en 1995, qui a aussi été publié pour MS-DOS.
Le premier jeu qui a été disponible sous Microsoft Windows est Planète Blupi. En 2014, un des jeux réalisés par Epsitec SA, CoLoBoT, a été libéré sous licence GPL v3 suite à la demande d’une équipe polonaise (TerranovaTeam) qui désirait lui redonner une nouvelle vie. Le jeu a été porté sous GNU/Linux et Apple macOS.
Vous connaissez peut‐être ce jeu sous le nom de Planet Eggbert (et surtout Speedy Eggbert). En effet, pour les États‐Unis, le personnage Blupi a dû être renommé Eggbert sur demande d’un des distributeurs (ce n’est pas un choix de l’auteur des jeux, bien au contraire).
Libération du code
Début 2017, j’ai proposé à cette même équipe polonaise, de reprendre le code source des jeux Blupimania 2, ainsi que Buzzing Cars, également réalisés par Epsitec SA et basés sur le même moteur que CoLoBoT. Ils ont accepté le « défi » et des branches de développement se sont mises en place (surtout pour Buzzing Cars) afin de leur donner une nouvelle vie. Comme vous l’avez compris, je suis un employé chez Epsitec SA et j’ai demandé à l’auteur des jeux Blupi, Daniel Roux, ainsi qu’à mon patron, Pierre Arnaud, s’ils étaient d’accord de libérer les codes sources de tous les jeux. Et c’est avec joie qu’ils ont accepté. La libération ne concerne pas que le code source, mais également tous les fichiers multimédia associés : sons, musiques, dialogues, images, vidéos…
Tout ce qu’on a pu récupérer des jeux Blupimania 2 et Buzzing Cars a été transmis à l’équipe polonaise. En revanche, pour les autres jeux qui n’étaient pas encore libérés, tout n’est pas libre. Il y a plusieurs raisons à cela :
La première raison est personnelle. Étant enfant au début des années nonante (quatre‐vingt‐dix), j’ai gardé beaucoup de nostalgie avec Blupi et j’ai depuis longtemps rêvé d’avoir accès aux sources. À part pour les jeux transmis à l’équipe polonaise, je souhaite réaliser moi‐même les portages pour tous les systèmes d’exploitation, et Planète Blupi est le premier d’une longue série.
Il y a une autre raison bien moins réjouissante. Certains anciens jeux, comme Toto s’amuse, Blupi explorateur ou encore, et c’est bien triste, le premier Blupimania (sûrement un des meilleurs jeux Blupi jamais réalisé selon moi) ne seront probablement jamais libérés pour la simple et bonne raison que les codes sources ont été perdus. Je garde encore un petit espoir qu’un de mes collègues tombe sur de vieilles archives, mais plus le temps passe et moins cela devient probable.
Planète Blupi
Suite à la libération, je me suis mis au travail. À l’origine je souhaitais porter Blupimania, mais comme je viens de l’expliquer, cela est impossible. J’ai alors simplement choisi dans ce que j’avais sous la main, le jeu le plus ancien (nostalgie oblige) : Planète Blupi.
Ce premier jeu prenant en charge Microsoft Windows, a été écrit pour DirectX 3 et, plus spécifiquement, DirectDraw et DirectSound. La première étape a été de débarrasser tout le code des dépendances Microsoft. DirectX et la boucle événementielle ont été remplacés par la bibliothèque SDL 2, le lecteur vidéo par FFmpeg, les traductions par GNU Gettext, etc.
Sur le site Blupi.org, vous trouverez des versions précompilées pour GNU/Linux sous la forme d’une AppImage, un DMG pour Apple macOS et un installateur NSIS pour la version Microsoft Windows. Un paquet officiel pour Debian est en cours de préparation.
Il reste encore beaucoup de travail. Je souhaite réaliser une version deux qui sera en haute définition. En effet, le jeu a été réalisé pour du 640 × 480 en 256 couleurs. Je ne souhaite pas dénaturer l’aspect original, bien que je puisse très facilement refaire les rendus en 32 bits, je ne le ferai pas pour la version un. En revanche, avec la version deux, il sera possible de basculer de la version haute définition à la version historique par un simple raccourci clavier (dans la même idée que les remakes de Monkey Island, par exemple). Il n’y a encore rien de concret pour l’instant, mais ça viendra les prochains mois.
Et les autres jeux…
Je m’attaquerai aux jeux Speedy Blupi 1 et 2 prochainement et en parallèle ou après la version deux de Planète Blupi. Je ne sais pas encore… En revanche, en attendant, la plupart des images ISO (avec les manuels) des jeux originaux sont disponibles sur le site Blupi.org. Cela ravira les fans et, pour les développeurs, il y a les sources de CoLoBoT, Buzzing Cars, Blupimania 2 et Planet Blupi pour vous amuser.
Aller plus loin
- Blupi.org (1528 clics)
- Dépôt principal sur GitHub (347 clics)
- CoLoBoT (136 clics)
- Planet Blupi sur itch.io (208 clics)
# Quid d'un peu d'aide ?
Posté par Colin Pitrat (site web personnel) . Évalué à 5.
En mettant les autres jeux en l'état actuel en ligne, tu pourrais obtenir de l'aide pour le portage. Pourquoi ne pas tenter cette approche ? Est-ce parce que tu as envie de le faire tout seul (ce qui est une bonne raison) ou parce que tu penses que tu n'obtiendras pas beaucoup d'aide (ce qui est peut être bien vrai aussi :) ) ?
[^] # Re: Quid d'un peu d'aide ?
Posté par Mathieu Schroeter (site web personnel, Mastodon) . Évalué à 8.
Principalement parce que j'ai envie de le faire tout seul.
# x86_64
Posté par ʭ ☯ . Évalué à -3.
Damned, j'ai pas de machine x86_64 moi, et j'ai pas trouvé de tarball à compiler moi-même.
M'enfin, demander du 64 bits pour un jeu de 1997 en couleurs 8 bits?
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: x86_64
Posté par jihele . Évalué à 4.
Le code n'est pas là ?
https://github.com/blupi-games/planetblupi-dev
[^] # Re: x86_64
Posté par Mathieu Schroeter (site web personnel, Mastodon) . Évalué à 3.
Il faut faire un :
pour prendre les sous-modules avec.
[^] # Re: x86_64
Posté par ʭ ☯ . Évalué à 2.
Merci, je fais ça. Mais un tarball c'est quand même plus simple pour les distributions…
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: x86_64
Posté par Mathieu Schroeter (site web personnel, Mastodon) . É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
planetblupiet 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: x86_64
Posté par Mathieu Schroeter (site web personnel, Mastodon) . É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 Zenitram (site web personnel) . Évalué à 10. Dernière modification le 09 octobre 2017 à 12:00.
Je comprend ta non envie de faire trop de binaires (c'est du temps à passer, et pour les gens pas contents ils n'ont qu'à faire ou payer pour faire faire) surtout vu la façon dont on te parle (et la non capacité de la personne à cliquer sur un lien dans le journal), mais un bémol sur ta considération : un Raspberry Pi Zero est bien capable de faire tourner ce genre de logiciel, et ce n'est pas du tout obsolète bien que ce soit en 32-bit, pour la simple raison que son intérêt est dans son prix et qu'il n'y a pas à ma connaissance de plate-forme 64-bit à 15 €.
(j'imagine que l'auteur du commentaire penser à du x86, bon la oui ps d’intérêt en 2017, même Ubuntu se met à lâcher ça)
Donc :
Que ça puisse tourner sur une machine à 15 € me semble digne d’intérêt.
[^] # Re: x86_64
Posté par Mathieu Schroeter (site web personnel, Mastodon) . É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.
# Merci !
Posté par GuieA_7 (site web personnel) . Évalué à 10.
Merci au créateurs & ayant droit d'avoir accepter de libérer leurs jeux (et de vraiment tout libérer, pas juste le code, comme on le voit "souvent").
Merci à toi d'avoir fait cette démarche de demande de libération, et de travailler dessus évidemment.
J'aimerai que plus de gens dans l'industrie s'en inspirent.
[^] # Re: Merci !
Posté par Mathieu Schroeter (site web personnel, Mastodon) . Évalué à 5.
C'est avec plaisirs :-)
# Portage
Posté par mzf (site web personnel) . Évalué à 8.
Ce travail a l'air énorme, est-ce possible de connaitre les difficultés techniques rencontrées et leurs solutions ?
En tout cas bravo pour le boulot effectué !
[^] # Re: Portage
Posté par Mathieu Schroeter (site web personnel, Mastodon) . É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.[^] # Re: Portage
Posté par freem . Évalué à 3.
Au sujet du static link, je pense que pour un dev isole c'est mieux: au moins tu es sur que tu n'auras pas de libs manquantes au runtime, et en plus il n'est pas ilpossible que le binaire soit plus performant ainsi (cf les opinions des dev de suckless, entres autres. La mienne, c'est que le full dynamic c'est pas vraiment pertinent, surtout quand on utilise des trucs genres exceptions ou methodes virtuelles).
[^] # Re: Portage
Posté par mzf (site web personnel) . Évalué à 2.
Merci pour ce retour !
(et bravo pour l'astuce de garder les deux rendus en parallèle)
[^] # Re: Portage
Posté par rewind (Mastodon) . Évalué à 2.
vcpkg est ton ami !
[^] # Re: Portage
Posté par Mathieu Schroeter (site web personnel, Mastodon) . É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.
# Great!
Posté par Guillaume Denry (site web personnel) . Évalué à 5.
Impressionnant, le jeu se prend en main immédiatement, c'est très sympa.
En plus en français !
Bravo à toi d'avoir ressuscité cette petite merveille !
[^] # Re: Great!
Posté par Mathieu Schroeter (site web personnel, Mastodon) . É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.
# Bravo !
Posté par eingousef . Évalué à 10.
Tant que les boites ne comprennent pas qu'un jeu qui ne rapporte plus est mieux libre que mort, il faudrait un gars comme toi chez tous les éditeurs.
Dommage pour les codes sources perdus, mais bravo pour tout le reste !
Longue vie aux jeux libres !
*splash!*
[^] # Re: Bravo !
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
Pour l'auteur, c'est évident, pour l'éditeur, c'est rajouter un concurrent gratuit sur son marché face à ces nouveautés… C'est un bon signe pour voir si ils se préoccupent de leurs auteurs ou non.
"La première sécurité est la liberté"
[^] # Re: Bravo !
Posté par freem . Évalué à 8.
Pour ce qui est des binaires perdus, liberer pourrait etre interessant aussi, parce que meme sans l'original, il est souvent relativement simple de recuperer les ressources (surtout quand le format est utilise dans un code dont on a les sources, et puis, ca manque tres souvent).
Pour ce qui est du code, c'est nettement plus complexe, mais je crois avoir souvenance que l'auteur de keeperfx (un… euh, comment dire… fork a partir du binaire de dungeon keeper) a une methode qui permets un portage progressif.
Bon, faut etre cale, surtout dans son cas qui est de la recup de binaire DOS (pas PE j'imagine donc, probablement du code mode reel?), et avoir du temps, mais vu que le repreneur ici a des sources liees (autres versions du meme moteur, ou petites lib internes, que sais-je?) y'a p'tet moyen via des outils tels qu'IDA de retrouver une partie non negligeable. Ce serait cela surement un travail de titan, j'imagine. C'est deja super de liberer et porter ces vieux codes!
[^] # Re: Bravo !
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
Il y a plein d'approches pour faire ce genre de choses.
Dans le cas de KeeperFX, très peu de code en mode réel, puisque Dungeon Keeper utilise (comme la plupart des jeux "DOS" de l'époque) un DOS extender (probablement DOS4GW?) qui permet de travailler en mode protégé (avec des "appels systèmes" qui passent en mode réel pour accéder au DOS là ou c'est nécessaire). Mais tout ça ça commence à être de l'archéologie. Mais je pensais qu'il travaillait plutôt à partir de la version Windows 95?
Même sans les sources, il est peut-être possible de faire quelque chose, même si ce sera plus une réécriture du moteur qu'un portage. Les projets de ce genre ne manquent pas et aujourd'hui on peut jouer à plein de jeux sous Linux grâce à cela (si on possède un CD ou une disquette du jeu avec les données originales, bien sûr).
Au passage je mentionne http://osgameclones.com qui liste les jeux qui sont plus ou moins dans ce cas (certains utilisant les données originales, d'autres ayant déjà remplacé toutes les données en plus du code). Je trouve que la liste est étonnamment longue, ce qui est une bonne chose.
[^] # Re: Bravo !
Posté par ben51 . Évalué à 2.
Merci pour osgameclones.
Depuis le temps que je cherchais une liste de moteur de jeux porté sous Linux.
# Jeux vidéo vers un logiciel de compta
Posté par tukutt . Évalué à 3.
Vous êtes bien l'éditeur de Crésus ? J'ai connu un comptable complètement fan de ce logiciel.
Créer des jeux puis un logiciel de compta, quelle ré-orientation !
[^] # Re: Jeux vidéo vers un logiciel de compta
Posté par Mathieu Schroeter (site web personnel, Mastodon) . É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.
# bonjour smaky
Posté par ixo . Évalué à 1.
Au début des années 2000 j'étais expatrié à Lausanne et je participais aux soirées autour de la collection Bolo. C'est la que j'ai découvert l'existence des smaky, et depuis je me dit quel gachis. Si seulement nos élites Françaises avait pu regarder ce qu'il se passait en Suisse Romande. Quel bonheur je crois ça aurait été d'avoir dans notre plan informatique des smaky 100 par exemple.
Tiens, du coup je vais voir si je peux installer smaky infini sur un Windows moderne.
# Disponibilité sous Debian
Posté par Mathieu Schroeter (site web personnel, Mastodon) . É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: Disponibilité sous Debian
Posté par Yth (Mastodon) . Évalué à 3. Dernière modification le 25 octobre 2017 à 20:35.
Dispo aussi depuis une semaine sous Slackware via un SlackBuild sur slackbuilds.org par moi-même.
Yth :)
[^] # Re: Disponibilité sous Debian
Posté par Mathieu Schroeter (site web personnel, Mastodon) . Évalué à 2.
Cool, Merci
[^] # Re: Disponibilité sous Debian
Posté par feth . Évalué à 2.
Exactement ma config… juste quand je viens de découvrir les fichiers Appimage.
Écoute, merci, merci ! je viens de passer un super bon moment !
# Coquille
Posté par NumOpen . Évalué à 3.
en chagre Microsoft Windows : dingue comme ça déraille dès qu'on s'approche de ce système.
[^] # Re: Coquille
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.