Par Light c'est avec ou sans Normal Map ? Dans les deux cas, ça passe par les shaders, SFML gère ça parfaitement. Au niveau des particules c'est relativement simple à faire, tu peux appliquer des shaders pour embellir ces mêmes particules. Au niveau des threads je ne sais pas trop, j'évite d'en utiliser, j'avais utilisé des std::async avec la SFML et ça marchait plutôt bien. Sinon c'est fluide et fonctionnel

Moi je resterai sur la sdl

Après une longue série de test pygame(sdl)/pysfml(sfml), j'ai bien vu que la sfml était stable pour +100'000 entités (mais avec un dt de rendu horrible, qui donne 10 fps, soit 100ms de rendu) mais qu'elle donnait des perfs pourries pour 100 entités, alors que pygame m'en donnait 2 fois plus ! un dt de rendu pour pygame de 10^-6 contre du 5*10^-6 !

Fin bref, je garde la sdl perso (après c'est du python)

-
Edité par Anonyme 26 avril 2016 à 18:21:37

Je ne te conseille aucune des deux, ou plutôt les deux ! Si tu te sens à l'aise avec la SDL, garde là, mais dis-toi bien que tu auras peut-être à faire des concessions. Pour les lights, admettons qu'il n'y ai aucun (je sais que c'est pas vrai) moyen d'en mettre. Tu ne serais pas obligé de passer à une autre bibliothèque pour autant. Il te suffirait juste de ne pas utiliser de lights...

En gros garde ou prend ce qui te semble le plus adapté.

Mizugola : Enfin des horaires plus adaptés !

-
Edité par jejeleterrible58 26 avril 2016 à 18:47:06

Gros, mais alors vraiment gros bâton dans mes roues : le depth sorting .

Il semblerait qu'il soit impossible de faire un bon z buffer dans un jeu en iso sans passer par des tiles, des layers etc... Or mon moteur est totalement détaché de ces concepts --' 

J'ai quelques solutions : le pre-sorting, à savoir définir à l'avance l'ordre de blittage de chaque objet statique de la map et autoriser uniquement les entités mobiles à se déplacer à travers cet ordre .

Ou alors implémenter un moteur de texturisation artisanal. Mais là autant passer directement sur un vrai moteur 3D. 

J'ai aussi vu un proto qui implémentait presque un pixel perfect en faisant un slicing selon une hauteur et une épaisseur de tiles prédéfinies , mais en vue oblique.

Dernière solution, abandonner certaines fonctionnalités et faire comme tous les développeurs de jeu Iso. Mais ça m'intéresse pas. 

Des idées ? 

Edit: j'ai déjà des tas de concepts plus ou moins réalisables dont certains qui me permettraient d'atteindre une qualité graphique élevée et de revenir à des idées que j'avais dû abandonner mais je suis toujours ouvert à d'autres idées 

Edit2 pour mizugola : juste des lights banales par dessus des textures , pas de normal map ou autre ; ) 

-
Edité par -Ginka 27 avril 2016 à 20:54:39

Pour des lights banales j'avais fait ça en SFML, le rendu est pas dégueu et c'est simple à implémenter

https://youtu.be/7P2aYnFjCt0

Tu utilises quel type de coordonnées dans ton jeu ? Sans cette information c'est plus dur de t'aider :) 

Yaalval : Comme tu le dis, c'est du Python, les performances ne sont pas du tout les mêmes en C++ avec SDL / SFML, donc tes données ne sont pas valables ici :) 

jejeleterrible : A partir de quelle heure mon horaire est considérée comme inadaptée ? 

Oui j'avais vu ton projet qui est vraiment pas mal soit dit en passant pour les coordonnées c'est des points (x,y,z) .plus on va vers 0,0,0 plus on tend vers le haut de l'écran. 

Sur mes screens le point 0 est la pointe nord du décor. 

