Journal Les jeux arrivent sur la Freebox

Posté par  (site web personnel) .
Étiquettes : aucune
16
19
nov.
2009
Vieille arlésienne de plusieurs années, l'arrivée de jeux sur Freebox a enfin eu lieu, après de multiples délais, pré-annonces et fuites de plus en plus fréquentes et explicites. Alors, qu'y trouve-t-on, que peut-on faire avec ce matériel pas particulièrement prévu pour ça ? On peut répartir l'offre en deux grandes catégories :

- Moteurs et émulateurs, sans données de jeux ; certainement repris de l'univers open-source, la Freebox intègre maintenant les moteurs de Doom et Duke Nukem 3D, ainsi que des émulateurs Master System, Game Gear, Game Boy.

- Développements spécifiques, par Free, manifestement d'un niveau assez moyen ; on peut se demander à quel point ils sont inspirés de développements open-source.

- API JavaScript publique, baptisée Elixir, basée sur les EFL (Enlightenment Foundation Libraries) ; Free annonce l'ouverture prochaine d'un système de vente de jeux, a l'instar de l'Apple Store.

Free, comme toujours, surfe aux limites de la légalité :

En ce qui concerne les jeux à utiliser sur les moteurs et émulateurs, elle pointe bien sûr vers les quelques développements libres qui existent, sachant très bien que la plupart de leurs utilisateurs iront se fournir en copies illicites de jeux commerciaux (quand bien même vieux et oubliés).

Difficile de se prononcer en ce qui concerne les développements spécifiques. Y a-t-il eu reprise de code, dans quelles conditions ? On sait bien, notamment avec l'affaire du noyau Linux de la Freebox, que Free surfe également aux limites de la GPL.

Le plus intéressant, au final, est probablement l'API Elixir. L'obligation de développer en JavaScript risque d'être un facteur très limitant au niveau performance. C'est par contre une occasion de (re)découvrir ce langage, sans le handicap du DOM et des multiples variations/bugs entre implémentations.

Communiqué de presse Iliad :
http://www.iliad.fr/presse/2009/CP_191109.pdf

Quelques articles Freenews :

Lancement des jeux vidéo sur Freebox HD
http://www.freenews.fr/spip.php?article7313

Plus d’infos sur l’API des jeux Freebox, Elixir
http://www.freenews.fr/spip.php?article7317

Mini-tests des jeux du lancement
http://www.freenews.fr/spip.php?article7349

