jeu isométrique

[mazertys17]

Bonjour.

Je suis en train de monter mon jeu 2D en c++ avec la SFML. La vue est en isométrique. Il y a des menus, des niveaux différents, de nombreuses sprites. J'aimerai concevoir un bon système d'affichage dès le départ, sans pour autant faire appel à un vrais moteur qui ne serait pas forcément nécessaire.

C'est pourquoi je sollicite votre aide et vos conseils 

Dans l'idée globale, je pensais partir sur un objet "Afficheur", qui charge et affiche les images qui lui sont demandées.
Je ne souhaite pas faire quelque chose de compliqué, mais qui offre tout de même de bonnes performances.

Merci si vous pouvez m'aider

[Laurent]

"Bonjour je veux un système efficace, simple et performant, et n'utilisant pas les solutions existantes" --> tu veux pas cent balles et un mars non plus ?

Malheureusement la programmation ce n'est pas le monde de Candy, il faut écrire quelques versions foireuses avant d'arriver à un truc à peu près potable. Et itérer (= recommencer) encore et encore jusqu'à ce qu'on soit plus ou moins satisfait de son travail.

Peut-être que quelqu'un te donnera quelques bons conseils ici, mais honnêtement tu ne devrais pas attendre un miracle (surtout avec une description aussi vague de ce que tu veux), commence plutôt à écrire du code.

Mon conseil perso : n'essaye pas de concevoir un truc compliqué dès le départ, implémente plutôt les choses "naïvement", le plus simplement possible. Ca te permettra d'avoir un peu de recul et de voir les points à travailler. Plutôt que de chercher à faire dès le départ un "système" sans connaître les problèmes qu'il devra résoudre

[msteve]

Il a tous dit =)
Sinon je peu te passer la fonction qui fait des map iso si tu en a besoin =)

[mazertys17]

Bonjour, et merci pour votre réponse et l'intérêt que vous portez à mon projet.

J'ai déjà travaillé sur mon jeu et élaboré une version jouable sur les 3 premiers niveaux, avec la SDL.
Mais je souhaite aller plus loin, et élaborer mon jeu le plus sérieusement possible. Voila pourquoi d'ailleurs je me suis mis au c++ et à la SFML 

J'ai déjà commencé à mettre en place ma programmation, que je vais tenter d'expliquer ici, en vous priant de me dire si quelque chose vous choque ou vous parait mal conçu:

Chaque niveau du jeu est contenu dans un objet propre(appelé par le main) qui contient toutes les donnés propres du niveau: objets présents, coordonnés, collisions etc...C'est de lui qu'est lancé la boucle du jeu, et par lui que transmutent les informations. Il fait appel à l'objet Afficheur, qui se charge de gérer toutes les images. (même chose pour le menu en hors jeu).

Un seul et unique objet "Afficheur afficheur" est crée depuis le main. Sa référence "&afficheur" est envoyé aux objet sollicitant l'affichage, (niveaux ou menus) qui pourront l'utiliser en tant que pointeur *m_afficheur. Ils doivent tous agir sur un seul et même objet, l'afficheur original.
Afficheur fait alors appelle a un objet "Affichage affichage" qui contient en privé toutes les textures et les sprites du jeu, qui seront chargés ou libérés en fonction de ce que demande les niveaux/menu.

voila en gros l'état actuel de ma conception de programmation...Mais malheureusement je ne suis pas ingénieur,(pour tout vous avouer, a la base je suis un artiste) alors je ne sais pas vraiment si les choses sont envisageables de cette manière ou pas, a grande échelle: Pour l'instant, cela fonctionne, mais j'aurais de nombreuses textures et sprites et animations à gérer.

 Une questions concrète :

 -peut on utiliser des sf::Textures et sf::Sprites, ainsi que sf::RenderWindow dans les attributs private d'une classe pour les faire charger/afficher par des methodes de la même class sans que cela soit problématique d'une quelconque façon pour les process, carte graphiques etc.., en imaginant que toutes les images du jeux (il en a quand même beaucoup) sont censés tenir dedans?

donc finalement, est-ce une manière de procéder correcte?

J'espère avoir été plus clair quant à ma problématique, et le soutient technique que je sollicite. J'ai déjà une maquette de code, mais elle n'est pas assez abouti pour y poster des extraits pour l'instant, mais ca ne saurait tardé.

Merci

[Glân de Brylan]

Peut on utiliser des sf::Textures et sf::Sprites, ainsi que sf::RenderWindow dans les attributs private d'une classe pour les faire charger/afficher par des methodes de la même class sans que cela soit problématique d'une quelconque façon pour les process, carte graphiques etc.., en imaginant que toutes les images du jeux (il en a quand même beaucoup) sont censés tenir dedans?

