Le HTML5 va-t-il révolutionner l’industrie vidéoludique ?

Chez Epic Games, on y croit dur comme fer

Le 02 avril 2013 à 14h50

3 min

Société numérique

Société

Interrogé par nos confrères de Gamasutra, Tim Sweeney, développeur de l'Unreal Engine 4, et Mark Rein, vice-président d'Epic Games, se sont confiés au sujet de leur nouveau moteur de jeu, et de sa compatibilité avec le HTML5. Selon eux, c'est ce dernier point qui fera son succès, non sans bousculer les habitudes des studios.

Démonstration de l'Unreal Engine 4 lors de la GDC 2013

Epic Games mise tout sur le HTML5

Mark Rein, le vice-président d'Epic Games et Tim Sweeney, développeur de l'Unreal Engine 4, se sont longuement exprimés au sujet de leur nouveau moteur et tout particulièrement de son support du HTML5 qui devrait permettre de faciliter le portage des jeux. En effet, il suffirait que la plateforme visée dispose d'un navigateur compatible pour que le titre fonctionne.

« [Le HTML5] fait évoluer le web en une plateforme. Tout comme Sony et Microsoft ont des plateformes, le web en devient une, et si vous voulez faire et distribuer un jeu, vous pouvez le faire marcher sur plusieurs navigateurs web compatibles et avoir une super expérience. C'est la fin des pilotes, des installations et tous les trucs bizarres liés au développement classique », explique Tim Sweeney.

Le grand changement apporté par le HTML5, est selon le développeur sa capacité à être déployé rapidement. « Vous pouvez avoir des graphismes de classe mondiale dans n'importe quel navigateur, pour des jeux, des outils ou quoi que ce soit d'autre. Et ce n'est pas fait avec un langage biscornu comme JavaScript. On fait du C++ pur, le même code que l'on utilise pour d'autres plateformes, et il est seulement compilé en HTML5 et JavaScript pour l'environnement web », affirme le développeur.

Les constructeurs de consoles vont-ils apprécier ?

Si les studios pourront très facilement créer des jeux fonctionnant sur toutes les plateformes, que restera t-til aux consoles de jeu ? Les joueurs auront-ils le réflexe d'utiliser le navigateur de leur PlayStation ou de leur Xbox pour jouer, ou se tourneront-ils vers les PC et les tablettes, bien plus adaptées à la navigation sur le web ? Ce changement pourrait aussi être le théâtre d'une nouvelle lutte entre les navigateurs, afin de déterminer lequel est le plus efficace pour lancer des jeux.

Les studios indépendants pourraient aussi y trouver leur compte, puisqu'il leur suffirait que les consoles embarquent un navigateur compatible pour s'affranchir des limites imposées par les stores de chaque console. Tim Sweeney s'en inquiète. « C'est une source de tensions à venir. Il y a une grande compétition entre les différents navigateurs pour les rendre les plus compatibles possible avec les standards, mais quand vous combinez cela avec les propriétaires de plateformes qui veulent prendre leur commission sur les ventes, il y a là un motif économique à vouloir résister à la standardisation ».

Sans forcément parler de studios indépendants, les éditeurs devraient aussi pouvoir en profiter pour faciliter les portages de leurs titres, vu qu'il serait possible de toucher un grand nombre de supports avec une seule version du jeu. On se posera seulement la question de la qualité des graphismes qui, dans un tel cas, sera certainement déterminée par la puissance de la machine la moins performante.

Commentaires (82)

CryoGen

Le 02/04/2013 à 16h09

brazomyna a écrit :

Sauf que les frameworks qui promettent le Saint Graal de l’uniformisation des plateformes, c’est pas la première fois qu’on essaie de le vendre. Et c’est pas pour rien qu’à chaque fois ça ne dépasse pas la bonne intention (au mieux) ou la bullshit marketing (au pire).

