Ah, c'est un étrange choix de Chrome/Webkit que d'afficher la barre de navigation par-dessus la page en effet :/
Pas sûr que j'ai vraiment de solution élégante, j'essaierai de trouver.
Edit: bon, j'ai tenté un fix, mais je ne sais pas s'il marchera... Il faudrait que je mette Webkit sur mon mobile, mais ni Chrome ni Opera ne fournissent d'APK, donc, merde, je n'ai pas envie de passer par leur store à la con, alors je laisse de côté
Mais il est génial ton randomisateur d'éclair ! Xenos t'es un génie
@L'omniscient Merci
@lucard: Jean-Michel Pifométrie a donc fait du bon boulot =P
En pratique, j'avais précédemment posé la dimension et l'overflow sur le body (
body { height: 100vh; width: 100vw; overflow: hidden; }) et je l'ai reporté sur le body et sur le HTML. Je suppose que Chrome utilise la dimension du HTML pour sa fenêtre et celle du body pour son contenu, un truc du genre...
Oui, généralement je mets aussi le height: 100vh; sur le <html> car c'est le premier conteneur.
c'est bon a savoir que le problème venait de là
Salutations,
un nouveau petit "jeu" en ligne ce week end:
https://xenos.reinom.com/the-board/
C'est un "bac à sable": vous êtes sur une carte de jeu aléatoire, et vous pouvez placer des objets et des personnages dessus, puis les bouger. Vous pouvez sauvegarder votre partie, et vous pouvez également inviter un ami (ou plusieurs) à vous rejoindre. Les joueurs partagent alors le même plateau de jeu, et voient les modifications des autres (ajouts de personnages, déplacement d'objets, changement de tiles de décor, etc).
C'est basé sur les personnages de deux de mes amies, qui m'avaient suggéré l'idée. Le but principal de ce jeu, pour moi, était de tester comment synchroniser les changements entre plusieurs joueurs. J'ai tenté WebRTC d'abord, mais fail (car on est souvent derrière un NAT et il est très compliqué de connecter les joueurs entre eux). J'ai alors changé pour du ajax long polling et du HTTP chunck: 1 connexion entre le navigateur et le serveur, qui reste ouverte une petite trentaine de secondes (arbitraire), et le serveur push (flush) des infos quand il en a de nouvelles, via un chunck HTTP. C'est plutôt efficace, même si c'est pas le top (PHP d'un mutu OVH, ça ne tient pas le websocket).
Je pense en sortir un petit article pour présenter la solution, desfois que cela serve à d'autres (et desfois que ça me serve sur Variispace pour avoir les infos du jeu en "temps réel").
Sur ton petit dernier, lorsque je sauvegarde, je tombe sur une page blanche derrière. Je suis sur mozilla (je ne sais pas si ça change quelque chose pour toi). Impossible du coup pour moi de retrouver ma carte sauvegardée.
Il manquait en effet les droits sur la BDD :/
Etrange... j'étais sûr d'avoir testé que tout marchait! Soit je me suis emmêlé entre local et prod, et j'ai testé mon local au lieu de ma prod, soit j'ai oublié de tester, soit les droits ont sauté... Si cela recoince, n'hésite pas à me le signaler
[Edit]
Ah, OVH semble également s'être lancé dans un upgrade d'Apache qui passe en HTTP/2 et non plus HTTP/1.1 ce qui coince la requête d'arrière-plan pour synchroniser les joueurs... je regarde ça
[Edit 2]
C'est corrigé, et déployé. En revanche, cela m'oblige à pusher 4Ko de data inutile pour vider un cache intermédiaire (probablement dans Apache) que je n'arrive pas à trouver (et donc, que je n'arrive pas non plus à configurer correctement!). Sans compter que j'ai dû faire sauter la compression gzip d'Apache pour éviter qu'il ne bufferise tout le long-polling qui tourne derrière... Et sans compter en plus qu'OVH supportant maintenant HTTP/2, j'ai dû re-coder le Transfer-Encoding: chunked n'ayant pas encore pu mettre les mains dans HTTP/2 (qui ne supporte plus HTTP/1.1 chunked!) pour trouver la nouvelle façon de faire ça...
Bref, le long polling prend un sacré coup dans l'aile sur ce projet de test
Je ne pense pas y recourir pour Variispace du coup :/
Bah en attendant tu peux toujours faire du long-polling classique ...
C'est finalement ce que je viens de faire: en creusant un peu ce que HTTP/2 apporte, je m'apperçoit que les notions de "stream" et de "server push" n'ont rien à voir avec une connexion persistante qui me permettrait de transférer des infos (type "ce que les autres joueurs ont fait comme actions").
Donc, j'en suis revenu au long polling simple: quand le serveur a qqc de nouveau à répondre, il construit la réponse complète et l'envoie au client, ce qui "ferme la connexion" pour cette ressource. J'ai remis le gzip du coup et viré les dumb data devenues inutiles.