| Version imprimable du sujet
Cliquez ici pour voir ce sujet dans son format original |
| Forum TourDeJeu > Design et graphismes > Superpositions D'images... |
| Ecrit par: bibi.skuk Samedi 04 Juin 2005 à 15h49 |
| Bonjour à tous, Je suis en train de faire une map en 2Disométrique pour un jeu en php... Le problème est que lorsque que je veux positionner les décors, ca merde royalement... Pour l' instant, j'ai 2 types d'arbres, des simples, et un petit bouquet. Les voici : http://dev.tdl.free.fr/isomap/img/decors/arbre.png http://dev.tdl.free.fr/isomap/img/decors/arbre2.png quand je veux les inclure sur la maps, le premier marche sans probleme, mais su 2eme, on ne voit que le dessus... J'ai essayé de spécifié la taille exacte des images dans les attributs de style, de placer des z-index en me disant que si ca se trouve, il est superposé, mais rien ne marche... Chaque case est un div avec un background-image correspondant à la texture, les decors c'est la même chose... Je ne comprend pas comment cela se fait-il que cela ne marche pas... http://dev.tdl.free.fr/isomap Merci de vos réponses... |
| Ecrit par: -=[ X-ZoD ]=- Samedi 04 Juin 2005 à 16h11 |
| bha deja moi je dit bravo poru la carte jla trouve plutot zoli...je crois que vai en faire un e en iso aussi...car la mienne et trop basique... enfin bon ..heu....je vai a la post, pis à coty....et kan je rentre j'essai de voir ça....sinon je suis presque sur que ce sont les attributs de taille....enfin je regarde kan je re .. a taleur |
| Ecrit par: bibi.skuk Samedi 04 Juin 2005 à 16h17 | ||
Je viens de reverifier mon code... J'ai oublié de specifier px dans mon attribut width et height... ca marche vachement mieux tout à coup... Bon, j'ai toujours un probleme à cause du fait que les tiles ne sont pas parfaitement alignés... |
| Ecrit par: Nonothehobbit Samedi 04 Juin 2005 à 16h25 |
C'est bien foutu.  Tu devrais peut-être faire des bordures plus fines, de 1px au lieu de 2, c'est un peu épais par rapport à la taille des cases. Autre chose, je sais pas si c'est prévu mais utilise des classes css pour chaque type de case au lieu de spécifier en dur les images dans chaque div. Vu le nombre de cases, tu économisera de précieux Ko.  Sinon c'est très joli. |
| Ecrit par: Corentin Samedi 04 Juin 2005 à 16h27 |
| Pas parfaitement alignées ? Je vois pas trop ce que tu veux dire... Tu parles des cases dans la mer dont les bords semblent plus épais ? Ca c'est probablement un bête problème graphique de ta tile non ? Marrant comme ça ressemble au jeu que je suis en train de faire, mais en même temps tous les jeux en isométrique se ressemblent un peu. Juste un screen pour juger de la ressemblance : http://img48.echo.cx/my.php?image=screen47wz.jpg |
| Ecrit par: bibi.skuk Samedi 04 Juin 2005 à 16h28 | ||
il n'y a qu'un seul pixel normalement, mais il faut que je fasse des ajustements... C'est pas évident de trouver des formules de positionnement qui marchent dans tous les cas... edit : de plus actuellement ma page est beaucoup trop grosse... il faut que j'optimise tout ca... je pense pouvoir descendre à 10ko sans decors...( la je suis à 90...) |
| Ecrit par: Nonothehobbit Samedi 04 Juin 2005 à 16h30 |
| Il faut que tu retire 1px au positionnement des div, comme ça les bord seront superposés et non plus collés (ce qui leur donne l'épaisseur de 2px). |
| Ecrit par: bibi.skuk Samedi 04 Juin 2005 à 16h32 | ||
Mais, c'est de l'html la ?? @nonothehobbit : oui, c'est ce que je suis en train de faire... |
| Ecrit par: Corentin Samedi 04 Juin 2005 à 16h33 |
| Non non, le mien repose sur un client téléchargeable, mais ça se ressemble quand même vachement non ? |
| Ecrit par: Nonothehobbit Samedi 04 Juin 2005 à 16h37 |
| Bah, ce qui est ressemblant ce sont les cases de même taille bordées de noire, classique de l'isométrique. C'est pas si étonant, non ? |
| Ecrit par: bibi.skuk Samedi 04 Juin 2005 à 16h41 | ||
Ca y ressemble, effectivement... on a sensiblement les mêmes taille de cases, et des bordures noires... J'aime bien l'idée du client (Flash ?) Mais en fait, le but pour moi est de faire ca en html pur... |
| Ecrit par: bibi.skuk Samedi 04 Juin 2005 à 17h24 |
| Je cherche de plus à gagner de la place au niveau de mon code html, quelqu'un à-t-il une idée... Par exemple, pour utiliser autre chose que des div... (un truc qui prenne moins de place...) J'ai pensé à hr, mais cela va sembler assez bourrin et cela ne marchera surement pas... En gros je cherche une balise du genre <quelquechose /> qui me permette de faire la même chose... p.s. : l'optimisation avance... j'ai deja gagné 40ko... |
| Ecrit par: Vorgat Samedi 04 Juin 2005 à 17h38 |
| Je crois que <span> fait la même chose que <div>, mais c'est une balise de type inline. |
| Ecrit par: bibi.skuk Samedi 04 Juin 2005 à 17h40 | ||
oui, mais avec span, je ne gagne sur la taille... je perd même 2octets par case que j'affiche... ca qui en l'occurence, pour cette carte la me fait 1,8ko en plus... |
| Ecrit par: bibi.skuk Samedi 04 Juin 2005 à 18h33 |
| hem... je viens de faire un petit test... sous ie... et bien, surtout ne regardez pas la page avec... c'est affligeant... |
| Ecrit par: Nonothehobbit Samedi 04 Juin 2005 à 20h13 |
| A part utiliser mettre les paramètres width et height dans les classes des décors, tu ne peux plus rien faire pour le html je pense. Tu pourrais t'amuser à utiliser une balise d'un seul caractère (a, b, i...) à la place du div, mais bon ça devient un peu crade pour pas grand chose. En ce qui concerne le problème d'ie, c'est parce que tu utilise des png24-bits, dont la transparence n'est pas gérée sous ie. Vu que ce sont de petites images, je te conseille de les passer en 256 couleurs et de les sauvegarder en png8-bits. Ca réduira leur poids, et ça ne fera plus de bug sous ie. |
| Ecrit par: bibi.skuk Samedi 04 Juin 2005 à 20h33 | ||
ben oui, au temps pour moi ca sera beaucoup mieux... pour les balises, mouaif, je peux plusrien faire, je m'en doutait bien... |
| Ecrit par: zumba Samedi 04 Juin 2005 à 21h49 |
| ou en gif. Permet en plus d'animer le décor. |
| Ecrit par: Nonothehobbit Samedi 04 Juin 2005 à 22h22 |
| Ah oui Zumba, c'est vrai. A quand les png animés ????  |
| Ecrit par: bibi.skuk Dimanche 05 Juin 2005 à 00h02 | ||
le Gif, pour moi , c'est définitivement non ( format propriétaire... etc...) @nono : le png, ca peut etre animé, mais il n'y a pas vraiment de standard en la matière... Et puis de toute manière, pour moi le petit dessin animé, je trouve cela particulierement moche... et insupportable... plutot que de voir un personnage pietiner sur place, je prefere voir un personnage fixe... L'html est statique, les images devrait l'etre aussi... je laisse le soin des animation à flash, etc... |
| Ecrit par: Corentin Dimanche 05 Juin 2005 à 00h06 |
| Au fait, puisque tes arbres font partie de tes tiles ça veut dire que tu ne pourras pas faire passer un perso (par exemple) derrière l'arbre, comment vas-tu gérer ça ? Moi j'ai finalement des terrains (les tiles) et des décors que je mets dessus (arbres...). Ca pose problème pour le relief, puisque ça veut dire qu'on ne peut pas passer derrière une colline par exemple (puisqu'elle est en tiles). Ca fait quand même des grosses limitations, mais c'est encore ce qui m'a parru le plus simple |
| Ecrit par: Nonothehobbit Dimanche 05 Juin 2005 à 00h09 |
| Non si tu regarde bien, les arbres sont superposés aux tiles. |
| Ecrit par: Corentin Dimanche 05 Juin 2005 à 00h22 |
| Ah voui ! Suis-je bête ! Ca me rassure qu'on ait fait pareil, ça veut dire que mon système n'est pas trop trop mal foutu |
| Ecrit par: Saikoh Dimanche 05 Juin 2005 à 10h08 |
| J'aime beaucoup cette map en iso. Je m'y suis moi même essayé, mais c'était beaucoup moins concluant. Par contre si les arbres sont petits comme ça, il va falloir que le personnage soit minuscule pour respecter l'echelle ? |
| Ecrit par: Nonothehobbit Dimanche 05 Juin 2005 à 10h58 |
| T'as déjà vu un jeu en iso qui respectait l'échelle ? Que ce soit un rpg, un jeu de stratégie, un wargame, aucun ne respecte l'échelle ( à part peut-être des exceptions). |
| Ecrit par: bibi.skuk Dimanche 05 Juin 2005 à 11h22 | ||
Pour l'instant, c'est un test... Je ne sais pas trop comment je vais gerer tous mes problemes d'echelle, etc... @corentin : ca serait beaucoup trop genant pour le graphiste(moi en l'occurence) de devoir faire des arbres pour chaque texture de fond... donc, c'est une image par dessus le tile... Je veux ensuite jouer par la suite sur les z-index pour avoir des superpositions... Mais bon, pour l'instant, il faut deja que je finisse toutes les series de calculs (parce que la c'est pas encore au point) et que je fasse l'autogeneration de la route... |
| Ecrit par: Kévin Dimanche 05 Juin 2005 à 11h31 |
| je me permet de poser une petite questions au passage, les maps iso (type smile war ,adept), ne sont-elles pas plus gourmandes en bande passante ou/et en requètes que les maps version Démange (tableau / div) ? |
| Ecrit par: Saikoh Dimanche 05 Juin 2005 à 11h50 | ||
J'aimerai bien y arriver, enfin sans non plus être perfectionniste, mais au moins que mon personnage soit pas plus grand ou aussi grand qu'un arbre.  |
| Ecrit par: naholyr Dimanche 05 Juin 2005 à 11h54 | ||
Si elles sont plus gourmandes c'est surtout en temps de programmation. Au final les images sont les mêmes (en tous cas sensiblement du même poids), et le poids final dépend surtout du nombre de cases affichées, qui est le même dans les deux cas C'est surtout qu'une map en 2D est beaucoup plus facile à développer/maintenir/optimiser parce qu'on se la représente plus facilement. Mais dans les deux cas une map non optimisée arrive très vite aux 30Ko-50Ko de code (sans compte le poids des images donc). Après optimisation (l'idéal c'est de générer en PHP un tableau Javascript et de faire la procédure d'affichage en Javascript) on réduit facilement de 95% suivant les méthodes. |
| Ecrit par: Kévin Dimanche 05 Juin 2005 à 12h42 |
| Je te remercie de l'info . Je suis bon programmeur PHP, mais j'ai peu d'expérience en JS, je verrais donc plus tard quand j'aurais le temps, si je peux faire ça... |
| Ecrit par: zumba Dimanche 05 Juin 2005 à 13h00 | ||
héhé c'est exactement ce que j'ai fait. Il est vrai que c'est une sacrée optimisation de la bp vu qu'on a pas à appeller une page du serveur qui va generer une image a chaque déplacement. Le revers de la médaille c'est que le développement est BEAUCOUP plus compliqué. Nottament les notions de synchro entre la carte client en JS et les données de la carte générale stockée sur le serveur. Mais c'est faisable ! j'avais écris un long post sur cette méthode avec le pour et le contre, l'année dernière mais je le retrouve plus. A la limite si tu ne connais rien au JS/css, pars directement sur du flash pour ton moteur de carte côté client, c'est encore plus compliqué pour certains aspects mais bien plus rapide que du js (on bosse là dessus actuellement et c'est prometteur). |
| Ecrit par: bibi.skuk Dimanche 05 Juin 2005 à 14h38 | ||
Actuellement, ma carte, fait 6ko si je n'affiche qu'une zone de 10*10 (ce qui sera fait au final...). De plus, si on n'utilise pas de base de donnée pour stocker les infos de la map, on gagne enormement de temps... Si c'est le probleme de la taille qui te gène, tu peux changer la taille de tes tiles (voir http://dev.tdl.free.fr/isomap/test128.php pour un affichage plus grand) Quand au fat que c'est plus dure de se representer une carte en iso qu'en 2D, il faut simplement prendre son temps, tester correctement ses formules... et ca passe tout seul... j'ai obtenu l'apparence generale de ma carte en moins d'une heure... Pour placer les decors, c'est une autre affaire, mais ce n'est pas la mort. |
| Ecrit par: bibi.skuk Dimanche 05 Juin 2005 à 17h56 |
| Bon,maintenant, les routes marchent aussi... il faut que j'ajoute des elements de decors... et que je gere les superpositions... |
| Ecrit par: zumba Lundi 06 Juin 2005 à 15h14 | ||||
Là encore je ne dirai pas le contraire !! d'ailleurs une bdd n'est fondamentalement pas faite pour stocker une info de structure matricielle !
bon alors ca ca me <pas de pub, hein ?>démange</pas de pub, hein ?> un peu au niveau du vocable. Pour l'instant, telle que je la vois, ta carte c'est de la 2D toute bête, tout comme la mienne d'ailleurs ou celle de sombre destin qui sont concues comme toi sur une matrice losange. Ce n'est pas parce que tu pars d'un losange sur lequel tu plantes un arbre droit, et pas d'une matrice "carrée" comme par exemple dans ideo pour ne citer que lui, que tu peux dire que ta carte est en 3D iso. Elle sera 3d iso a partir du moment ou tu arriveras à tirer des arretes orthogonales au plan de ton sol, et ainsi generer un véritable relief. Déjà ca implique une 3 eme coordonnée "Altitude" au niveau de chaque point de jonction entre 2 losanges. Une vraie carte 3d iso, pour citer la référence de cette technique, c'est celle de populous (les jeunes n'ont pas connu !) et crois moi c'est déjà une autre algorithmique à développer (calculer les plans d'incidence selon les deltas d'altitude, la nature du sol avec différentes expositions à la lumière, etc etc...BONNE CHANCE !! au début je voulais faire ma carte comme ca mais j'ai dû abandonner tant c'est compliqué a adapter surtout en web. Bon en bidouillant bien je suis parvenu a simuler des falaises droites mais c'est pas parfait niveau perspective. Je crois que, à ce jour, la seule carte en vraie 3d iso que j'ai vu tourner c'est celle de gorgu, il nous confirmera ! |
| Ecrit par: bibi.skuk Lundi 06 Juin 2005 à 20h45 |
| je n'ai jamais pretendu faire de la 3d, iso, je veux juste essayer de faire une petite carte en iso... Je n'arriverait pas à gerer le relief, j'en suis parfaitement conscient... Je vais essayer, mais je suis quasi certain de n'arriver à rien...( ou alors si, mais trop lourd...) |
| Ecrit par: Nonothehobbit Lundi 06 Juin 2005 à 20h54 |
| Le problème du relief dans les cartes statiques comme ça c'est que la hauteur masque des cases. Le seul moyen pour palier à ça serait de pouvoir tourner la carte, avoir plusieurs angles. Pas très adapté au format web (flash à la limite)... |
| Ecrit par: khiguard Mercredi 22 Juin 2005 à 23h03 | ||
Tu a faux zumba :
Oui la 3D isométrique est bien de la 2D mais ce n'est pas parce que tu utilise des coordonée de hauteur. A la rigueur, ton exemple serais plus porter vers le moteur 3D: tirer des polygones. Maintenant, je reconnais que le moteur de SD n'est pas satisfaisant, mais c'est bien de la 3D iso. Tu est sure que populous utilisait un moteur de calcul? Car de ce que je me souvient pour l'époque, c'était une bêtes projection de tiles avec des script qui calculais la hauteur. Sinon pour le sujet (que je viens juste de voir ) je prefere le GD a l'utilisation de DIV, pour cause, la bande passante, la lourdeur des pages (essayer de lire une page avec des DIV sur un p2)@+ |
| Ecrit par: naholyr Jeudi 23 Juin 2005 à 11h32 | ||
Les DIV permettent l'utilisation de kits d'images téléchargeables pour réduire le besoin de BP. Si vraiment c'est critique l'installation de ce kit peut devenir obligatoire ou fortement souhaitable pour l'utilisateur (on laisse des images très basse résolution sur le site, et on met les belles images dans le kit). Avec ce système, et le cache du navigateur s'il est bien géré, on arrive à des taux absolument ridicules, ce qui n'est pas du tout possible avec la solution GD. |
| Ecrit par: khiguard Jeudi 23 Juin 2005 à 11h41 |
| Je prendrais l'exemple de SD, avec une image qui génére plus de 50 images différente par affichage et 5 couche sussessive, j'en ai maximum pour 20KO l'images générer, et ca va aussi vite sur un p2 que sur des pc 56K. Les DIV sont lourd a l'affichage, je ne parle pas seulement des images, mais également des traitements des DIV par le navigateur. Pour un jeux comme SD, il faudrais 5 couche de DIV pour arriver a afficher certaine carte. J'ai déjà fait le test avec des DIV, la performance est lamentable. Oui, avec un kit graphique ca économise la BP, mais combien de % de joueur l'utilisent? J'ai un moteur, qui genere pres de 200 case par couche, et bien en GD il va aussi vite que la carte de SD (9*9 case) et sans prendre plus de mémoire. L'image fait 448*336 et est remplie. Elle fait a peine 20Ko. @+ |
| Ecrit par: Nonothehobbit Jeudi 23 Juin 2005 à 16h15 |
| Ouais mais les process trinquent et faut une machine pour assurer derrière. ^^ Si la map d'ideo était en GD, le serveur serait mort. |
| Ecrit par: zumba Jeudi 23 Juin 2005 à 20h57 |
| idem. tiens je pensais qu'ideo faisait sa carte en gd moi. c'était pas le cas au début ? elle est faite en js / css/ div alors ? sinon pour en revenir a la définition de l'isométrie khiguard tu m'as mal compris : bien sur que c'est de la fausse 3D à base de 2D, avec des sprites à plat qui simulent une élévation / dénivélation/stagnation générant l'effet de hauteur, néenmoins le choix du sprite est conditioné par le dirac, ou plutot le +/0/- des 4 cases autour. On a donc en x,y la valeur de la case (herbe, terre, bonbons haribo) + la notion de "ca monte ca stagne ca descend" qui détermine si on va afficher un pan plat, montant ou descendant d'herbe de terre ou de fraises tagada. |
| Ecrit par: Nonothehobbit Vendredi 24 Juin 2005 à 10h14 |
| Nan, c'est bien du html/css/js. Faut dire que sur la map on a beaucoup plus d'élément interactif que celle de sd par exemple où on ne peut cliquer que sur une case. Avec une map gd il faudrait définir tout un tas de zone invisible calées sur l'image, pas pratique. Alors qu'avec html/css/js, il suffit de lier l'événement à l'élément html. ^^ Bref, à chaque carte son implémentation, tout dépend de l'utilisation qu'on souhaite en faire. |
| Ecrit par: khiguard Vendredi 24 Juin 2005 à 11h47 | ||
Tu n'a pas vu les derniere mise a jour alors Ce n'est plus le cas j'utilise pas mal de DIV pour décrire les cases lorsque la souris passe sur la case. Maintenant, il est clair que si le traitement de la carte prend déjà pas mal de temps, je ne vais pas non plus en rajouter des tonnes. Sinon, il faut pas croire qu'utiliser le GD est une erreur, il faut simplement savoir programmer comme il faut. Maintenant non, comme je l'ai dis sur un autre post, on programme les outils en fonction des besoins, pour 1000 joueurs par jour, le GD n'est pas du tout l'outils idéal. Par contre pour continent, ca le serais (mais il faudrais remanier quelques trucs.) Si j'arrive a gerer une carte sur un mutualisé avec autant de traitement que maintenant pour 200 à 300 joueur / jour, continent devrait s'en sortir sans problème. LE GD est l'idéal pour un jeu qui demande beaucoup de traitement mais n'aura pas beaucoup de joueur (je pense que 500 par jour est un maximum). Et la programmation est facile. Il y a des astuce pour ne pas mettre le serveur a genou: ne pas déclarer plusieurs fois la meme images, ect... Mais tant que je te tiens Zumba, je suis impatient de voir le traitement par flash de continent, car le moteur actuel est super lent (sur toute mes machines, et je n'ai pas que des p2 ). J'ai même fait des tests de moteur semblable en GD, même si ca aurais été plus lourd niveau proc et mémoire, niveau client ca aurais été 10 fois plus vite.Et tant que je vous tiens tout les deux: 20 jour d'abscence pour éffacement de compte c'est trop cours. je suis rester 21 jours sans me connecter, vous avez du entendre mon cris de désespoire quand j'ai ouvert ma boite lors de mon retour et que j'ai vu : compte idéo et continent éffacer la veuille!! haaarg! @+ |
| Ecrit par: Nonothehobbit Vendredi 24 Juin 2005 à 12h10 |
| Tiens du coup je me pose une question : comment vous faîtes dans une carte isométrique pour qu'une case soit réactive étant donné qu'elles sont en losange et que les blocs html sont forcément rectangulaires. A part les <map> ou l'utilisation de filtre IE, je voie pas... PS : pour ideo, on a un mail au bout d'une semaine sans jouer et 2 semaines à partir du mail pour se reconnecter. Ce qui fait donc un minimum de 3 semaines. Seuls les niveaux < 5 sont supprimés (ça évite les pertes malheureuses). Et étant donné que le script de nettoyage est activé manuellement quand j'y pense, on a en général plus de temps que ça. |
| Ecrit par: khiguard Vendredi 24 Juin 2005 à 12h21 | ||
J'était niv 9. Tant pis, quand j'aurais le temps je me réinscrirais, mais j'ai plus trop envie de remonter un perso  mais je voulais surtout prendre mon perso pour faire un test pour gameplay en fait. Même chose pour continent.Ben oui, avec le GD tu cree une image, donc tu cree une map pour cette image (en polygone). LE reste on joue avec le JS. @+ |
| Ecrit par: bibi.skuk Vendredi 24 Juin 2005 à 19h32 | ||
C'est ce que je suis en trainde faire en ce moment, on créé une image vide (aie...) et on fait une <map> dessus... Pas le choix autrement... @khiguard : ma carte s'affiche sans problemes sur un P2... ( c'est la machine sur laquelle je developpe...) |
| Ecrit par: zumba Mardi 28 Juin 2005 à 13h47 | ||||
j'ai pas compris. ou alors tu parles en GD ?
merci pour tes conseils mais je crois que tu n'as pas le recul suffisant pour de telles affirmations. Pour continent il faut une machine de 2 ans max. Perso j'y joue sur un athlon xp 1200+, ca rame, c'est le minimum mais c'est jouable, ou sur un centrino 1.3 et la c'est hyper rapide. En carte standard, 1/4 de secondes pour bouger. Maintenant sur une machine plus faible, tu peux baisser la qualité et surtout retirer les effets météo. Enfin, ca va peut être te faire mal mais chez moi entre firefox et IE ca va du simple au double en vitesse. D'autres personnes m'ont dit que c'était plus rapide sous ff ou netscape 7, nottament sur les machines plus faibles (mais dans tous les cas IE l'emporte haut la main sur le glisser/déplacer des fenetres DIV, il doit y avoir une optimisation hard sur le layering dans IE, car meme avec la transparence, c'est instantané). Donc continent est gourmand, c'est un fait, je ne l'ai jamais nié, mais en revanche en GD c'est tout simplement impossible. Mon premier moteur était en GD. En carte standard, on utilisera entre 4 et 600 images : GD ne suivait pas, je dois avoir encore les scripts de ces essais. Qui plus est, et c'est le plus important et vous omettez bien de le dire, en GD, il n'y a pas de buffering de la carte côté client de possible. Donc dialogue client serveur A CHAQUE DEPLACEMENT, ce qui dans mon cas exploserait la BP, qui est déjà limite (réservée donc pour le forum et le reste de l'interface !). Imagine que pour faire la meme chose dans un cas tu envoies un tableau de donnée destiné a fabriquer une image, et dans l'autre tu envoies carrément l'image. Pour un jeu de stratégie ou le refresh serveur n'est pas une nécéssité, le buffering est une réelle optimisation. En GD qq soit la rapidité de la génération de la carte coté serveur, il y aura tjr un temps incompressible pour le dialogue http qui peut etre d'une demi seconde au mieux du mieux à plusieurs secondes en cas de charge. incompressible QQ SOIT la config du client. Dommage de priver les possesseurs de p4 d'une vitesse supérieure je trouve. En GD tu n'as pas non plus d'animation possible des éléments de la carte, le pointage des éléments est bcp plus complexe (moi je fais comme nono, du onXXX sur les img)... Et il y a plein de cas ou il est inutile de refaire toute l'image pour n'en changer qu'un morceau (gd t'obblige à tout repeindre : ex : quand on on déplace une troupe, quand on pose un bâtiment... bref la liste est longue en défaveur du GD mais crois moi sur le critère de la vitesse d'affichage, je ne pense pas que gd l'emporte sur une machine récente. C'est un choix que j'ai fait de privilegier ces configs pour tirer le maximum visuel de ma carte, après libre à toi de le critiquer ! GD est a limiter a des cas d'affichage simples et demandant un .raffraichissement serveur permanent (et encore je ne crois pas que ce soit une bonne soluce). De toute facon, la GD tout comme JS/css n'a pas été concu pour faire des cartes non plus j'en conviens. le web n'est pas concu pour faire un jeu. la soluce parfaite n'existe pas. Aussi je ne jouerai pas à la plus longue d'autant que je me base pour comparer a ce que j'avai svu de sd il y a bien un an. Je veux bien aller voir la nouvelle version de la carte si elle est accessible hors jeu (d'ailleurs c'est une remarque que je fais à tous les faiseurs de jeu : une démo technique hors jeu est un réel plus pour moi, je regrette que bien peu le fassent )Sinon la version flash avance, mais il ya des trucs vraiment compliqués à gerer en flash : le dialogue bidirectionnel avec les éléments JS de la page, la mise à jour des ressources graphiques du flash... C'est légèrement mieux mais pas non plus la panacée par rapport au JS. Rapellons que flash est optimisé pour faire du vectoriel et se contente d'assurer le minimum syndical pour ce qui est du bitmap matriciel. C'est pourquoi même quand on aura la version flash, je laisserai à dispo le moteur JS. En revanche, énorme plus dans flash : la carte se charge duynamiquement au fil des mouvements : plus de chargements intermédiaires au changement de zone. Et pour finir, l'inactivité : bon c'est l'équipe mj qui gère ca, mais en effet je crois que c'est 20 tours dans cnt, au dela de cette période, on considère que de toute facon le fief n'est plus viable et aura trop dépérit. Il vaut mieux recommencer. Le mieux -et c'est ce que font tous les joueurs maintenant- est de se trouver un binôme pour jouer ne serait ce qu'un tour par semaine. |
| Ecrit par: Nonothehobbit Mardi 28 Juin 2005 à 17h10 | ||||
Non rien, j'avais oublié qu'avec un mappage on pouvait utiliser n'importe quel polygone. |
| Ecrit par: khiguard Mardi 28 Juin 2005 à 17h53 | ||||||||||||||
Quel recul il faut avoir? C'est justement après plusieurs expériences que je peut me permettre de dire ca. J'ai tester les DIV et javascript et le GD.
J'ai un p4 2.4go avec carte graphique de 128mo. Heu il faut un biprocesseur pour que ca rame pas maintenant c'est vrai, IE est optimiser avec Direct X pour ce genre de chose, mais bon. Moi je prend le suport internet pour que les joueurs de tout les OS et tout browser puissent jouer, sinon je programme en c++ et direct x si c'est pour limiter les utilisateurs a un OS et un browser (pas de direct X sur Mac )
non, un image GD est de 20ko, si tu prend le code html envoyer au client, je pense que tu doit etre dans les 5 a 10ko (pour les divs ect...) donc ca ne change pas tant que ca.
il faut faire des choix, j'en ai fait aussi, et je pense avoir fait le meilleur pour SD, je ne critique pas ton choix, je donne juste mon avis.
Simple? Hum, tu doit pas avoir pousser tes expérience bien loin, si tu savais ce qu'on est capable d'en faire. Maintenant tu a raison sur beaucoup de point: pas fait pour ca (pas plus que les browser ), raffraississement fréquant (mais bon 20ko ca va quoi), pas d'animation (mais bon, on est sur le net aussi, il faut choisir. Pour moi l'animation est très secondaire dans un pbem). Aucune méthode n'est parfaite, il faut juste choisir le bon outils pour son application. ET optimiser son moteur le mieux possible.
qui te demande de faire la gamin? Je ne suis pas comme ca non plus, je me fou que mon moteur soit meileur que le tiens ou inversément. J'espère pour toi, que le moteur graphique de continent n'est pas ton seul atout pour faire un bon jeu, ca serais regretable se baser sur le jeu uniquement pour ses graphismes, non? D'autant plus que tu te base sur SD, mais la carte de SD (et je le reconnais) et un très vieux script. La carte de SD est la version 1, j'en suis a la version 3 et je peut te dire qu'on peut en faire beaucoup plus que ce que tu a vu. Mais pour SD je n'ai pas besoin de plus, alors je la laisse comme ca (version 1). Sinon pour le flash, tu sais qu'il existe des client flash, ca pourrais vous aider pour faire un moteur plus rapide (puisque l'ordinateur se connecte au serveur et le pc fait le reste). Sinon ne te choque pas, j'aime bien le moteur de continent, je le trouve très bien, ma seul critique était sur la lourdeur de cette application ce qui au final, est normal car le web n'est pas fait pour ca.
Ce n'est souvent pas possible non plus. pour moi balader un goblin sur une carte ne represente pas le jeu. il aurais falus plus de chose a faire. @+ |
| Ecrit par: zumba Mercredi 29 Juin 2005 à 15h50 | ||
ahh ok ! je pige mieux. Non moi je n'utilise pas de mappage pour détecter sur quel losange je suis, un petite formule mathématique par rapport aux coordonnées permet de le faire. @khiguard : ok laisse tomber. |
| Ecrit par: Nonothehobbit Mercredi 29 Juin 2005 à 16h11 |
| Dois-je en déduire que tous tes calculs de zone (savoir si on est sur tel ou tel élément) se fait avec javascript ? Si c'est le cas c'est pas un peu lourd ? |
| Ecrit par: zumba Mercredi 29 Juin 2005 à 16h30 |
| oui c'est le JS qui fait le calcul mais c'est une formule toute bête, pour détecter si on est a l'interier d'un losange (inscris dans un rectangle) ou dans l'un des 4 triangles extérieurs. Bref infinitésimal et de ce que je peux dire de mon cas, on peut faire de l'arithmétique + - * / sur un onmousemove sans aucun problème (tout browser confondu) du moment que tu refais l'affichage du curseur que quand tu changes de losange sur le onmousemove (car c'est l'affichage qui bouffe de la ressource), et même encore plus infinitésimal si c'est sur un onclick. A mon avis quand le browser fait sa détection de mouseover dans un losange il fait de même (voire meme pire quand c'est un cercle et encore pire quand c'est basé sur le bitmask de transparence de l'image, pour faire la détection au pixel pres). Sauf que là bah je n'ai aucun area, heureusement car sinon j'en aurais 250 à génerer je crois que le navigateur souffrirait avec tout ca (déjà qu'il a en moyenne 400 images à afficher). Enfin bon une tite démo vaut mieux qu'un long discours : tu n'as que te faire ta propre opinion sur une des démos de cnt (page d'accueil en bas) |
| Ecrit par: khiguard Mercredi 29 Juin 2005 à 21h06 | ||
C'est toujours agréable de discuter avec toi. Enfin, je savais bien que tu ne m'appréciais pas (sans que je sache vraiment pourquoi: on ne peut pas aimer tout le monde après tout) mais j'aurais penser que tu aurais la déscence de ne en tenir compte lors de discution. Enfin, j'ai penser qu'on pouvais discuter avec toi, je me suis tromper, ca ne se reproduira plus. @+ |
| Ecrit par: bibi.skuk Jeudi 30 Juin 2005 à 09h47 | ||
Est ce que tu pourrait t'expliquer un peu plus, je suis assez mauvais en JS, et là, e crains que cette possibilitée m'avait échapé... |
| Ecrit par: zumba Jeudi 30 Juin 2005 à 16h26 | ||||
| je peux pas te ressortir mon code car ma fonction de positionnement est tres spécifique à mon jeu (curseur de taille variable) mais je peux te sortir en gros la théorie mathématique en métacode on veut déterminer l'x,y du losange a partir de mousex,mousey. On est d'accord que ton losange s'inscrit dans un recrtangle de width * height pixels d'ou :
après il ne te reste qu'à comparer ces coords a celles actuelles du losange pour savoir si ca vaut le coup de réafficher le curseur a sa nouvelle position. voilà c'est tout, j'exécute ce code sur le mouseover du body de ma carte |
| Ecrit par: Ludvig Vendredi 01 Juillet 2005 à 11h52 |
| Ca marche très bien maintenant ! Il faut juste trier les objets en 'Z' avant de les afficher |
| Ecrit par: naholyr Lundi 04 Juillet 2005 à 12h32 | ||
Non ce n'est pas nécessaire. Vu que c'est justement pour gérer les superpositions de cadre que ce calcul est effectué |
| Ecrit par: Ludvig Samedi 24 Septembre 2005 à 21h12 |
| Ouh, je remonte ce post mais c'est parce que c'est quand même très sympa le map iso  Les tiles, c'est parfait, mais ce qu'il faut trier c'est les objets tel que les joueurs et les arbres etc. C'est implementé dans un jeu quelque part ? /Lud *qui va faire un pareil * |
| Ecrit par: bibi.skuk Mercredi 19 Octobre 2005 à 02h13 | ||
coucou, après une longue periode d'absence, me revoilou... en fait, tu joue sur le z-index des css... et c'est tout... en fait, c'est une horreur, les 3/4 du temps, moi j'ai mes persos qui marchent dur les arbres ou l'inverse... J'ai pas encore trouvé de methode satisfaisante... |
| Ecrit par: zumba Mercredi 19 Octobre 2005 à 09h49 |
| héhé moi aussi je fais comme ca et j'avoue que je rencontre à peu près le même problème, pour l'instant insolvable, dans le cas ou je dois tracer un objet par dessus un autre qui occuperai plus que sa case d'assise (ex un objet occupant 4 cases mais réellement "codé que sur 1 seule de ces cases). C'est pas les 3/4 des cas mais bon ca reste complexe. Solidarité ! |
| Ecrit par: Ludvig Vendredi 30 Décembre 2005 à 17h33 |
| Pour moi ça marce parfaitement Je dessine la carte dabord, d'en haut vers le bas, puis je parcours les objets de la même facon, tous avec le même z-index. Faut juste que je mets tout ça en 'prod' ... /Lud |
| Ecrit par: bibi.skuk Mardi 03 Janvier 2006 à 10h05 | ||
Je veux bien voir une tite demo si c'est possible, je suis curieux... |
| Ecrit par: Guest Mardi 03 Janvier 2006 à 12h33 |
| Bonjour (et bonne année ) C'est un sujet très intéressant ! Mais j'ai juste une petite question sur la synchro client/serveur : est-ce lorsque le perso change de case on est obligé de recharger toute la page, et donc le script PHP, pour que les modifications (position du perso) soient enregistrées dans la base de données ? |
| Ecrit par: Aldur Mardi 03 Janvier 2006 à 12h33 |
Oups, oubli de connexion  |
| Ecrit par: bibi.skuk Mardi 03 Janvier 2006 à 15h03 |
| dans ce que j'avait codé, oui, pour la bonne et simple raison, c'est que je ne voulait pas du totu de javascript, mais il suffit de reecrire les fonctions d'affichage en js avec quelques modifs pour pouvoir deplacer les persos dynamiquement dessus, ca demande plus de boulot quand même, mais ca reste faisable. |
| Ecrit par: Ludvig Mardi 03 Janvier 2006 à 15h21 |
| C'est pas en prod encore (il parait que le 'iso' plait pas a tout le monde^^) mais voila un screenshot :  C'est en principe sans JS, j'utilise un petit script pour qu'on puisse cliquer sur les cases, le reste c'est du html (plus un css). On peux evidamment faire une javascript qui prends (lire : avec les donnés collés dedans par le php) les donnés des images et qui sors tout seul tout ces lignes de html sur la machine du client pour allèger le php... Sinon, oui il faut recharger la page dés qu'on se déplace, c'est pas du temps-réelle. /Ludvig |
| Ecrit par: zumba Mardi 03 Janvier 2006 à 16h06 |
| A Aldur : ca dépend de ton jeu : est ce que les autres joueurs ont besoin de pouvoir voir que tu as bougé à chacun de tes déplacements (typiquement, jeu de rôle) ou pas. Dans mon cas (jeu de stratégie asynchrone), je ne fais l'écriture des nouvelles coordonnées en base et sur les fichiers de carte qu'à la fin du déplacement de l'unité, avec une validation du chemin parcouru à ce moment là (ca implique tout de même niveau JS de tracer toutes les cases parcourues entre 2 validations). Sinon pour tout le reste de la carte, le statique en somme, je passe par une reconstruction JS, en bufferisant une grande zone de la carte globale (200*200 je crois) dans le JS, ce qui permet de s'y déplacer sans aucun dialogue client / serveur. En plus avec ajax que j'ai découvert il ya peu, je peux mettre à jour ce buffer sans recharger le script, ce qui est du bonheur. Ceci allège énormément la charge du serveur (et offre des temps de réponse bien meilleurs, du moins sur une machine récente car c'est ton pc qui prends en charge le rendu), mais augmente dans des proportions affolantes l'effort de code à mettre au début (et encore longtemps après...) sur les JS de rendu (et j'en passe sur les variations en bug majeur entre les machines js des différents navigateurs...) et faut bien voir que JS a variment pas été conçu pour ce genre d'utilisation. Aujourd'hui je conseillerais à ceux qui voudraient faire comme ça d'attendre l'arrivée de flash 9 (betas développeurs dispos cet été), dont on m'a dit qu'il embarquerait enfin une librairie de manipulation de sprites 2D digne de ce nom (pasque avec flash8 on ne fait pas mieux qu'en JS) ainsi que des couches de dialogue client/serveur vraiment optimisées. Bref s'il est à la hauteur de ce que m'en a dit (un pro) ca sera l'idéal pour le développement de jeux web. capture quand même :  Et vive le JS ! |
| Ecrit par: bibi.skuk Mercredi 04 Janvier 2006 à 08h35 |
| mouaif, le flash, personnellement, ca m'a jamais vraiment plus... (propriétaire toussa), si je doit passer a une solution du genre, ca sera svg+js, même si pour ca je doit me limiter dans les navigateurs... (de toute maniere, avec le flash, ca limite les architectures...) |
| Ecrit par: zumba Mercredi 04 Janvier 2006 à 09h56 |
| ouais en fait le svg je connais très peu, j'ai vu que 2 ou 3 sites qui l'utilisaient et rien de très époustouflant visuellement parlant. Mais si tu as quelques sites à me faire connaître qui démontrent la puissance de cet outil, et nottament dans ses applications ludiques, je suis preneur ! |
| Ecrit par: Haiken Mercredi 04 Janvier 2006 à 13h01 |
| Prends ça alors : http://www.GalacticPathways.com |
| Ecrit par: zumba Mercredi 04 Janvier 2006 à 15h08 |
| mouais... je veux pas paraitre sectaire mais bon y'a rien de très flamboyant là dedans. Attention je ne parle pas de l'intérêt du jeu qui a l'air excellent (surtout pour moi qu isuis un ascedency addict) mais uniquement du rendu visuel. Je ne vois pas vraiment ce que svg apporte dans ce cas par rapport a du bon vieux html / js / css2. je trouve même que ca va plutôt à 2 à l'heure, pourtant je suis sur une machine a 2.8ghz. Sans parler du plugin à installer. Ah si tout de même, on ne s'em#####e plus à fourcher toutes les 3 lignes de code pour se faire comprendre de tel ou tel navigateur, ca c'est un plus indéniable. Moi j'attends de voir ce que SVG sait faire en terme de perfs quand il s'agit d'affficher en 1 / 10ème de secondes + de 400 images et animer le tout avec une transparence progressive ! mais de tout ce que j'ai vu sur cette techno, elle ne sait pas faire, on en est a peine au niveau de ce que savait faire flash 2 ou 3. Je n'ai pas l'impression (a moins qu'on me montre le contraire) que ca soit une techno de rendu rapide. Au contraire même. Bon ok c'est full xml (ce qui implique que c'est lent), c'est w3c-normé et tout mais si c'est juste une usine a gaz poussive pour faire du dessin vectoriel, ca ne sert pas à grand chose en terme de perfs multimédia, c'est pas avec ca que je pourrai refaire ma carte en 10 * plus rapide. Mais ca n'est mon avis du moment, si vous me sortez une carte qui fuse en full screen, je vous l'achète ! |
| Ecrit par: Haiken Mercredi 04 Janvier 2006 à 16h30 |
J'attendais ton avis, mais j'ai eu la même impression sur la lenteur...  A mon avis, on ne peut guère espérer grand chose de tous ces langages interprétés en n couches logicielles Si tu veux un rendu rapide, il faut se rapprocher un peu plus du système... SVG en effet c'est pas fait pour afficher des images à base de pixel, mais du vectoriel. Il ne faut pas en espérer grand chose de ce côté là à mon avis, sauf si tu redessines toutes tes images en vectoriel  |
| Ecrit par: khiguard Mercredi 04 Janvier 2006 à 17h17 |
| Je suis assez d'accord avec Zumba, c'est très lent pour pas grand chose. On peut mieux faire avec des languages simple. Et le plug in est embetant car il limite pas mal. De plus, même si au premier abord j'ai cru a un civilization futuriste en ligne, l'interet frise le ogame en plus beau au final. Alors l'intêret est plus technique que ludique je pense pour ce jeu. Je trouve que pour programmer en SVG autant programmer en C++... enfin, il faut s'avoir programmer aussi Tu n'a rien d'autre comme exemple, haiken? Ca m'intérresse. @+ |
| Ecrit par: bibi.skuk Mercredi 04 Janvier 2006 à 20h29 |
| En fait, je parlait essentiellement de la simplicité d'utilisation du SVG (oui, c'est du texte, et le texte, ca se genere bien en php par exemple, et puis ca se modifie bien en js), et puis pour le coup du plugin, firefox le gère en standard, konqueror et safari aussi, enfin bon, il y a beaucoup de navigateurs qui sont capables de l'afficher (enfin ie y arrive pas... mais bon est-ce si grave...</troll>). Et pour afficher des images bitmaps, non, c'est pas fait pour ça... (dans ce cas la html marche tout aussi bien)... Sinon, effectivement, c'est peut etre un peu lent, mais mes tests n'ont pas été très poussés (pas cherché à afficher un map par exemple...) Mais je m'y essayerait... En attendant, il faut que je finisse ma map hexagonale... |
| Ecrit par: Haiken Jeudi 05 Janvier 2006 à 19h33 |
| Ok voici ce que j'ai de valable dans mon bookmark : http://www.mycgiserver.com/~amri/widget/widget.svg http://www.croczilla.com/svg/samples/ (j'adore le http://www.croczilla.com/svg/samples/tiger/tiger.svg )http://www.kevlindev.com/ |