Les middleware ca existent, qui ne ne connait pas RenderWare ? Bien utilisé pour les jeux sous consoles et PC tirant les fonctionnalités vers le bas (qui a dit GTA " />)

Khalev

Le 02/04/2013 à 16h11

flagos_ a écrit :

Avec asm.js, Mozillaparle effectivement de performances approchantes au code natif en écrivant à partir du c++ et en transcodant vers du html5 + js.

Si les performances sont bien la, on peut effectivement anticiper qu’il s’agit de la prochaine plateforme de développement (et tant mieux !)

Avec asm.js on parle juste de temps d’exécution 2 fois plus long. Rien de bien méchant : On est juste en retard de 18 mois selon la loi de Moore.

C’est mieux que les 10 à 20 fois qu’on observe quand on n’utilise pas asm.js

Et ce n’est que le début!

Khalev

Le 02/04/2013 à 16h24

brazomyna a écrit :

Sauf que si j’ai bien compris, leur bouzin n’est ni plus ni moins que la création d’une sorte d’assembleur basé sur un subset du JS. Dit autrement, un bytecode avec des bases communes au JS. Dit autrement … ben une machine virtuelle à la Java intégrée dans le browser.

Sauf que ça reste compatible avec n’importe quel moteur JS. Au prix d’un différence de performances

gundz

Le 02/04/2013 à 16h45

CryoGen a écrit :

Les middleware ca existent, qui ne ne connait pas RenderWare ? Bien utilisé pour les jeux sous consoles et PC tirant les fonctionnalités vers le bas (qui a dit GTA " />)

GTA ? Meuh non c’est juste Rockstar qui code avec les pieds, je connais pas un seul de leur jeu qui soit pas sortis bourré de bug

Sinon ça reste à voir, mais bon quand je vois les performances cacastrophiques de certaines interface html5+ajax pas trop optimisé, alors j’imagine même le truc sur un moteur comme celui la…

linconnu

Le 02/04/2013 à 17h14

En HTML il y aura forcement une baisse énorme de performance car c’est un langage interprété pas compilé.

kwak-kwak

Le 02/04/2013 à 17h34

Le HTML5 va-t-il révolutionner l’industrie vidéoludique ?

Non, juste remplacer le flash.

hansi

Le 02/04/2013 à 17h36

Même si l’article n’est pas clair, la récente annonce de Mozilla en dit long sur les progrès en cours.

Le navigateur est en train de devenir le couteau suisse, à la fois côté applications métiers clients, en rendant les logiciels indépendants de la plate-forme, et à la côté gamer, en uniformisant une fois pour toute les développements (il était bien temps…).

Quand à ceux qui s’imaginent qu’il pourront facilement porter leurs applis existantes en version web, je leur souhaite bien du plaisir. Les spécificités et les contraintes d’un navigateur n’ont rien à voir avec celles d’un framework de bas niveau. Et à ce niveau là, j’ai bien peur que beaucoup n’aient pas encore compris que la roue tourne.

cendrev3

Le 02/04/2013 à 17h40

Pour ceux aussi qui doutent sur les performances du JS, c’est le langage interprété le plus rapide actuellement (le marche des navigateur est le plus concurrentiel de l’informatique).

Et les performances du JS en général sont très proches du C (je parle pas du DOM qui est plus lent lui), regardez nodejs pour vous faire une idée de la vitesse a laquelle on exécute du JS aujourd’hui.

HarmattanBlow

Le 02/04/2013 à 18h07

Eagle1 a écrit :

je pige pas comment des graphismes de ce genre pourrait exister en HTML5 dans un navigateur

si ça fonctionne ça veut vraiment dire qu’on s’est fait enc depuis longtemps.

Je ne comprends pas ton raisonnement, il semble que tu aies mal compris quelque chose.

batoche a écrit :

Le binaire, c’est de la merde, maintenant on compile le C++ en html+javascript, interprété par un moteur de rendu HTML + un executeur javascript tous deux écrits en C++ ou en langage exécuté au sein d’un VM elle même écrite en C++ ou dans un langage interprété au sein d’un OS (lui même écrit en C++ ou exécuté au sein d’une VM (elle même écrite en C++ et exécuté par un noyau (lui même écrit en C++ ou interprété au sein d’une VM (écrite en C++ exécutée par l’UEFI))))

:brainfuck:

" />

Khalev a écrit :

Avec asm.js on parle juste de temps d’exécution 2 fois plus long. Rien de bien méchant : On est juste en retard de 18 mois selon la loi de Moore.

C’est mieux que les 10 à 20 fois qu’on observe quand on n’utilise pas asm.js

En effet. Encore faudra t-il que asm.js soit complété, peut-être standardisé, puis adopté par les autres navigateurs. Si cela les intéresse (espérons).

cendrev3 a écrit :

Pour ceux aussi qui doutent sur les performances du JS, c’est le langage interprété le plus rapide actuellement (le marche des navigateur est le plus concurrentiel de l’informatique).

Et les performances du JS en général sont très proches du C (je parle pas du DOM qui est plus lent lui), regardez nodejs pour vous faire une idée de la vitesse a laquelle on exécute du JS aujourd’hui.

C’est sans doute le plus rapide des escargots aujourd’hui vu les énormes efforts qui ont porté sur son optimisation (et non pas du fait de sa conception) mais les performances restent beaucoup plus éloignées du natif que ce que tu dis, sauf dans des cas faciles à optimiser. Ce qui est rarement le cas des gros programmes dans la vraie vie.

brazomyna

Le 02/04/2013 à 18h31

Khalev a écrit :

Sauf que ça reste compatible avec n’importe quel moteur JS. Au prix d’un différence de performances

Sauf que tout peut être rendu compatible pour peu que tu code l’interpréteur adéquat. Le seule ‘détail’, ce sont les perfs ; or si on fait ce genre de chose, le but est justement les perfs, c’est donc un bon gros FAIL by design.

Bon allez zou, je vais me faire une petite partie de 1943 sur un émulateur JS d’Amstrad CPC. Ce sera un peu juste de faire tourner ça sur mon ordi tellement l’overhead tient du délire, mais ça devrait passer quand même (EDIT: 11fps sous FF19 + Ubuntu).

brazomyna

Le 02/04/2013 à 18h47

HarmattanBlow a écrit :

C’est sans doute le plus rapide des escargots aujourd’hui

Oui et non: le JS reste quand même une belle prouesse du côté de l’interprété et peut parfaitement être intégré dans de nombreux applicatifs sans que ça ne pose de réel problème de perfs.

Mais c’est à une condition: bien définir l’endroit où on pose la frontière entre les deux mondes.

Une bonne approche en règle générale est de se débrouiller pour que le JS soit là pour contrôler le ‘haut niveau’ (genre “lance telle anim de là à là en x secondes”), mais ne s’occupe pas des basses besognes à chaque epsilon de temps (genre chaque image). Sinon, c’est l’explosion des appels JS natif et les perfs sont assurées d’être minables.

Or dans le contexte ici, il n’y a pas 36 solutions:

soit on fait un binding de haut niveau et on va se retrouver dans le cas d’un simili plugin qu’on pourra controler depuis le JS. On aura de bonnes perfs, mais un flash-bis au niveau interopérabilité et ouverture. En effet, le simili plugin sera soit fait par un privé (Unreal, Adobe, Dassault ou quiconque), soit fait par une des grosses ‘marques’ de browser, que les autres ne voudront donc pas reprendre, concurrence oblige (genre NaCl).

soit on fait du bas niveau standardisé, et on aura des perfs médiocres.

brazomyna

Le 02/04/2013 à 18h54

^^ je précise quand même que cette approche est valable dans le strict cadre de l’article (“Le HTML5 va-t-il révolutionner l’industrie vidéoludique ?”) ; et de par le fait qu’on ne pourra pas s’en servir pour les jeux “triple A” (gros budget, grosse 3D, gors…).

Pour tout le reste, notamment le casual gaming où la course à la puissance n’est plus un impératif, l’existant est au contraire largement adapté.

Lumina

Le 02/04/2013 à 19h01

On se posera seulement la question de la qualité des graphismes qui, dans un tel cas, sera certainement déterminée par la puissance de la machine la moins performante.

solution a) le vectoriel

solution b) le téléchargement de ressources graphiques dépendantes de la puissance de la machine

Soit au moins deux solutions pour éviter de s’aligner sur la puissance la plus faible.

C’était donc dommage ne se poser “que” cette question.

zefling Abonné

Le 02/04/2013 à 19h03

HarmattanBlow a écrit :

En effet. Encore faudra t-il que asm.js soit complété, peut-être standardisé, puis adopté par les autres navigateurs. Si cela les intéresse (espérons).

Visiblement V8 serait assez facilement compatible, il y aurait juste un bug à corriger pour ça.

_fdk_

Le 02/04/2013 à 19h58

GitHub

Uther Abonné

Le 02/04/2013 à 20h08

cendrev3 a écrit :

Pour ceux aussi qui doutent sur les performances du JS, c’est le langage interprété le plus rapide actuellement (le marche des navigateur est le plus concurrentiel de l’informatique).

Et les performances du JS en général sont très proches du C (je parle pas du DOM qui est plus lent lui), regardez nodejs pour vous faire une idée de la vitesse a laquelle on exécute du JS aujourd’hui.

Le JS de base n’est certainement pas le langage interprété le plus rapide, il reste bien derrière le Java et matière de performance brute car la plupart de ces fonctionnalités avancées rendent sont optimisation difficile. Le typage dynamique est entre autre une plaie.

Par contre avec asm.js, ça pourrait clairement changer, vu qu’il permet de se concentrer sur une partie limitée de javascript facilement optimisable,

bombo

Le 02/04/2013 à 14h56

ah bon ? on peut compiler du C++ en HTML5 et javascript ? " />

zefling Abonné

Le 02/04/2013 à 14h56

Il faut se dire que Unreal Engine 3 passe en WebGL :

YouTube

tsubasaleguedin

Le 02/04/2013 à 14h58

C’est la fin des pilotes