Mizugola : Entre 0:00 et 6:00 je considère cela comme étant inadapté. Le dodo c'est sacré ! Et là je viens de voir que tu me réponds à une heure du matin ! Alors à moins d'habiter dans un pays lointain (décalage horaire) tu devrais être en train de dormir ! 

Bon plus sérieusement j'imagine que tu as tes raisons... Mais quand même !

J'ai essayé de reproduire ton screen avec tri, je trie juste mon tableau en fonction de (x + y + z) de chaque composant et ça a l'air de marcher

Évidemment j'y ai pensé mais ça crée un glitch quand un objet surplombe un autre objet par sa taille alors que ses coordonnées indiquent qu'il devrait être derrière. 

Je vais t'envoyer une image pour illustrer ça 

-
Edité par -Ginka 28 avril 2016 à 13:52:02

Et si la position de tes objets était parfaite ? Dans le sens où qu'un objet ou une entité est toujours SUR un cube quoi qu'il en soit, lorsque tu te déplaces d'un cube à un autre, l'entité fixe son référentiel au cube avec le z-buffer le plus bas (enfin blitté en dernière position quoi) et pour avoir une animation, tu rajoutes à ça un draw offset.

C'est le principe du tile-mapping en fait c'est la toute la difficulté parce que je veux absolument oublier ce genre de gestion . Qui plus est quand le héros saute il n'est de fait plus sur un cube.

Le fait d'avoir présenté un screen avec uniquement des tiles cubiques c'est juste parce que c'était plus rapide à implémenter,  mais en réalité le paysage sera plus subtil que ça,  le sol pourrait très bien être composé d'un seul grand rectangle ou d'une multitude de petits meshes placés à la main , et c'est ce qui m'intéresse le plus dans ce projet je veux être capable de piloter n'importe quelle composante du décor, que ce soit le sol, un arbre ou le héros, chose qui est impossible avec une vision old school du rpg making 

Cela dit c'est une bonne idée que t'as eu là si je trouve aucune solution satisfaisante et que je suis forcé de revenir à une gestion moins générale de la 3D , je creuserai sûrement dans cette direction 

Y aura du chevauchement possible dans ton moteur ?

C'est à dire ?

Est-ce que deux entitées ou tiles peuvent être enchevêtrées ?

Non, ça serait trop compliqué

Déjà dimanche !

La semaine est passée trop vite et j'ai été pas mal ralenti par ce problème de z-order . J'ai mis plein de solutions sur papier et je me concentre donc sur ça jusqu'à ce que ça soit réglé. 

Enfin pour l'instant c'est bien parti puisque j'ai implémenté un z-buffer... qui fonctionne !! Du moins dans les tests ça a l'air pas trop mal . Je travaille donc uniquement avec des tampons de pixels en Uint32, et à chaque Sprite j'associe un depth buffer , l'objectif étant de ne plus me soucier du depth sorting et plus tard de déplacer la gestion des pixels directement sur le gpu en multithread.

Les perfs, bien que pas trop dégueu, ont évidemment pris un coup dans l'aile parce que tout est sur cpu,  mais avec 40 images de 64×64 , plus leurs depth buffers respectifs , plus deux buffers de 1024×768 (double buffering ) pour l'écran final ainsi que leurs depths , le tout nettoyé et blitté à chaque frame, on est sur un dt de facilement 10 ms voire moins . 

Mais je rappelle que pour l'instant c'est sur cpu donc je suis optimiste et l'affichage se fera en parallèle de l'update sur des threads séparés. 

Voilà pour aujourd'hui, je vais donc rester sur ça encore une ou deux semaines, ça va repousser la date du recrutement mais bon il faut ce qu'il faut. 

Bonne journée à tous ! 

Petit up vite fait :

J'ai déplacé l'affichage dans un thread séparé ça a créé quelques problèmes puisqu'il a fallu complètement isoler la fonction de rendu pour qu'elle n'interfère pas avec le reste du programme . J'ai aussi à ma grande surprise perdu 1ms de dt mais je pense que ça les vaut . Quand j'aurai fini de rattacher ce nouveau mode d'affichage à mes entités physiques on pourra voir la différence. Ça peut le faire pour dimanche si je me débrouille bien :) 

