gentildemon a écrit 246 commentaires

Je n'ai pas encore passé mon Galaxy S sous cyanogenMod, mais j'y pense de plus en plus.

Bouygues n'a pas été trop méchant sur la custo, ils ont installé quelques applis, mais le pire, c'est surtout qu'ils ont mis un écran de démarrage avec un $#@&* à réveiller les morts... Seul moyen de ne plus avoir ce son, mettre les sons "systèmes" à muet.

Pour les applis ajoutés par l'opérateur, si ton téléphone est comme le mien, c'est impossible de les désinstaller.

J'attends cyanogenMod 9 (android 4.0) stable pour Galaxy S, et je pense essayer.

L'un des points qui me plait dans Cyanogen, c'est de pouvoir choisir les autorisations des applications que tu installes. Je suis d'ailleurs assez surpris qu'il n'y ait pas plus de communication là-dessus.

Je pense que le but est que ce soit adapté au matériel d'aujourd'hui.

Les claviers sont en usb et non en ps/2, on n'utilise plus des disquettes mais des clefs usb, etc.

Je pense qu'il parlait du gouvernement ou de la police allemande...

Quelques rapides images sont passées dans JT de Canal+ lundi ou mardi à 19h45, dans la partie "Tour du monde" je crois.

C'est la seule évocation du sujet que j'ai vu dans les médias.

Si une interface veut avoir le même comportement quelque soit le "device" utilisé, il est obligatoire de virer le clic droit car un écran tactile ne gère que le clic gauche ;)

Après, il y a avantages et inconvénients à se poser une telle contrainte de comportement...

Même si le démantèlement est provisionné, j'ai franchement du mal à voir comment on peut budgétiser un truc qu'on fera dans 50 ans ou plus, avec des technos qu'on ne connait pas encore, sans connaître l'évolution de la monnaie...

A mon avis, les budgets de démantèlement sont largement sous-estimés...

Pour ajouter à ce que dit YeKcim, il faut bien voir que le développement d'un jeu comme Warmux se fait sur notre temps libre.

Nous sommes des bénévoles qui développons selon nos envies, selon notre MOTIVATION.

Il n'est donc pas si simple de dire, non, on ne fera pas A tant que B n'est pas fait. Si il n'y a pas dépendances entre les deux, ça fait juste stagner le logiciel de ne pas avancer sur A. Parce que si on n'est pas motivé pour faire B, ou qu'on ne voit pas comment le faire, si on nous dit de ne rien faire d'autre, bah on va rien faire tout simplement...

Satisfaire les utilisateurs est bien évidemment une sacré motivation, mais ça ne nous donne pas la solution à tous les problèmes!

Pour les personnages en suspension dans le vide, c'est moche, c'est vrai. Mais bien d'autres jeux ont eu des défauts graphiques avant aussi (arbres tout pixelisés en 2D dans les jeux de voitures 3D, etc.). Ça ne rend pas un jeu mauvais pour autant ;-)

Indice : les personnages ont maintenant la grosse tête! ;)

Ça m'étonnerait que ça aide beaucoup pour les vieux jeux.

L'idée est d'implémenter Direct3D 10 ou 11, donc ça dépend ce que tu entends par vieux, mais tous les jeux qui utilisent les version 7, 8 ou 9, tu oublies! (Il me semble que Direct3D est apparu aux alentours de directx 7)

Il faut bien voir que le moteur physique a été codé et amélioré au fur et à mesure pour le jeu et que le jeu a été codé pour utiliser ce moteur, il n'est pas évident de détricoter les deux.

Tout le monde ne souhaite pas bosser sur le moteur physique, donc ça oblige à faire un développement parallèle, avec le risque de ne jamais rapprocher les deux branches. Il faut absolument que le développement sur un nouveau moteur suive au plus près les évolutions du trunk. Ce n'était pas vraiment le cas. SVN n'aide pas beaucoup pour le coup (manque de rebase).

Nous avons déjà essayé 2 moteurs physiques externes : Box2D et Physics. Après avoir résolu bien des problèmes, l'implémentation du grappin a posé problème dans les 2 cas. La gestion d'une corde de taille variable avec un poids important au bout posait de gros problème de performances, mais ce n'était pas le seul problème. Dans certains cas, nous avions besoin d'une gestion non réaliste, et c'était dur à intégrer au milieu du moteur.

Externaliser le moteur physique est un *énorme* boulot assez frustrant. Et la tentation est grande (c'est ce qui s'est passé pour Physics) de commencer à utiliser des fonctions avancées et de rendre le portage encore plus compliqué...

HedgeWars simplifie une bonne partie du problème avec les personnages qui peuvent être assimilés à des ronds par le moteur physique, ce qui permet plein de trucs sympas.

Le changement de nom n'a pas pour but de relancer Wormux, mais d'éviter les problèmes avec les ayants droits de la série des Worms qui pourrait voir d'un mauvais oeil une sortie sur une plateforme mobile sur laquelle leur business est très actif.

Xmoto utilise SDL pour la gestion clavier, le réseau, le son probablement, mais utilise OpenGL pour l'affichage.