Hein ? Je vois pas le rapport, si firefox tourne en safe mode VGA, ca va pas le faire …

antoinet

Le 02/04/2013 à 14h59

Si ce n’est pas un poisson d’Avril, je me remettrai peut-etre a jouer.

Ca me parait hallucinant de pouvoir faire des trucs complexes en HTML5, mais ca ouvre des perspectives de dingues!

Citan Abonné

Le 02/04/2013 à 15h00

Si les studios pourront très facilement créer des jeux fonctionnant sur toutes les plateformes, que restera t-til aux consoles de jeu ?

À cette question, si l’on prend en compte cet élément de la news : “On fait du C++ pur, le même code que l’on utilise pour d’autres plateformes, et il est seulement compilé en HTML5 et JavaScript pour l’environnement web”

La réponse est simple : les mêmes arguments qu’auparavant, notamment l’uniformisation et la fiabilité de l’expérience de jeu.

Parce que porter en HTML5 et JS, c’est bien, mais il me semble que les performances d’un langage interprété sont incomparables avec un langage compilé. Outre le fait que la version console tire parti des spécificités techniques, tandis que la version HTML5 va à priori servir pour tous les périphériques possibles, avec leur diversité d’interprétation et de matériel.

Donc là, comme ça, pour tous les gros jeux, je doute que cette capacité de portage phagocyte le marché des consoles. En revanche pour des jeux moins gourmands, on peut l’envisager.

Reste que dans tous les cas, ça va nécessairement faciliter un développement multiplateforme, et ça c’est une bonne nouvelle pour les dev de tout poil, et un très bon argument marketing pour Epic Games.

Stargateur

Le 02/04/2013 à 15h01

bombo a écrit :

ah bon ? on peut compiler du C++ en HTML5 et javascript ? " />

franchement j’ai la même réaction de plus il dit c’est pas du javascript et après dit on le compile en javascript….. c’est un poison d’avril le 2 ?

TaigaIV

Le 02/04/2013 à 15h04

Stargateur a écrit :

franchement j’ai la même réaction de plus il dit c’est pas du javascript et après dit on le compile en javascript….. c’est un poison d’avril le 2 ?

Tu sais c’est du HTML5, c’est pas très rapide. " />

MorganStern

Le 02/04/2013 à 15h04

bombo a écrit :

ah bon ? on peut compiler du C++ en HTML5 et javascript ? " />

J’ai tiqué aussi sur ce point.

cyrano2

Le 02/04/2013 à 15h05

Il ne faut pas oublier que HTML5 propose un canvas opengl et un traitement du son “en natif”, ce qui prend le plus de temps de cpu que le reste du moteur du jeu. Free avait proposé un binding EFL+javascript pour sa freebox V5.

psn00ps

Le 02/04/2013 à 15h05

tsubasaleguedin a écrit :

Hein ? Je vois pas le rapport, si firefox tourne en safe mode VGA, ca va pas le faire …

La fin des problèmes liés aux pilotes pour les développeurs, ils n’optimiseront plus leur code par rapport à tel GPU.

Gromsempai

Le 02/04/2013 à 15h07

Son discours est quand même vachement orienté et exagéré pour ne pas dire bullshité.

Kokusho

Le 02/04/2013 à 15h09

Si ça fonctionne sur ChromeOS ça va devenir intéressant. De là à révolutionner, non.

DniMam

Le 02/04/2013 à 15h10

J’ai pas très bien compris. Basiquement on pourrais jouer sur un navigateur mais je vois pas comment ma carte graphique lit le HTML5 et le java script. La carte graphique ne sert plus à rien ? Un volontaire pour m’expliquer " />

Eagle1

Le 02/04/2013 à 15h10

je pige pas comment des graphismes de ce genre pourrait exister en HTML5 dans un navigateur

si ça fonctionne ça veut vraiment dire qu’on s’est fait enc depuis longtemps.

et profondément.

TaigaIV

Le 02/04/2013 à 15h11

psn00ps a écrit :

La fin des problèmes liés aux pilotes pour les développeurs, ils n’optimiseront plus leur code par rapport à tel GPU.

Mouais, est ce que ça ne va pas être pour tel navigateur sur tel OS avec tel GPU.

xdrh

Le 02/04/2013 à 15h12

psn00ps a écrit :

La fin des problèmes liés aux pilotes pour les développeurs, ils n’optimiseront plus leur code par rapport à tel GPU.

Je m’y connais pas extrêmement bien en dev de jeux vidéos, mais il me semble que les devs de JV ne sont pas obligés d’optimiser leur moteur pour tel ou tel jeu, et pourraient très bien avoir un unique code pour tous les GPUs. Ils le font uniquement pour gagner un peu de perfs dans chaque cas. Si c’est bien ça (à confirmer par d’autres connaisseurs), je vois pas trop ce que le HTML5 apporterait de plus.

Dedrak

Le 02/04/2013 à 15h13

Je n’ose pas imaginer le temps de téléchargement pour accéder au jeu " />

Skeeder

Le 02/04/2013 à 15h13

psn00ps a écrit :

La fin des problèmes liés aux pilotes pour les développeurs, ils n’optimiseront plus leur code par rapport à tel GPU.

Franchement à chaque fois que j’entends parler du HTML5 “multiplateforme”, c’est ça que je comprend.

yeagermach1

Le 02/04/2013 à 15h13

psn00ps a écrit :

La fin des problèmes liés aux pilotes pour les développeurs, ils n’optimiseront plus leur code par rapport à tel GPU.

Franchement non. Les navigateurs se basant toujours sur les drivers, les optimisations seront toujours presente.

Khalev

Le 02/04/2013 à 15h16

bombo a écrit :

ah bon ? on peut compiler du C++ en HTML5 et javascript ? " />

Bah moi c’est pas ça qui me choque.

Un compilateur ça traduit un code écrit en un langage en un code écrit dans un autre langage (souvent assembleur, qui n’est qu’un autre code). Ils ont très bien pu écrire un compilateur C++ vers Javascript/HTML5.

L’avantage c’est que tu codes en C++, donc pas de nouvelles compétences à acquérir pour un dév, ça tourne sur les navigateurs compatibles et ça optimise la taille du code compilé en ayant une vision globale du code (pour pouvoir envoyer ça via internet, réduire le plus possible la taille du bouzin peut-être très utile).

Je pense que c’est ce qu’à voulu dire le monsieur, mais soit la traduction a perdu une partie du sens, soit il s’est mal exprimé. Ou les deux en même temps.

Après j’aimerai bien voir la tête du compilo et les limites/optimisations associées.

TaigaIV

Le 02/04/2013 à 15h20

Eagle1 a écrit :

je pige pas comment des graphismes de ce genre pourrait exister en HTML5 dans un navigateur

si ça fonctionne ça veut vraiment dire qu’on s’est fait enc depuis longtemps.

et profondément.

On est pas la, pour l’instant j’ai juste trouvé ça (testé vite fait sur un firefox sous gentoo), que j’ai trouvé relativement impressionnant pour un truc sans plugin.