Bonne journée ! 

xGinkax a écrit:

Petit up vite fait :

J'ai déplacé l'affichage dans un thread séparé ça a créé quelques problèmes puisqu'il a fallu complètement isoler la fonction de rendu pour qu'elle n'interfère pas avec le reste du programme . J'ai aussi à ma grande surprise perdu 1ms de dt mais je pense que ça les vaut . Quand j'aurai fini de rattacher ce nouveau mode d'affichage à mes entités physiques on pourra voir la différence. Ça peut le faire pour dimanche si je me débrouille bien :) 

Bonne journée ! 

Faire du multithreading ne signifie pas nécessairement de meilleures performances... Si c'est mal géré, cela peut même diminuer les performances...

La news du dimanche avec deux jours de retard ! 

Semaine ultra short, pas eu énormément de temps, et rebelote cette semaine :/ mais bon, le moteur de rendu supporte maintenant les déplacements dans l'espace et s'adapte donc en prenant en compte la normal map des textures, altérée en fonction de leur distance à la caméra .

Pour faire simple, la profondeur des pixels est augmentée ou baissée en fonction de la position de l'objet. 

C'était assez hard, je me suis rendu compte que je brisais certaines lois de la POO à cause de SDL mais c'est maintenant réglé .

En ce qui concerne le multithreading , il va surtout être utile pour l'affichage parallèle à l'update, mais c'est clair que je vais éviter de me reposer dessus, c'est assez risqué parce que ça casse l'architecture quand c'est mal fait (bon dans mon cas c'est fait de manière très stricte mais sait-on jamais).

Cela mis à part, je vais repousser le recrutement initialement prévu pour mi-Mai d'au moins trois semaines.

Voilà voilà, bonne soirée à tous ! 

Tu utilises un shader pour tes normal maps ?

Non , pour l'instant tout est encore sur le cpu dans des Uint32*

Hello all !!!

Ça fait un moment que j'ai pas posté et j'ai perdu presque un mois de boulot sur le projet .

Mais je reviens avec quelques nouvelles . D'abord, j'ai dû revoir mes exigences à la baisse . J'ai réussi à implémenter un système d'affichage avec un depth buffer mais j'avais pas pensé à un truc : ça aurait demandé deux fois plus de travail aux artistes qui auraient dû créer une normal map pour chaque sprite ^^' 

Je suis donc revenu aux bases et c'est pas plus mal . Je vais bosser toute la semaine pour sortir une map sur laquelle on pourra se balader, afin d'avoir du visuel pour le recrutement . Ça sera un amas de dessins moches faits sur Paint mais bon je peux pas mieux :) 

L'autre nouvelle c'est que j'ai enfin Internet chez moi, et donc plus besoin de passer par mon portable pour les besoins du projet. 

Sur ce, à dimanche !!

A dimanche !

😞 À peine arrivé qu'il est déjà reparti

Et voilà pour vous !

https://youtu.be/yOiEQtFr_2Y

C'est fait à l'arrache, les textures faites à la souris sur Paint x) Enfin bref, en gros ça donne une petite map avec collisions, rien de bien méchant. Le plus gros du travail n'est pas visible pour l'instant.

J'ai un peu modifié le système de chunks pour faciliter le travail des graphistes : au lieu d'être créés avec des coordonnées 3D, les chunks se font en fonction de coordonnées On-screen. Sinon on aurait dû dessiner les backgrounds en pensant avec des coordonnées in-world, faire les heightmaps en forme de losanges, sans être sûr du bon placement de chaque pixel etc... Désormais, un chunk c'est toutes les coordonnées dont les équivalents à l'écran sont compris dans un rectangle de 1280*640. Dans le code, ça rajoute de la gestion, mais dans la pratique ça économisera du temps et des efforts

Si vous m'avez compris tant mieux, j'ai du mal à expliquer

