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 ?
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, ...).