On peut faire un zoom avec SDL_gfx mais c'est assez lent, et l'appliquer à tout l'écran serait particulièrement coûteux.

> À mon avis, seul un idiot peut penser que la croissance puisse être infinie dans un monde fini ! Mais peut-être ai-je tord ?

C'est pourtant ce que nous promettent tous les économistes, non ?

X % de croissance économique pendant des dizaines d'années, c'est une courbe exponentielle qui tend vers l'infini...

> aucun souci, juste ils ne seront pas directement disponibles depuis la distribution, en particulier sans QA et autres tests-que-ça-plante-pas préalables. ça gène peu de monde, en passant, d'aller choper un .deb sur un site tiers.

1 deb pour debian stable, 1 pour testing, 1 pour sid, 1 pour ubuntu LTS, 1 pour ubuntu current, ...
1 rpm pour fedora, 1 pour opensuse, 1 pour ...

Hm, ça fait beaucoup de fichiers à générer en fait!


> GNU/Linux n'est pas une cible unique, pas plus que Windows n'est une cible unique. ce n'est pas parce que les 37 versions de Windows que tu vas trouver là dehors sont pratiquement compatibles entre elles qu'elles sont identiques.

Les différentes versions de Windows ne sont certes pas identiques, mais on peut facilement savoir quelles fonctions sont disponibles à partir de quelle version. C'est beaucoup, beaucoup plus simple de faire une version qui fonctionne sur Windows XP, Vista, Seven qu'une version qui tourne sur les 5 plus grandes distro Linux du moment (Je te parle même pas de gérer des versions plus vieilles)

J'adorerai que ça marche, mais foutre les libs, ça ne suffit pas dans tous les cas, cf mon commentaire plus haut :

http://linuxfr.org/comments/1156169.html#1156169

A priori, pour essayer de le faire pour Wormux (cf plus haut), on embarque tout : libc, libc++, libX, ... même le ld.so. et finalement, ce n'est pas si gros. C'est clairement les images qui prennent le plus de place. C'est juste que ça ne marche pas, pour diverses raisons (cf plus haut).

J'attends ta contribution avec impatience pour Wormux!

On fait grosso modo ce que tu dis pour le fichier qu'on peut trouver ici : http://www.wormux.org/phpboost/download/download-4+wormux-0-(...)

On utilise même le ld.so du système sur lequel on génère le 'paquet', histoire qu'on soit vraiment sûr que la liaison dynamique se fasse de la même façon.

Je dirait simplement que ça ne marche pas. On pense ne plus le faire pour les prochaines versions.

