Mr.Boom est un jeu MS-DOS, clone de Bomberman, codé en pur assembleur à la fin des années 90. Il vient d’être converti en C.
Le jeu est identique à la version DOS à part l’ajout de l’I. A. Il est disponible en version SDL2 et RetroArch (pour toutes les plates‐formes qu’il prend en charge : Android, GNU/Linux, Apple macOS, Nintendo GameCube, Nintendo Wii, Raspberry Pi, Sony Playstation 3, Sony Playstation Portable, Microsoft Windows, Microsoft Xbox, Microsoft Xbox 360…).
Il s’agit d’un clone de Bomberman. La version DOS était uniquement multi‐joueur (« trouvez‐vous des amis ! », dit la documentation), mais la version GNU/Linux fournit des bots. Il est possible de jouer en réseau jusqu’à huit joueurs, avec un mode par équipes (deux ou quatre équipes).
Fait intéressant, le code original en assembleur a été converti à l’aide d’un outil appelé asm2c. Il a été développé pour l’occasion et est écrit en Swift. Cela a évité une réécriture manuelle de tout le code source.
Compilation
libretro
make clean
make
Version SDL2
Debian
apt-get install libsdl2-dev libmodplug-dev libsdl2-mixer-dev libminizip-dev
make clean
make mrboom LIBSDL2=1
make install
Apple macOS
brew install SDL2 minizip zlib SDL2_mixer --with-libmodplug
make clean
make mrboom LIBSDL2=1
make install
Microsoft Windows
pacman -S mingw-w64-x86_64-toolchain
pacman -S mingw-w64-x86_64-SDL2main
pacman -S mingw-w64-x86_64-SDL2_mixer
pacman -S mingw-w64-x86_64-SDL2
pacman -S mingw-w64-x86_64-libmodplug
make clean
make mrboom LIBSDL2=1 MINGW=mingw64
Paquets déjà faits
-
mrboomest dans Debian à partir de Buster (actuelletestingqui sera la dixième version) ; -
mrboomest dans Ubuntu ; -
libretro-mrboom-gitdans AUR (Archlinux User Repository) ; -
mrboomde FreshPorts pour FreeBSD ; - MrBoom sur Chocolatey (qui est un gestionnaire de paquets pour Windows).
Pour plus d’informations, vous pouvez consulter sa page sur repology.org.
Configuration pour Raspberry Pi
Pour avoir une vitesse correcte sur Raspberry Pi, assurez vous d’être en mode VGA 60 Hz dans /boot/config.txt :
hdmi_group=1
hdmi_mode=4
Aller plus loin
- Sources sur GitHub (615 clics)
- Convertisseur asm2c (237 clics)
- Site Web officiel (640 clics)
# Processus de conversion
Posté par weonbin . Évalué à 3.
Le processus de conversion du code assembleur en langage C m’intéresse, serait-il possible d'en savoir un peu plus?
Cela pourrait peut être être utilisé pour faire revivre d'autres programmes de cette époque.
Cela me rappelle la manière dont le projet OpenDUNE (réécriture de dune 2) avait démarré, sauf que leurs outils ne sont malheureusement pas publics.
[^] # Re: Processus de conversion
Posté par Colin Pitrat (site web personnel) . Évalué à 3.
Il suffit d'aller voir les fichiers mrboom.h et mrboom.c pour réaliser qu'il est sans doute préférable de réécrire ! Ça peut servir pour la transition et rendre l'assembleur portable mais c'est vraiment horrible comme code.
[^] # Re: Processus de conversion
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
ça n'empêche pas de le réécrire, en fait. Mais ça permet déjà d'avoir un code fonctionnel, à partir duquel on peut réécrire les choses petit à petit.
Parce que réécrire du code assembleur en C et le porter de DOS vers SDL en même temps et sans pouvoir tester tant que tout n'est pas fini, c'est pas forcément évident.
[^] # Re: Processus de conversion
Posté par FReEDoM (site web personnel) . Évalué à 7.
Pour avoir avoir lu les sources il y a une vingtaine d'années, je peux dire qu'à première vu c'était en effet compliqué à déchiffrer. Mais c'est à mon avis normal pour un programme de cette taille avec du graphique et une pile réseau écrit entièrement en assembleur.
A l'époque, j'étais jeune et fou et j'ai eu l'envie de porter ce monument ,déjà à l'époque, vers linux. 20 ans après la communauté l'a fait !
J'ai eu donc l'honneur à l'époque d'avoir rencontré l'auteur de ce jeu monumental, d'être dans la démo et d'avoir eu quelques discussions avec l'auteur. Entre autre, j'avait été impressionné qu'il ai tout codé en asm x86 y compris la couche réseau qui, si je me souviens bien attaquait un driver DOS IPX. Je me rappelle aussi avoir fait la remarque et j'avais été selon l'auteur le premier à lui faire que les labels des sauts locaux en assembleur avaient été choisi en se tapant la tête sur le clavier ou une technique similaire :). Ce qui était probablement la voie que j'aurais choisie vu le nombre de sauts dans tout le code (équivalent en C des while, for, if etc…). Je laisse les ayatollah du code en assembleur me dire qu'il y a des méthodes propres de faire ça mais cela ne change pas grand chose au final.
Je remercie donc encore une fois la communauté pour avoir fait ce que la paresse (ou la sagesse) m'a finalement fait renoncer : Le portage de ce jeu sous linux (enfin SDL, enfin j'me comprends !).
Et encore MERCI à l'auteur original : Remdy !
[^] # Re: Processus de conversion
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
Sur les assembleurs modernes, on peut définir des labels locaux, en général avec un préfixe ou un suffixe dédié (par exemple un . ou un $). La portée est entre deux labels globaux. Du coup, toutes les boucles peuvent s'appeler ".loop" ou quelque chose de ce genre.
[^] # Re: Processus de conversion
Posté par jseb . Évalué à 4. Dernière modification le 07 novembre 2017 à 09:52.
Et même sur les vieux, je me souviens avoir fait ce genre de choses.
Je me demande même si certains assembleurs Z80 n'offraient pas cette possibilité.
(dec ecx / jnz @loop ; voire même loop @loop) dans les années 90 avec TASM (l'assembleur de Borland).
Il y avait toutes les possibilités macro-assembleur également.
On pouvait définir des templates de fonctions : à la compilation, le nom de fonction était remplacé par le bloc de code défini, et il y avait également la possibilité de passer des paramètres à la macro.
Du genre:
(c'est de mémoire, donc je ne garantis pas l'exactitude de la syntaxe)
Je me demande si j'ai toujours le manuel de TASM, je crois l'avoir perdu dans un dégat des eaux :/
C'était autre chose que les programmes qui se trainaient en C :)
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
# 16.04
Posté par ComputingFroggy (site web personnel) . Évalué à 0. Dernière modification le 03 novembre 2017 à 11:57.
Dommage de ne pas l'avoir packagé pour Ubuntu 16.04 !
[^] # Re: 16.04
Posté par NaWer . Évalué à 2.
Ça passe sans problème :
https://packages.ubuntu.com/artful/mrboom
# merci du partage
Posté par cacatoès . Évalué à 3.
Ben voilà, j'ai trouvé ce qu'on va faire pendant notre prochaine réunion technique !
Les GIFs parlent d'eux-mêmes, mais il faut imaginer des ziks au format XM en plus.
Perso j'avais joué à Clanbomber (libre aussi, plus original mais moins léché graphiquement), et à Dynablaster sur Amiga.
Clanbomber a apparemment été retiré des dépots Debian.
# Assets copié-collés
Posté par damaki . Évalué à 8.
Il y a beaucoup plus urgent que de réécrire le code converti depuis l'assembleur, si on veut le pérenniser : les graphismes volés de Super Bomberman 3 (les bombers, les montures, les bombes et les items) sont beaucoup plus dangereux sur le long terme.
Bref, si le jeu vous plait, clonez vite fait le repo et virez tout ça parce qu'il pourrait ne pas faire long feu du tout.
[^] # Re: Assets copié-collés
Posté par dovik (site web personnel) . Évalué à 4.
J'ai abordé le sujet en tribune de rédaction : les graphismes seraient pour moitié originaux, et pour moitié volés à Hudson Soft. Le tout en dur dans le code.
[^] # Re: Assets copié-collés
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 1.
Étonnant qu'il soit rentré dans les repo debian dans ce cas !
[^] # Re: Assets copié-collés
Posté par Maclag . Évalué à 6.
Ça a dû échapper à la surveillance.
Les données sont souvent dans un paquet séparé "-data".
Ici, si j'ai bien compris, tout est en dur dans le binaire, ça a sans doute permis de ne pas capter l'attention.
# Pourquoi en C en 2017 ?
Posté par Aldoo . Évalué à 1.
Sans vouloir troller (bon, un peu quand-même : les questions du genre pourquoi tel ou tel langage… c'est toujours trollogène), en gros, on passe de la pierre taillée à la pierre polie ?
Pour faire les questions et les réponses, j'imagine que de toute façon, un outil automatique ne peut pas inventer un programme "haut niveau" depuis de l'assembleur, alors que vers le C, ça doit se faire "tout seul".
Mais est-ce que les auteurs envisagent cette version en C comme
- une fin en soi ?
- une démo pour asm2c ?
- ou bien seulement comme une étape obligatoire avant de passer à un langage de notre millénaire ?
[^] # Re: Pourquoi en C en 2017 ?
Posté par rewind (Mastodon) . Évalué à 2.
Tu proposes quoi comme langage ? Le C est ce qui se rapproche le plus sémantiquement de l'asm. J'imagine assez mal qu'on puisse transformer de l'asm en Rust (au hasard).
[^] # Re: Pourquoi en C en 2017 ?
Posté par GuieA_7 (site web personnel) . Évalué à 4.
À noter qu'il existe un outil, Corrode , capable de convertir du code C vers Rust (en revanche le projet n'a plus l'air très actif).
Évidemment ce n'est pas magique, mais l'outil a quand même réussi à convertir le code de CVS (50K lignes de code).
Dans le cas présent il est clair que si le code n'est déjà pas du joli C (pour des raisons évidentes), passer de l'asm à du Rust idiomatique ne va pas se faire sans travail de la part des codeurs.
[^] # Re: Pourquoi en C en 2017 ?
Posté par Aldoo . Évalué à 2.
La proximité sémantique a facilité le portage vers C, mais ne justifie pas de son utilité.
Je ne propose pas de langage, ça dépend des préférences et objectifs des développeurs.
Si un effort de portage a été fait, j'imagine que c'est qu'ils comptent améliorer/ajouter des fonctionnalités. Donc n'importe quel langage moderne favorisant un style de programmation sain et maintenable aurait été un meilleur choix que C (qui n'est au fond qu'un assembleur un peu plus lisible et multi-plateforme).
Pour un bomberman-like, sur les machines d'aujourd'hui (fixes comme mobiles), on n'a plus vraiment besoin de faire de micro-optimisations, donc, selon moi, le meilleur compromis se situerait plutôt dans le (très) haut niveau (je verrais probablement objet+fonctionnel… mais après, chacun ses préférences).
Indépendamment du paradigme du langage, un atout de poids serait la possibilité de compiler vers différentes plateformes natives fixes comme mobiles, mais aussi vers JS ou WebAssembly pour en faire une appli web (mais je crois qu'on peut le faire avec le C, via Emscripten).
[^] # Re: Pourquoi en C en 2017 ?
Posté par j_m . Évalué à 4.
Tu es un peu dur avec le C. Il a un typage qui est verifie a la compilation. C'est deja un gros avantage par rapport a des languages plus modernes comme php par exemple, qui pour le coup fait penser a "un assembleur plus lisible".
[^] # Re: Pourquoi en C en 2017 ?
Posté par Aldoo . Évalué à 2.
Oui, j'exagère un peu : le typage c'est déjà énorme (le polissage du silex ? ;-) ).
Peut-être un minimum vital pour tout projet à partir d'une certaine taille (évidemment, je ne suis pas fan de PHP non plus !).
[^] # Re: Pourquoi en C en 2017 ?
Posté par Aldoo . Évalué à 1.
Et pendant ce temps…
(Note : il ne s'agit pas de conversion automatique vers Rust, mais de l'écriture de bindings Rust pour GStseamer. Néanmoins, c'est encore un symptôme de l'inadéquation/l'obsolescence du C ressentie par plus en plus de développeurs !)
[^] # Re: Pourquoi en C en 2017 ?
Posté par rewind (Mastodon) . Évalué à 3.
Tu devrais dénoncer celui qui t'a maltraité à grand coups de bouquins de C. #BalanceTonPorc
Plus sérieusement, personne ne t'oblige à faire du C. Il y a des gens qui aiment bien ce langage et qui ont envie de l'utiliser, c'est bien leur droit. Si d'autres ont envie de se palucher du Rust ou du Brainfuck, c'est aussi leur droit.
[^] # Re: Pourquoi en C en 2017 ?
Posté par xcomcmdr . Évalué à 2.
Ok, du moment qu'on a le droit de critique le C et le C++, et autant qu'on veut (du moment que c'est justifié).
Parce que bon, Rust n'existe pas que pour le plaisir.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pourquoi en C en 2017 ?
Posté par rewind (Mastodon) . Évalué à 9.
Alors deux choses.
Premièrement, chaque fois qu'on parle de C ou C++, on a des rabat-joie qui sont là pour nous rappeler à quel point ce sont de mauvais langages et qu'il faut absolument s'excuser d'utiliser ces langages et qu'on est tellement bête de ne pas utiliser des langages top moumoute qui font le café. À un moment donné, ça va, on a compris. Rien que la dépêche en préparation intitulé «Faut-il continuer à apprendre le C++?» donne bien le ton actuel face à ces deux langages. On devrait la renommer «Pardon aux familles, on continue à faire du C++»
Deuxièmement, les critiques, je veux bien les entendre mais elles sont souvent complètement à côté de la plaque parce qu'on compare des choux et des carottes, c'est-à-dire des langages qui ont été conçus dans les années 70-80 avec des langages qui ont été conçus il y a une dizaine d'année, des langages qui ont été conçus pour une foultitude d'architectures hyper-exotiques avec des langages qui fonctionnent sur quelques architectures modernes assez courantes, des langages qui ont des processus de normalisation internationaux avec une forte rétrocompatibilité avec des langages qui sont encore en développement. Bref, chacun ses forces et ses faiblesses.
[^] # Re: Pourquoi en C en 2017 ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
Puisqu'on parle de #balancetonporc et de Rust, pour les dénonciations ça se passe ici:
https://github.com/ansuz/RIIR
https://transitiontech.ca/random/RIIR
[^] # Re: Pourquoi en C en 2017 ?
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 8.
Il n'y a rien à dénoncer, il faut juste savoir garder un œil critique.
On n'a jamais vu un langage percer uniquement en le comparant aux autres.
Que quelqu'un recode Mr. Boom en Rust et montre les avantages et inconvénients comme cela a été fait dans le journal sur Gnirehtet, c'est beaucoup plus constructif que de dire que coder en C c'est nul.
[^] # Re: Pourquoi en C en 2017 ?
Posté par Aldoo . Évalué à 7.
Et à chaque fois qu'on ose critiquer le C ou le C++, il y a une meute de programmeurs qui se sentent insultés et nous tombent dessus à bras raccourcis.
Au passage, je n'a jamais dit le C saynul ou saylemal. J'ai juste remarqué qu'il y avait mieux (à nuancer selon le domaine, bien sûr, mais plus ça va, moins je vois où se trouve le pré carré du C).
Par exemple, je pense que C et le C++ (surtout le C) sont excellents d'un point de vue pédagogique car ils permettent de mettre en évidence les mécanismes sous-jacents à tout langage de programmation, moderne ou non (et non je n'ai pas été maltraité par un professeur de C ou C++, merci bien !). Notamment, beaucoup de bonnes idées de Rust (ex. : pointeurs intelligents) proviennent de C++ (le principal tort de C++ étant de permettre d'utiliser aussi les mauvaises idées trop facilement !). En plus leur syntaxe reste l'inspiration principale de celle des langages modernes, donc on n'est pas dépaysé (et on perd moins de temps sur ces aspects annexes).
Ce que je dis plus haut, c'est que C et C++ sont intéressants pour enseigner la théorie des langages de programmation. Par contre, je ne les conseillerais pas pour apprendre à (bien) programmer : ces langages sont bien trop permissifs.
Et alors ?
En quoi cela est-il un argument pour défendre l'utilisation de ces outils antédiluviens ?
Si je compare les mérites de la charrue et de la moissonneuse-batteuse, dans le contexte de quelqu'un qui monterait une nouvelle exploitation agricole, est-ce que tu lui conseillerais la charrue parce qu'elle fonctionne avec une foultitude d'architectures exotiques, qu'elles ont été maintes fois normalisées, et qu'elles sont rétro-compatibles avec les champs égyptiens, babyloniens et sumériens ?
[^] # Re: Pourquoi en C en 2017 ?
Posté par Aldoo . Évalué à 3.
Pardon, je voulais dire tracteur tirant une déchaumeuse, pas une moissoneuse-batteuse (qui sert à autre chose !). Mais revenons à nos moutons !
[^] # Re: Pourquoi en C en 2017 ?
Posté par Renault (site web personnel) . Évalué à 7.
Bah personnellement, un gars peut écrire son logiciel perso en COBOL, BASIC ou autre, je m'en fout un peu même si je n'aime pas ces langages et sont inadaptés. Je veux dire, cela ne me regarde pas, si le gars assume son choix (qui peut poser des soucis dans l'évolution de son logiciel, dans l'élaboration d'une communauté ou la venue d'autres contributeurs) je ne vois pas le soucis.
Le C a quelques domaines :
Si le C perd du terrain dans ces domaines, sa disparition complète risque de prendre beaucoup de temps. Surtout que son historique fait que c'est un langage que pratiquement tout développeur a touché une fois dans sa vie et qu'il y a beaucoup de code à maintenir.
C'est un projet personnel, je ne vois pas le soucis que quelqu'un fasse ça pour le fun. Dans un contexte professionnel, démarrer un projet en C devrait être lourdement justifié bien entendu, dans un contexte perso, qui s'en préoccupe ? Charge à l'auteur d'assumer ce choix.
[^] # Re: Pourquoi en C en 2017 ?
Posté par Aldoo . Évalué à 4.
Non mais, en fait, je suis d'accord avec tout ça !
Ma question initiale était juste pourquoi le C (sous-entendu, pour un projet personnel pour se faire plaisir, qui ne fait partie d'aucun des domaines de prédilections du C que tu listes, c'est plutôt un plaisir masochiste !). Je me demandais s'il n'y avait pas une raison un peu profonde.
Mais vraisemblablement, la réponse ne va pas plus loin que "bah, c'était facile à faire avec asm2c".
[^] # Re: Pourquoi en C en 2017 ?
Posté par rewind (Mastodon) . Évalué à 5.
«mieux» ne signifie rien dans l'absolu. Ton «mieux» est beaucoup trop générique parce que, ce que tu mets dans la catégorie des défauts de C, c'est en réalité tout ce qui fait sa spécificité et qu'on doit placer dans la catégorie des avantages (par exemple, les pointeurs). Dans le cas de ce jeu, il est absolument clair que C était le meilleur choix et de très loin ! Et je l'ai justifié dès la première réponse : c'est ce qui se rapproche le plus sémantiquement de l'asm. J'aurais fait exactement le même choix. J'aurais en tout cas éviter un choix dogmatique fondé sur la hype d'un langage «moderne».
Franchement, j'arrêterai de râler quand on arrêtera de faire des comparaisons idiotes entre des langages de programmation. C'est bien de comparer, mais pas pour dire qu'un est «mieux» que l'autre parce que ça n'a strictement aucun sens.
C'est du jeunisme bas de gamme. Ce n'est pas parce qu'ils sont antédiluviens qu'ils sont forcément mauvais (ou bon d'ailleurs). Beaucoup de gens trouvent leur compte avec ces langages, et même beaucoup y trouvent du plaisir et n'ont aucune envie de passer à autre chose.
[^] # Re: Pourquoi en C en 2017 ?
Posté par Aldoo . Évalué à 2.
Tout à fait. D'où les modalités entre parenthèses.
Oui, c'est toujours l'argument de la facilité, que j'entends. Toujours est-il que la valeur ajoutée est plus faible que si on avait traduit vers un langage capable d'abstraire efficacement les différentes entités du jeu (favorisant la ré-utilisabilité, l'extensibilité et la maintenabilité, etc. etc. je ne refais pas tout le topo). Évidemment, ce genre de traduction ne peut pas encore se faire de façon automatique (ça relèverait probablement du domaine de l'IA : reconnaissance de motifs, etc.), donc il faudrait plus d'huile de coude (initialement).
Peut-être le terme antédiluvien est-il un peu provocant. Mais le propos était juste de réfuter l'argument comme quoi on ne pouvait pas comparer l'ancien et le nouveau. Cela n'est pas du jeunisme, mais du pragmatisme : la question se pose très concrètement à chaque fois qu'il faut faire le choix d'une technologie pour arriver à un but donné.
[^] # Re: Pourquoi en C en 2017 ?
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 06 novembre 2017 à 21:35.
Et Rust aussi
Comme beaucoup d'autres langages, rien de nouveau sous le soleil.
[^] # Re: Pourquoi en C en 2017 ?
Posté par Zenitram (site web personnel) . Évalué à 5.
Un peu comme tous les autres langages sortis depuis C et C++, non?
Parce que bon, je dois taper la vingtaine d'années en code (la vieillesse…), et le "langage qui va nous faire arrêter de nous faire chier avec le C et C++", ça doit faire le 4ème ou 5ème (si ce n'est plus) langage hype qui va tout détruire, et à chaque fois le "langage hype" est pris comme "référence" certes mais dans des domaines de niche, jamais aussi largement que C et C++. Quand j'étais à l'école, c'était Java qui allait tout détruire (il fallait même développer des applets Java pour le navigateur, c'était le futur du web tellement c'était puissant, et rien d'autre que Java allait exister du le web, si si c'est le but car HTML et JS c'est de la merde on vous dit)
Rien de nouveau sous le soleil, à part l'incrémentation du nombre de "remplaçants potentiels, on vous le dit c'est le but, du C et C++".
bref : phrase bateau classique qui n'argumente pas grand chose (ha, sinon PHP dit pareil, pourquoi ne pas faire du PHP alors?)
[^] # Re: Pourquoi en C en 2017 ?
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 6.
Au moins, il y a quand même un truc super positif qui ressort de tout ça, c'est qu'avec tout ce qu'il y a à ré-écrire, les développeurs Rust ont du boulot pour au moins 15 ans :D
[^] # Re: Pourquoi en C en 2017 ?
Posté par Christophe . Évalué à 6.
Pourquoi pas, ai-je envie de dire.
Il y a certes moins de garde-fou en C, mais faire un code sain n'a pas grand chose à voir avec le choix du langage.
Si le code final n'a aucun commentaire et ressemble à un plat de spaghetti, l'avoir fait en Ruby/C#/Go ne va pas le rendre magiquement maintenable.
Et puis le C est vieux, mais il reste tout à fait un "langage de notre millénaire", vu le nombre de projets actifs qui l'utilisent.
[^] # Re: Pourquoi en C en 2017 ?
Posté par Maclag . Évalué à 4.
Je ne m'aventurerais pas à dire que le C c'est la "pierre polie" ou "pas un langage du millénaire", mais disons que je le vois également comme peu adapté à toutes les tâches dont les performances ou l'empreinte mémoire ne sont pas critiques, et j'ai du mal à croire qu'ici ce soit le cas.
Du coup, je ne questionnerais pas le choix du C parce que c'est "vieux", mais parce qu'on peut certainement développer et maintenir le même jeu bien plus rapidement dans un langage de plus haut niveau sans impacter les perfs.
Pour le cas présent, je suppose par contre que la contrainte initiale, c'est passer de l'assembleur à autre chose, et le C était la seule option utilisable rapidement.
[^] # Re: Pourquoi en C en 2017 ?
Posté par arnaudus . Évalué à 4.
Bah, c'est vrai que quand on prend un peu de recul, le moteur d'un bomberman ressemble plus à un projet d'étudiant sur 24h qu'à un truc industriel avec une équipe de 18 personnes sur 3 ans… Du coup, à part pour l'exploit, l'histoire du code assembleur traduit en C, bof bof, hein… Surtout quand on lit que les graphismes sont en dur dans le code, ça fait quand même un peu peur.
[^] # Re: Pourquoi en C en 2017 ?
Posté par Anonyme . Évalué à 4.
Ça parait simple maintenant qu'on a beaucoup d'outils de haut niveau. Ce n'est pas non plus un homebrew en BASIC façon Atari 2600 de la crise du jeu vidéo de 83 (et les copies du jeu E.T. enterrées dans le désert mexicain).
C'est pas très juste en terme de jugement du temps de travail, c'est comme si tu comparais la MAO actuelle avec une musique chiptune de console 8 bit composée directement par programmation d'une puce sonore basique sans même de synthèse FM ou de séquenceur.
Mais oui, pour moi aussi ce n'est pas le jeu qui est intéressant en lui-même mais bien la performance technique dont l'outil permet davantage de portabilité.
[^] # Re: Pourquoi en C en 2017 ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
Toi tu n'as jamais essayé de programmer une Atari 2600. Ce n'était certainement pas du BASIC, en tout cas.
La console n'a pas assez de RAM pour un frame buffer, donc il faut générer à la volée, ligne par ligne, ce qui s'affiche à l'écran pendant que la télévision balaye ce dernier. TOUT le code doit donc être écrit en tenant compte de ces timings.
Le jeu ET est plutôt bien conçu, mais trop ambitieux pour la console et les moyens de l'époque, ce qui le rend difficile à comprendre (graphismes peu lisibles à cause de la faible résolution des images) et à jouer (maniabilité pas terrible).
En tout cas, ce n'est pas un jeu développé "à l'arrache" sur un coin de table. Même si le résultat n'est pas franchement convaincant, c'était déjà pas facile d'en arriver jusque là étant donné les contraintes.
Oh et pour la musique chiptune faite "à la main": https://www.linusakesson.net/hardware/chiptune.php
[^] # Re: Pourquoi en C en 2017 ?
Posté par arnaudus . Évalué à 3.
Certes, mais là, il y a deux choses qui sont complètement mélangées. 1) la mise à disposition d'un bomberman libre, et 2) la "ressucitation" et la traduction en C d'un vieux code à valeur historique. Le côté "une pierre deux coups", je n'y crois pas une seconde, car le code est dégueu, le langage est anachronique pour ce genre de projet, et il y a des medias non-libres codés en dur dans le code.
Si l'objectif était de founir un bomberman libre en code moderne, ça peut être fait en quelques jours-homme (et pas forcément mal fait) dans un langage adapté. Sans IA et sans graphiques, ça peut même se compter en heures. Du coup, l'histoire du désassamblage, ça semble viser un objectif complètement différent, c'est tout.
Quand on dit "en 2017 un tel projet nécessite 2 jours-hommes", ça ne veut pas dire que dans les années 1980 ça ne nécessitait pas 2 ans de développement. Il y a quand même des progrès qui ont été fait dans les langages de programmation et dans les bibliothèques tierces, en 30 ans! Mais du coup, le projet d'il y a 30 ans n'a plus qu'un intérêt historique.
[^] # Re: Pourquoi en C en 2017 ?
Posté par Tonton Th (Mastodon) . Évalué à 4.
Show us the code.
[^] # Re: Pourquoi en C en 2017 ?
Posté par arnaudus . Évalué à 3.
Haut - bas - gauche - droite - poser une bombe dans une game loop, une boucle pour faire péter les bombes avec un timer… Tu envisages une vraie difficulté qui t'empêcherait d'arriver à un truc fonctionnel en une journée?
Comme toujours, l'IA, c'est chaud (surtout une bonne IA, qui serait par exemple capable d'anticiper la pose de bombe en fonction des options qu'elle est susceptible de collecter), et la création des menus, des options, etc., c'est chiant et ça prend du temps.
Si la seule manière d'évalluer la complexité d'un projet était de le coder, alors ça ne servirait pas à grand chose d'évaluer la complexité d'un projet…
[^] # Re: Pourquoi en C en 2017 ?
Posté par GuieA_7 (site web personnel) . Évalué à 7. Dernière modification le 07 novembre 2017 à 00:49.
Certes, mais en parlant d'une journée max de boulot, tu montres à mon avis à quel point il est courant dans le milieu de l'informatique de sous-évaluer le temps de développement (mais peut-être es-tu commercial dans une SSI :) ).
Alors oui, il existe des gens capables lors d'une GameJam de 24h de pondre seul des jeux même plus ambitieux que ça (et en faisant les graphismes et le son) (regardez ce que DeepNight arrive à faire par exemple), mais il s'agit de gens rodés à cet exercice depuis de longues années, qui connaissent leur outils de création de jeux sur le bout des doigts ; généralement ce sont des professionnels de la création de jeux vidéos. Donc s'ils sont capable de faire ça en un week-end, il ne faut pas oublier les années de création de jeux qui on permis d'atteindre ce niveau.
De simples amateurs qui se mettent à la création de jeux il leur faudra bien plus. Ça ne sera pas des années de développement évidemment, mais moi rien que pour lire la documentation et faire les tutoriels de GodotEngine, ça m'a largement pris plus d'une journée, pendant mes vacances. Il est tout à fait possible que tu sois bien plus compétent que moi, mais je bosse depuis suffisamment longtemps pour savoir que je suis plus compétent que la moyenne. Après je serai heureux que tu viennes nous présenter les applications libres que tu codes ; parce que si tu es capable de faire ça en quelques heures, j'imagine qu'en quelques jours de travail ça doit vraiment être impressionnant.
PS: 90% du code écrit ne fait rien de bien complexe. Pourtant le diable se cache dans les détails et même faire quelque chose d'assez trivial, quand on veut que ça soit de bonne qualité, ça prend du temps. Sinon nous aurions des tas de jeux libres de qualité. Hélas on sait qu'il ne sont pas très nombreux.
[^] # Re: Pourquoi en C en 2017 ?
Posté par Anonyme . Évalué à 3.
Oui on est plus à l'état de prototype que de jeu réel en une journée. Après j'imagine qu'arnaudus veut parler de gens un peu expérimentés dans une suite d'outils pour créer la mécanique sans avoir de travail sur le design.
Je ne pense pas que ce soit aussi simple que le fait que ça prenne du temps. Pour moi il y a principalement des problèmes d'absence de modèle économique, de manque de lâcher-prise des créateurs de jeux sur la vie de leurs œuvres et d'une infériorité, en ergonomie, en performance ou en possibilité, des moteurs de jeux libres face aux géants propriétaires qui sont la plupart du temps gratuits et utilisés dans le milieu pro.
Aussi, très peu de studios libèrent leurs codes (jeu, designs graphiques et audio ainsi que les moteurs) même après des décennies sans exploitation commerciale mais ça c'est le cas dans toutes les branches de la programmation. Parfois on trouve des paliers très hauts pour l'ouverture du code dans les campagnes de financement participatif de jeux indépendants mais c'est rare et encore plus rarement atteint.
On trouve donc pas mal de prototypes libres dans les gamejam (souvent en Lua ou en Python) mais pour des jeux aboutis il ne reste plus que quelques militants libristes qui n'ont bien souvent pas le bagage technique ou l'ambition pour sortir du clone rétro.
[^] # Re: Pourquoi en C en 2017 ?
Posté par arnaudus . Évalué à 5.
Oui, je parlais évidemment du temps qu'il fallait pour quelqu'un d'expérimenté. Quand un plombier te dit qu'il en a pour deux heures pour remplacer ton radiateur, il ne prend pas en compte son temps de formation sur la pose de radiateur.
Mouais, en même temps l'amateurisme des équipes qui développent les jeux libres est peut-être le problème majeur. Il y a des problèmes avec le côté participatif des jeux libres, surtout en matière de medias artistiques (musiques et graphismes). Il y a aussi un problème avec le côté "évolution au fil de l'eau", puisqu'il faut quand même maintenir une cohérence au jeu, et que ça n'est pas facile dans le cadre d'une communauté pas bien définie. Mais bon, pour la partie code / AI / pathfinder etc, c'est souvent un problème de compétence dû au fait que les gens motivés pour faire un jeu libre ne sont pas les gens qui savent faire un jeu libre…
[^] # Re: Pourquoi en C en 2017 ?
Posté par GuieA_7 (site web personnel) . Évalué à 3.
Certes. Mais dans cas tu es le plombier et tu dis à des non plombiers qu'ils devraient faire la réparation (eux-mêmes) et que ça prendra 2h ; personnellement je le comprends comme "ça va vous prendre 2h". Mais c'est peut-être moi. Peu importe.
Je suis globalement d'accord avec tout ton paragraphe. Mais il n'est pas en contradiction avec ma phrase ; même des pros vont avoir besoin de beaucoup de temps pour faire quelque chose de soigné. Si tu codes (mais c'est vrai pour tout), alors tu sais ce que c'est que faire un sympathique prototype en 3h, mais au final passer 2 semaines sur ton patch pour gérer tous les cas particuliers pénibles etc…
[^] # Re: Pourquoi en C en 2017 ?
Posté par GuieA_7 (site web personnel) . Évalué à 3.
Je suis d'accord avec l'ensemble de ton commentaire. Je reviens sur 2 points en particulier:
Intéressant. Je me suis déjà amusé à faire le tour des plateformes de financement participatif à la recherche de projets de jeux libres, et je n'avais rien trouvé (sauf un anecdotique jeu genre casse brique pas du tout attrayant). La seule exception semble être la campagne d'amélioration de 0AD.
Du coup l'existence de tels paliers dans des projets de jeux m'intéresse, mais j'y vois 2 bémols:
J'ai axé ma réponse autour du temps, en rapport au message auquel je répondais ; ce n'est évidemment pas le seul problème.
Mais pour préciser ma réponse, je parlais de petits jeux d'arcade comme celui de cette dépêche. Pour de tels jeux, il n'y a pas de grosse difficulté technique (le côté artistique c'est autre chose) (ex: il ne s'agit pas de faire un modèle d'éclairage dynamique 3D nécessitant des connaissances pointues en optique et en pipeline 3D), je pense pour l'aspect mathématique un niveau 4ème doit suffire (bon allez si on peut envoyer une bombe, faut peut-être savoir ce qu'est une parabole). Du coup même si ce sont des amateurs qui codent, s'ils ont assez de temps, ils vont y arriver (le code ne sera peut-être pas terrible, mais ça marchera à peu prêt). Mais même pour un petit jeu comme ça, il faudra pas mal de temps pour faire tous les petits détails qui font que ça rend bien.
Évidemment pour des jeux plus ambitieux le problème sera tout autre.
[^] # Re: Pourquoi en C en 2017 ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
Y'avait pas eu une campagne pour Plee the Bear il y a quelques années?
[^] # Re: Pourquoi en C en 2017 ?
Posté par GuieA_7 (site web personnel) . Évalué à 2.
En effet le site officiel parle bien d'une campagne sur OpenFunding (qui a l'air mort).
[^] # Re: Pourquoi en C en 2017 ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 1.
Il y a bien eu l'ajout d'une IA dans cette version Linux qui n'existait pas pour la version DOS. Donc ça montre bien qu'il est possible de faire évoluer ce code pour y ajouter des fonctionnalités.
[^] # Re: Pourquoi en C en 2017 ?
Posté par Anonyme . Évalué à 2. Dernière modification le 07 novembre 2017 à 18:09.
Il est toujours possible de faire évoluer un code et de le nettoyer, personne ne nie ça.
Ce qu'on dit c'est que ça ne vaut pas forcément le coup de se trainer une telle relique avec autant de travail de réorganisation du code en perspective alors que pour un jeu aussi peu complexe dans ses mécaniques et ses graphismes il est envisageable de faire une réécriture pour repartir sur une base saine avec des outils plus modernes.
Après si c'est pour l'exercice de style et que ça vous éclate, tant mieux si cette façon de faire vous motive.
Je pense qu'on est toutes et tous d'accord pour dire que le principe de ce convertisseur asm2c est excellent mais à mon avis le programme choisi ne mérite pas davantage d'attention que le stade de la démonstration de faisabilité.
[^] # Re: Pourquoi en C en 2017 ?
Posté par Anonyme . Évalué à 3.
Désolé on avait pas la thune pour un Atari mais j'ai touché à un CPC464. Alors oui les jeux étaient pas fait en BASIC mais les multiples mauvais clones de l'arcade ont pourri l'industrie. Et E.T. est peut-être pas mal conçu (il y a quand même des bugs importants), il n'empèche qu'il ne colle pas avec le film et qu'il n'est pas du tout amusant même pour l'époque.
Quant au chiptune, je parle bien des technique de l'époque 70-80 avant les trackers et les FMsynth ce qui correspond à automatiser un générateur de fréquence donc oui c'est composé à la main, note par note. Ton lien est intéressant mais en dehors de mon exemple vu que le gros de son travail c'est de créer un tracker, chose qui n'existait pas.
[^] # Re: Pourquoi en C en 2017 ?
Posté par Aldoo . Évalué à 2.
On utilise souvent le C, soit parce qu'on connaît déjà, soit parce qu'on travaille sur un projet qui était déjà écrit en C.
Le reste du temps (hors niches, dont, je pense, le développement d'un jeu à la Bomberman ne fait pas partie… mais je peux me tromper !), il y a probablement assez peu de raisons valables de démarrer un nouveau projet en C quand on connaît mieux.
Concernant les autres langages, je ne pense pas qu'il en existe un seul qui empêche quelqu'un de vraiment déterminé à mal programmer. Disons que quand-même tous les langages ne sont pas aussi convaincants les uns que les autres sur cet aspect-là !
[^] # Re: Pourquoi en C en 2017 ?
Posté par steph1978 . Évalué à 4.
Le C ici ne sert qu'à avoir de l'asm portable.
Étant donné que l'on n'ajoute aucune sémantique, quel serait l'intérêt d'un langage de plus haut niveau ?
[^] # Re: Pourquoi en C en 2017 ?
Posté par GuieA_7 (site web personnel) . Évalué à 3.
Visiblement l'idée est d'améliorer le jeu (avec un peu d'imagination, les possibilités sont nombreuses), pas juste de garder quelque chose de figé qu'on va faire tourner sur plein de plateformes. Auquel cas, la façon la plus pragmatique de faire aurait été de faire de l'émulation [*] ; ce n'est pas forcément la plus excitante techniquement évidemment.
Donc un langage de plus haut niveau peut avoir du sens (pour écrire un code réseau plus sereinement par exemple). Après ce n'est pas à moi de décider si le jeu en vaut la chandelle.
[*] la NES mini & la SNES mini par exemple, ce ne sont "que" des émulateurs dans un joli écrin.
[^] # Re: Pourquoi en C en 2017 ?
Posté par Anonyme . Évalué à 1.
Malheureusement, avec les problèmes de licences des assets et leur codage en dur il y a sans doute plus à y gagner de repartir sur un moteur neuf donc un langage plus convivial. Après à chacun son intérêt.
Ce sont aussi des machines hors de prix avec un SOC sur-dimensionné qui est bridé par le manque de connectique et la capacité ridicule de la NAND.
[^] # Re: Pourquoi en C en 2017 ?
Posté par Shunesburg69 . Évalué à 1.
Je me posais la même question.
Pourquoi pas simplement compiler le programme en assembleur ?
Quel intérêt de passer en C ?
L'assembleur est pas plus optimisé et rapide ?
Désolé n'étant pas développeur, je vois pas l'utilité de ce portage.
[^] # Re: Pourquoi en C en 2017 ?
Posté par nonas . Évalué à 4. Dernière modification le 05 novembre 2017 à 21:26.
L’intérêt réside justement dans le portage, ou plutôt la portabilité du code C.
Par sa nature même, du code en assembleur ne pourra être exécuté que sur une architecture matérielle (ici x86). Transformer ce code spécifique en code C, plus générique, permet par compilation d’obtenir des exécutables pour plein d’autres architectures (ARM, PPC, etc.) et plein d’autres systèmes d’exploitation.
[^] # Re: Pourquoi en C en 2017 ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
ça permet aussi de migrer des morceaux du code vers du C "propre" petit à petit. C'est possible de mélanger le C et l'assembleur aussi, mais pas forcément évident surtout si c'est de l'assembleur écrit pour MS-DOS (avec accès direct à la RAM vidéo, tout ça).
Le temps de la https://www.svgalib.org est révolu!
# contrôle clavier
Posté par goeb . Évalué à 2.
Comment on contrôle jeu au clavier ? Y a-t-il une documentation ?
[^] # Re: contrôle clavier
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
man mrboomdonne les touches pour deux joueurs et précise « Bomberman is controlled with the keyboard or with (up to 8) joypads » (clavier ou jusqu'à 8 manettes).# RetroArch > MrBoom
Posté par P@sNox Nox (site web personnel) . Évalué à 2.
A noter que si vous possedez RetroArch, le core MrBoom est telechargable depuis les preferences de celui ci !!!
Le bemole c'est toujours le non support des joysticks!!! en 2017 c'est plus possible Franck, stp ajoute ca ;)
[^] # Re: RetroArch > MrBoom
Posté par P@sNox Nox (site web personnel) . Évalué à 1.
Bon en fait c'etait un probleme RetroArch/macOS pour mon probleme de joystick! Tout fonctionne bien maintenant !!
# Xblast
Posté par sifu . Évalué à 2.
Ça me rappelle xblast où j'ai pas mal joué avec des collègues… On pouvait se faire des personnages avec Pov-Ray ;)
Il y a même un package Debian.
[^] # Re: Xblast
Posté par P@sNox Nox (site web personnel) . Évalué à 0.
il est quand meme a des années lumiere question game play ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.