Wow, je connaissais mais je n’avais pas vu combien ça s’était développé, il vont très loin maintenant :
Statements are terminated by a period instead of a semicolon. Semicolons are clearly a phallus symbol. C+= supports freebleeding and thus uses periods.
^^
ce commentaire est sous licence cc by 4 et précédentes
Alors dans la blague de zurvan< « cum » n’était pas le verlan de « mec » mais bien le verbe to cum¹.
la « gent féminine » s’écrit sans « e » et le « t » n’est pas prononcé (on prononce la gent exactement comme on prononce les gens). Le mot « gente » est d’une toute autre nature (c’est un adjectif et non un nom) et d’un tout autre sens (il signifie « gentil ») : La gent féminine. La gente dame.
Thomas, expert. Euh, en langue.
_______
¹ Personne ne te fera le reproche d’ignorer cela. 😉
ce commentaire est sous licence cc by 4 et précédentes
Ce n'est pas de la vapeur d'eau au sens classique. La vapeur à la pression ambiante, c'est 100 °C. Elle ne peut pas exister autrement.
Bien sûr que si que c’est de la vapeur, la où tu fais une confusion, c’est sur la signification du palier de 100°C. 100°C n’est pas le point d’évaporation de l’eau, c’est le point auquel l’eau ne peut pas rester à l’état solide ou liquide. En dessous de 100°C, l’eau peut s’évaporer, à partir de 100°C, l’eau ne peut pas ne pas s’évaporer (ébullition).
Ça me rappelle une autre confusion courante avec les images animées : on dit qu’on perçoit une illusion de mouvement à partir de 16 images secondes, certains en déduisent qu’on ne voit plus rien de plus au delà. Une variante existe avec d’autre valeurs comme 30fps, fondé sur le même biais cognitif : c’est une confusion sur la nature des bornes.
100°C n’est pas la borne en dessous de laquelle l’eau ne peut pas s’évaporer, c’est la borne à partir de laquelle l’eau ne peut pas ne pas s’évaporer.
ce commentaire est sous licence cc by 4 et précédentes
Ça fait très amateur-réalisé-avec-trois-bouts-de-scotch, la prise de son est nulle, de toute évidence il n'ont pas de micro-perche, les acteurs parlent pas assez fort, dans les scènes d'intérieur les voix résonnent et le micro sature, dans les scènes d'extérieur quand une voiture passe au loin on entend mieux la voiture que les acteurs au premier plan. Le mixage sonore est catastrophique (…)
que ça m’a fait une association d’idée dans ma tête, parce qu’il y a bien une à deux heures de travail pour ces 8 secondes de bonheur :
En fait, tu n’as fait aucune bêtise. Tu n’avais juste pas besoin de formater le disque de GrandPère puisque l’installation de Linux va le faire.
Si t’arrives à booter aucun périphérique depuis l’ordi sur lequel tu veux installer Linux, et que tu as un autre ordi sous la main (qui lui sait booter des CD ou des clés USB) c’est facile.
Appelons GrandPère l’ordi qui doit être installé en Linux, et AutreOrdi l’autre ordinateur sous WinXP.
depuis AutreOrdi, tu graves un DVD d’installation d’une distro Linux (par exemple Ubuntu, télécharger ici), ou bien tu transformes l’iso DVD en clé USB bootable (chercher sur le web un tuto pour faire ça depuis Windows)
tu éteins GrandPère et AutreOrdi
tu retires le disque dur de GrandPère
tu débranche le disque dur de AutreOrdi (pour être sûr de ne pas installer Linux dessus par erreur, et pour éviter qu’il soit trouvé à l’installation)
tu branche le disque dur de GrandPère dans AutreOrdi
tu insères dans AutreOrdi le DVD d’installation ou la clé USB bootable
tu installes Linux sur AutreOrdi (qui a en fait le disque de GrandPère !) : suivant, suivant, suivant. Quand il te demande quoi faire avec le disque, tu lui dis de prendre toute la place et d’effacer ce qu’il y a déjà (c’est aussi pour ça que c’est plus sûr d’avoir débranché l’autre, comme ça, pas de fausse manip). Suivant, suivant suivant.
quand c’est terminé, tu éteins AutreOrdi, tu remets le disque dur de GrandPère dans GrandPère et celui de AutreOrdi dans AutreOrdi.
Après ça, GrandPère démarre sous Linux, et AutreOrdi sous WinXP. Voilà.
ce commentaire est sous licence cc by 4 et précédentes
Vu que ton proco vient de chez Intel, si ton processeur a un GPU intégré, tu pourrais peut-être juste essayer sans carte graphique PCIe, du tout, juste l’écran sur la prise écran de la carte mère, et voir si ça devient plus stable comme ça.
ce commentaire est sous licence cc by 4 et précédentes
Si c'est la carte-mère (comme je le prétends plus haut) c'est un diagnostic par élimination : une fois que tous les autres diagnostics sont négatifs, il ne reste que la carte-mère qui puisse être mise en cause. En gros.
En fait il n’a pas dit que son PC ne démarrait pas (depuis un état éteint), il a dit que son PC ne s’éteignait pas ou ne redémarrait pas (ce qui signifie, depuis un état démarré avec sa Debian déjà en route), ce qui peut être un simple kernel panic et autre plantade comme vue dans ses copies d’écran, ou bien un bug dans le système d’init (systemd mon amour) dans la phase d’extinction.
Il a dit :
le pc ne s’éteint ou ne redémarre pas seul une fois sur deux
ce commentaire est sous licence cc by 4 et précédentes
J’ai peut-être zappé dans la discussion, mais t’as essayé avec une autre carte graphique ?
Tes messages d’erreur parlent beaucoup du pilote nouveau…
J’ai eu un problème avec une carte Radeon qui est sujette à plantage dans certaines configurations de gestion d’énergie, qui produisait les mêmes effets : figeage intempestifs etc. Dans mon cas il suffisait juste de choisir un autre profil de gestion d’énergie, mais malheureusement pour toi, les pilotes libres pour les cartes NVidia sont grave à la ramasse derrière les pilotes Radeon (qui ont des développeurs d’AMD et de Valve qui travaillent dessus…) donc t’auras peut-être pas le genre de tweak qui m’a sauvé la vie. Cela dit tu pourrais essayer le pilote proprio d’Nvidia, aussi.
ce commentaire est sous licence cc by 4 et précédentes
Mais si comme tu l'indiques la machine ne démarre pas DU TOUT (tu n'as pas présisé) de temps en temps, c'est la carte-mère, point.
Non.
Je raconte une histoire vraie d’il y a un peu plus d’un mois je crois.
Je redémarre mon ordinateur pour différentes raison de temps en temps, donc je sais que l’ordinateur, dans sa configuration de l’époque et tous ses périphériques branchés, savait redémarrer correctement.
Pourtant, un jour, en redémarrant, le PC ne démarre pas, l’écran s’allume mais rien ne se passe et je n’arrive même pas à l’affichage du BIOS. Aucun beep, aucune alarme, mais seul l’écran s’allume et rien d’autre ne se passe.
Ce qui est très bizarre, c’est que même mes ventilateurs ne démarrent pas, je l’ai appris à mes dépends puisqu’alors que j’étais en train de réfléchir et que le PC était dans dans cet état, alimenté après démarrage écran allumé et tout (mais rien d’affiché et planté), mon ordinateur s’est éteint à cause de la sécurité de mon processeur qui surchauffait.
C’était vraiment bizarre parce que j’ai configuré le BIOS pour démarrer mes ventilateurs à toute berzingue, c’est fancontrol qui bien plus tard, une fois Linux chargé et tout et tout, se charge de calmer mes ventilos. Donc, si le BIOS s’initialise correctement, même si rien d’autre ne se passe, même si aucun OS n’est chargé, mon PC est sensé être sûr question température. Et là c’était pas le cas, mon bug était si vicieux que cela plantait le BIOS à une étape très très tôt de son initialisation, avant même de pouvoir démarrer des ventilateurs !
J’ai retiré les barrettes de mémoire, je les ai remises, rien. J’ai testé avec chacune des barrettes seules (ce serait un comble de griller 4 barrettes d’un coup donc en cas de problème mémoire, j’espérai qu’au moins une fonctionne), rien ne se passe. J’ai deux boutons spéciaux sur la carte-mère, un bouton pour reconfigurer les mémoires sur une configuration sûre, rien n’y fait, un bouton pour forcer l’accès au BIOS quelque soit l’état du PC, rien n’y fait.
Avant de remarquer ce problème avec les ventilateurs, voyant simplement un PC amorcé, un écran allumé mais rien d’affiché, je pense au début à la carte graphique. Je la retire et mets une autre à la place, toujours rien.
Histoire de réduire la charge sur l’alimentation, j’avais débranché tout ce que je pouvais : disques durs etc. Toujours rien.
Après trois ou quatre heures de bataille, je retire je ne sais plus pour quelle raison le récepteur de ma souris sans fil, un truc qui dépasse de 3mm d’un port USB. Et là tout redémarre. J’avais deux récepteurs de souris, pour deux souris différentes (une plus gaming, et une autre verticale, plus ergonomique). Et bien la raison était simple et très très conne, mais le BIOS se vautrait dans une espèce de conflit USB lorsque les deux récepteurs de souris sans fil étaient branchés en même temps.
En fait, une fois redémarré avec l’une des deux souris, l’ordinateur savait redémarrer même avec les deux souris, comme il le faisait déjà avant.
Ce jour-là j’ai perdu 4h de ma vie à cause d’un conflit USB entre deux récepteurs de souris sans fil. Avant ça marchait, puis ça marchait plus, et après ça re-marchait. Allez savoir…
Rien ne s’affichait, les ventilateurs ne démarraient même pas, et pourtant la carte mère n’était pas morte : j’écris ce message avec ledit PC plus d’un mois après, même configuration.
Alors oui on peut dire que mon problème venait de la carte mère qui se vautrait avec un pauvre conflit USB, mais elle n’était pas à jeter.
ce commentaire est sous licence cc by 4 et précédentes
N’empêche je remercie grave pour toutes ces petites corrections partout tout le temps, merci pour ce dévouement #like# #keurkeur#. Faudrait pouvoir faire des pull-requests qu’il suffirait de réviser, ça rendrait peut-être les choses plus faciles ! :-)
ce commentaire est sous licence cc by 4 et précédentes
Ben en regardant l'illustration, si tu considères qu'on a un mouvement de balancier, et que tu supposes que la corde est attachée au milieu de la poutre, tu te dis que la poutre doit sûrement péter le plancher à chaque passage.
Un mécanisme de ce type est simple et efficace: le bélier frappe le mur lorsque la masse revient à sa position initiale, c’est à dire quand l’énergie cinétique est maximale. L’ensemble du mécanisme tient à l’intérieur de la structure lorsqu’il est armé (masse levée prête à être relâchée), ce qui signifie que la structure possède son maximum de manœuvrabilité lorsque le bélier est armé, ce qui est excellent.
ce commentaire est sous licence cc by 4 et précédentes
Oui, et c’est un raisonnement assez partagé en fait.
C’est pour cela que de nombreux projets libres font l’effort de ne pas compiler leur paquets windows avec le compilateur de microsoft, parce que dans ce cas le binaire produit ne serait pas un logiciel libre.
ce commentaire est sous licence cc by 4 et précédentes
In a normal OpenArena build, QVM files would be built from these sources
using lcc. In Debian we build them as native-code using gcc instead.
Donc ils font bien ce que je supposais… Mais ça signifie que l’environnement d’exécution du client n’est pas “pur” par rapport au serveur (le serveur ne peut pas vérifier que le client utilise un code de connu, ça pourrait aussi être un aimbot ou autre triche), comment font-ils pour le jeu en ligne ? Il n’y a pas de vérification du tout ?
ce commentaire est sous licence cc by 4 et précédentes
La nouvelle animation est en effet bien plus satisfaisante ! J’y connais rien en perse, mais cette animation était pour le moins incongrue.
Je me demande qui a bien pu imaginer la précédente animation… et surtout comment elle avait pu faire son chemin jusqu’à publication ! Un bélier étant dans sa forme la plus basique un tronc porté par des hommes pour enfoncer une porte, l’idée actuelle fait tout à fait sens : on y reconnaît une version évoluée du bélier sous la forme d’une structure complexe fournissant protection des opérateurs contre les projectiles et équipée d’un système de balancier pour faire reposer la force d’impact du bélier sur une force naturelle au lieu de la force humaine. La précédente animation en forme de marteau n’avait vraiment aucun sens. C’est le genre de petit détail qui a beaucoup d’importance, c’est top de voir que l’équipe prend aussi soin de ces petits détails !
ce commentaire est sous licence cc by 4 et précédentes
[…] lcc is not public-domain software, shareware, and it is not protected
by a `copyleft' agreement, like the code from the Free Software
Foundation.
lcc is available free for your personal research and instructional use
under the `fair use' provisions of the copyright law. You may, however,
redistribute lcc in whole or in part provided you acknowledge its
source and include this CPYRIGHT file. […]
You may not sell lcc or any product derived from it in which it is a
significant part of the value of the product.
[…] Using parts of lcc in other products is more problematic. For example,
using parts of lcc in a C++ compiler could save substantial time and
effort and therefore contribute significantly to the profitability of
the product. This kind of use, or any use where others stand to make a
profit from what is primarily our work, requires a license agreement
with Addison-Wesley.
Bref, c’est du Fair-Use-NC-ND.
Bouh, OpenArena sapusaypalibre ! :o Maintenant tu as une bonne raison de ne plus jouer à OpenArena, en plus d’être môche, saypalibre ! :p
ce commentaire est sous licence cc by 4 et précédentes
Tu parles de qc (quake code) ? Il me semble que ça n'a été abandonné qu'à partir de idTech 4.
Probablement. Je ne sais pas quand ça a été abandonné (ni même si ça l'a été en fait) par les auteurs, mais:
En fait il y a eu plusieurs techniques employées.
QuakeC
Quake utilisait QC effectivement, un langage dédié (et assez limité) et inspiré du C (ce n’est pas du C) qui se “compile” avec un outil associé (FTEQCC, GMQCC…). Les gros défauts sont en gros: la conception du langage possède des incongruités étonnantes (désolé, pas d’exemple là), aucune bibliothèque préexistante et réutilisable puisque c’est un langage de niche, et puisque la toolchain est elle aussi “de niche”, les optimisations ne seront jamais aussi poussées qu’un compilateur comme GCC ou clang. QC est utilisé par Quake premier du nom. Les gros utilisateurs de QC aujourd’hui sont donc Xonotic, donc si vous voulez en savoir plus sur les défauts de QC, il suffit de demander sur le canal #xonotic sur FreeNode ;-). Si le QC est converti vers un autre format (.dat) et que j’ai employé le verbe “compiler” à ce sujet, en fait on considère que techniquement, le .dat lui-même est interprété. Donc le dernier défaut, c’est que c’est pas très rapide. Avec beaucoup d’ironie MinceR disait récemment à propos de Darkplace (le moteur dérivé de Quake 1 utilisé par Xonotic) que [Darkplace] can't be a piece of shit if it manages to run xonotic :>, on peut dire la même chose de QuakeC: son unique qualité aujourd’hui doit être de motoriser Xonotic. ;-)
QVM
C’est la techno utilisé par Quake III Arena, la QVM (ou Q3VM) est une machine virtuelle (spécifications) qui exécute (n’interprète pas) du code binaire. Le jeu se programme en C ANSI, gros plus par rapport au QC, cgest un langage standard et du code peut être partagé ou certaines bibliothèques existantes réutilisées si elles n’utilisent pas de spécificité trop modernes du langage. Par exemple lors de la transition de d’Unvanquished depuis la QVM (héritée de Tremulous et donc de Quake 3) vers NaCL, le même code C pouvait être compilé vers du code natif (une bibliothèque .so sous linux ou .dll sous windows pour faciliter le débugage avec GCC, être compilé en .qvm pour la machine virtuelle historique de Quake 3, ou compilé vers la machine virtuelle NaCL (voir ci-après). Le code est compilé avec un compilateur dédié (LCC qui a l’avantage d’être un vrai compilateur C standard, mais qui a l’inconvénient de ne pas bénéficier de toutes les optimisations que peuvent fournir un compilateur comme GCC ou clang, il en va de même pour les fonctionnalités : on doit se restreindre à un C aux spécifications figées. Le compilateur LCC n’est pas libre (c’est une espèce de shareware, pas très contraignant mais pas libre). Un des défauts est donc aussi le fait de devoir se farcir une toolchain non standard. Quand Unvanquished a complètement viré la QVM, 8 000 lignes en rapport à la QVM ont été virées du moteur, mais surtout, 23 000 lignes de code d’outils associés (pour compiler le code pour la QVM) ont été supprimés du dépôt.
Code natif
Méthode employée par Wolfenstein: Enemy Territory: le code est compilé vers une bibliothèque native (.so, .dll) et pas seulement pour le débogage. Ça peut faire sens pour un jeu non-multijoueur (comme Return to Castle Wolfenstein) de ne pas se prendre la tête avec la sécurité du code exécuté (il provient du CD de toute façon), mais ça pose de vrais problèmes de sécurité dans un jeu multijoueur comme Wolf:ET : le client se connecte à un serveur, télécharge un mod automatiquement, extrait la bibliothèque et l’exécute sans autre forme de procès. C’est un trou de sécurité immense impossible à combler sans se couper de la logithèque existante… L’avantage, c’est que le développeur est très libre (par exemple True Combat: Elite, un mod de Wolf:ET, est codé en C++). Un autre inconvénient, est qu’il faut donc compiler nativement le mod pour chaque architecture. Par exemple la seule versions de TC:E pour Mac est une version PowerPC, aujourd’hui c’est inutilisable. C’est aussi pour cela que si ET:Legacy fonctionne très bien en 64bit, il est conseillé d’utiliser la version 32bit car c’est la seule qui peut exécuter les mods existant.
Je suppose que les développeurs de RTCW avaient éliminés le code de la QVM pour leur jeu simple joueur parce que c’était inutile, et qu’ensuite, développant Wolf:ET sur la base de RTCW, ben c’était trop tard…
Le truc de Doom 3
En fait je ne sais pas quelle technologie est employée par Doom 3. The Dark Mod est basé sur Doom 3 donc ils réutilisent ladite techno, et ce serait intéressant de savoir. Peut-être que c’est aussi du code natif vu que c’était un jeu single user, je ne sais vraiment pas.
NaCl
Native Client, une machine virtuelle inventée par Google pour son navigateur Chrome, permettant de compiler du code C/C++ ou possiblement d’autres langages vers un code intermédiaire exécuté dans un bac à sable. Il y a deux versions, NaCl et PNaCl. NaCL (pour _Na_tive _Cl_ient) est indépendant du système d’exploitation : le même code x86 32bit tournera dans une machine Windows x86 32bit, Linux x86 32bit, Mac 32bit, mais il faut une (et une seule version) x86 64bit pour viser Mac/Linux/Windows en x86 32bit. Ainsi, puisque Unvanquished (qui utilise la machine virtuelle NaCl) est compilé et distribué pour x86 32/64bit (avec un client Linux/Mac/Windows), il “suffirait” de porter le moteur (et uniquement le moteur) vers Haiku/DargonFlyBSD/Syllable/AROS/Minix pour que le jeu tourne sur ces systèmes d’exploitation sans recompiler le code du jeu lui-même, tant que l’architecture est la même. Pour porter vers Power/ARM/MIPS, il faudrait recompiler le jeu mais une seule fois par architecture matérielle, indépendamment du Système d’exploitation.
PNaCl est une version _P_ortable d’NaCl: un seul et unique code distribuable est suffisant pour viser tous les systèmes d’exploitation et architecture. C’est en fait une version intermédiaire qui est translatée au moment de l’exécution vers l’architecture cible. Je ne crois pas qu’un jeu vidéo utilise cela aujourd’hui, il y a eu des expérimentations pour Unvanquished, mais rien eu de concluant, et pour diverses raisons, il y a peu de chance que quelqu’un perde du temps dessus.
NaCl fonctionne très bien, est très performant, permet d’être débuguée directement, permet d’utiliser des langages modernes (comme du C++) avec des compilateurs modernes (comme clang ou gcc, le code est converti depuis les fichiers objets après compilation) et de réutiliser des bibliothèques existantes. Par exemple Unvanquished réutilise la bibliothèqie C++ de rendu HTML/CSS libRocket pour son interface utilisateur. Le code du jeu est désormais entièrement en C++ comme le moteur de jeu, permettant d’écrire des bibliothèques pour des fonctions communes au moteur et au jeu lui-même.
Il est très peu probable que des efforts soient fait en direction de PNaCl. En effet, Google a abandonné NaCl pour son moteur Chrome. Cela n’a pas d’incidence directe pour le moteur Dæmon (et des jeux comme Unvanquished), car c’est comme si Dæmon était un autre navigateur qui fournit aussi une machine NaCl, mais la techno NaCl perd son plus gros contributeur, donc on sait déjà que ça ne va pas beaucoup évoluer. Il y a peu de chance que les développeurs de Dæmon aient l’envie et le courage de devenir les mainteneurs principaux de Nacl donc il est probable qu’une migration soit envisagée dans un moyen ou long terme, mais il n’y a rien d’urgent : NaCl fonctionne très bien et répond toujours au besoin.
WebAssembly
Je ne crois pas que des moteurs à la Quake utilisent déjà cette techno, mais c’est la techno d’avenir. Si Dæmon voulait migrer de NaCl vers autre chose, ce serait clairement vers WebAssembly. Comme NaCl, c’est une techno poussée par les développeurs de navigateurs web. Contrairement à NaCl, Google n’est pas seul dans la course: on trouve aussi Mozilla avec son Firefox par exemple. Google a donc en réalité abandonné NaCl pour WebAssembly, là où NaCl avait échoué à rassembler les développeurs de navigateurs sous une bannière commune, WebAssembly a réussi. WebAssembly est d’ailleurs plus un concurrent de PNaCl: un même code pour toutes les architectures et les systèmes. Pour des jeux comme Unvanquished ou Xonotic, WebAssembly ne serait pas encore vraiment prêt (il y a encore trop de limitation question multi-processus si je me souviens bien), et c’est encore trop frais trop mouillé, mais hyper prometteur, c’est le chemin à suivre.
Si la transition d’Unvanquished/Dæmon de la QVM vers NaCL avait été un énorme travail de très longue haleine, compliqué et chronophage, la transition de NaCl vers WebAssembly ne le serait pas tout autant : le gros du travail est fait. Notamment, tout le portage C++ est déjà fait. Une des choses fatiguantes avec la QVM c’était que tout code C++ qui devait être utilisé par le jeu devait être intégré au moteur uniquement en vue de fournir des interfaces pour le jeu en retour (!!!). Puisque NaCl permet le C++ directement, ces codes ont été correctement rapatriés dans le code du jeu, et des mods pourraient choisir d’autres technologies sans avoir à l’ajouter dans le moteur directement (un comble). Tout ça est déjà fait.
Le jeu Xonotic travaille à migrer depuis le moteur Darkplaces vers le moteur Dæmon. J’ai vu passer deux plans de migrations, le premier, naïf, peut-être plus rapide, mais qui serait un peu “dommage”, serait de porter l’interpréteur QuakeC vers la machine NaCl. Une transition plus tard vers WebAssembly serait aisée : il faudrait en gros, intervertir les toolchains. Le gros défaut c’est que Xonotic se traînerait encore et toujours QuakeC. J’ai vu des personnes envisager cette hypothèse et peut-être même y travailler, mais je ne sais plus qui. L’autre solution serait de transpiler le code QuakeC vers du C++ et de faire le grand saut, en compilant le code C++ transpilé pour NaCl, ce qui ouvrirait la porte à plein de choses magiques et à l’écosystème C++ existant. C’est la solution sur laquelle travaille TimePath. Là encore, une transition de NaCl vers WebAssembly serait en gros une question de toolchain (une fois WebAssembly incorporé dans Dæmon, bien sûr, ce qui est une autre affaire).
Bon, l'article date de 2013, je ne peux pas accéder au site officiel pour voir l'état actuel de la chose… (déjà 4 ans…p'tin…)
Pour référence, l’article qui annonce la migration d’Unvanquished vers NaCl (et l’abandon de la QVM) est celui de l’alpha 37, en mars 2015.
Code du jeu (VM) et code du jeu (scripts)
En gros a l'origine une partie tres importante du code etait une VM (genre llvm) qui faisait tourner des binaires en pseudo-C, rien que ca (la raison derriere est tres pertinente, de memoire c'est utilise pour les cartes, pour la portabilite et la stabilite) peut faire fuir pas mal de codeurs, surtout amateurs. Me semble que cette section a ete remplacee par llvm, pour le coup, mais n'empeche qu'il faut du c++ pour scripter les cartes me semble (je previens, je n'avais pas trop creuse et ca date) ce qui ne facilite pas la tache.
En fait il y a confusion. ;-) les choses comme la QVM ou NaCL (le truc basé sur llvm auquel tu penses) ne sont pas utilisés pour les même choses. Ces choses-là sont faites pour coder le jeu lui-même, comme présenté plus haut, ça va être aussi le code qui intègre le moteur de rendu HTML si ton interface est en HTML. Le C++ est donc plus qu’indiqué. Une bonne partie du code réseau en fait partie aussi, généralement. En gros le moteur de jeu est principalement une machine virtuelle, quelques primitives réseau, une abstraction du système de fichier, le moteur de rendu, l’interprétation de la carte elle-même bien entendu, l’interprétation des shaders, le décodage des textures et des sons, ainsi que le système sonore.
Un jeu comme UrbanTerror (initialement un mod de Quake 3) est un jeu complet et n’est pas envisageable avec un simple langage de script. Il tourne surle moteur de jeu de Quake 3, mais il remplace intégralement le code du jeu de Quake 3. UrbanTerror pourrait fournir un langage de script, Quake 3 pourrait fournir un autre langage de script, ça ne bénéficierait pas vraiment de l’un à l’autre.
Pour scripter un jeu et des événements (par exemple en Lua, en JavaScript ou en Python), ce n’est pas le moteur de jeu qui fournit l’interpréteur éventuel pour ces langages, c’est le code du jeu, celui qui est programmé en QC, en C pour la QVM ou en C++ pour NaCl ou WebAssembly. Il est donc très très très intéressant de pouvoir coder son jeu en C++ pour pouvoir incorporer un interpréteur Lua, JavaScript ou Python qui existe déjà en C ou en C++ !
C’est donc au code du jeu de fournir un interpréteur pour ces choses-là. Et il est plus facile d’incorporer un interpréteur Python en C que recoder Python depuis zéro en QuakeC.
Le défaut des jeux comme Quake 3, c’est qu’il n’y avait pas grand chose de prévu pour les missions en joueur seul : le jeu de base était une suite de carte du jeu multijoueur avec des bots. Il n’y avait aussi quelques événements “programmables” (mais sans vrai langage de programmation dédié), par exemple une porte qui s’ouvre quand le joueur s’approche près d’elle (si le volume du joueur collisionne avec un volume invisible devant la porte, la porte s’ouvre), ou encore des actions liées à un impact de projectile (un joueur passe sous une presse, tu tires sur un objet à l’autre bout de lacarte, la presse écrase le joueur). À partir de là et avec d’autres fonctionnalités (plate-forme mobiles) on peut faire des choses un peu plus évoluées, comme des ascenseurs reliés à un bouton, des trains, ou des trucs bien plus complexe comme cette “preuve de concept” de Simon O'Callaghan : The Edge Of Forever qui est une mission mono joueur qui fonctionne sur un Quake 3 Arena non-modifié (c’est un puzzle, le joueur doit résoudre des énigmes pour ouvrir des portes et parcourir tout le niveau jusqu’à la fin). Mais la méthode est très archaïque. Ce n’est pas un langage de programmation écrit, les événements sont des objets que l’on connecte entre eux dans la carte elle-même, il faut donc passer par la case édition de la carte pour modifier la logique… Un langage dédié serait appréciable en effet.
Notez que tout cela ne fait pas partie du moteur de Quake 3, mais du code du jeu Quake 3. Pour bénéficier des ces fonctionnalités il ne suffit pas de baser son jeu sur id Tech 3, mais de reprendre aussi le code du jeu lui-même (qui est libre, aussi). Ainsi, ajouter un langage interprété pour améliorer cela se fait dans le code du jeu (celui qui tourne dans la VM).
On peut imaginer divers langages. Par exemple, ET:Legacy (à la fois un moteur pour Wolf:ET et un mod de Wolf:Et) fournit un interpréteur langage Lua, mais le système de bot est en Perl (Omnibot) mais pour ce dernier j’ai un doute s’il est embarqué dans le code du jeu ou dans le moteur avec une interface pour le code du jeu, (spyhawk< pourrait lever le doute).
Moteur id Tech 4 pour le “single user”
Un dernier point: si quelqu’un veux faire un jeu libre avec des missions, il serait plus prudent de commencer avec le moteur id Tech 4 (utilisé par The Dark Mod, qui contient des mécanismes en ce sens (Doom 3 était un jeu de ce type) : événements scriptés, dialogues, etc. The Dark Mod est un bon exemple de jeu basé sur un moteur libre et proposant des missions aux joueurs.
J’avoue que je ne sais pas du tout comment ça marche, mais c’est à mon avis le plus avancé. L’éditeur de niveau DarkRadiant est correctement maintenu en plus.
Après, pour des missions simples (un peu comme le jeux de SimonOC) avec des plateformes, des portes à ouvrir et des machines à manipuler, forker Unvanquished suffit, en plus avec Unvanquished charger des cartes en fonction de la réussite ou non de la carte précédente, ce qui est déjà pas mal, et scripter certains comportements de bots. Il ne s’agira pas de les voir faire quelque chose en fonction de ce que tu fais directement ni de ton avancée dans le niveau, mais il est possible de les faire découvrir le niveau tout seul pour te trouver, revenir à leur base pour guérir ou réparer des constructions ou des trucs comme ça.
Par contre faire émerger à partir de rien des bots au coin de la rue en fonction du chemin que tu suis (comme Half Life 2), faut oublier.
De même pour avoir des bots qui changent de comportement quand ils t’entendent, ou encore si tu veux manipuler des objets que tu trouves par terre et les jeter sur un ennemi ou quelque chose pour déclencher un mécanisme, dans ce cas il vaut mieux forker The Dark Mod.
(mince, j’ai écrit un journal)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: C+=
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal [Jeu] Parser de l'écriture inclusive.. Évalué à 7.
Wow, je connaissais mais je n’avais pas vu combien ça s’était développé, il vont très loin maintenant :
^^
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: man sed
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au message Que fait la commande sed ’/^#/d’ ?. Évalué à 6.
c’est un devoir ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: fork
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Wikum : Résumé et récursion. Évalué à 4. Dernière modification le 17 septembre 2017 à 14:23.
Alors dans la blague de zurvan< « cum » n’était pas le verlan de « mec » mais bien le verbe to cum¹.
la « gent féminine » s’écrit sans « e » et le « t » n’est pas prononcé (on prononce la gent exactement comme on prononce les gens). Le mot « gente » est d’une toute autre nature (c’est un adjectif et non un nom) et d’un tout autre sens (il signifie « gentil ») : La gent féminine. La gente dame.
Thomas, expert. Euh, en langue.
_______
¹ Personne ne te fera le reproche d’ignorer cela. 😉
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Exceptionnel ou systémique ?
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Le jour d’après, c’est aujourd’hui. Évalué à 10.
Bien sûr que si que c’est de la vapeur, la où tu fais une confusion, c’est sur la signification du palier de 100°C. 100°C n’est pas le point d’évaporation de l’eau, c’est le point auquel l’eau ne peut pas rester à l’état solide ou liquide. En dessous de 100°C, l’eau peut s’évaporer, à partir de 100°C, l’eau ne peut pas ne pas s’évaporer (ébullition).
Ça me rappelle une autre confusion courante avec les images animées : on dit qu’on perçoit une illusion de mouvement à partir de 16 images secondes, certains en déduisent qu’on ne voit plus rien de plus au delà. Une variante existe avec d’autre valeurs comme 30fps, fondé sur le même biais cognitif : c’est une confusion sur la nature des bornes.
100°C n’est pas la borne en dessous de laquelle l’eau ne peut pas s’évaporer, c’est la borne à partir de laquelle l’eau ne peut pas ne pas s’évaporer.
ce commentaire est sous licence cc by 4 et précédentes
# Moi aussi j’ai fait un film libre !
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Plus que 3 jours pour financer deux long-métrages libres. Évalué à 5. Dernière modification le 07 septembre 2017 à 07:12.
C’est en lisant le commentaire d’eingousef au dessus:
que ça m’a fait une association d’idée dans ma tête, parce qu’il y a bien une à deux heures de travail pour ces 8 secondes de bonheur :
Vin d’orange
ce commentaire est sous licence cc by 4 et précédentes
# Utilise l’autre PC
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au message comme quoi les bonnes idées quand on connait rien, c'est pas les bonnes idées. Évalué à 10.
En fait, tu n’as fait aucune bêtise. Tu n’avais juste pas besoin de formater le disque de GrandPère puisque l’installation de Linux va le faire.
Si t’arrives à booter aucun périphérique depuis l’ordi sur lequel tu veux installer Linux, et que tu as un autre ordi sous la main (qui lui sait booter des CD ou des clés USB) c’est facile.
Appelons GrandPère l’ordi qui doit être installé en Linux, et AutreOrdi l’autre ordinateur sous WinXP.
Après ça, GrandPère démarre sous Linux, et AutreOrdi sous WinXP. Voilà.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Carte graphique
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au message DEBIAN plantage. Évalué à 4. Dernière modification le 27 août 2017 à 22:47.
Vu que ton proco vient de chez Intel, si ton processeur a un GPU intégré, tu pourrais peut-être juste essayer sans carte graphique PCIe, du tout, juste l’écran sur la prise écran de la carte mère, et voir si ça devient plus stable comme ça.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Change de carte-mère
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au message DEBIAN plantage. Évalué à 3. Dernière modification le 27 août 2017 à 22:45.
En fait il n’a pas dit que son PC ne démarrait pas (depuis un état éteint), il a dit que son PC ne s’éteignait pas ou ne redémarrait pas (ce qui signifie, depuis un état démarré avec sa Debian déjà en route), ce qui peut être un simple kernel panic et autre plantade comme vue dans ses copies d’écran, ou bien un bug dans le système d’init (systemd mon amour) dans la phase d’extinction.
Il a dit :
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: essayer une autre distribution
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au message DEBIAN plantage. Évalué à 2.
Pas besoin d’un LiveCD pour faire un memtest, depuis ta Debian (quand elle marchotte), tu l’installes comme ça :
Après ça tu rebootes et tu prends la première option memtest dans GRUB (pas celle pour port série, la première, normale).
ce commentaire est sous licence cc by 4 et précédentes
# Carte graphique
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au message DEBIAN plantage. Évalué à 5.
J’ai peut-être zappé dans la discussion, mais t’as essayé avec une autre carte graphique ?
Tes messages d’erreur parlent beaucoup du pilote
nouveau…J’ai eu un problème avec une carte Radeon qui est sujette à plantage dans certaines configurations de gestion d’énergie, qui produisait les mêmes effets : figeage intempestifs etc. Dans mon cas il suffisait juste de choisir un autre profil de gestion d’énergie, mais malheureusement pour toi, les pilotes libres pour les cartes NVidia sont grave à la ramasse derrière les pilotes Radeon (qui ont des développeurs d’AMD et de Valve qui travaillent dessus…) donc t’auras peut-être pas le genre de tweak qui m’a sauvé la vie. Cela dit tu pourrais essayer le pilote proprio d’Nvidia, aussi.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Change de carte-mère
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au message DEBIAN plantage. Évalué à 3. Dernière modification le 27 août 2017 à 22:34.
Non.
Je raconte une histoire vraie d’il y a un peu plus d’un mois je crois.
Je redémarre mon ordinateur pour différentes raison de temps en temps, donc je sais que l’ordinateur, dans sa configuration de l’époque et tous ses périphériques branchés, savait redémarrer correctement.
Pourtant, un jour, en redémarrant, le PC ne démarre pas, l’écran s’allume mais rien ne se passe et je n’arrive même pas à l’affichage du BIOS. Aucun beep, aucune alarme, mais seul l’écran s’allume et rien d’autre ne se passe.
Ce qui est très bizarre, c’est que même mes ventilateurs ne démarrent pas, je l’ai appris à mes dépends puisqu’alors que j’étais en train de réfléchir et que le PC était dans dans cet état, alimenté après démarrage écran allumé et tout (mais rien d’affiché et planté), mon ordinateur s’est éteint à cause de la sécurité de mon processeur qui surchauffait.
C’était vraiment bizarre parce que j’ai configuré le BIOS pour démarrer mes ventilateurs à toute berzingue, c’est fancontrol qui bien plus tard, une fois Linux chargé et tout et tout, se charge de calmer mes ventilos. Donc, si le BIOS s’initialise correctement, même si rien d’autre ne se passe, même si aucun OS n’est chargé, mon PC est sensé être sûr question température. Et là c’était pas le cas, mon bug était si vicieux que cela plantait le BIOS à une étape très très tôt de son initialisation, avant même de pouvoir démarrer des ventilateurs !
J’ai retiré les barrettes de mémoire, je les ai remises, rien. J’ai testé avec chacune des barrettes seules (ce serait un comble de griller 4 barrettes d’un coup donc en cas de problème mémoire, j’espérai qu’au moins une fonctionne), rien ne se passe. J’ai deux boutons spéciaux sur la carte-mère, un bouton pour reconfigurer les mémoires sur une configuration sûre, rien n’y fait, un bouton pour forcer l’accès au BIOS quelque soit l’état du PC, rien n’y fait.
Avant de remarquer ce problème avec les ventilateurs, voyant simplement un PC amorcé, un écran allumé mais rien d’affiché, je pense au début à la carte graphique. Je la retire et mets une autre à la place, toujours rien.
Histoire de réduire la charge sur l’alimentation, j’avais débranché tout ce que je pouvais : disques durs etc. Toujours rien.
Après trois ou quatre heures de bataille, je retire je ne sais plus pour quelle raison le récepteur de ma souris sans fil, un truc qui dépasse de 3mm d’un port USB. Et là tout redémarre. J’avais deux récepteurs de souris, pour deux souris différentes (une plus gaming, et une autre verticale, plus ergonomique). Et bien la raison était simple et très très conne, mais le BIOS se vautrait dans une espèce de conflit USB lorsque les deux récepteurs de souris sans fil étaient branchés en même temps.
En fait, une fois redémarré avec l’une des deux souris, l’ordinateur savait redémarrer même avec les deux souris, comme il le faisait déjà avant.
Ce jour-là j’ai perdu 4h de ma vie à cause d’un conflit USB entre deux récepteurs de souris sans fil. Avant ça marchait, puis ça marchait plus, et après ça re-marchait. Allez savoir…
Rien ne s’affichait, les ventilateurs ne démarraient même pas, et pourtant la carte mère n’était pas morte : j’écris ce message avec ledit PC plus d’un mois après, même configuration.
Alors oui on peut dire que mon problème venait de la carte mère qui se vautrait avec un pauvre conflit USB, mais elle n’était pas à jeter.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: lien mort
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Sortie de 0 AD Alpha 22 Venustas. Évalué à 5. Dernière modification le 26 août 2017 à 18:42.
N’empêche je remercie grave pour toutes ces petites corrections partout tout le temps, merci pour ce dévouement #like# #keurkeur#. Faudrait pouvoir faire des pull-requests qu’il suffirait de réviser, ça rendrait peut-être les choses plus faciles ! :-)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: lien mort
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Sortie de 0 AD Alpha 22 Venustas. Évalué à 2.
Super !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: lien mort
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Sortie de 0 AD Alpha 22 Venustas. Évalué à 2.
…et un tiret de trop. L’ancre doit être
#travail-sur-le-game-designet non##travail-sur-le-game-design-!ce commentaire est sous licence cc by 4 et précédentes
# lien mort
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Sortie de 0 AD Alpha 22 Venustas. Évalué à 2.
Le premier lien du chapitre “Équilibrage” est un lien mort (il pointe vers l’espace de rédaction)
(sinon, sympa les minijeux de l’été 😉)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: bélier perse
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Sortie de 0 AD Alpha 22 Venustas. Évalué à 5.
Une grosse masse suffit:
Un mécanisme de ce type est simple et efficace: le bélier frappe le mur lorsque la masse revient à sa position initiale, c’est à dire quand l’énergie cinétique est maximale. L’ensemble du mécanisme tient à l’intérieur de la structure lorsqu’il est armé (masse levée prête à être relâchée), ce qui signifie que la structure possède son maximum de manœuvrabilité lorsque le bélier est armé, ce qui est excellent.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: bélier perse
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Sortie de 0 AD Alpha 22 Venustas. Évalué à 3. Dernière modification le 24 août 2017 à 22:10.
Haha, je me demandais si tu allais vraiment chercher :p La question était purement rhétorique. ^_^
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: pas de FPS libre mono-joueur?
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. Évalué à 2.
Booouuuh :p
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: pas de FPS libre mono-joueur?
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. Évalué à 2.
Oui, et c’est un raisonnement assez partagé en fait.
C’est pour cela que de nombreux projets libres font l’effort de ne pas compiler leur paquets windows avec le compilateur de microsoft, parce que dans ce cas le binaire produit ne serait pas un logiciel libre.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: pas de FPS libre mono-joueur?
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. Évalué à 2.
Donc ils font bien ce que je supposais… Mais ça signifie que l’environnement d’exécution du client n’est pas “pur” par rapport au serveur (le serveur ne peut pas vérifier que le client utilise un code de connu, ça pourrait aussi être un aimbot ou autre triche), comment font-ils pour le jeu en ligne ? Il n’y a pas de vérification du tout ?
ce commentaire est sous licence cc by 4 et précédentes
# bélier perse
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Sortie de 0 AD Alpha 22 Venustas. Évalué à 8.
La nouvelle animation est en effet bien plus satisfaisante ! J’y connais rien en perse, mais cette animation était pour le moins incongrue.
Je me demande qui a bien pu imaginer la précédente animation… et surtout comment elle avait pu faire son chemin jusqu’à publication ! Un bélier étant dans sa forme la plus basique un tronc porté par des hommes pour enfoncer une porte, l’idée actuelle fait tout à fait sens : on y reconnaît une version évoluée du bélier sous la forme d’une structure complexe fournissant protection des opérateurs contre les projectiles et équipée d’un système de balancier pour faire reposer la force d’impact du bélier sur une force naturelle au lieu de la force humaine. La précédente animation en forme de marteau n’avait vraiment aucun sens. C’est le genre de petit détail qui a beaucoup d’importance, c’est top de voir que l’équipe prend aussi soin de ces petits détails !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: pas de FPS libre mono-joueur?
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. Évalué à 2.
Le langage c’est du C ANSI a priori, donc ça va encore, mais oui il n’est pas possible de produire le jeu complet sans un outil propriétaire.
Il est peut-être possible de compiler le même code en shared lib (au lieu d’un binaire pour la Q3VM), mais dans ce cas, adieu le jeu en ligne.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: pas de FPS libre mono-joueur?
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. Évalué à 2. Dernière modification le 23 août 2017 à 21:21.
https://github.com/OpenArena/gamecode/blob/master/code/tools/lcc/COPYRIGHT
https://github.com/ioquake/ioq3/blob/master/code/tools/lcc/COPYRIGHT
https://github.com/Unvanquished/Unvanquished/blob/v0.36.0/src/tools/lcc/COPYRIGHT
Bref, c’est du Fair-Use-NC-ND.
Bouh, OpenArena sapusaypalibre ! :o Maintenant tu as une bonne raison de ne plus jouer à OpenArena, en plus d’être môche, saypalibre ! :p
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: pas de FPS libre mono-joueur?
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. Évalué à 2.
y a peut-être des alternatives libres aussi, c'est pas impossible à ré-implémenter !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: pas de FPS libre mono-joueur?
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Terminal Overload : un FPS entièrement libre et récent, mais déjà abandonné ?. Évalué à 10.
Sommaire
QuakeC / QVM / NaCl toussa
En fait il y a eu plusieurs techniques employées.
QuakeC
Quake utilisait QC effectivement, un langage dédié (et assez limité) et inspiré du C (ce n’est pas du C) qui se “compile” avec un outil associé (FTEQCC, GMQCC…). Les gros défauts sont en gros: la conception du langage possède des incongruités étonnantes (désolé, pas d’exemple là), aucune bibliothèque préexistante et réutilisable puisque c’est un langage de niche, et puisque la toolchain est elle aussi “de niche”, les optimisations ne seront jamais aussi poussées qu’un compilateur comme
GCCouclang. QC est utilisé par Quake premier du nom. Les gros utilisateurs de QC aujourd’hui sont donc Xonotic, donc si vous voulez en savoir plus sur les défauts de QC, il suffit de demander sur le canal #xonotic sur FreeNode ;-). Si le QC est converti vers un autre format (.dat) et que j’ai employé le verbe “compiler” à ce sujet, en fait on considère que techniquement, le.datlui-même est interprété. Donc le dernier défaut, c’est que c’est pas très rapide. Avec beaucoup d’ironie MinceR disait récemment à propos de Darkplace (le moteur dérivé de Quake 1 utilisé par Xonotic) que [Darkplace] can't be a piece of shit if it manages to run xonotic :>, on peut dire la même chose de QuakeC: son unique qualité aujourd’hui doit être de motoriser Xonotic. ;-)QVM
C’est la techno utilisé par Quake III Arena, la QVM (ou Q3VM) est une machine virtuelle (spécifications) qui exécute (n’interprète pas) du code binaire. Le jeu se programme en C ANSI, gros plus par rapport au QC, cgest un langage standard et du code peut être partagé ou certaines bibliothèques existantes réutilisées si elles n’utilisent pas de spécificité trop modernes du langage. Par exemple lors de la transition de d’Unvanquished depuis la QVM (héritée de Tremulous et donc de Quake 3) vers NaCL, le même code C pouvait être compilé vers du code natif (une bibliothèque
.sosous linux ou.dllsous windows pour faciliter le débugage avec GCC, être compilé en.qvmpour la machine virtuelle historique de Quake 3, ou compilé vers la machine virtuelle NaCL (voir ci-après). Le code est compilé avec un compilateur dédié (LCC qui a l’avantage d’être un vrai compilateur C standard, mais qui a l’inconvénient de ne pas bénéficier de toutes les optimisations que peuvent fournir un compilateur commeGCCouclang, il en va de même pour les fonctionnalités : on doit se restreindre à un C aux spécifications figées. Le compilateur LCC n’est pas libre (c’est une espèce de shareware, pas très contraignant mais pas libre). Un des défauts est donc aussi le fait de devoir se farcir une toolchain non standard. Quand Unvanquished a complètement viré la QVM, 8 000 lignes en rapport à la QVM ont été virées du moteur, mais surtout, 23 000 lignes de code d’outils associés (pour compiler le code pour la QVM) ont été supprimés du dépôt.Code natif
Méthode employée par Wolfenstein: Enemy Territory: le code est compilé vers une bibliothèque native (
.so,.dll) et pas seulement pour le débogage. Ça peut faire sens pour un jeu non-multijoueur (comme Return to Castle Wolfenstein) de ne pas se prendre la tête avec la sécurité du code exécuté (il provient du CD de toute façon), mais ça pose de vrais problèmes de sécurité dans un jeu multijoueur comme Wolf:ET : le client se connecte à un serveur, télécharge un mod automatiquement, extrait la bibliothèque et l’exécute sans autre forme de procès. C’est un trou de sécurité immense impossible à combler sans se couper de la logithèque existante… L’avantage, c’est que le développeur est très libre (par exemple True Combat: Elite, un mod de Wolf:ET, est codé en C++). Un autre inconvénient, est qu’il faut donc compiler nativement le mod pour chaque architecture. Par exemple la seule versions de TC:E pour Mac est une version PowerPC, aujourd’hui c’est inutilisable. C’est aussi pour cela que si ET:Legacy fonctionne très bien en 64bit, il est conseillé d’utiliser la version 32bit car c’est la seule qui peut exécuter les mods existant.Je suppose que les développeurs de RTCW avaient éliminés le code de la QVM pour leur jeu simple joueur parce que c’était inutile, et qu’ensuite, développant Wolf:ET sur la base de RTCW, ben c’était trop tard…
Le truc de Doom 3
En fait je ne sais pas quelle technologie est employée par Doom 3. The Dark Mod est basé sur Doom 3 donc ils réutilisent ladite techno, et ce serait intéressant de savoir. Peut-être que c’est aussi du code natif vu que c’était un jeu single user, je ne sais vraiment pas.
NaCl
Native Client, une machine virtuelle inventée par Google pour son navigateur Chrome, permettant de compiler du code C/C++ ou possiblement d’autres langages vers un code intermédiaire exécuté dans un bac à sable. Il y a deux versions, NaCl et PNaCl. NaCL (pour _Na_tive _Cl_ient) est indépendant du système d’exploitation : le même code x86 32bit tournera dans une machine Windows x86 32bit, Linux x86 32bit, Mac 32bit, mais il faut une (et une seule version) x86 64bit pour viser Mac/Linux/Windows en x86 32bit. Ainsi, puisque Unvanquished (qui utilise la machine virtuelle NaCl) est compilé et distribué pour x86 32/64bit (avec un client Linux/Mac/Windows), il “suffirait” de porter le moteur (et uniquement le moteur) vers Haiku/DargonFlyBSD/Syllable/AROS/Minix pour que le jeu tourne sur ces systèmes d’exploitation sans recompiler le code du jeu lui-même, tant que l’architecture est la même. Pour porter vers Power/ARM/MIPS, il faudrait recompiler le jeu mais une seule fois par architecture matérielle, indépendamment du Système d’exploitation.
PNaCl est une version _P_ortable d’NaCl: un seul et unique code distribuable est suffisant pour viser tous les systèmes d’exploitation et architecture. C’est en fait une version intermédiaire qui est translatée au moment de l’exécution vers l’architecture cible. Je ne crois pas qu’un jeu vidéo utilise cela aujourd’hui, il y a eu des expérimentations pour Unvanquished, mais rien eu de concluant, et pour diverses raisons, il y a peu de chance que quelqu’un perde du temps dessus.
Le moteur de jeu Dæmon (qui motorise Unvanquished) utilise NaCL.
NaCl fonctionne très bien, est très performant, permet d’être débuguée directement, permet d’utiliser des langages modernes (comme du C++) avec des compilateurs modernes (comme clang ou gcc, le code est converti depuis les fichiers objets après compilation) et de réutiliser des bibliothèques existantes. Par exemple Unvanquished réutilise la bibliothèqie C++ de rendu HTML/CSS libRocket pour son interface utilisateur. Le code du jeu est désormais entièrement en C++ comme le moteur de jeu, permettant d’écrire des bibliothèques pour des fonctions communes au moteur et au jeu lui-même.
Il est très peu probable que des efforts soient fait en direction de PNaCl. En effet, Google a abandonné NaCl pour son moteur Chrome. Cela n’a pas d’incidence directe pour le moteur Dæmon (et des jeux comme Unvanquished), car c’est comme si Dæmon était un autre navigateur qui fournit aussi une machine NaCl, mais la techno NaCl perd son plus gros contributeur, donc on sait déjà que ça ne va pas beaucoup évoluer. Il y a peu de chance que les développeurs de Dæmon aient l’envie et le courage de devenir les mainteneurs principaux de Nacl donc il est probable qu’une migration soit envisagée dans un moyen ou long terme, mais il n’y a rien d’urgent : NaCl fonctionne très bien et répond toujours au besoin.
WebAssembly
Je ne crois pas que des moteurs à la Quake utilisent déjà cette techno, mais c’est la techno d’avenir. Si Dæmon voulait migrer de NaCl vers autre chose, ce serait clairement vers WebAssembly. Comme NaCl, c’est une techno poussée par les développeurs de navigateurs web. Contrairement à NaCl, Google n’est pas seul dans la course: on trouve aussi Mozilla avec son Firefox par exemple. Google a donc en réalité abandonné NaCl pour WebAssembly, là où NaCl avait échoué à rassembler les développeurs de navigateurs sous une bannière commune, WebAssembly a réussi. WebAssembly est d’ailleurs plus un concurrent de PNaCl: un même code pour toutes les architectures et les systèmes. Pour des jeux comme Unvanquished ou Xonotic, WebAssembly ne serait pas encore vraiment prêt (il y a encore trop de limitation question multi-processus si je me souviens bien), et c’est encore trop frais trop mouillé, mais hyper prometteur, c’est le chemin à suivre.
Si la transition d’Unvanquished/Dæmon de la QVM vers NaCL avait été un énorme travail de très longue haleine, compliqué et chronophage, la transition de NaCl vers WebAssembly ne le serait pas tout autant : le gros du travail est fait. Notamment, tout le portage C++ est déjà fait. Une des choses fatiguantes avec la QVM c’était que tout code C++ qui devait être utilisé par le jeu devait être intégré au moteur uniquement en vue de fournir des interfaces pour le jeu en retour (!!!). Puisque NaCl permet le C++ directement, ces codes ont été correctement rapatriés dans le code du jeu, et des mods pourraient choisir d’autres technologies sans avoir à l’ajouter dans le moteur directement (un comble). Tout ça est déjà fait.
Le jeu Xonotic travaille à migrer depuis le moteur Darkplaces vers le moteur Dæmon. J’ai vu passer deux plans de migrations, le premier, naïf, peut-être plus rapide, mais qui serait un peu “dommage”, serait de porter l’interpréteur QuakeC vers la machine NaCl. Une transition plus tard vers WebAssembly serait aisée : il faudrait en gros, intervertir les toolchains. Le gros défaut c’est que Xonotic se traînerait encore et toujours QuakeC. J’ai vu des personnes envisager cette hypothèse et peut-être même y travailler, mais je ne sais plus qui. L’autre solution serait de transpiler le code QuakeC vers du C++ et de faire le grand saut, en compilant le code C++ transpilé pour NaCl, ce qui ouvrirait la porte à plein de choses magiques et à l’écosystème C++ existant. C’est la solution sur laquelle travaille TimePath. Là encore, une transition de NaCl vers WebAssembly serait en gros une question de toolchain (une fois WebAssembly incorporé dans Dæmon, bien sûr, ce qui est une autre affaire).
Pour référence, l’article qui annonce la migration d’Unvanquished vers NaCl (et l’abandon de la QVM) est celui de l’alpha 37, en mars 2015.
Code du jeu (VM) et code du jeu (scripts)
En fait il y a confusion. ;-) les choses comme la QVM ou NaCL (le truc basé sur llvm auquel tu penses) ne sont pas utilisés pour les même choses. Ces choses-là sont faites pour coder le jeu lui-même, comme présenté plus haut, ça va être aussi le code qui intègre le moteur de rendu HTML si ton interface est en HTML. Le C++ est donc plus qu’indiqué. Une bonne partie du code réseau en fait partie aussi, généralement. En gros le moteur de jeu est principalement une machine virtuelle, quelques primitives réseau, une abstraction du système de fichier, le moteur de rendu, l’interprétation de la carte elle-même bien entendu, l’interprétation des shaders, le décodage des textures et des sons, ainsi que le système sonore.
Un jeu comme UrbanTerror (initialement un mod de Quake 3) est un jeu complet et n’est pas envisageable avec un simple langage de script. Il tourne surle moteur de jeu de Quake 3, mais il remplace intégralement le code du jeu de Quake 3. UrbanTerror pourrait fournir un langage de script, Quake 3 pourrait fournir un autre langage de script, ça ne bénéficierait pas vraiment de l’un à l’autre.
Pour scripter un jeu et des événements (par exemple en Lua, en JavaScript ou en Python), ce n’est pas le moteur de jeu qui fournit l’interpréteur éventuel pour ces langages, c’est le code du jeu, celui qui est programmé en QC, en C pour la QVM ou en C++ pour NaCl ou WebAssembly. Il est donc très très très intéressant de pouvoir coder son jeu en C++ pour pouvoir incorporer un interpréteur Lua, JavaScript ou Python qui existe déjà en C ou en C++ !
C’est donc au code du jeu de fournir un interpréteur pour ces choses-là. Et il est plus facile d’incorporer un interpréteur Python en C que recoder Python depuis zéro en QuakeC.
Le défaut des jeux comme Quake 3, c’est qu’il n’y avait pas grand chose de prévu pour les missions en joueur seul : le jeu de base était une suite de carte du jeu multijoueur avec des bots. Il n’y avait aussi quelques événements “programmables” (mais sans vrai langage de programmation dédié), par exemple une porte qui s’ouvre quand le joueur s’approche près d’elle (si le volume du joueur collisionne avec un volume invisible devant la porte, la porte s’ouvre), ou encore des actions liées à un impact de projectile (un joueur passe sous une presse, tu tires sur un objet à l’autre bout de lacarte, la presse écrase le joueur). À partir de là et avec d’autres fonctionnalités (plate-forme mobiles) on peut faire des choses un peu plus évoluées, comme des ascenseurs reliés à un bouton, des trains, ou des trucs bien plus complexe comme cette “preuve de concept” de Simon O'Callaghan : The Edge Of Forever qui est une mission mono joueur qui fonctionne sur un Quake 3 Arena non-modifié (c’est un puzzle, le joueur doit résoudre des énigmes pour ouvrir des portes et parcourir tout le niveau jusqu’à la fin). Mais la méthode est très archaïque. Ce n’est pas un langage de programmation écrit, les événements sont des objets que l’on connecte entre eux dans la carte elle-même, il faut donc passer par la case édition de la carte pour modifier la logique… Un langage dédié serait appréciable en effet.
Notez que tout cela ne fait pas partie du moteur de Quake 3, mais du code du jeu Quake 3. Pour bénéficier des ces fonctionnalités il ne suffit pas de baser son jeu sur id Tech 3, mais de reprendre aussi le code du jeu lui-même (qui est libre, aussi). Ainsi, ajouter un langage interprété pour améliorer cela se fait dans le code du jeu (celui qui tourne dans la VM).
On peut imaginer divers langages. Par exemple, ET:Legacy (à la fois un moteur pour Wolf:ET et un mod de Wolf:Et) fournit un interpréteur langage Lua, mais le système de bot est en Perl (Omnibot) mais pour ce dernier j’ai un doute s’il est embarqué dans le code du jeu ou dans le moteur avec une interface pour le code du jeu, (spyhawk< pourrait lever le doute).
Moteur id Tech 4 pour le “single user”
Un dernier point: si quelqu’un veux faire un jeu libre avec des missions, il serait plus prudent de commencer avec le moteur id Tech 4 (utilisé par The Dark Mod, qui contient des mécanismes en ce sens (Doom 3 était un jeu de ce type) : événements scriptés, dialogues, etc. The Dark Mod est un bon exemple de jeu basé sur un moteur libre et proposant des missions aux joueurs.
J’avoue que je ne sais pas du tout comment ça marche, mais c’est à mon avis le plus avancé. L’éditeur de niveau DarkRadiant est correctement maintenu en plus.
Après, pour des missions simples (un peu comme le jeux de SimonOC) avec des plateformes, des portes à ouvrir et des machines à manipuler, forker Unvanquished suffit, en plus avec Unvanquished charger des cartes en fonction de la réussite ou non de la carte précédente, ce qui est déjà pas mal, et scripter certains comportements de bots. Il ne s’agira pas de les voir faire quelque chose en fonction de ce que tu fais directement ni de ton avancée dans le niveau, mais il est possible de les faire découvrir le niveau tout seul pour te trouver, revenir à leur base pour guérir ou réparer des constructions ou des trucs comme ça.
Par contre faire émerger à partir de rien des bots au coin de la rue en fonction du chemin que tu suis (comme Half Life 2), faut oublier.
De même pour avoir des bots qui changent de comportement quand ils t’entendent, ou encore si tu veux manipuler des objets que tu trouves par terre et les jeter sur un ennemi ou quelque chose pour déclencher un mécanisme, dans ce cas il vaut mieux forker The Dark Mod.
(mince, j’ai écrit un journal)
ce commentaire est sous licence cc by 4 et précédentes