Écoute, moi je fais comme ça et cela fonctionne parfaitement. Alors lui faire contenir tous les sf::Sprite peut-être pas, mais les sf::Texture, c'est parfait, cela permet de ne charger chaque texture qu'une seule fois.
Ce que je peux te conseiller c'est d'avoir simplement un attribut conteneur qui utilise des random access iterators (un std::vector par exemple) et ainsi fonctionner avec un système d'ID. Chaque sf::Sprite (ou classe dérivée) demanderait à ton Affichage l'adresse de la texture ayant tel ID (const sf::Texture* getTexture(unsigned int ID) et s'en servirait.

Bon, après je ne suis pas un expert de la SFML, mais ça me semble être un moyen simple et efficace de gérer ses textures. Et réutilisable dans d'autre projets en plus.

[mazertys17]

Merci Glân de Brylan.

Ca me conforte dans mon idée. Je vais donc surement partir là dessus.
J'ai d'autres question pour la gestion d'images:

-Est-ce que charger des sprites carrés en multiples de 2 (512,1024 etc...) optimise le rendu? ou est*ce négligeable, voir inutile?

-Charger des dizaines de sprites en 4096/4096, par exemple, pour un niveau, vous parait-il lourd?

Merci

[Glân de Brylan]

ALors pour l'optimisation je n'en sais absolument rien., mais à mon avis, ça ne change rien.
Par contre des images aussi grosses que ça ça peut poser problème...essaie plutôt de la fragmenter en quatre images de 2048*2048. Au moins tu seras sûr que ceux qui ont une petite config' pourront jouer sans problèmes.

Autre truc à propos des textures, si l'image à charger n'est pas trop grande, ça ira plus vite de n'en charger qu'une ! Je m'explique : charger une image de 100*100 sera plus rapide que quatre de 50*50.
Tu peux choisir quelle zone de la texture est utilisée par le sprite grâce au paramètre rectangle du constructeur de sf::Sprite : http://sfml-dev.org/documentation/2.1-fr/classsf_1_1Sprite.php#a01cfe1402372d243dbaa2ffa96020206
 ou grâce à la fonction setTextureRect : http://sfml-dev.org/documentation/2.1-fr/classsf_1_1Sprite.php#a3fefec419a4e6a90c0fd54c793d82ec2

Par exemple, mettons que dans ton jeu il faille récupérer des pièces et qu'il y en ait 6 différentes de 50*50 chacune. Dans ce cas fais une image de 150*100 (ou 100*150, peu importe), que tu charges une seule fois, et tous les sprites représentant tes pièces utiliseront cette même texture, mais une zone différente en fonction de si c'est une pièce d'or, d'argent, etc.
Comme ça tu optimises l'utilisation du CPU et de la RAM ! Et aussi un peu celle du disque dur mais c'est moins important : 4 images de 50*50 prennent un peu plus de place qu'une image de 100*100, même si elles sont de même qualité.

Voilà voilà !

[mazertys17]

OK.

Oui, je savais, pour le découpage des sprites et le paramètre rectange. C'est pour ca que je pensais faire des grandes images de 4096 qui contiendraient un max d'images différentes. Surtout pour les animations.
 2048 parait en effet plus sage. Je vais voir tout ca.

Merci pour la réponse

[AnselmeSfml]

Salut!

Je développe actuellement un moteur isométrique et je te conseille (c'est ce que je fais) d'utiliser un sf::VertexArray, et eventuellement d'en créer plusieurs (1 par chunk) et de n'afficher que ceux présents à l'écran. Question perfs, c'est la meilleure chose qu'on puisse faire pour l'instant. Tous tes sprites seraient contenus dans un seul fichier. De plus, le changement de tuile à tel ou tel index de la carte est très simple, aucun calcul n'est à refaire pour déterminer l'ordre de blittage de la tuile modifiée.

[msteve]

Bon, j'ai prix un peu de temps pour te faire un petit diagramme uml de mon crue. Je pense que cette conception s'approche de la réalité (je veux dire par la, qu'il me semble que ce soit stable). Je dit bien "je pense" car ce n'es ici que ma vision (simplifiée) des choses. En tout cas j'espère que sa pourra t'aider dans ton projet.



Pour aller un petit peut plus loin, je voudrais juste préciser deux/trois trucs. Comme tu peu le constater dans cette architecture de moteur de jeux, chaque élément contient une liste d'autres éléments de plus petites tailles. C'est un peu ce que tu disais dans ton explication mais je voulais essayer de développer un peu. Dans ma vision des choses chaque éléments conteneur (Par exemple Engine, Scene, Game ) possède des méthodes qui reviennes tout le temps. Une méthode pour ajouter un élément (add), supprimer (remove) mais égallement pour dessiner tout ce qui est contenue (draw) ou le mêtre à jour (update).

Bon... Un dessin vaut souvent dix milles discours alors:



Ce que j'essaye d'expliquer ici, c'est que chaque élément demande aux éléments qu'il contient de se dessiner et de se mettre à jour.

Engine demande à ses scènes de se dessiner.
Une scène demande à ses éléments d'interfaces et à la game de se dessiner.
Une Game demande à ses éléments de se dessiner.
... Une entité utilise la méthode draw qu'il hérite de sprite pour se dessiner.
Et le Sprite va avec plusieurs getteurs remonter jusqu'au getWindow de Engine pour pouvoir vraiment déssiner (avec la fonction SFML).

J'espère avoir été assez clair sur ce qui me semble être une marche a suivre intéressante pour concevoir un jeux =)

[mazertys17]

Bonjour, et merci, msteve, pour votre réponse, et pour votre intérêt.

C'est en effet un shéma intéressant! J'en suis en fait, arrivé aux mêmes conclusions,(ce qui est rassurant) et j'ai repris mon idée de départ pour en arriver à un concept similaire au votre :

J'ai, depuis le main, une boucle qui contient sf::RenderWindow (un peut comme "engine", dans votre shémat)et  appel constament à un "Afficheur", (probablement l'équivalent de scène), pour savoir s'il y a des choses à afficher. Afficheur va lui même faire appel à "interface" ou "niveaux", qui diront: "oui, nous avons tel ou tel objet a afficher à tel endroit, et renveront les entitée à afficher s'il y en a...

Voila, il me semble que c'est dans le même esprit. (peut être que la différence est le fait que, dans votre shéma, les objets se dessinent eux même, alors qu'il sont déssinés par le main (engine) dans le mien..?

Merci en tout cas, je vais bien regarder votre shémat