Anonyme

Le 02/04/2013 à 15h20

«c’est pas fait dans un langage biscornu comme le js, c’est juste compilé en js.»

ah ouais, rien à voir.

bon, l’avenir des jeux est donc d’avoir des machines dix fois plus puissantes parce que les devs ne veulent pas bosser…

yeagermach1

Le 02/04/2013 à 15h21

Le plus gros probleme c’est pas de faire tourner, c’est de rapatrier l’ensemble des modeles, textures, …

un exe c’est pas bien gros, le reste si.

Teybeo

Le 02/04/2013 à 15h26

Il y a emscripten qui fait la conversion vers le javascript.

Une démo du moteur 3d Sauerbraten porté grâce à ca.

Une autre du moteur Unigine

Et maintenant l’unreal engine :)

Blood_Man

Le 02/04/2013 à 15h27

Yzokras a écrit :

bon, l’avenir des jeux est donc d’avoir des machines dix fois plus puissantes parce que les devs ne veulent pas bosser…

Même 10x plus puissant c’est trop peu. Et puis bon, si c’était compilé en JS, le cheat serait d’une facilité…

Altium

Le 02/04/2013 à 15h29

Kokusho a écrit :

Si ça fonctionne sur ChromeOS ça va devenir intéressant. De là à révolutionner, non.

On parle pas de cloud gaming là, cela utilise quand même ta carte graphique et ton processeur. Cela dit les performances doivent être catastrophique. J’ai testé worms en HTML5/Javascript sur facebook et même sur mon ancien AMD Athlon c’était plus fluide en natif " />

Khalev

Le 02/04/2013 à 15h33

DniMam a écrit :

J’ai pas très bien compris. Basiquement on pourrais jouer sur un navigateur mais je vois pas comment ma carte graphique lit le HTML5 et le java script. La carte graphique ne sert plus à rien ? Un volontaire pour m’expliquer " />

Ta carte graphique ne lit pas le HTML5 et le javascript, mais le navigateur oui. Et le navigateur est capable de commander la carte graphique.

Du coup ton navigateur lira le HTML5 et le javascript, en déduiras les opérations à faire pour le CPU, celles à faire pour le GPU, répartira les 2 et synchronisera les actions.

Là ou avant le (moteur du) jeu gérait lui-même ces actions.

C’est “un peu” plus compliqué que ça en vrai. Mais dans l’idée je pense que je suis pas loin. Par contre je ne suis pas si je suis clair.

On aura quand même une perte de performance, c’est toujours le même problème avec les langages interprétés. Et les moteurs JavaScript vont devenir des éléments vitaux des navigateurs. Entre les exigences de sécurités et les optimisations nécessaires pour les jeux, ça va devenir des trucs de malades.

Ça va être marrant à la sortie d’un gros jeu on aura un combo update navigateur + update drivers pour diverses optimisations…

zefling Abonné

Le 02/04/2013 à 15h35

Blood_Man a écrit :

Même 10x plus puissant c’est trop peu. Et puis bon, si c’était compilé en JS, le cheat serait d’une facilité…

T’as pas du du code optimisé pour asm.js. " />

Zaouli

Le 02/04/2013 à 15h35

Dedrak a écrit :

Je n’ose pas imaginer le temps de téléchargement pour accéder au jeu " />

Pour les jeux ne demandant pas de précharger une quantité trop importante de données, il y a la solution de renvoyer les textures/meshes et autres données avant chaque scène. Ça occasionnera de gros chargements entre les scènes tant que ça ne sera pas en cache et Il faudra certainement une bonne connexion.

Sinon pour les jeux demandant beaucoup de données, comme tout jeu dématérialisé il faudra certainement passer par une étape de DL massif. Les API HTML5 prévoient des méthodes de stockage en local qui ne sont pas encore à maturité et ne permettent pas ça (il me semble), ça devra juste évoluer un peu de ce coté là.

Khalev

Le 02/04/2013 à 15h42

Blood_Man a écrit :

Même 10x plus puissant c’est trop peu. Et puis bon, si c’était compilé en JS, le cheat serait d’une facilité…

Quand même pas. Par contre je vois pas en quoi le cheat sera facilité.

Skeeder

Le 02/04/2013 à 15h44

TaigaIV a écrit :

On est pas la, pour l’instant j’ai juste trouvé ça (testé vite fait sur un firefox sous gentoo), que j’ai trouvé relativement impressionnant pour un truc sans plugin.

Cela me fait penser à Kkrieger " />

anonyme_d58ae7e2d09a5d3fb2e3eb976436dda3

Le 02/04/2013 à 15h49

je ne sais pas trop quoi penser de ces déclarations, je ne vois pas trop où ils veulent en venir.

Quand je lit çà :

C’est la fin des pilotes, des installations et tous les trucs bizarres liés au développement classique

je me dit qu’il y a anguille sous roche. N’importe quel professionnel vous dira que convertir du C++ vers du Javascript, et espérer que tous les navigateurs l’interprètent de la même manière et avec un rendu visuel identique du produit final, c’est du bullshitage complet.

En rajoutant une couche d’abstraction qu’est la black-box de sa moulinette C++ > Javascript on va pas magiquement éviter tous les problèmes… de plus les pilotes sont évidemment toujours nécessaires et impérativement à lier étroitement au développement pour avoir un rendu performant, sauf qu’en plus maintenant il y a toute la tambouille inclue dans le navigateur entre les 2… tambouille que personne ne connait, sauf les développeurs des browsers.

De plus une PS3 / Xbox360 est une archi figée, codez un jeu dessus et çà marchera toujours. Là, à chaque nouvelle version d’un browser, va falloir se taper de dizaines de tests pour vérifier que tout reste compatible… quand on voit les nouveaux cycles de développement des browsers… et le nombre de browsers différents (et donc de bidouilles à inclure pour que çà marche à peu près dans chacun….)

Franchement ces déclarations me laissent perplexe.

Zyami Abonné

Le 02/04/2013 à 15h51

Avec l’annonce de Mozilla, clairement oui, HTML 5 + JS et le tour est joué.

Voir ici :http://comptoir-du-net.fr/13/mozilla-porte-unreal-engine-3-sur-son-navigateur-fi…

Blood_Man

Le 02/04/2013 à 15h53

Khalev a écrit :

Quand même pas. Par contre je vois pas en quoi le cheat sera facilité.

Car il est plus facile de lire du JS que de l’assembleur. Et qu’il n’y aura rien de compliqué pour lancer le débugger sur le navigateur contrairement à certaines appli client lourd qui empêche le lancement de certains outils.

Khalev

Le 02/04/2013 à 15h55

hadoken a écrit :

En rajoutant une couche d’abstraction qu’est la black-box de sa moulinette C++ > Javascript on va pas magiquement éviter tous les problèmes… de plus les pilotes sont évidemment toujours nécessaires et impérativement à lier étroitement au développement pour avoir un rendu performant, sauf qu’en plus maintenant il y a toute la tambouille inclue dans le navigateur entre les 2… tambouille que personne ne connait, sauf les développeurs des browsers.

