Julien Jorge a écrit 526 commentaires

Avec une version de colout clonée depuis GitHub ce matin, j'ai une erreur qui m'empêche de voir la pile d'appel :

Program received signal SIGABRT, Aborted.
0x00007ffff5e7abb9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: Aucun fichier ou dossier de ce type.
(gdb) where
[colout] ERROR: unknown color: cpp
cat: erreur d'écriture: Relais brisé (pipe)

Une idée pour résoudre ce petit souci ?

Je vois bien ce que tu fais devnewton ; sous couvert de trolls tu veux surtout nous montrer ton dernier jeu ;) Et bien j'ai testé et je dois dire que hormis une petit problème de recherche d'assets vite corrigé, le jeu est… waw ! C'est complètement différent de tout ce qu'on a pu voir jusqu'à maintenant. Bien que légèrement répétitif au début, on se prend vite au jeu et on se laisse entraîner par le rythme. C'est simple, sobre et efficace. À quand une version Apple Watch ?

Tu peux passer Plee the Bear en version 0.7.0 sortie il y a quelques mois :)

Pour ma part c'est beaucoup pour l'exercice : pratiquer, m'entraîner, découvrir et m'améliorer. J'essaie aussi de produire autre chose que du code, comme des sprites ou de la musique, et jusque là j'ai plus souvent lancé des projets libres que contribué à des projets tiers.

À ce sujet, je cherche un jeu libre auquel contribuer graphiquement, de préférence en dehors des styles FPS et stratégie. Des idées ?

Bon finalement j'ai trouvé. Pour ceux qui se posent aussi la question, il s'agit de la nouvelle syntaxe C++11 de déclaration de fonctions, où le type de retour est indiqué après la flèche et le nom est précédé du mot clé auto.

Ici la déclaration de G::f est équivalente à

class G {
public:
  void f() {
    // …
  }
};

Comme le type de retour (nommé trailing return type) est indiqué après la fonction, il est interprété dans le contexte de la fonction. Par exemple (inspiré de cette source), si j'écris

class C {
public:
  enum E { a, b, c };

  E f();
  auto g() -> E;
};

Je dois implémenter C::f en préfixant le type de retour avec le nom de la classe :

C::E C::f() {
  // …
}

Tandis que la nouvelle syntaxe m'épargne ce préfixe pour C::g :

auto C::g() -> E {
  // …
}

Ici le type de retour est bien C::E, c'est à dire E interprété dans le contexte de C.

C'est super car j'ai économisé l'écriture de C:: au prix de l'écriture de auto -> ! Je ne me suis pas fait avoir…

En fait l'intérêt est surtout lié à l'arrivée de decltype. On peut ainsi déclarer le type de retour en fonction des entités apparaissant dans la signature de la fonction, comme dans l'exemple suivant :

template<class T, class U>
auto add(T t, U u) -> decltype(t + u);

Ici la fonction add retourne une valeur du même type que le résultat de operator+ sur les paramètres. Si T et U sont int, alors le type de retour est int ; si T est int et U est double, le type de retour est double.

Une troisième source sur le sujet.

Dans la présentation sur bounded::integer, il y a une classe dont la syntaxe des fonctions m'étonne (classe Goblin, slide 25). Ça ressemble à cela :

class G {
public:
  auto f() -> void {
    ++m_h;
  }

private:
  int m_h;
};

Quelqu'un peut-il m'expliquer la déclaration de G::f ? Ça ressemble à la syntaxe des lambda avec une déduction automatique du type de f. Je pensais que ça serait une variable de type fonction nommée f mais GCC n'est pas d'accord.