Site dédié : http://www.jeuxfreebox.fr/

  • # Freebox ?

    Posté par  (site web personnel) . Évalué à 1.

    Ce ne serait pas dans le décodeur, plutôt que dans la Freebox ?

    • [^] # Re: Freebox ?

      Posté par  . Évalué à 7.

      ce que tu appelles décodeur = Freebox HD
      le modem = Freebox

      par abus de langage, quand on parle de la Freebox, on englobe souvent les deux modules : modem et décodeur.

      en même temps, la Freebox HD ne fait pas que décodeur, donc c'est un peu réducteur de ta part aussi :-)

      par abus de langage, c'est bien dans la Freebox :-)
      précisément, c'est dans la Freebox HD.

      c'est la partie de la freebox qui a un disque dur, donc logique :-)

      • [^] # Re: Freebox ?

        Posté par  (site web personnel) . Évalué à 2.

        Parmi les deux boîtiers, le plus gros ordinateur, donc. :-)

        • [^] # Re: Freebox ?

          Posté par  . Évalué à 2.

          Oui, j'ai lu que dedans c'est un CPU MIPS, comme dans le Gdium...

          ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

          • [^] # Re: Freebox ?

            Posté par  . Évalué à 5.

            Oui, j'ai lu que dedans c'est un CPU MIPS, comme dans le Gdium...

            Pour être exact, c'est un sigma design SMP8634 qui embarque le jeux d'instructions MIPS.

            • [^] # Re: Freebox ?

              Posté par  (site web personnel) . Évalué à 3.

              Qui fait 250 Bogomips, le programme dispose de 32 Mo de RAM. C'est comparable à un pentium 75... sans fpu :)

              "La première sécurité est la liberté"

  • # Se documenter :-)

    Posté par  . Évalué à 8.

    Juste comme ca, en suivant les liens, tu peux atterrir sur :

    http://code.google.com/p/freebox-elixir/source/browse/#svn/t(...)

    Avec toutes les sources des jeux developpe en interne.

  • # A quoi ca sert ?

    Posté par  . Évalué à 6.

    Honnetement, qui va utiliser cette fonctionnalité ?

    A part le net, la tv et le téléphone, qui peut bien utiliser ces services, a part 3 geeks.

    Tous les services freebox sont mal fichus, mal finis, et peu utilisable.
    La VOD free est pathetique face a Canalplay ou TF1 vision, le telesites. on se demande a quoi ca sert, le partage de video perso, sans interet aussi...

    Ca sert juste a free a faire un communique de presse, mais l'interet est pas enorme...

    Je me demande si le dev interne pour 3 sous, autrefois utile, n'atteint pas aujourd'hui ses limites. Les produits meme s'ils fonctionnent bien et a bon tarifs souffrent de finition mediocre.
    Avec bientot la telephonie mobile... on verra bien ce que ca donnera !

    Mais un site web qui gere bien les authentifications, une freebox qui n'a pas besoin de rebooter pour appliquer de nouveaux settings, une interface de TV un peu plus travaillée graphiquement...

    • [^] # Re: A quoi ca sert ?

      Posté par  (site web personnel) . Évalué à -1.

      Bah, on n'a pas forcément besoin de ces services, mais au moins Free reste un fournisseur de connexion à Internet, pas au Minitel.

    • [^] # Re: A quoi ca sert ?

      Posté par  (site web personnel) . Évalué à 2.

      La VOD free est pathetique face a Canalplay ou TF1 vision, le telesites. on se demande a quoi ca sert, le partage de video perso, sans interet aussi...

      En ce qui me concerne, tous les fournisseurs sont égaux, pour la VoD : inutilisables.

      Canalplay, TF1 vision : verrouillé, pas lisible. Free : il faut un téléviseur, alors que je n'ai qu'un ordinateur.

      • [^] # Re: A quoi ca sert ?

        Posté par  . Évalué à 2.

        Free : il faut un téléviseur, alors que je n'ai qu'un ordinateur.

        J'ai un scoop pour toi: on peut brancher le boitier tele sur un ecran de pc.

        Sisi, par la magie de cables nommes "rca", hdmi" ou encore "hmdi to dvi" (ce dernier etant aussi connu sous le nom de dvi to hdmi), tiens toi bien: tu peux brancher le boitier sur autre chose qu'une tele!!

        • [^] # Re: A quoi ca sert ?

          Posté par  (site web personnel) . Évalué à 3.

          Oui, super l'ergonomie : pour les informations sur ma ligne, débrancher l'écran de mon ordinateur, le brancher sur le décodeur. Heureusement que mon ordinateur sait lire des flux vidéo, histoire que je ne puisse pas m'en servir !

          • [^] # Re: A quoi ca sert ?

            Posté par  . Évalué à 1.

            Heuuuuuuuuuuuu...

            T'es au courant que beaucoup d'ecrans ont plusieurs entrees (je m'etais trouve un 23" wide precisement pour ca, 250 euros, po cher)?
            Qu'un ampli sert precisement a faire le switch entre plusieurs sources sur un meme ecran?
            Les switchs KVM, ca te dit quelque chose?

            'fin la, tu me sideres, decreter la VOD de free nulle a chier parce que t'es pas foutu de brancher le boitier free sur ton moniteur, c'est fort de cafe quand meme...

            Cela dit, tu rates rien, la VOD de free est effectivement nulle, pas pour les raison que tu cites, mais parce que l'interface est pourrie, les fontes bavent comme c'est pas permis, la navigation est lente et lourdingue, la telecommande biscornue, les categories mal faites et aussi parce que je trouvais ca cher.

            Dommage pour les francais que netflix n'ait pas prevu de s'attaquer au vieux continent, ils ont un business model tres efficace et interessant pour le consommateur.

      • [^] # Re: A quoi ca sert ?

        Posté par  . Évalué à 3.

        > Free : il faut un téléviseur, alors que je n'ai qu'un ordinateur.

        C'est faux, il te suffit d'ajouter une entrée vidéo à ton ordinateur....

        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: A quoi ca sert ?

      Posté par  (site web personnel) . Évalué à 10.

      > une freebox qui n'a pas besoin de rebooter pour appliquer de nouveaux settings

      Ça, c'est un choix d'architecture, pas une limitation de dev interne à 3 sous.

      Pour le reste, c'est la culture d'entreprise Free, qui est aussi quelque part la culture Internet. On s'en fout de savoir si ça répond à un besoin fondamental de l'humanité, on bricole des trucs plus ou moins cool, on verra bien ce qui marche au final.

      • [^] # Re: A quoi ca sert ?

        Posté par  . Évalué à 2.

        > Pour le reste, c'est la culture d'entreprise Free, qui est aussi quelque part la culture Internet. On s'en fout de savoir si ça répond à un besoin fondamental de l'humanité, on bricole des trucs plus ou moins cool, on verra bien ce qui marche au final.

        et de menus détails comme les droits d'auteur et autres copyrights, merci, on sait

      • [^] # Re: A quoi ca sert ?

        Posté par  . Évalué à 0.

        Ça, c'est un choix d'architecture, pas une limitation de dev interne à 3 sous.

        Mon avis, c'est que c'est surtout une contrainte legale: ca empeche l'utilisateur d'utiliser la freebox, et donc a free d'etre coherent avec sa position "la freebosque est chez nous".
        C'est plus simple pour la freebosque de puller sa config quand elel redemarre que la pusher depuis les serveur de free a chaud.

    • [^] # Re: A quoi ca sert ?

      Posté par  (site web personnel) . Évalué à 4.

      le SDK permet de faire bien plus que de "simples jeux" ;-)
      Va voir les apis ...

      Certains sont déjà en train de plancher sur des applis P2P ...

      • [^] # Re: A quoi ca sert ?

        Posté par  . Évalué à 2.

        Et elle apparait avec quelle IP la freebox HD ? Ca doit pas etre compliqué de coder un proxy :)

  • # Performances javascript

    Posté par  . Évalué à 6.

    Avec le relancement de la guerre des navigateurs, les performances de javascript ne sont pas mauvaises poiur un langage interprété.

    Voici par exemple un benchmark entre python (version inconnue) et le javascript de v8 (le moteur javascript de chromium):

    http://shootout.alioth.debian.org/u64q/benchmark.php?test=al(...)

    Envoyé depuis mon lapin.

    • [^] # Re: Performances javascript

      Posté par  (site web personnel) . Évalué à 3.

      >>> Voici par exemple un benchmark entre python (version inconnue)

      Python 2.6.3

      trouvé ici : http://shootout.alioth.debian.org/u64q/benchmark.php?test=al(...)

      • [^] # Re: Performances javascript

        Posté par  (site web personnel) . Évalué à 3.

        A priori, il s'agit de tracemonkey le moteur utilisé.

        La lib C utilise au mieux le hard en dessous : un mips à 300Mhz, 32 Mo de ram dispo, un accélérateur 2D, une api réseau.

        "La première sécurité est la liberté"

    • [^] # Re: Performances javascript

      Posté par  (site web personnel) . Évalué à 2.

      > les performances de javascript ne sont pas mauvaises poiur un langage interprété

      Oui, sauf que pour autant que je sache, les interpréteurs JavaScript récents et performants le sont notamment parce qu'ils produisent du code machine, spécifique aux CPU supportés donc. Et a priori, il n'y a pas d'interpréteur haute performance qui cible les MIPS. Donc, ce ne peut être qu'un interpréteur « basique ».

      J'aimerais être démenti. :-)

      • [^] # Re: Performances javascript

        Posté par  . Évalué à 3.

        C'est le cas du moteur v8 de google. Mais il n'y a pas longtemps, les moteurs javascripts étaient déjà performants sans en arriver là.

        Peut-être que free a fait cette technique sur la freebox, peut-être pas.

        Envoyé depuis mon lapin.

      • [^] # Re: Performances javascript

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Pour tracemonkey (Mozilla), il ne cible en effet que ARM, PPC, Sparc, X64, et i386, si je ne me trompe pas. Je suppose que la compilation de tracemonkey sur d'autres architectures desactive le JIT.

        • [^] # Re: Performances javascript

          Posté par  . Évalué à 2.

          Il y a un certain nombre de probleme lie a tracemonkey. Tout d'abord quelque soit le backend, il ne supporte pas les algorithmes recursif. Ca va etre genant pour pas mal d'algo d'IA qui sont plus simple a ecrire de cette maniere. Ensuite, effectivement, il n'existe pas de backend MIPS 4KEc.

          Et tant que le premier point n'est pas regle, il n'est a mon avis pas prioritaire de porter tracemonkey sur MIPS. D'autant plus qu'il y a finalement pas mal de memoire de dispo et une approche avec des resultats precalcule ou de mettre en cache les resultats au fur et a mesure.

          • [^] # Re: Performances javascript

            Posté par  . Évalué à 1.

            Est-ce que tu pourrais m'en dire davantage sur le non-support de la récursivité ?
            Et est-ce que ça ne serait pas possible de récrire les algorithmes pour qu'ils utilisent des tail calls ( http://en.wikipedia.org/wiki/Tail_call ) ?

            • [^] # Re: Performances javascript

              Posté par  . Évalué à 1.

              Alors le Tail_Call, c'est en gros une optimisation qui permet de transformer une chaine d'appel recursif en une boucle. Il y a une economie de memoire (en diminuant la taille de la pile necessaire) et une economie de CPU (en remplacant des call par de simple jump). Cette optimisation peut beneficier au bytecode et il n'est pas necessaire d'avoir du JIT pour en beneficier. Par contre, il faut faire attention a la maniere dont on ecrit une fonction recursive, si on veut beneficier de cette optimsation (voir l'exemple de la fonction factorisation).

              Maintenant TraceMonkey fonctionne en sauvegardant une «Trace» de tous le bytecode genere. Lorsqu'il detecte dans cette trace une «zone chaude», il va passer le JIT dessus. Le probleme vient de la detection des «zone chaude» a priori qui ne se fait actuellement que si il y a une boucle explicite. Avec l'optimisation des Tail Call, il serait peut etre possible de detecter certaines «zone chaude», mais je doute que ce soit la bonne solution, etant donnee la difficulte a ecrire des fonctions tail recursive.

          • [^] # Re: Performances javascript

            Posté par  (site web personnel, Mastodon) . Évalué à 2.

            le tracemonkey du trunk (Firefox 3.7, peut etre 3.6, j'ai pas suivi si ça avait été backporté sur la branche 3.6) supporte maintenant les optimisations JIT sur les appels récursifs.

            ça supporte tellement bien qu'une des demos de Paul Rouget est à revoir : http://people.mozilla.com/~prouget/demos/worker_and_simulate(...)

            Cette demo fait du calcul recursif, et lance 6 calculs en même temps. Elle était là pour montrer la puissance des webworker, et montrer la différence entre faire ces calculs "classiquement" (dans le meme thread) ou utiliser les web worker (qui permettent en js de faire des choses dans des threads).

            Avec firefox 3.5, le calcul dans le meme thread (sans worker) fige totalement l'interface de firefox pendant plusieurs secondes, puisque la page web est exécutée dans le même thread que l'interface (on voit d'ailleurs la png animée s'arreter). Avec une nightly de firefox, le calcul se fait en à peine 2 secondes, voir quasi instantanné, sans l'aide des web worker.

            Bref, TraceMonkey ça poutre aussi bien que V8 :-)

            • [^] # Re: Performances javascript

              Posté par  . Évalué à 1.

              Ca doit etre tres tres recent, car au 1er septembre, ca n'etait pas encore resolu : http://www.bailopan.net/blog/?p=546

              De plus, il y a encore des conflits entre JIT et thread. Le fait que l'interface ne fige pas, ca veut peut-etre juste dire que le calcul est execute dans un autre thread que celui qui s'occupe de l'interface. D'apres ce que j'ai lu, il y a encore quelques jours sur la ML de SpiderMonkey, l'utilisation des threads desactivaient le JIT.

    • [^] # Re: Performances javascript

      Posté par  (site web personnel) . Évalué à 1.

      Si, les performances restent mauvaises en tant que langage interprété. C'est pour ça que V8 en fait un langage compilé :)

      • [^] # Re: Performances javascript

        Posté par  . Évalué à 2.

        Il compile à la volée, tu peut toujours jouer avec eval. Je ne sais pas où s'arrête la définition de langage interprété.

        Envoyé depuis mon lapin.

        • [^] # Re: Performances javascript

          Posté par  . Évalué à 2.

          Je ne sais pas où s'arrête la définition de langage interprété.

          Entièrement d'accord. Je suis de plus en plus prudent en ce qui concerne les interpréteurs actuellement ; j'ai l'impression que beaucoup de gens ont des représentations erronées ou en tout cas simpliste de leur fonctionnement. Les interpréteurs compilent les sources, en font une représentation binaire, et ensuite l'exécute via une machine virtuelle. On n'est plus très loin de Java et de son bytecode, la seule différence étant qu'on ne sauve pas le bytecode dans un fichier (au passage ça permet d'avoir un bytecode et une machine virtuelle peut-être plus proche de la machine hard sous-jacente).

          Ici tous les traitements graphiques et la gestion d'évènements sont dévolues à des lib optimisées, il y a peu à parier que les perfs globales ne seront pas impactées par le fait que la "glue" est en Javascript. Tout autre langage aurait pu convenir.
          Par contre JavaScript offre des facilités de programmations qui risquent de surprendre ceux qui viennent de langages plus classique (closures...)

          • [^] # Re: Performances javascript

            Posté par  (site web personnel) . Évalué à 3.

            > la seule différence étant qu'on ne sauve pas le bytecode dans un fichier

            Ce n'est même pas forcément vrai. Python le sauvegarde dans des fichiers .pyc et/ou .pyo par exemple.

            > (au passage ça permet d'avoir un bytecode et une machine virtuelle peut-être plus proche de la machine hard sous-jacente)

            Non pas forcément, il peut au contraire y avoir des opcodes assez distant de la réalité matérielle, mais qui représentent des opérations atomiques assez puissantes et fréquentes dans le langage. Tout l'art de la création d'un bytecode est justement de trouver ce juste milieu.

        • [^] # Re: Performances javascript

          Posté par  (site web personnel) . Évalué à 3.

          Ben en tout cas, V8 compile le code javascript avant de l'exécuter : ce n'est plus de l'interprétation.
          Bref dire que les perfs d'un langage interprété deviennent intéressantes est complètement faux puisque le gain de perf vient justement de la compilation en lieu et place de l'interprétation.
          Pour eval, je ne vois pas en quoi le process serait différent : V8 peut compiler son contenu en live...

    • [^] # Re: Performances javascript

      Posté par  (site web personnel) . Évalué à 4.

      En même temps, ici uniquement le moteur javascript est présent, pas le navigateur.

      L'affichage se fait avec des bindings vers les EFL, donc trés peu de calculs en javascript, seulement le comportement, le reste est fait en natif.

      Elixir est bien foutu (et open source !), et présente une belle api javascript vers sqlite, les fichiers, le son de SDL et les ELF.

      • [^] # Re: Performances javascript

        Posté par  . Évalué à 1.

        Elixir est peut être bien foutu, mais je vois pas beaucoup de monde écrire son interface de A à Z dans une collection Edje. Peut être faudrai-t-il fournir Elementary (même s'il n'est pas forcement stable à 100%), plutôt que de laisser tout les développeurs réinventer la roue ...

        Mais bon, si on parle de jeux, l'interface ne doit pas être bien compliquée.

      • [^] # Re: Performances javascript

        Posté par  (site web personnel) . Évalué à 2.

        > L'affichage se fait avec des bindings vers les EFL, donc trés peu de calculs en javascript, seulement le comportement, le reste est fait en natif.

        Ben oui, mais ça peut ne pas être négligeable. Par exemple le démineur fourni, il ben il rame très visiblement quand il s'agit de révéler une série de cases vides, ou de valider la victoire. De l'ordre d'une ou deux secondes pour valider une grille de démineur... c'est quand même beaucoup !

        (Surtout quand on voit que de leur côté Doom et les émulateurs tournent sans souci de performance.)

        • [^] # Re: Performances javascript

          Posté par  (site web personnel) . Évalué à 2.

          Eux tourne en C natif, ce qu'ils ne peuvent faire pour les autres jeux pour des raisons de sécurité j'imagine.

          "La première sécurité est la liberté"

          • [^] # Re: Performances javascript

            Posté par  . Évalué à 4.

            La solution pour faire des jeux, du coup, c'est peut être de les développer pour une des consoles émulées :)

        • [^] # Re: Performances javascript

          Posté par  (site web personnel) . Évalué à 3.

          Justement tu mets le doigts sur le genre d'opérations qui est lente en javascript, le calcul !

          Si on se cantone à juste orchestrer l'affichage et éviter de faire de trop gros calculs, ou les faire à l'avance comme pour DOOM, ça ne pose pas tant de problèmes que ça !

          L'autre avantage est qu'ils vont sûrement proposer d'autres bindings plus tard, et le champ est ouvert sur ce coté la !

        • [^] # Re: Performances javascript

          Posté par  (site web personnel) . Évalué à 1.

          Sauf que les mini jeux ne sont pas trop optimisé.

          "La première sécurité est la liberté"

  • # Un problème: le joystick.

    Posté par  . Évalué à 2.

    Oui, mais... il y a apparemment un gros problème. D'après ce que j'ai lu, la télécommande sert de joystick, et la liaison avec la freebox est en infrarouge (comme toutes les télécommandes).
    Ce qui induit une latence rendant difficile le contrôle des jeux; cela oblige à anticiper les mouvements. Anticiper au morpion, c'est fastoche; pour un doom-like, c'est plus coton...

    • [^] # Re: Un problème: le joystick.

      Posté par  (site web personnel) . Évalué à 2.

      D'une part, la télécommande est étonnamment réactive pour de l'infrarouge (et même presque trop, dans Doom), et d'autre part en effet, on souffre du drop de certains inputs, ou d'une mauvaise pression sur la croix directionnelle, assez sensible.

      Ceci dit, le problème se pose plus au niveau des jeux JavaScript qu'au niveau de Doom.

      Par ailleurs, la Freebox supporte les périphériques HID, donc on peut brancher un paddle ou une souris en USB, et jouer ainsi (j'ai pas pris le temps de tester ça hier). Je n'ai pas de nouvelles du clavier, mais il n'y a pas de raison qu'il ne soit pas supportable.

      • [^] # Re: Un problème: le joystick.

        Posté par  . Évalué à 2.

        "télécommande est étonnamment réactive pour de l'infrarouge (et même presque trop, dans Doom)"
        Ce n'est pas du tout l'avis de NoFrag (ni clubic) : http://nofrag.com/2009/nov/19/32967/ .

        Regardez la vidéo de doom sur freebox, ça vaut vraiment le coup d'oeil de voir comment n'importe quel joueur parait complètement nul, la faute à une maniabilité complètement nulle.

        • [^] # Re: Un problème: le joystick.

          Posté par  (site web personnel) . Évalué à 1.

          Tu ne peux pas comparer l'efficacité d'un pad avec celui d'une souris. La sourise gagne toujours.

          De plus, la télécommande a une limitation pour des raisons d'économie d'énergie j'imagine : l'info part uniquement toutes les 100 ms. Donc, c'est peu réactif.

          La solution est de brancher un pad usb.

          "La première sécurité est la liberté"

    • [^] # Re: Un problème: le joystick.

      Posté par  . Évalué à 2.

      En même temps, même sans infrarouge, un doom-like au joystick, ça ne mérite pas le titre doom-like.

      • [^] # Re: Un problème: le joystick.

        Posté par  . Évalué à 1.

        C'est vrai, mais à l'époque de Doom, c'était jouable. La "faute" au système de visée qui ne prenait pas en compte le haut et le bas : on tire tout droit, et l'ennemi qui est en l'air se prend la balle.

        D'ailleurs les FPS de l'époque étaient assez chiants à configurer en clavier/souris à la façon de ceux de maintenant.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.