C’est aussi ce que je me dis. Déjà les moteurs javascripts optimisent différemment. Donc ça va être la misère.

Après l’avantage c’est qu’il n’y en a pas tant que ça des moteurs javascript. Mais faut pas croire que ça signera la fin des problèmes de drivers & co. Le moteur JS passe aussi par les drivers, et selon son optimisation il sera plus performant sur certains que sur d’autres. Parce que faut pas oublier qu’un jeu c’est extrêmement gourmand et que ça va taper dans les limites des machines (pour les gros jeux)

Pour la tambouille navigateur, vive l’opensource :)

DniMam

Le 02/04/2013 à 15h56

Khalev a écrit :

Ta carte graphique ne lit pas le HTML5 et le javascript, mais le navigateur oui. Et le navigateur est capable de commander la carte graphique.

Du coup ton navigateur lira le HTML5 et le javascript, en déduiras les opérations à faire pour le CPU, celles à faire pour le GPU, répartira les 2 et synchronisera les actions.

Là ou avant le (moteur du) jeu gérait lui-même ces actions.

C’est “un peu” plus compliqué que ça en vrai. Mais dans l’idée je pense que je suis pas loin. Par contre je ne suis pas si je suis clair.

On aura quand même une perte de performance, c’est toujours le même problème avec les langages interprétés. Et les moteurs JavaScript vont devenir des éléments vitaux des navigateurs. Entre les exigences de sécurités et les optimisations nécessaires pour les jeux, ça va devenir des trucs de malades.

Ça va être marrant à la sortie d’un gros jeu on aura un combo update navigateur + update drivers pour diverses optimisations…

Je vois du coup pour résoudre les problèmes d’interpretations entre navigateurs, il faut un même moteur et ce sera Webkit (Safari et Chrome l’utilisent ainsi qu’Opéra). Ce qui est super c’est qu’on pourra jouer sur un iMac, un iPad, linux, je crois qu’un éditeur va apprécier " />

brazomyna

Le 02/04/2013 à 15h57

Citan666 a écrit :

Parce que porter en HTML5 et JS, c’est bien, mais il me semble que les performa[quote:4524761:cyrano2]Il ne faut pas oublier que HTML5 propose un canvas opengl et un traitement du son “en natif”, ce qui prend le plus de temps de cpu que le reste du moteur du jeu.

Sauf que faire du webGL c’est du très bas niveau, ce qui implique un nombre assez incroyable d’appels de fonction JS=>natif par frame. C’est totalement délirant en terme de perfs tellement ça va plomber le tout.

Free avait proposé un binding EFL+javascript pour sa freebox V5.

Même ce binding était déjà de bien plus haut niveau que WebGL ou Canvas: la manipulation sa faisait autour d’éléments en statefull, pas au niveau de primitives graphiques de base

Donc là, comme ça, pour tous les gros jeux, je doute que cette capacité de portage phagocyte le marché des consoles. En revanche pour des jeux moins gourmands, on peut l’envisager.

Exact. Reste à savoir si ça apporte réellement un plus par rapport à ce qui existe déjà.

Reste que dans tous les cas, ça va nécessairement faciliter un développement multiplateforme, et ça c’est une bonne nouvelle pour les dev de tout poil, et un très bon argument marketing pour Epic Games.

Sauf que les frameworks qui promettent le Saint Graal de l’uniformisation des plateformes, c’est pas la première fois qu’on essaie de le vendre. Et c’est pas pour rien qu’à chaque fois ça ne dépasse pas la bonne intention (au mieux) ou la bullshit marketing (au pire).

Ce qu’ils veulent tenter manifestement c’est beaucoup plus d’imposer le support de leur plugin/techno proprio pour que ça devienne une forme de standard de fait. La même chose que Flash en son temps, quoi, ceci n’est rien d’autre que cela:

Zyami a écrit :

Avec l’annonce de Mozilla, clairement oui, HTML 5 + JS et le tour est joué.

Voir ici :http://comptoir-du-net.fr/13/mozilla-porte-unreal-engine-3-sur-son-navigateur-fi…

HarmattanBlow

Le 02/04/2013 à 15h59

psn00ps a écrit :

La fin des problèmes liés aux pilotes pour les développeurs, ils n’optimiseront plus leur code par rapport à tel GPU.

Ils peuvent déjà ne pas optimiser aujourd’hui s’ils le veulent, simplement on perd des perfs. Là ils en perdront encore plus.

Quant à l’absence d’installation, je veux bien, ça facilite le test par le joueur et donc augmente les achats, mais les temps de chargement sont toujours là en réalité, à moins de brider le jeu en fonction de ça.

brazomyna a écrit :

Sauf que les frameworks qui promettent le Saint Graal de l’uniformisation des plateformes, c’est pas la première fois qu’on essaie de le vendre. Et c’est pas pour rien qu’à chaque fois ça ne dépasse pas la bonne intention (au mieux) ou la bullshit marketing (au pire).

" />

flagos_

Le 02/04/2013 à 15h59

Avec asm.js, Mozillaparle effectivement de performances approchantes au code natif en écrivant à partir du c++ et en transcodant vers du html5 + js.

Si les performances sont bien la, on peut effectivement anticiper qu’il s’agit de la prochaine plateforme de développement (et tant mieux !)

ouvreboite

Le 02/04/2013 à 16h03

Eagle1 a écrit :

je pige pas comment des graphismes de ce genre pourrait exister en HTML5 dans un navigateur

si ça fonctionne ça veut vraiment dire qu’on s’est fait enc depuis longtemps.

et profondément.

Pourquoi ?

Tu crois que parce que ca tourne en HTML5, ca va tourner pareil partout ? Qu’on va avoir les même perf entre un atom et un i7+680gtx ?

Ca ne fait que déporter tes calculs, c’est pas “magique”.

Khalev

Le 02/04/2013 à 16h07

DniMam a écrit :

Je vois du coup pour résoudre les problèmes d’interpretations entre navigateurs, il faut un même moteur et ce sera Webkit (Safari et Chrome l’utilisent ainsi qu’Opéra). Ce qui est super c’est qu’on pourra jouer sur un iMac, un iPad, linux, je crois qu’un éditeur va apprécier " />

Voilà c’est ça. En théorie on élimine le problème d’OS. Sauf que les navigateurs+drivers ne sont pas équivalent sur tous les OS.

Du coup on se retrouvera avec des problèmes de compatibilité Navigateur+Moteur JS+pilotes au lieu de l’ancien OS+pilotes.

Le pied quoi!

Blood_Man a écrit :

Car il est plus facile de lire du JS que de l’assembleur. Et qu’il n’y aura rien de compliqué pour lancer le débugger sur le navigateur contrairement à certaines appli client lourd qui empêche le lancement de certains outils.