On a vendu un peu plus de 10 exemplaires d'Andy's Super Great Park et 3 exemplaires de Newton Adventure. Pas de quoi faire des stats :(

Sur les deux derniers mois, la version d'ASGP sur Android (gratuite) a environ 40 nouveaux joueurs par jours.

Autre retours, sur une Fedora 20 x86_64 et en utilisant les librairies fournis par le système (eg. après un rm lib/*) le binaire ne fonctionne pas si l'utilisateur n'a pas la version i686 de la libGL.so.1 spécifique à chaque driver.

J'ai mis en ligne une version 64 bits de l'archive. Pourrais-tu tester si cela fonctionne sur la Fedora x86_64 (éventuellement après le rm lib/* ?

Mmh… la tâche sur OpenFunding me semble tout à fait accomplie avec cette nouvelle version. En fait je suis obligé de la fermer (la tâche) pour pouvoir faire valider son accomplissement par les utilisateurs.

J'ai une autre tâche en attente, qui consiste en fait à réaliser les trois niveaux suivants. Le coût est bien plus grand que la première tâche, qui n'avait même pas reçu la moitié de la somme prévue, donc je dois trouver une autre façon de l'aborder si je veux pouvoir la faire financer.

Merci :)

En appuyant sur F2 pendant le jeu tu pourras voir le nombre d'images et d'itérations de la boucle de jeu par seconde. Si tout va bien ils doivent être à 66 tous les deux.

Nous avons quelques artefacts graphiques parfois (des sprites qui tremblent) et il y a aussi un petit saut de mouvement de temps en temps, qui se voient surtout quand le perso court. Est-ce que ça correspond à ce que tu as ?

Peux-tu donner plus de détails sur l'erreur ? Je pense qu'elle vient du fait d'une construction non « release ». Je n'ai pas eu le souci avec une construction release comme suit :

tar xf plee-the-bear_0.7.0-light.tar.gz
mkdir build
cd build
cmake ../plee-the-bear-0.7.0-light/ -DCMAKE_BUILD_TYPE=release -DCMAKE_INSTALL_PREFIX=/usr
make
sudo make install
plee-the-bear

Le make install est important, sinon le jeu ne sais pas trouver ses données. Pour les constructions de développement il s'attend à les trouver dans le dossier source, et du coup il faut effectivement appeler cmake . dans le source.

Bon je ne retrouve pas l'article qui dit de faire des zip plutôt que des installateurs pour communiquer avec la presse… Tout ce que je peux te proposer c'est ce sondage dans les forums de TIGSource. La tendance est celle relevée dans les autres commentaires : les gens qui ont un minimum de niveau technique veulent des zip, pour le reste il faut un installateur.

Merci pour le retour ! J'ai remplacé l'archive en ligne en ajoutant cette bibliothèque et deux autres qui manquaient aussi.

J'avais oublié de donner les droits de lecture à Apache sur les fichiers… C'est corrigé, merci !

Est-ce que ça fonctionne mieux si tu enlèves libX11.so.6 du dossier lib ? Et en virant tout le dossier lib ?

Je ne connaissais pas ! Ça a l'air effectivement pratique. Connais-tu des projets qui l'utilisent ?

Effectivement c'est un peu lourd de transporter toutes les bibliothèques, et je n'ai pas essayé de faire dans la finesse : quasiment toutes celles que je n'ai pas pu lier statiquement sont dans le dossier lib… Il y en a certainement à supprimer.

J'ai entendu beaucoup de bien d'OBS et j'aimerais bien prendre le temps de l'essayer à l'occasion. Un élément qui m'inquiète est dans la gestion des dépendances car j'utilise la SDL2 et libclaw qui ne sont pas toujours disponibles dans les distributions.

Pour le build Windows il s'avère que je faisais des installateurs pour les versions précédentes, mais j'ai appris depuis qu'il était plus efficace de faire un zip pour minimiser les actions de l'utilisateur. Il semblerait que plus il y a de clics entre le téléchargement et le lancement du jeu, moins les gens testent effectivement. C'est pour ça que j'ai opté pour le zip cette fois ci.

Suite à ton message, j'ai testé rapidement l'autonomie en ne faisant rien sous les deux systèmes. J'ai désactivé le blocage de la charge de batterie à 80% dans le bios ainsi que la mise en veille automatique et j'ai effectué une charge complète. J'ai ensuite démarré sur batterie sous Windows 7 et sous Ubuntu 13.10 avec Gnome 3. Dans les deux cas j'ouvre une session puis je ne fais plus rien jusqu'à extinction.

La mise en veille automatique était désactivée, seule la luminosité de l'écran baissait après quelques secondes d'inactivité. En dehors de ça je n'ai rien fait de particulier (bluetooth et wifi étaient allumés sous Linux, je n'ai pas vérifié sous Windows). La batterie de la zone de notification sous Windows indiquait bien que le mode économie d'énergie était actif.

Bilan : 5 h 30 sous Windows et 4 h 30 sous Linux.

Je n'ai pas fait de mesure sérieuse sous Windows mais je crois que c'est du même ordre. J'avais juste laissé l'ordi en idle 20-30 minutes puis j'ai regardé l'autonomie restante. Ça donnait un total un peu inférieur à 4 heures, de souvenir.

Avec la carte éteinte sous Linux, je n'ai pas fait de mesure sérieuse non plus. Je sais juste que je peux l'utiliser normalement (surf sur le web, developement, compilations…) pendant facilement 3 heures.

J'ai aussi eu de gros problèmes de batterie pendant longtemps, et j'ai récemment trouvé un contournement grâce à aux forums de LinuxFr.org¹. Le problème était que l'ordi a une sorte de carte graphique hybride ATI/Intel dont les deux parties étaient actives simultanément. Pour vérifier, tape lspci dans un terminal et compte le nombre de lignes contenant « VGA compatible controller ». Si tu en as plus d'une, c'est gagné.

Le contournement consiste à éteindre la partie ATI, ce qui m'a donné une autonomie de plus de 3 h contre 1 h 20 initialement.

¹ Les forums servent pour demander de l'aide, poser des questions diverses et variées, tandis que les journaux sont destinés aux discussions et aux informations qui n'auraient pas leur place en dépêches. [ref] ;)

Aah merci :) J'ai enfin une durée correcte d'utilisation sur batterie !

Ce qui est décrit dans le wiki d'ArchLinux est quasiment fait par défaut sous Ubuntu. Il suffit alors de désactiver la carte ATI en tapant :

# echo OFF > /sys/kernel/debug/vgaswitcheroo/switch

J'ai mis cela dans mon /etc/rc.local et je peux enfin rester sur batterie plus de 3 heures.

Bon en fait c'est peut-être lié. Quand j'enlève le pilote intel et que je laisse le pilote ATI, j'ai un OpenGL bizarre :

$ glxinfo | grep OpenGL
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.3, 128 bits)
…

Ça a l'air d'être la cause des montées en fréquence du CPU. Finalement pour l'instant j'ai les meilleures performances en supprimant le pilote radeon et en utilisant intel. C'est triste.

Pas ici. Le pilote radeon est bien là pour faire l'accélération. S'il n'y en avait pas, Gnome Shell ne se lancerait pas.

Je confirme qu'en ayant supprimé le pilote intel, et donc en utilisant uniquement le pilote libre radeon, j'ai aussi une autonomie de deux heures sur batterie. C'est déjà mieux.

Je vais tenter de mettre le power_profile à low comme indiqué plus haut, pour voir si ça s'améliore encore.

J'ai aussi l'impression d'avoir des problèmes avec Gnome Shell maintenant. Lorsque je lance le moniteur système il me mange 50% de chaque CPU (top confirme que gnome-shell est à 200%, contre 2% avec rien).