Elixir : l’API des jeux sur Freebox

13

On le sait désormais, n’importe qui peut concevoir ses propres jeux pour la Freebox. C’est un véritable atout qui permettra sans doute de voir émerger quelques perles, avec le talent des développeurs de la communauté.

La conception d’un jeu Freebox passe par une API conçue par les développeurs Freebox, portant le nom d’Elixir. Celle-ci repose lourdement sur les EFL, alias Enlightenment Foundation Libraries, contenues dans la Freebox. Il s’agit de librairies graphiques, utilisées à la base pour Enlightenment, un gestionnaire de fenêtres Linux. Parmi les exemples les plus célèbres de programmes exploitant les EFL, on pourra citer OpenMoko (système d’exploitation libre pour téléphones portables), Canola2 (interface pour tablettes tactiles Nokia) ou GeeXboX (Media Center libre).

Elixir consiste en un binding Javascript pour ces EFL. Cette solution sert de « sécurité » à Free (en limitant notamment l’accès à certaines fonctions des librairies). Les développeurs devront donc se familiariser avec cette manière de travailler, même si les différences avec l’API en C restent minimes selon les développeurs Freebox.

La page officielle d’Elixir sur Google Code (lien) contient toute la documentation nécessaire sur l’API sous forme de wiki, mais également quelques exemples d’utilisation avec l’EFL Edje qui gère toute la partie « effets graphiques / animation ».

N’hésitez pas à vous rendre sur JeuxFreebox.fr et ses forums pour toute l’actualité des développeurs !

Site officiel : http://elixir.freebox.fr

Partager

A propos de l'auteur

[Responsable de la rédaction]
Sévit également sur Café Gaming et Point de vue social.

13 commentaires

  1. Le SDK étant la seule partie qui m'intéressait réellement dans cette "grande annonce", j'attendais avec anxiété de voir ce qu'il aurait réellement "dans le ventre": 1- concernant les possibilités graphiques elle-même, les EFL sont plutôt une bonne chose et me donne un à priori positif (qu'il faudra confirmer avec des tests concrets). 2- par contre, l'utilisation du Javascript n'augure absolument rien de bon pour l'étendue des possibilités que va offrir ce SDK: si le Javascript est effectivement interprété (et pas compilé), il sera suffisant pour assurer le développement de quelques jeux et/ou applications qui ne nécessiteront absolument aucune puissance (sudoku, jeu de cartes, majjhong, ...) mais va très rapidement montrer ses limites dès que le jeux aura besoin d'un minimum de calculs temps réel (un peu de physique très basique) . Bien entendu, seuls des tests (que je ne tarderai pas à faire personellement) permettront de se rendre concrètement compte de l'étendue des possibilités et de la puissance disponible du bazar. Mais d'emblée, quel dommage de ne pas avoir opté pour un autre langage bien plus prometteur comme un binding en Java par exemple : cela n'aurait en rien remis en cause les possibilités de 'sécuriser' la box, mais ça aurait non seulement eu de bien meilleures performances (même que du JScript compilé) et ça aurait permis de réutiliser les millions de librairies Java déjà disponibles. My 2 cents.

  2. Le javascript est utilisé en binding, il sert seulement à limiter le nombre de fonctions de l'API disponibles. Les fonctions elles-mêmes sont exécutées par des librairies binaires programmées en C! Bref, ça ne pose aucun problème pour les performances. Exemple de jeu fait suivant le même principe : FrozenBubble (binding perl->SDL).

  3. yoann007 a écrit :
    Permissif mais complexe à comprendre. Ca se résume un peu comme ça à mon avis.
    J'ai pas compris le sens de ta phrase, tu pourrais détailler ?
    Zézinho a écrit :
    Le javascript est utilisé en binding, il sert seulement à limiter le nombre de fonctions de l'API disponibles. Les fonctions elles-mêmes sont exécutées par des librairies binaires programmées en C! Bref, ça ne pose aucun problème pour les performances.
    On est d'accord: les fonction de l'API sont exécutées en natif, donc pour tout ce qui touche notamment au graphisme, il ne devrait pas y avoir de soucis MAIS comme précisé dans mon premier post, le souci se posera pour tout le code qui ne fait pas appel à l'API des EFL qui grosso modo comprendra tout ce que le développeur codera avec ses petits doigts. Et ça représente notamment tout le moteur du jeu. Donc ça posera des limites à partir du moment où tu voudras gérer de la physique où tout autre besoin en calculs 'temps réel' pour ton jeu comme par exemple si tu veux faire: - un équivalent de 'world of goo' - un moteur 'physique' avancé pour le comportement des voitures dans un jeu automobile - la gestion des données réseau pour du jeu d'action en multijoueur online (plusieurs dizaines de paquets reçus par client et par seconde) - etc... Bref, à partir du moment où tu devras faire du calcul un peu plus lourd en 'temps-réel' ... là le Javascript pourra peut-être être le facteur limitant. A nouveau, cet aspect technique est à confronter à la réalité avec des tests faits en 'grandeur nature' ; tant que ceux-ci ne seront pas menés avec des exemples représentatifs, on ne pourra guère conclure quoi que ce soit. Rien qu'entre du code javascript interprété ou le même javascript compilé avant d'être exécuté, il y a déjà un gouffre (et j'espère ardemment que les ingé R&D de Free y ont pensé et ont opté pour la seconde solution). Pour continuer dans les questions, je suis curieux de voir ce que le framework autorisera (ou pas) en matière de réseau, notamment: - la possibilité de faire de la requête 'http' simple => permettra de faire à minima du jeu en tour par tour. - la possibilité d'utiliser directement des sockets TCP => permettra d'envisager des petits jeux d'actions en réseau - la possibilité d'utiliser directement des sockets UDP => ça ouvre un peu plus l'ensemble du champ des possibles, avec même des jeux d'action à très fortes contraintes temps-réel (FPS-like, ...).

  4. bandi a écrit :
    Y'a t'il moyen de faire des jeux en reseau entre plusieurs Freebox ? Comme par exemple un Tetris en battle ?
    L'API permet d'ouvrir des communications en HTTP mais on manque encore un peu de détails sur ce sujet. Voir la légitime question de nouknouk à ce sujet sur le forum Jeux Freebox : http://www.jeuxfreebox.fr/forum/topic.php?id=6 (restée sans réponse pour l'instant)

  5. j'ai eu un début de réponse à ce propos, par Watchwolf sur PC-Inpact:

    le commit sur elixir[/url]) TCP/UDP et il y a ecore_download (qui utilise ecore_con) qui propose le http/ftp dans une optique de téléchargement d'un fichier (zip, html, xml ...). Il y a également 'eet' qui permet de sérialiser une structure et la sauver dans un fichier ou l'envoyer par le réseau (avec gestion de la compression et du chiffrement)
    Par contre, pas de réponse pour la question subsidiaire (hautement technique, mais importante) : quid de la possibilité de désactiver l'algo de Nagle, aussi connu comme le flag 'TCP_NODELAY' ? C'est indispensable pour les applis réseau et jeux temps-réel si on veut utiliser le TCP.

  6. Réagir sur le forum