Les raisons sont multiples :
- la lib client pulseaudio n'est pas forcément compatible avec le serveur pulseaudio de l'utilisateur (a priori, ils communiquent directement par segment mémoire partagé, et quand le format des données changent, impossible d'avoir du son).
- il y a peut-être des blagues du même style pour X, on a déjà eu des comportements bizarres sur de la transparence qu'on a absolument pas compris.
- pour les traductions, il n'y a pas de variables d'environnement pour dire à gettext d'aller les chercher à un endroit précis, et apparemment il peut y avoir des conflits entre des versions de lib embarquées et les traductions du système.
- et d'autres problèmes que nous n'avons pas compris... on observe notamment sur certaines machines un crash à l'initialisation du réseau avec ce "paquet"

Mouais, sauf que pour ça, il faut que les développeurs aient fait une version statique/semi-statique. Et d'expérience, c'est loin d'être si évident que tout le monde veut bien le dire.

Sinon, c'est prendre le tarball des sources, décompresser, lancer un terminal, taper "./configure --prefix=/opt/monlogiciel_vX", se rendre compte qu'il manque une dépendance sur libYYY, l'installer à coup de apt-get install/urpmi/whatever libYYY-dev, relancer le configure, installer une autre lib manquante, puis faire make, sudo make install, modifier le .bashrc pour ajouter /opt/monlogiciel_vX/bin/ au PATH.

Trivial, c'est sûr...

Tu veux vraiment qu'on enlève tous les logiciels avec un numéro de version < 1.0 ?

Je te laisse essayer de démarrer en enlevant tout ça...

Le protocole de Wormux n'a pas vraiment changé. Simplement, nous ne pouvons autoriser des versions différentes à jouer ensemble.

La communauté de joueurs étant petite, supporter des multiples versions ne feraient que la diminuer. Nous limitons volontairement les versions "supportées" à 2 ou 3. Actuellement, sont supportées les versions 0.9.1 et 0.9.2.

Le problème de la mise à jour des logiciels ne se pose pas que pour les logiciels qui communique en réseau. La cohabitation OpenOffice.org 2.x vs 3.x était délicate il y a quelques temps. J'ai eu l'occasion de devoir mettre à jour un document OOo 3 sur une distrib qui n'avait que OOo 2, j'ai été obligé de prendre la version sur le site officiel, et l'installation ne s'est pas passée correctement, il a fallu bidouiller un peu...

En tant que développeur, si tu me dis comment faire un paquet statique pour Wormux, je suis content.

On a essayé, et on s'est cassé les dents!

On ne fait pas un paquet static, mais une archive qui contient toutes les libs + ld.so(enfin on espère nécessaire ) et qui paramètre le LD_LIBRARY_PATH. Et bien ça ne marche pas.

Suivant la distrib sur laquelle on a compilé le paquet et pris les libs, et la distro sur laquelle on lance, ça va de :
- tout marche à la perfection
- le son ne marche pas (lib cliente pulse audio incompatible avec le serveur probablement)
- la transparence ne marche pas dans les menus mais marche dans le jeu (celui-là, je n'ai pas trouvé d'explication logique... j'imagine que c'est un problème de version/d'extension X.org mais ça n'explique pas pourquoi ça marche dans le jeu alors que ce sont les mêmes fonctions qui sont appelées)
- l'activation du réseau fait planter le programme.

Quant à compiler en statique, il semble que ce ne soit pas possible, notamment à cause de libcurl...

J'utilise tous les jours Linux que ce soit chez moi ou dans mon boulot et pour le coup, je suis bien d'accord avec Zenitram.

Il arrive parfois, pas souvent, d'avoir besoin d'un logiciel particulier dans une version spécifique non disponible dans la distro (le logiciel ou la version). Et dans ce cas là, ça peut être l'enfer...

Grong c'est quoi ? Je m'attendais à trouver la réponse dans la suite de la dépêche mais non!

Je suis l'un des développeurs de Wormux, et je peux te dire qu'on s'est arraché les cheveux pendant des heures pour faire un binaire 'standalone'.

Certaines librairies ne te permettent pas de faire un binaire statique (c'est le cas de libcurl). On compile donc un binaire dynamique, et on met toutes les librairies (libc, libc++, libsdl-xx et même le ld.so) dans un répertoire. Un petit script met en place le LD_LIBRARY_PATH, et c'est parti.

Et au final, ça juste marche pas. On a des problèmes de son : merci pulse audio dont les versions clients ne sont pas compatibles avec toutes les versions serveurs. Des problèmes d'affichage (absence de transparence) dans certains cas. Je soupçonne un problème de discussion entre le client X et le serveur X. Et on a dans certains cas des crashs lors de l'initialisation du réseau...

Donc non, des binaires statiques ou qui contiennent tout, ça ne marche pas pour l'ensemble des distributions linux.

Il faut bien voir que le schéma de numérotation est historique (et reste malgré les batailles pour le changer!)

Première version : 0.1. Puis viens la 0.2, la 0.3, la 0.4 a dû voir l'arrivée du son et d'un menu (je suis rentré dans le projet après la 0.3). La 0.4 était donc une version majeure avec de telles ajouts ;)

Ensuite, il y a une 0.5, version bien avancée qui utilisait Clanlib 0.6 et que haypo, développeur principal à l'époque, voulait numéroter 1.0. J'étais plutôt favorable, mais tout le monde n'était pas d'accord...

Plus tard, on décide de passer sur Clanlib 0.7 (version de développement mais recommandée par les développeurs de Clanlib), on sort une version 0.6... Même si certains voulaient sortir une 1.0, d'autres disaient : "Oui, mais y'a pas d'IA, y'a pas de réseau, y'a pas ceci, ...".

Passage à SDL suite aux déboires avec Clanlib -> Wormux 0.7

Les améliorations s'enchaînent mais rien d'aussi important qu'un portage : 0.7.1, 0.7.2, 0.7.4, ...

Le jeu en réseau commence à être mis en place par lodesi, chantier monstrueux. On décide que ce sera la version 0.8. Commence alors le cycle des alphas/betas (alpha1, beta1, jusqu'à 4). A chaque fois, le réseau s'améliore, mais péniblement et le jeu solo aussi. On décide de sortir une version dite "stable", en désactivant le réseau : Wormux 0.7.9. Ce numéro pour indiquer que ce sera la dernière version avant le jeu en réseau "stable". Là encore, certains criaient aux scandales lorsque quelqu'un évoquait la 1.0. "Comment, une 1.0 sans IA ??"

Après, un tel cycle, c'était déjà difficile de mettre à jour le 2ème numéro... Certains voulaient numéroter la version actuelle 0.8.6... Alors enlever le 0. ... T'imagine même pas les levées de bouclier qu'il peut y avoir quand on parle de numéro de versions :)

C'est beaucoup plus simple de rester dans une numérotation foireuse qui s'est créée historiquement, que d'en remettre une sur les railles!

Et je crois que ce n'est pas près de s'arranger pour Wormux si on change vraiment le moteur physique. Ça m'étonnerait qu'on sorte une version aussi stable de but en blanc, donc ça voudra dire réutiliser des numérotations avec un joli beta ou rc en suffixe...

Note cependant qu'on peut vouloir laisser ses enfants faire une partie en réseau local sans leur laisser l'accès internet.

Une autre possibilité serait pour le papa de laisser un serveur headless tourner en permanence (ou lancer au démarrage d'une des 2 machines, peu importe). Comme ça, c'est toujours la même adresse IP pour se connecter à la partie. Faudrait que je prenne le temps un jour de documenter comment lancer un serveur :/