Un éditeur de jeu de style Unity fonctionnant en WASM pur

 (raverie-us.github.io)
2 points par GN⁺ 2023-09-27 | 1 commentaires | Partager sur WhatsApp
  • Un moteur de jeu léger visant à faire revivre l’expérience de Macromedia/Adobe Flash d’autrefois
  • Conçu pour fonctionner sur toutes les plateformes, avec du WASM pur comme unique cible de sortie
  • La sortie n’inclut ni exécutable ni glue code, et n’utilise pas Emscripten
  • La liste des imports et exports est clairement définie dans PlatformCommunication.hpp
  • Une structure facile à implémenter sur n’importe quelle plateforme, y compris dans le navigateur

Aperçu

  • Un moteur de jeu léger (light-weight) qui vise à recréer l’expérience de Macromedia/Adobe Flash d’autrefois

Architecture

  • Conçu pour s’exécuter sur n’importe quelle plateforme, avec du WASM pur comme unique cible de sortie
  • La sortie n’inclut ni exécutable ni glue code, et n’utilise pas Emscripten
  • La liste des imports et exports est proprement définie dans PlatformCommunication.hpp, ce qui permet une implémentation facile sur n’importe quelle plateforme, y compris dans le navigateur

À lire aussi

1 commentaires

 
GN⁺ 2023-09-27
Commentaires Hacker News

  • Waouh, ce sont les personnes qui ont créé Zero Engine ? Je l’avais utilisé il y a longtemps lors d’un camp d’été DigiPen, et programmer en Zilch était vraiment un plaisir.
    J’avais même créé une IA qui jouait à un clone de Galaga. Avec toute l’affaire Unity, je me demandais ce qu’était devenu Zero ; je suis vraiment impatient de le voir peut-être renaître

    • Génial ! Zilch était un projet auquel je tenais énormément, donc ça me fait vraiment plaisir de lire ça :D

  • Pour ajouter un point de référence : sur un portable clairement bas de gamme avec GPU intégré, ça se comporte comme un autre superbe diaporama.
    J’ai aussi essayé sur un vieux Mate 20 Pro, et ça semblait bloqué sur « Downloading runtime ». Je ne pense pas que ce soit dû à la 4G instable : j’ai branché le téléphone au portable en USB, ouvert chrome://inspect pour examiner l’onglet, et j’ai vu l’erreur Uncaught (in promise) Error: Needs OES_texture_float_linear to function. Après, c’est une question philosophique de savoir si ça vaut la peine de créer un écran d’erreur juste pour afficher un message disant que, de toute façon, on ne pourra pas jouer avec

  • J’aime le concept. Mais mon GPU et mon navigateur pleurent à cause de la latence, et ça ressemble à un diaporama impressionnant.
    Après plusieurs tentatives, j’ai tout juste réussi à sélectionner la sphère de départ. Au début, je n’étais même pas sûr que le chargement soit terminé. Évidemment, je suis sur Firefox avec un Celeron à 1,8 GHz, un GPU intégré et 8 Go de RAM, donc on est loin d’une machine haut de gamme

    • Je serais curieux de savoir si ça tourne mieux sous Chrome. Il semble que pas mal de gens aient des problèmes avec Firefox. À l’avenir, je testerai aussi Firefox régulièrement
    • Si vous pouvez réessayer, un correctif qui améliore fortement les performances sur certaines machines vient d’être déployé.
      Comme il s’agit du portage en WASM d’un moteur de jeu natif, le problème venait du code de limitation du framerate, qui ne s’accordait pas bien avec les API de timing du navigateur : https://raverie-us.github.io/raverie-engine/
    • J’ai eu exactement la même expérience sur un M2 Pro, et j’étais aussi sur Firefox
    • Ils fabriquent encore des Celeron ?

  • Le passage « notre moteur avait une fonctionnalité unique appelée Spaces, qui permettait d’instancier des mondes/niveaux séparés » me semble correspondre exactement à ce que fait le moteur Godot[1].
    Ce moteur dispose aussi d’une cible navigateur (WASM). [1] : https://godotengine.org/

    • Il n’a pas seulement une cible WASM, il existe aussi en version web : https://editor.godotengine.org/
      Je n’ai pas l’impression que ce soit une priorité élevée pour le projet. Après quelques tests, ça semble fonctionner :), mais c’est plus lent qu’en natif
    • Je ne vois pas trop non plus en quoi c’est différent des scènes de Unity

  • Je me demande s’il existe un flux de développement WASM qui permettrait aux Web API du navigateur et au WASM pur d’interagir sans couche JS, ou avec un coût faible.
    Je consulte parfois https://github.com/WebAssembly/proposals et c’est très déroutant. La proposition d’import de types semble encore à plusieurs années de distance, et la proposition GC, presque finalisée, paraît destinée aux langages à GC plutôt qu’aux échanges navigateur↔WASM. Le modèle de composants semble éloigné des cas d’usage navigateur, et JS String Builtins accélère les chaînes JS, mais pas le DOM. L’intégration avec les modules ECMAScript transforme les modules WASM en modules ES, mais les Web API ne sont pas des modules ES, donc ça n’aide pas. En lisant les échanges des contributeurs, on a parfois l’impression que fournir ce genre de fonctionnalités n’est ni une priorité ni même prévu, et que pour la majorité, WASI et le modèle de composants pour des usages comme le cloud ou la cryptographie sont plus importants

    • Je veux vraiment ça moi aussi. J’aimerais voir un navigateur wasm pur, où la page est simplement du WASM et où le « navigateur » fournit des imports de plateforme, à la manière de WASI.
      Mais comme vous le dites, ça ne semble pas être leur priorité. J’espère que ce sera possible un jour
    • Grâce aux reference types, il est déjà techniquement possible d’appeler directement les API du navigateur. C’est parce que WASM peut recevoir et renvoyer des objets JavaScript.
      Si toutes les Web API pertinentes sont importées, les objets JS peuvent être transmis tels quels entre les appels d’API individuels, ce qui peut quasiment éliminer le JS intermédiaire. En pratique, le JS n’est vraiment nécessaire que pour initialiser le module WASM au départ
    • Le problème du WASM pur, c’est que cela pourrait mener à un Web fermé avec des publicités impossibles à bloquer
    • Je pense qu’au moins une partie de cela correspond à la direction visée par la proposition GC

  • Super projet. Existe-t-il un moyen d’agrandir l’UI sur les écrans haute résolution ?
    Sur un écran 2:1, les polices paraissent crénelées. Si je règle le zoom du navigateur à 50 %, l’UI devient nette, mais tout est trop petit pour être utilisable

    • À l’OP : la façon de corriger ça consiste à définir la largeur du canvas sur window.innerWidth * window.devicePixelRatio et sa hauteur sur window.innerHeight * window.devicePixelRatio.
      Ensuite, il suffit de maximiser le canvas à l’écran via CSS
    • Je ne comprends pas pourquoi l’UI n’utilise pas le moteur de rendu natif du navigateur, ou au moins du SVG.
      Ce serait moins coûteux en ressources (mémoire, réseau, CPU), plus facile à rendre accessible, et le rendu serait aussi plus simple

  • Trevor ! J’avais adoré l’option CS à DigiPen qui abordait la conception de langages de programmation à travers la syntaxe.
    Beaucoup des étudiants à qui tu as enseigné travaillent maintenant sur Minecraft. En concevant actuellement l’API de scripting de Minecraft, j’utilise les bases apprises à l’époque ainsi que beaucoup de choses de mes années DigiPen. Ça fait plaisir de voir que tu continues à faire des choses géniales

    • Je suis vraiment content que ça ait été utile ! Un jour, je me remettrai sûrement à enseigner ;)
      J’aimerais aussi beaucoup voir l’interface de scripting sur laquelle vous travaillez. J’ai énormément créé de mods Minecraft par le passé, et j’ai toujours voulu une forme de scripting dynamique

  • Vraiment excellent. Ça fait plaisir de voir un produit fondé sur du WASM pur dans ce domaine. Cela dit, sur mon M1 Mac Pro, ça saccade pas mal

  • J’ai une question : est-ce que ça tourne aussi sur NES ? C’est un modèle frontal reconditionné ; la plupart des pièces sont d’origine, mais j’ai ajouté un peu de RAM.
    Je l’ai collée dessus au pistolet à colle, j’ai aussi peint le boîtier en rouge et ajouté quelques figurines de soldats

    • Pourquoi l’idée de créer un convertisseur WASM > NES a-t-elle l’air réellement amusante…

  • Même avec seulement la scène de base de la balle affichée, ça tape très fort sur ma Radeon Pro 560X dans un environnement presque 4K.
    Le simple fait de faire pivoter la caméra fait chuter le framerate très bas. Quelqu’un sait s’il pourrait y avoir un problème d’optimisation WebGL ?

    • Sur mon Intel HD Graphics 620, ça fonctionne très fluidement. C’est un iGPU Intel de 7e génération, donc ancien et plutôt lent, mais j’ai été surpris de voir à quel point la scène de base avec la balle était fluide sur mon système. J’utilise Chrome
    • Si vous pouvez réessayer, un correctif qui améliore fortement les performances sur certaines machines vient d’être déployé.
      Comme il s’agit du portage en WASM d’un moteur de jeu natif, le problème venait du code de limitation du framerate, qui ne s’accordait pas bien avec les API de timing du navigateur : https://raverie-us.github.io/raverie-engine/
    • On dirait aussi que la carte graphique dédiée n’est pas utilisée. Les autres démos WebGL tournent-elles normalement ?