En tout cas je commence à manquer de ressources graphiques, alors je lance un premier appel aux graphistes qui passent par là, même si le recrutement ne peut pas ouvrir pour l'instant (faute de concret à proposer), je suis néanmoins ouvert à vos propositions D'ailleurs je me tâte à chercher un deuxième programmeur aussi. Fin bref, pour l'instant rien ne presse.

Sur ce, à bientôt !

Ben c'est pas mal, les collisions sont bien gérées, la map estbien foutue, les graphismes aussi ^^ 

Tout ça avance ! Après effectivement il faudrait un autre dev et un graphiste pour bien faire, j'avais pensé me proposer mais je ne connait pas trop la SDL... Dans quelques semaines tu pourrais ouvrir un topoc de recrutement, oui y a pas énormément de choses concrètes mais p't'être qu'avec une vidéo ça fera l'affaire...

Sur ce, bosse bien !

Merci

A titre d'information : la SDL est totalement wrappée par mon moteur pour se rapprocher d'une programmation orientée objet (je sais, vous allez me dire "autant se caler dès le début sur une lib en POO" , et vous aurez raison ^^). Elle est donc invisible en dehors des fichiers concernant directement le moteur graphique.

J'ai encore du taf au niveau des maps donc j'attendrai encore au moins un mois pour le recrutement. Pour ce qui est des graphismes, je sais pas si c'était de l'ironie x) en tout cas c'est pas du tout ce que j'ai en tête pour l'avenir du jeu.

-
Edité par -Ginka 20 juin 2016 à 12:00:05

Bof, la SDL a ses points forts et ses points faibles, ils sont un peu différents de SFML (qui est le plus gros "concurrent") :

Points forts

• Une gestion d'Inputs/Output plus simple
• Un multi-plateforme assuré et bien testé

et d'un autre côté les points faibles :

• Pas écrit en C++, ce qui implique l'utilisation d'un wrapper
• Pas de support pour des fonctionnalités avancées comme les Shaders et une gestion des Sprites assez chaotique (on y va à la mano quoi)

De son côté la SFML a l'avantage d'être un peu plus haut niveau et écrite en C++, ces deux atouts facilitent légèrement la tâche de dev et rendent le code un peu plus léger.

En bref, faut faire comme on le sent !

Ta démo m'a l'air bien sympa sinon, pas de bug apparent !

Sympa de voir un peu l'avancement Si y avait un autre dev il aurait quoi à faire dans ton projet ?

Bah en gros il ferait le travail à ma place ... XD

Nan, plus sérieusement je sais pas vraiment ce qui est le plus adapté, je dois encore m'informer sur le travail en équipe. En vrai j'ai surtout besoin d'un programmeur qui aurait sa propre vision d'une bonne architecture, pour mettre nos expériences en commun et proposer un code de qualité

Je suis très à cheval sur une prise de décision réfléchie, mais ça prend du temps et de l'énergie pour tester les meilleures solutions !

Salut à tous !

Straight to the point, la saison estivale me prend du temps et de l'énergie au boulot, donc pas beaucoup d'avancée de juin à début septembre :/ Néanmoins, j'ai retravaillé certaines classes, commenté un max dans la moitié de mes fichiers(en prévision d'une collab), et j'ai enfin attaqué la gestion du texte

Je viens aussi d'ouvrir le recrutement pour un graphiste, recrutement que je ne ferai donc pas sur OC. En revanche, c'est officiel, je recherche un programmeur C++ ! Quelqu'un qui de préférence a déjà pris part à un projet, qui connaît les bonnes pratiques du C++ (les VRAIES bonnes pratiques). Des connaissances en Lua seraient un plus.

Je ne pense pas faire un thread dans l'autre section, je m'attaquerai à d'autres forums si j'ai terminé le noyau du jeu et que j'ai encore personne pour m'aider.

Si quelqu'un est intéressé, ça se passe en MP Ciao

-
Edité par -Ginka 15 juillet 2016 à 18:24:59