C’est vrai que lire du js c’est plus facile que de lire de l’assembleur (ASM, on comprend bien pourquoi il y a SM dans le nom " />) par contre les clients lourds qui empêchent les outils de se lancer, c’est très loin d’être bloquant.

batoche

Le 02/04/2013 à 16h07

On fait du C++ pur, le même code que l’on utilise pour d’autres plateformes, et il est seulement compilé en HTML5 et JavaScript pour l’environnement web

Le binaire, c’est de la merde, maintenant on compile le C++ en html+javascript, interprété par un moteur de rendu HTML + un executeur javascript tous deux écrits en C++ ou en langage exécuté au sein d’un VM elle même écrite en C++ ou dans un langage interprété au sein d’un OS (lui même écrit en C++ ou exécuté au sein d’une VM (elle même écrite en C++ et exécuté par un noyau (lui même écrit en C++ ou interprété au sein d’une VM (écrite en C++ exécutée par l’UEFI))))

:brainfuck:

brazomyna

Le 02/04/2013 à 16h08

flagos_ a écrit :

Avec asm.js, Mozillaparle effectivement de performances approchantes au code natif en écrivant à partir du c++ et en transcodant vers du html5 + js.

Sauf que si j’ai bien compris, leur bouzin n’est ni plus ni moins que la création d’une sorte d’assembleur basé sur un subset du JS. Dit autrement, un bytecode avec des bases communes au JS. Dit autrement … ben une machine virtuelle à la Java intégrée dans le browser.

brazomyna

Le 02/04/2013 à 20h31

Uther a écrit :

Le JS de base n’est certainement pas le langage interprété le plus rapide, il reste bien derrière le Java

Sauf que Java ne peut pas être considéré comme un langage interprété étant donné qu’il subit une étape de compilation vers un bytecode intermédiaire.

Stargateur

Le 02/04/2013 à 20h32

brazomyna a écrit :

Sauf que tout peut être rendu compatible pour peu que tu code l’interpréteur adéquat. Le seule ‘détail’, ce sont les perfs ; or si on fait ce genre de chose, le but est justement les perfs, c’est donc un bon gros FAIL by design.

Bon allez zou, je vais me faire une petite partie de 1943 sur un émulateur JS d’Amstrad CPC. Ce sera un peu juste de faire tourner ça sur mon ordi tellement l’overhead tient du délire, mais ça devrait passer quand même (EDIT: 11fps sous FF19 + Ubuntu).

35 sous opera

cendrev3

Le 02/04/2013 à 20h52

Uther a écrit :

Le JS de base n’est certainement pas le langage interprété le plus rapide, il reste bien derrière le Java et matière de performance brute car la plupart de ces fonctionnalités avancées rendent sont optimisation difficile. Le typage dynamique est entre autre une plaie.

Par contre avec asm.js, ça pourrait clairement changer, vu qu’il permet de se concentrer sur une partie limitée de javascript facilement optimisable,

Non non, le JS est actuellement devant le Java en terme de performances brutes on dirais: (du moins sur les tests que j’ai pu voir " />)

http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=v8&lang2=java

http://www.redcode.nl/blog/2012/07/java-speed-of-math/

Ca parais logique en même temps, la compétitivité est tellement forte sur les navigateurs que des millions sont investis sur une simple VM javascript ! " />

C’est sans doute le plus rapide des escargots aujourd’hui vu les énormes efforts qui ont porté sur son optimisation (et non pas du fait de sa conception) mais les performances restent beaucoup plus éloignées du natif que ce que tu dis, sauf dans des cas faciles à optimiser. Ce qui est rarement le cas des gros programmes dans la vraie vie.

Alors oui en effet, le natif est forcement plus rapide, c’est obligé " />.

Mais du fait de la nature asynchrone du JS, certains des programmes écris en C seront principalement plus lent, un exemple tout con :

En C pour lire un fichier on va plutôt utiliser fgets qui bloque en attendant une ligne.

En nodejs on va utiliser fs.read qui utilise ‘read’ de la lib C qui lui est non bloquant (il y a une option pour le faire rendre tout de suite la main) et donc on peut exécuter d’autres choses dans le même temps.

Cette exemple est valable avec beaucoup d’appels système de la libC.

Évidement on pourrais faire exactement la même chose en C mais la plupart des gens ne le font pas non plus " />.

metaphore54

Le 02/04/2013 à 21h25

J’espère qu’ils ne misent pas sur la LTE, car 4 à 5 personnes à jouer sur le même jeu et sur la même antenne relai et tu te retrouve avec un 486 faisant tourner crysis.

Je pense aussi qu’il faudra télécharger le jeu avant, mais si les technos ne sont pas mure, je me demande comment ils vont faire.

brazomyna

Le 02/04/2013 à 21h37

cendrev3 a écrit :

Non non, le JS est actuellement devant le Java en terme de performances brutes on dirais: (du moins sur les tests que j’ai pu voir " />)

Sauf que tu ne sais pas lire les liens que tu as toi-même donnés:

le premier lien donne javascript gagnant sur un test qui éprouve plus l’implémentation d’une fonction native en particulier (sur les regexp) plutôt qu’autre chose. Pour l’ensemble des autres tests de la même page, JS se banane comparé à Java.

le second lien donne l’explication lui-même, avec le fait que Java ne propose que des fonctions pour des calculs sur les doubles.

Plus généralement, ce qu’il faut comprendre c’est que la plupart des mini tests dans ce genre sont basés sur un grand nombre d’itérations de quelque chose qui comporte pas ou peu de branchements conditionnels ; c’est donc très éloigné de la réalité d’un programme alors que c’est un des points faibles du JS.

Mais du fait de la nature asynchrone du JS, certains des programmes écris en C seront principalement plus lent, un exemple tout con

T’as bien retenu par coeur les articles surNode.JS mais tu n’as pas compris l’essence de ce qu’ils racontent.

Ce qu’ils mettent en avant c’est pas le JS en lui-même, c’est l’asynchrone vs. le synchrone dans un cas extrêmement particulier (la multiplications de requêtes de courtes durées pour un serveur qui va devoir multiplier des appels vers des ressources externes, fichiers, BdD, …, pour y répondre).

Ce cas de figure est reproduit dans un serveur et apporte un intérêt pour éviter des switchs incessants entre (centaines de) threads qui finissent par peser lourds dans la balance. Mais ça ne s’applique clairement pas dans une application ‘utilisateur’.

Et même au dela, dans tout ça, Javascript n’est qu’un support pour la paradigme asynchrone, choisi avant tout du fait de ses propriétés qui facilitent l’écriture de code asynchrone (closures, etc…) ; pas pour des supposées performances ou autres qualités intrinsèques qui y sont reliées.

metaphore54

Le 02/04/2013 à 21h58

Ca m’apprendra à ne pas tout lire, je m’étais arrêté à zaouli, Donc le javascript peut lancer du code html 5, donc si je comprends( car je suis nul), le jeu sera un programme javascript à télécharger et le jeu se jouera au travers de Java script.

Dire que je n’ai pas installé java, moi qui pensais que c’était une techno du passé. En même temps je me voyais mal jouer au travers d’un explorateur jouer à un jeu avec l’unreal engine 4avec un simple adsl.

methos1435

Le 03/04/2013 à 00h14

metaphore54 a écrit :

Ca m’apprendra à ne pas tout lire, je m’étais arrêté à zaouli, Donc le javascript peut lancer du code html 5, donc si je comprends( car je suis nul), le jeu sera un programme javascript à télécharger et le jeu se jouera au travers de Java script.

Dire que je n’ai pas installé java, moi qui pensais que c’était une techno du passé. En même temps je me voyais mal jouer au travers d’un explorateur jouer à un jeu avec l’unreal engine 4avec un simple adsl.

Javascript n’a rien à voir avec Java " />

Holly Brius

Le 03/04/2013 à 04h19

hadoken a écrit :

je me dit qu’il y a anguille sous roche. N’importe quel professionnel vous dira que convertir du C++ vers du Javascript, et espérer que tous les navigateurs l’interprètent de la même manière et avec un rendu visuel identique du produit final, c’est du bullshitage complet.

Ben non, que ce soit en C++ ou en JS, ta carte graphique reçoit les mêmes shaders, mesh et autres textures et les interpréte de la même manière.

Par contre, du js aussi rapide que du C++, j’y crois pas une seconde…

Holly Brius

Le 03/04/2013 à 04h30

cendrev3 a écrit :

Pour ceux aussi qui doutent sur les performances du JS, c’est le langage interprété le plus rapide actuellement (le marche des navigateur est le plus concurrentiel de l’informatique).

Et les performances du JS en général sont très proches du C (je parle pas du DOM qui est plus lent lui), regardez nodejs pour vous faire une idée de la vitesse a laquelle on exécute du JS aujourd’hui.

Si c’est avec ce genre de bench complètement bidon que tu te fais un avis, c’est triste.

NodeJS est très bon , mais comparer 4 lignes de JS qui balance en dur un hello world avec Apache qui interprète du PHP (et fait aussi bien d’autre chose), c’est plus que comique…

dam1605 Abonné

Le 03/04/2013 à 05h55

DniMam a écrit :

J’ai pas très bien compris. Basiquement on pourrais jouer sur un navigateur mais je vois pas comment ma carte graphique lit le HTML5 et le java script. La carte graphique ne sert plus à rien ? Un volontaire pour m’expliquer " />

La carte graphique ça lui change rien.

C’est juste qu’au lieu d’avoir un programme (le jeu) qui fait appel à elle (via la lib directx/opengl) ce sera un “site web” (enfin sûrement un truc local prétéléchargé) qui fera pareil puisque opengl est accessible en html5.

Par ailleurs ça va prendre une place monstre un jeu en html5/js, non ? Genre x10 sur la taille du jeu par rapport à une version compilée.

D’ailleurs c’est le bon terme “compiler” pour une transformation html5/js, je suis pas sûr du tout.

dam1605 Abonné

Le 03/04/2013 à 06h01

cendrev3 a écrit :

Pour ceux aussi qui doutent sur les performances du JS, c’est le langage interprété le plus rapide actuellement (le marche des navigateur est le plus concurrentiel de l’informatique).

Et les performances du JS en général sont très proches du C (je parle pas du DOM qui est plus lent lui), regardez nodejs pour vous faire une idée de la vitesse a laquelle on exécute du JS aujourd’hui.

Ca dépend complètement de l’implem, et puis maintenant avec le git, “interprétation” est quand même un grand mot. Et c’est juste techniquement impossible que ce soit aussi rapide qu’un binaire déjà compilé (si le compilo est aussi performant).

C’est quoi l’intérêt de faire du html5/js par rapport a du java (je veux dire c’est aussi portable). Moins de risque de failles ?

Uther Abonné

Le 03/04/2013 à 06h11

cendrev3 a écrit :

Non non, le JS est actuellement devant le Java en terme de performances brutes on dirais: (du moins sur les tests que j’ai pu voir " />)

http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=v8&lang2=java

http://www.redcode.nl/blog/2012/07/java-speed-of-math/

Ca parais logique en même temps, la compétitivité est tellement forte sur les navigateurs que des millions sont investis sur une simple VM javascript ! " />

Merci de me fournir les arguments contre javascript. Le seul test ou Javascript fait vraiment mieux c’est sur les expressions régulières qui sont gérés en natif par Javascript et en bytecode par Java. Dans tous les autres tests, Javascript fait au mieux jeu égal avec Java, au pire 7x plus lent.

cendrev3 a écrit :

Alors oui en effet, le natif est forcement plus rapide, c’est obligé " />.

Mais du fait de la nature asynchrone du JS, certains des programmes écris en C seront principalement plus lent, un exemple tout con :

En C pour lire un fichier on va plutôt utiliser fgets qui bloque en attendant une ligne.

En nodejs on va utiliser fs.read qui utilise ‘read’ de la lib C qui lui est non bloquant (il y a une option pour le faire rendre tout de suite la main) et donc on peut exécuter d’autres choses dans le même temps.

Cette exemple est valable avec beaucoup d’appels système de la libC.

Évidement on pourrais faire exactement la même chose en C mais la plupart des gens ne le font pas non plus " />.

Il est possible de faire des opérations en synchone et en asynchrone aussi bien en C qu’en Javascript.

Dire la plupart des gens ne le font pas n’est pas un argument recevable pour comparer les performances intrinseques des deux langages.

metaphore54

Le 03/04/2013 à 06h48

methos1435 a écrit :

Javascript n’a rien à voir avec Java " />

Ce n’est pas la même chose. " /> A part cette erreur le reste doit être bon.

xxxo

Le 03/04/2013 à 07h07

Je ne comprends pas pourquoi vous parlez de langage interprété pour JavaScript. Si ce fut longtemps le cas, il est désormais compilé en code natif avant d’être exécuté, ce qui lui donne les performances de ouf qu’on lui connait actuellement.

Après pour les dévs, même s’il n’y a plus de problèmes de drivers, il y a toujours le fait que le moteur JS n’est pas le même pour tous les navigateurs et que donc, un truc qui va être super optimisé pour Chrome, par exemple, ne le sera peut-être pas autant sur Opera ou IE.

Il y aura donc sûrement des optimisations spécifiques mais en fonction des moteurs JS cette fois.

brazomyna

Le 03/04/2013 à 07h13

dam1605 a écrit :

C’est quoi l’intérêt de faire du html5/js par rapport a du java (je veux dire c’est aussi portable). Moins de risque de failles ?

Non, JS n’est pas aussi ‘portable’ que Java, dans le sens où certaines opérations peuvent s’exécuter différemment selon la plateforme.

Il peut y avoir des différences dans les ‘arrondis’ effectués par les opérations mathématiques (sqrt, cos, sin, …) en fonction de l’interpréteur, de l’archi du CPU de la plateforme cible, etc…

Ce n’est pas le cas de Java, qui renverra toujours le même résultat, et est donc plus “portable” dans le sens “s’exécutera exactement à l’identique quelle que soit la plateforme cible”.

flamaros

Le 03/04/2013 à 07h18

Attention comme il s’agit encore de code natif, pour les consoles il restera du code spécifique. Les navigateurs peuvent juste jouer un role dans la standardisation de composant pour gerer les sauvegardes, détection de la langue,… mais les optimisations pour les CPU Cell par exemple reste propre à la PS3.

De même, bien que les navigateurs web soient les même sous linux je doute quand employant les drivers open source le moindre jeu basé sur l’unreal engine puisse tourner.

Par contre effectivement le packaging sous linux sera du coup uniforme quelque soit la distribution et le support certainement plus simple pour les éditeurs.

Actuellement de nombreux moteurs non multi-platforme utilisent des fonctions Win32 carrément exotique, mais prenez un moteur qui tourne sous Wndows, Mac OS X et iOS,… vous verrez que le porter sous linux ou PS3 n’est pas forcement très complexe, puisque que tout le code ultra spécifique est cantonné à quelle que sources précises.

Ne revez pas non plus, les contrats que lient les éditeurs aux fabricants de consoles imposeront toujours ces premiers à reverser des part à Microsoft, Sony, Apple (iOS) même si l’application se lance depuis un site internet puisqu’ils sont de toute façon maître du navigateur sur la plateforme qui leur appartient.

Donc en gros je doute que ça soit un bouleversement.

Uther Abonné

Le 03/04/2013 à 07h28

ennixo a écrit :

Je ne comprends pas pourquoi vous parlez de langage interprété pour JavaScript. Si ce fut longtemps le cas, il est désormais compilé en code natif avant d’être exécuté, ce qui lui donne les performances de ouf qu’on lui connait actuellement.

Il faut essayer d’arrondir les angles parce que la définition de code interprété vs compilé est de toute façon plutôt floue de nos jours :

Des langage totalement interprétés directement comme au temps des premiers Basic, ça n’existe presque plus.

De nos jours compilé peut signifier beaucoup de choses aussi, on ne compile plus seulement en langage machine mais éventuellement en bytecode, ou un autre langage

La compilation peux avoir lieu en AOT ou JIT

Bref ca ne me choque pas d’appeler un langage que l’on recouit sous forme de source et compilé en JIT, interprété même si je sais qu’en interne c’est plus complexe que ça.

brazomyna

Le 03/04/2013 à 08h16

Uther a écrit :

Il faut essayer d’arrondir les angles parce que la définition de code interprété vs compilé est de toute façon plutôt floue de nos jours

Exact, même si d’une façon générale, un langage dont l’objectif est d’être interprété est souvent un langage qui inclut des fonctionnalités que permettent la souplesse de l’interprété (du eval(), de l’introspection, de la génération/modification dynamique de code, typage faible, …). Or ce sont justement ces aspects qui rendent le langage à peu près impossible à ‘compiler’ de la façon la plus efficiente qui soit.

A l’opposé un langage dont la finalité est dès le départ la compilation en natif propose souvent un langage plus strict (typage fort, …) qui va donc permettre une optimisation plus grande du langage machine généré.

Et dans le domaine (spécifique) des jeux vidéos à ‘haute technicité’, la différence est sensible.

fken

Le 03/04/2013 à 08h58

Un tout nouveau marché pour les asso de défense de l’audiovisuel : après la protection des ventes de cd, je propose la protection des ventes de consoles.

Sans blague : c’est un marché porteur…

Uther Abonné

Le 03/04/2013 à 11h35

brazomyna a écrit :

Exact, même si d’une façon générale, un langage dont l’objectif est d’être interprété est souvent un langage qui inclut des fonctionnalités que permettent la souplesse de l’interprété (du eval(), de l’introspection, de la génération/modification dynamique de code, typage faible, …). Or ce sont justement ces aspects qui rendent le langage à peu près impossible à ‘compiler’ de la façon la plus efficiente qui soit.

En effet, c’est pour cela que asm.js est interessant, il se base sur un sourensemble de Javascript qui n’inclus pas ces elements difficiles a optimiser et utilise les tableaux typés pour faire fin du typage dynamique. Du coup, on se retrouve avec un Javascript hautement optimisable, qui peut même dans la plupart des cas être complètement compilé en AOT.

brazomyna

Le 03/04/2013 à 11h48

Uther a écrit :

En effet, c’est pour cela que asm.js est interessant

Oui et non, parce que - fusse-t-il un subset d’un autre langage - ça revient finalement à créer un nouveau langage. Et à ce jeu, on en a quelques uns qui sont déjà parfait pour faire ça (genre le C, C++ etc…), avec tout l’existant qui leur sied.

Et même si effectivement asm.js offre en plus la possibilité de faire un fallback vers une exécution en ‘vrai javascript’ (quand le support d’asm.js n’est pas proposé par la plateforme), ça restera in-intéressant dans les faits: un code qui peut s’exécuter mais dont les piètres performances en ‘mode fallback’ rendent l’application inutilisable dans la pratique, ça ne sert peu ou prou à rien.

D’autant que rien n’empêche déjà de proposer des techniques de fallback C (ou autre) vers Javascript via des outils comme ClueCC par exemple.

Uther Abonné

Le 03/04/2013 à 12h03

brazomyna a écrit :

Oui et non, parce que ça revient finalement à créer un nouveau langage. Et à ce jeu, on en a quelques uns qui sont déjà parfait pour faire ça (genre le C, C++ etc…), avec tout l’existant qui leur sied.

Je dirais plutôt un nouveau bytecode qu’un nouveau langage.

asm.js n’a clairement pas été pensé pour être utilisé à la main. J’ai un peu regardé la syntaxe, c’est particulièrement indigeste. L’intérêt est justement qu’avec des compilateurs comme enscriptem, on peut générer du asm.js à partir des langages parfait pour le développement de jeux que sont C/C++.

On sera certes toujours un peu en dessous des performances du natif, c’est le prix de la portabilité, mais la différence est clairement moindre.

brazomyna a écrit :

Et même si effectivement asm.js offre en plus la possibilité de faire un fallback vers une exécution en ‘vrai javascript’ (quand le support d’asm.js n’est pas proposé par la plateforme), ça restera in-intéressant dans les faits: un code qui peut s’exécuter mais dont les piètres performances en ‘mode fallback’ rendent l’application inutilisable dans la pratique, ça ne sert peu ou prou à rien.

Pour un jeu AAA, peut-être pas car avoir un navigateur suportant asm.js deviens en effet indispensable. mais il y a plein de cas intermédiaires ou ça peux être utile.

brazomyna

Le 03/04/2013 à 12h19

Uther a écrit :

Pour un jeu AAA, peut-être pas car avoir un navigateur suportant asm.js deviens en effet indispensable. mais il y a plein de cas intermédiaires ou ça peux être utile.

Je parlais bien des jeux AAA ; pour moi les cas intermédiaires se satisfont sans problème du JS “de base”.