SpaceCraft.js

SpaceCraft.js
Je fais un peu de recyclage. J'avais déjà présenté ce projet en 2014 ICI
La différence majeur, c'est que je viens de porter ce jeu pour le web avec WebAssembly:
Demo: http://arthursonzogni.com/app/SpaceCraft.js
Git: https://github.com/smealum/SPACECRAFT

Description:
SpaceCraft est un explorateur d'univers à toute les échelles (sol, planète système solaire, galaxie)
L'univers est entièrement modifiable par le joueur et est modélisé par un empilement de blocs qu'il peut retirer pour construire des grottes ou bien ajouter pour créer des maisons et autres éléments d'architecture.
Cette modélisation est très fortement inspirée du jeu Minecraft de Mojang, et on pourrait en fait résumer ce projet comme étant de créer un Minecraft donnant accès à un univers "infini" jusqu'à l'échelle galactique..

Ah cool ça, j'ai pas encore tenté d'export en webassembly.
Ça se passe comment du coup? C'est via emscripten j'imagine? Un flag a set?
En tout cas ça a l'air de bien diminuer les temps de chargement et le poids du truc final, c'est cool.
Reste a voir le support global aussi.

Édit: Je viens de comprendre lan question. Oui avec Emscripten, pour ne plus faire de l'asmjs mais du webassembly, il suffit d'ajouter -s WASM=1.

Je suis très content de pouvoir exporter pour le web. Ça rend mes jeux plus faciles à exécuter et plus besoin de faire une build par système.

J'ai eu la chance d'avoir utiliser GLFW pour obtenir un contexte OpenGL et dialoguer avec le système. GLFW est très bien géré par emscripten.

En gros oui, c'est juste 2 ou 3 flags à ajouter. Tu peux regarder mon CMakeList.txt si tu veux.

Principalement, voici ce que j'ai fais en plus:
1) Updater mes shaders avec la bonne version et définir la précision des flottants. J'ai également eu l'infortune d'utiliser des geometry shaders, j'ai du les supprimer . Ça m'a pris un certain temps.

2) Définir comment charger fichiers contenant mes ressources (texture, shaders, ...). Évidemment on ne peut plus ouvrir de fichiers sur le web.
Emscripten gère ça très bien aussi. Il faut donner au compilateur la liste de fichiers qu'on souhaite pouvoir ouvrir et il va produire un petit fichier qui est la concaténation de tous ça. Pas besoin de modifier mon code pour les ouvrir ensuite !

3) Supprimer les threads. Ce que j'ai fais, j'ai exécuté mes tâches à la fin de la boucle principale (en IDLE Time) en fonction du temps qu'il me restait.

4) Dire a Emscripten où se trouve la boucle principale.

5) De petites incompatibilités. Par exemple, saviez vous qu'avec WebGL, les textures 2D et 3D existent, mais pas les texture 1D? Je sais pas pourquoi, mais j'ai donc du mettre mes LUTs dans des texture 2D. Pourquoi pas.

Ce que j'aimerais beaucoup maintenant, c'est de rendre la SFML compatible avec Emscripten. Au moins le module Graphique. Ainsi je pourrais exporter tous mes anciens jeux \o/

