24-01-2013, 11:52 PM
Pour la D&D, on connait le point de départ et la position du curseur à la date T. On connait la taille de la carte en pixels et en case, on peut donc faire le ratio: la souris se déplace de x pixels, avec P pixels par case, donc on se déplace de x/P cases. On sait quelle est la case centrale de la carte au départ, on sait donc quelle sera la case centrale après déplacement.
Pour le déplacement par bord d'écran (ou par les flèches), il suffit de calculer la durée de la requète précédente, admettons, S secondes. On connait la vitesse maximale V de déplacement. ON sait donc qu'au plus, en moyenne, on se déplacera de V*S cases. On charge donc une carte qui contient S*V cases de plus à droite, gauche, haut et bas.
Si tu as bien conçu ta carte, tu peux faire un document xml léger avec de très nombreuses cases, récupéré par le javascript.
Les anciennes cases hors écran sont virées du DOM, mais pas du contenu des variables javascript
On peut donc ainsi avoir une page web légère, mais si on revient sur les cases déjà vues, le javascript a conservé les données en cache.
120*120=14.400 oui, mais si c'est un simple tableau javascript, cela peut passer. De plus, qui te dit que sur ce carré de 120x120, toutes les cases ont été vues?
Enfin, si tu as peu de types de case, intéresse-toi aux octrees (dans la 2D, on appellera ca des quad-tree). L'idée est très simple:
On considère que la carte est un carré de 2^n par 2^n éléments. Par exemple, 128x128. Si, parmis tous ces éléments, 2 ne sont pas identiques du point de vue d'une donnée (par exemple, pas le même joueur qui possèdfe la case, ou pas le même type de sol, etc), alors on découpe ce carré (qu'on appellera le carré de niveau 0) en 4 sous-carrés (carrés de niveau 1) de 64x64 cases chacun. Et on recommence.
On obtient ainsi une structure arborescente qui regroupe les cases identiques (ce principe est utilisé aussi en compression d'image).
En 3D, ca donne ca
![[Image: 400px-Octree2.svg.png]](http://upload.wikimedia.org/wikipedia/commons/thumb/2/20/Octree2.svg/400px-Octree2.svg.png)
(je cite plutôt la 3D car c'est ce à quoi j'ai eu recours durant mon stage ingénieur de cet été).
Si la carte présente une forte répétition d'éléments, cela peut réduire la taille des données à transférer.
Enfin, je rappelle que ces données sont assez légères point de vue javascript, et donc, cela ne rame QUE parceque tu essaie d'AFFICHER 120x120 cases, pas parce que tu essaie de gérer 120x120 cases.
Rien ne t'empêche, sinon, de faire un fichier xml ou json coté serveur avec les données statiques ou quasi-statiques de toutes les cases de la carte, et de laisser le navigateur aller récupérer ce xml. Le navigateur devrait, normalement, mettre le document en cache assez rapidement, et donc, tu n'auras plus de gros transfert.
Pour le déplacement par bord d'écran (ou par les flèches), il suffit de calculer la durée de la requète précédente, admettons, S secondes. On connait la vitesse maximale V de déplacement. ON sait donc qu'au plus, en moyenne, on se déplacera de V*S cases. On charge donc une carte qui contient S*V cases de plus à droite, gauche, haut et bas.
Si tu as bien conçu ta carte, tu peux faire un document xml léger avec de très nombreuses cases, récupéré par le javascript.
Les anciennes cases hors écran sont virées du DOM, mais pas du contenu des variables javascript
On peut donc ainsi avoir une page web légère, mais si on revient sur les cases déjà vues, le javascript a conservé les données en cache.120*120=14.400 oui, mais si c'est un simple tableau javascript, cela peut passer. De plus, qui te dit que sur ce carré de 120x120, toutes les cases ont été vues?
Enfin, si tu as peu de types de case, intéresse-toi aux octrees (dans la 2D, on appellera ca des quad-tree). L'idée est très simple:
On considère que la carte est un carré de 2^n par 2^n éléments. Par exemple, 128x128. Si, parmis tous ces éléments, 2 ne sont pas identiques du point de vue d'une donnée (par exemple, pas le même joueur qui possèdfe la case, ou pas le même type de sol, etc), alors on découpe ce carré (qu'on appellera le carré de niveau 0) en 4 sous-carrés (carrés de niveau 1) de 64x64 cases chacun. Et on recommence.
On obtient ainsi une structure arborescente qui regroupe les cases identiques (ce principe est utilisé aussi en compression d'image).
En 3D, ca donne ca
(je cite plutôt la 3D car c'est ce à quoi j'ai eu recours durant mon stage ingénieur de cet été).
Si la carte présente une forte répétition d'éléments, cela peut réduire la taille des données à transférer.
Enfin, je rappelle que ces données sont assez légères point de vue javascript, et donc, cela ne rame QUE parceque tu essaie d'AFFICHER 120x120 cases, pas parce que tu essaie de gérer 120x120 cases.
Rien ne t'empêche, sinon, de faire un fichier xml ou json coté serveur avec les données statiques ou quasi-statiques de toutes les cases de la carte, et de laisser le navigateur aller récupérer ce xml. Le navigateur devrait, normalement, mettre le document en cache assez rapidement, et donc, tu n'auras plus de gros transfert.