Willpower - J'ai tester ton code. Je suis en train d'essayer de le comprendre... et je te dirai...;)
NoSmoking : Si je comprend bien ton code, tu remplace mes object image() par autant d'object div... nn? un div est moins gourmand qu'une image()?
Version imprimable
Willpower - J'ai tester ton code. Je suis en train d'essayer de le comprendre... et je te dirai...;)
NoSmoking : Si je comprend bien ton code, tu remplace mes object image() par autant d'object div... nn? un div est moins gourmand qu'une image()?
Toujours en train de tester ta méthode Willpower. Merci pour les commentaires.
Par contre, comme mes textures sont en biais avec une zone transparente, j'essaye de décaler les background mais ....
Mon moteur est en 2d isométrique...
test
Impossible de modifier le background, (enfin pour ce que tu veux faire), la solution est de créer des images modifiées comme ceci :
http://www.hommk.net/img.png
Qui misent côte à côte te donnent le bon résultat :
http://www.hommk.net/test.htm
http://www.hommk.net/JEU/
merci, c'est bien ce que je pensais.
Je garde ta solution pour le cas où je ne change pas beaucoup de textures au final.
On verra, mais ta méthode est la plus rapide. Merci encore.
ce qui est fortement moins gourmand et de jouer sur le CSS en non sur le DOM, il est plus rapide de modifier la class d'un élément que les valeurs de ses propriétés, en code et en redraw du navigateur.Citation:
Envoyé par Darkyl
Ceci étant, je viens de reprendre la discussion que j'avais lue en diagonale, ton soucis est plus un soucis de méthode optimum à appliquer.
Si la "map" de fond ne te sert que de "quadrillage coloré" il est effectivement plus judicieux de mettre une image en background de la DIV, comme l'a suggéré Willpower.
dans ce cas tu n'aurais pas de chance, mais dans tout les autres cas tu resteras gagnant à ne modifier que ce qui doit être changer.Citation:
Envoyé par Darkyl
Qui plus est lors d'un rajout d'un étang tu peux encapsuler les losanges dans une DIV qui lors d'un déplacement sera la seule à déplacer.
Tu te retrouveras avec un empilage de niveau et sur chacun d'entre eux tu pourras mettre un écouteur personnalisé.
On rejoint un autre point souligné par Willpower, qui est de mettre un écouteur sur la "map" plutôt que sur chaque élément, la position sur le quadrillage étant somme toute facile à récupérer, il s'agit d'une simple équation du type y=ax. Si une couche intermédiaire récupère un événement tu le traites et tu stoppes la propagation.
Sûrement oublié des petites choses mais ...
NoSmoking : Oui, tu as raison, mon soucis est plus du point de vue de l'archi optimal à mettre en place, que d'optimisation d'une tache en particulière.
Je viens de m'en rendre compte car:
- je veux mettre des textures (par exemple une zone cultivable), hors l'image de cette zone peut être plus grande qu'une case (par exemple les tiges des herbes dépassent le haut de la case). Si je gère ces ressources primaires comme des textures, c'est pas bon, car si je veux une ressource qui fasse deux cases... pas possible, de plus, je dois impérativement gardé une image de fond sur chaque case (même rempli par un batiment) car sinon au survol de la souris, le temps de changer l'image du batiment, j'ai un léger blanc ou décalage de l'image de texture (que je viens remettre) enfin bref, comme tu vois c'est la ....:cry:
Donc, je repense l'archi et j'en viens à faire:
- une ressource primaire (bois, herbe cultivable, gisement de fer ...) sera le plus simple objet géré par mon moteur graphique. Cet objet sera en realité, un objet général (x,y,zindex,src,width,height) ->prototypé dans tous les objets construits
et un objet relatif au type construit, ici un objet ressource_primaire...
Voili, donc je repense à tous ça... Je pense qu'effectivement je vais faire la méthode du backround de Willpower au final pour le fond de mes cases.
Concernant le déplacement, je garde le scroll invisible de mon body. Donc toute la map sera créé en entière. Par contre, je testerai avant de changer une src d'une image case et de déplacer un perso, que ceux-ci soient bien dans la zone visible... Pour pas faire des choses pour rien.
Concernant les écoutes, je fais déjà un mouseover sur la map et non sur les cases. De plus l'écoute sur la map ne se fera quand mode édition, mode construction (au survol donc), sinon, en mode normale, il n'y aura qu'une écoute en onclick sur la map donc rien de gourmand en temps réel.
Je galère là avec des cours de classes javascript puis surtout, voulant rendre les ajouts de type de batiment facilement faisable, je confond bien souvent le constructeur d'un type (par ex maison) avec celui de sa possible déclinaison en objet (par ex maison 1)...
C'est de la lobotomisation en directe.
merci de ta réponse, je continu ma prospection... merci encore
N'empêche faut être barge pour faire un jeu composé de cases de forme non carré !!
Petite version hexagonale : http://www.hommk.net/JEU/
:mrgreen:
lol :ccool:
mes cases sont carrées, elles font même 30*30 mais en 3d isométrique alors pffff...
C'est vrai que ça complique pas mal le truc, enfin juste une fonction coord_3d_iso_to_2d pour transformer ma position souris dans le body en position souris dans la map...
J'y penserai pour la prochaine fois....A faire des cases carrées comme à l'armée :aie:
re,
Voilà une version de base (avec toujours la vieille méthode d'affichage de fond) mais à part cela, c'est optimisé.
lien
Je n'ai fait que survoler ce thread (intéressant, d'ailleurs :)), mais je voulais juste souligner en passant l'existence de YSlow (surcouche de Firebug) pour profiler le code JS et savoir "là où ça coince" en terme de performance.
Mais bon, vous avez l'air d'avoir déjà bien avancé, ce n'est peut-être plus très utile... disons que c'est juste au cas où. ^^
Je ne connais pas YSlow, je vais y jeter un coup d'oeil, c'est toujours bon à prendre. Merci.
J'ai fini la fonction de survol de la map et de construction de batiment.
Voici le lien.
lien
Si on clique sur un bâtiment à construire (de préf, production -> hutte de bucheron) et que l'on se ballade sur la map, la vérif des cases marchent bien mais firefox est toujours aussi lents, notamment quand on survol les herbes fertiles (prés de la rivière).
Chrome marche trés bien (l'accés au dom, $('#terrefertile_n').hide()) est toujours aussi lent sous firefox.
Si vous pouviez tester pour voir si cela vient pas que de chez moi...
chez moi firefox plante au chargement de la page ;-)
Ha bon...
Désolé, j'espère que tu n'as pas dû tout fermer...:(
Bizarre... Chez moi, firefox (v 12) marche bien, juste un peu lent.
C'est peut-être le surchargement du DOM avec mes n*m image() de fond...
Et tu as testé sous chrome par hazard? :mrgreen:
Oui je suis sous chrome (par défaut) et ça va bien.
J'ai ouvert sous firefox juste pour voir et ça plante ... ça ne charge pas les images de fond.. et firefox ne répond pas. (j'ai testé sur un vieux pc et sur mon pc plus récent avec firefox 12 et même résultat.) :?
Merci d'avoir pris le temps...:ccool:
Bon, je re-recommence tout, cette fois-ci en appliquant ta méthode pour le fond... et déjà elle est pas compatible IE...
Je commence à en avoir marre, même les style css sont mal géré par IE... ca craint.
test
note pour les wrap(zones pour cacher les cotés et les rendre oblique), je m'étais amusé pour le fun de les créer en css, pour ceux-ci une image des qqes pixels étirée à la bonne taille est peut-être plus adaptée. :ccool:
merci pour l'edit...
Heu, cela fait tout moche une petite image étirée à la bonne taille, mais je pense avoir trouvé une bonne solution.
Je tiens o jus.
MERCI (;))
nouvelle version (avec ta méthode) :
lien
Cette fois-ci, je crois que c'est la bonne.
Juste une ptite qust:
Comment laisser passer un évènement? sans l’arrêter...
derniere version
Bon, ben, merci Willpower de t'être intéressé à ce topic.
Merci à tous.
Je suis arrivé à optimiser assez bien pour l'instant donc je pense que le sujet est résolu.
Info à retenir : firefox n'aime pas du tout gérer un gros DOM... mais pas du tout. et je vais me pencher sur le lancement de tache en parallèle pour toute la gestion dite mathématique (et plus graphique) de la cité.
Encore merci à tous.
Une petite question encore:
Pour mes animations d'images, vaut-il mieux que je les gères par des gif (qui changent en fonction de l'animation que je veux) ou que je gère tout avec des png changer à la volée par setinterval?
J'aurais tendance à penser que le gif est mieux question ressources utilisés et temps de traitement non fait...
Je n'ai jamais étudié la question, mais je suis formellement convaincu que le gif doit être bien mieux pour des animations répétées.
slt Willpower,
c'est bien ce que je pensais...
Le seul hic c'est que si je veux gérer un mode pause, à moins de changer mes gif par des png, les animations continueront...
Mais c'est pas si grave. Merci de ton avis.
Je up le message car j'ai voulu passer en html5 avec canvas.
Je travaille actuellement au rendu du moteur de terrain et je suis de plus en plus décu par javascript.
nouveau moteur
http://s408852608.onlinehome.fr/test...-d-ecran_2.jpg
Qu'est-ce que cela va être qu'en je vais appliquer mes textures...
Pourtant, je fais tous (pour l'instant avec des lineto) mais il est déjà (au vu) des performances impossible d'essayer de rafraichir l'image en temps réel.
Il y a t-il un moyen d'accéler l'accés et le traitement d'un canvas? ou une astuce...
Oui laisser tombeer canva qui n'est pas fait pour faire du rendu 2D pas plus que word/vba
mais utiliser webGL.
et tout cela n'a rien a voir avec le langage
si tu utilise C et le canevas 2D de windows pour faire un moteur de rendu 3D
au mieux en une semaine tu affiche un paysage simple.
il ne faut pas confondre le langage et la techno que tu utilise pour dessiner.
ce n'est pas par hazard qu'on en est venu à faire des GPU et ce n'est pas par hazard que M$ à pondu DirectX pour l'utiliser ni que Linux et consors ont pondu OpenGL. le processeur généralise de ton PC ne fera jamais de rendu 3D en temps réel et ceux même avec le langage le plus performant.
A+JYT
pour les animations il y a aussi la methode des sprites qui permet dans un setInterval de modifier non pas l'image, mais sa partie visible...
houla, pas mal !
par contre je ne pourrais plus t'aider, ça sort totalement du domaine de mes compétences. ;)
sekaijin : Je me souviens à l'époque avoir fait un moteur de jeu 3d iso en delphi (pascal), qui était le même principe que celui que j'ai montré. Il dessiné sur une form et tout était calculé par mes soins sans passer par des biblio tierce ou processeur graphique, j'arrivais à rafraichir la map sans scintillement, le tout en recalculant tout et reaffiché chaque image en temps réel...
Heu tu veux dire 3d, nn? parce que sinon je comprend plus rien. (je croyais que justement canvas servait à cela...Citation:
Oui laisser tombeer canva qui n'est pas fait pour faire du rendu 2D pas plus que word/vba
Concernant Webgl, je ne trouve pas de tuto digne de ce nom (et suis nul en Anglais, oui je ais faudrait que je mis mette :aie:).
SpaceFrog
Tu peux développer un peu plus? Un sprite n'est qu'une image non?Citation:
pour les animations il y a aussi la methode des sprites qui permet dans un setInterval de modifier non pas l'image, mais sa partie visible...
Donc si je remplace sprite par image dans ta phrase, je comprend pas ce que tu appelle la méthode des sprites...
Mais ça m'intéresse.
De plus, je n'ai pas besoin d'actualiser la map en temps réel, elle sera crée et affichée en début de parti et ces tout.
J'avoue par contre avoir du mal à saisir les notions d'effacement d'une partie du dessin, de "zindex" des image drawer dedans et tout, bref ce qui permet d'optimiser tout cela.
Mais je continu mo apprentissage (mon but étant de rentrer dans la nouvel ère du web :ccool:).
Si vous connaissez des bon cours webGL? J'ai firefox 12, il est pas compatible...
Willpower, c'est pas grave, tu m'as déjà bien aider, merci d'être venu jeter un oeil...
Chez moi ta map fonctionne bien.
La mer se dessine instantanément sous chrome et firefox et s'efface après un délai d'environ : 1 sec sous firefox et 0.3 sec sous chrome.
La mer étant une surface en théorie "plate", tu peux placer une simple image .png par dessus ton canevas pour cacher la zone où doit se trouver celle-ci, par une zone bleue et le reste de ton image transparente. (note, ton image, bien qu'en "position absolute", devra se trouver DANS les balises de ta map pour laisser les évènements se propager correctement vers cette dernière.)
Dans cette optique, les sprites qui n'ont rien à voir avec le canvas peuvent devenir utile pour limiter le nombre d'images chargées.
Enfin, le z-index sert à définir a quel niveau de superposition se trouve l'élément, autrement dis, celui qui aura le z-index le plus élevé, sera au premier plan et cachera ceux derrière. Note que le z-index ne fonctionne que pour les élément du DOM sortis du flux d'affichage logique, typiquement ceux qui ont la propriété de style : position:absolute;;)
oui un sprite est une image ...
le principe du sprite est basé sur le dessin animé ...
voici un exemple
http://www.developpez.net/forums/d90...-dessin-anime/
Oui sauf que la map n'est pas la même à chaque fois, beaucoup de random() :aie:. Donc la mer est calculé sur la map... Mais surement qu'à terme, la map sera fixe (pas de random, là c'est plus un générateur de terrain), donc oui j'appliquerai ta méthode.Citation:
tu peux placer une simple image .png par dessus ton canevas pour cacher la zone où doit se trouver celle-ci,
Concernant les zindex, oui je sais ce que sait (tu pense bien qu'avec la version précédente du moteur et les image()), je gérais déjà toute la hiérarchie d'affichage par zindex mais là où je bloque, c'est la notion de zindex avec des images drawer dans canvas, sans composant image().
Mais j'ai vite survolé cette partie, je vais mis plonger.
A put****, je comprend plein de truc maintenant. Je croyais que la propagation d'événement se faisait sur les objets dont l'affichage était dessus-dessous et non l'implémentation dedans/dehors... :aie:Citation:
(note, ton image, bien qu'en "position absolute", devra se trouver DANS les balises de ta map pour laisser les évènements se propager correctement vers cette dernière.)
SpaceFrog, je vais voir ton lien, merci