Ouai webgl, comme gles, c'est un espece de subset de gl3 je crois.
Et ouai emscripten ça poutraille j'avais fait quelques petits jeux avec, mais a l'époque y avait pas webassembly et du coup ça générait aussi un interpreteur assez lourd en full js (ça prenait quasiment 1mo et du coup ça limitait vite l'utilisation du truc a plus "large" échelle).

Je crois que les thread seront "supportés" par emscripten (si ce n'est pas déjà le cas dans un truc non officiel) en utilisant des web workers.
Perso ça m'arrangera pas mal car j'utilise un thread pour le streaming audio.

Aussi j'ai vu aussi un truc très intéressant, c'est un port de boost.asio, avec des websockets. Donc en gros on pourrait faire une appli client web qui communique avec un server C++, tout en gardant le même moteur des deux côtés. La seule difficulté étant sûrement qu'il faille faire une passerelle entre sockets <=> websockets.

Pour ma part j'utilise SDL2 ça marche nickel (et c'était supporté bien avant les versions de GLFW).
Pour SFML j'avais vu plusieurs discussions et le soucis est que la bibli ne pourrait pas être totalement portée + le fait que l'auteur n'a pas l'air vraiment intéresse a la question, du coup ça a pas trop l'air d'avancer dans ce sens.
Mais bon SFML dès qu'on dépasse le stade du fenêtrage et de la petite appli c'est pas vraiment très fournis donc bon...

Faudra que je continue le portage de mon moteur en tout cas, la dernière fois que je m'étais amusé a le faire ça remonte a quand j'étais encore sous windows
Et je n'avait pas accès a emscripten car j'étais en 32 bit (et y avait que des versions 64 bit) du coup je devais galérer sur un autre ordi pour faire le portage, bref c'était pas pratique du tout.
Le jour ou j'arrive a faire tourner centauri sur le web jsuis tout bon x)

Au niveau de la taille, c'est vraiment pas mal.
* binaire: 1600 ko
* webassembly: 400 ko

Je sais pas trop pourquoi le webassembly est plus petit. J'utilise 2 libs de moins (libnoise + libantweakbar)

--

J'ai regarder. On dirait qu'il y a un support expérimental des threads:
https://kripken.github.io/emscripten-site/docs/porting/pthreads.html

Sinon, on peut utiliser les WebWorker: (voir emscripten_call_worker). Il n'y a pas de mémoire partagé par contre.

--

Pour la SFML, ça ma l'air compliqué, mais rien d'impossible. J'ai vu certaines discussions parlant d'une personne qui aurait expérimenté SFML+emscripten avec succès. Sinon rien de bien encourageant.

--

Bonne chance pour essayer d'utiliser Emscripten avec ton moteur. Ce serait cool. Les performances sont bien meilleurs que ce que je pouvais imaginer auparavant.

Ben quand tu vois qu'unity utilise emscripten pour les exports web c'est pas pour rien =D
Et unreal tournait aussi très bien depuis un gros moment, je sais pas si tu avais vu la démo de la citadelle.

"Je sais pas trop pourquoi le webassembly est plus petit."
De ce que j'ai compris avant il fallait;
1. Compiler les instructions en un sous ensemble de javascript
2. Utiliser ces instructions avec une espèce d’interpréteur qui lui même n'était pas léger.

En webassembly déjà on ne compile plus en js (c'est un vrai binaire non l'assembly?), et y a plus besoin d’interpréteur ou équivalent puisque le navigateur s'en charge a 100%

T'as qu'a tester avec un bête hello world tu verras la différence :p
Le truc cool c'est que désormais on peut faire des technos client full C++ sans que ça impacte les perfs ou le poids de la page.

J'aurais bien voulu y jouer mais ça ne marche pas chez moi. Mon onglet chromium crashe, et sous firefox j'ai juste un semblant d'UI sur fond bleu.
C'est pas encore au point le gaming du futur

A mince Mass. Sous Firefox Est-ce-que que tu vois des étoile (ou bien un soleil)?
Si possible, ça m'intéresserait de voir un screenshot de Chrome DevTools.

Il faut OpenGL 3.0 au passage.

J'ai testé sous firefox sur une tablette sous windows 8.1 (burk), et je peut me déplacer dans le système solaire =D

Mais j'arrive pas à "atterrir" sur une planète =/
En tout cas, c'est un projet sympa =)

[TheDarkTiger]. Est ce que tu vois des planètes?
Il peut y avoir deux problème:

[Les planète sont très petites à l'échelle de l'univers]
C'est assez difficile de trouver une planète. Il ne faut pas sortir du système solaire initial, sinon il est très dur de se rapprocher suffisamment d'un autre.
Normalement, initialement, il y a une planète sur la droite (à 90°). Il faudra peut-être accélérer un peu.

[Le clavier est compliqué]
Pour ce projet, on se moquait nous même de notre gestion du clavier. Il y a plein de touches (on utilise 95% des touches)).
Si tu vole près à la surface d'une planète, la touche R permet d'attérir.

Plop =P

Vi, je voyais les planètes (tout comme je les vois sur mon pc fixe ^^)

J'avais essayé R me semble il, mais rien n'y faisait =/

J'ai du coup essayé à l'instant sur mon PC fixe, et R fonctionne =D
Mais je suis "mangé" par la planète =S
Je suis pas A sa surface, je suis DANS sa surface =P
Du coup, je peut plus me déplacer, ni en sortir, ni explorer =/

[TheDarkTiger] a écrit:

J'ai du coup essayé à l'instant sur mon PC fixe, et R fonctionne =D
Mais je suis "mangé" par la planète =S
Je suis pas A sa surface, je suis DANS sa surface =P
Du coup, je peut plus me déplacer, ni en sortir, ni explorer =/

Haha, tu m'as fais rigoler. Que dire... Désolé ! ^^

Dans le mode espace, Il n'y a pas de collisions. Dans le monde surface, il y en a.

Ho y a pas de blem =P
Tester ça sert à ça ^^