Discussion :

[Invité]

J'ai essayé de tout dessiné avec un seul draw call juste pour voir si ça augmenterait les performances (tout en me foutant des effets de glitch), mais je n'ai pas eu de gain au niveau du FPS (pas avec opengl 3.0 dans tout les cas)

Je ne vois donc plus qu'une seule solution dans ce cas là surtout si je veux garder l'ordre avec lequel les shaders sont exécutés et donc pas que opengl exécute les shaders dans n'importe quel ordre ce qui est le cas avec l'instanced rendering. (et donc ce qui va poser problème avec la semi-transparence ou je dois appliqué l'algorithme du peintre pour dessiner les entités dans un ordre bien précis) :

-Faire le rendu en parallèle avec les autres traitements, il va falloir que je puisse faire une technique similaire au double buffering mais avec une différence fondamentale c'est à dire, avec un thread qui exécute les shaders dans l'ordre et qui met à jour le framebuffer du composant, et un autre thread qui dessine le composant en faisant un appel à display à chaque fois que le 1er thread à fini de mettre à jour, ainsi je me ressert du double buffering, en ayant à chaque fois la dernière frame qui a été mise à jour, sans faire attendre le CPU, tout ne exécutant les shaders dans l'ordre pour éviter les effets de glitch, je n'ai même pas besoin de contenaire lock free.

Bref, merci pour ses informations à propos d'opengl, je pense que j'ai enfin trouvé la solution à ce problème de FPS!

Dans ce cas je n'aurai même pas besoin de contenaire lock-free!

Suffit juste de se servir du tutoriel sur le rendu multi-thread de SFML.

[Invité]

Salut!

A partir de maintenant je stop les mises à jour sur le dépôt git.

Pour débuter la version payante du framework.

Celle-ci comportera des changements importants dans le but de permettre la création de jeux avec des scènes plus réaliste, ainsi que un meilleur FPS et des nouvelles fonctionnalités pour la 3D.

Je vais donc annoncer les grand changements :

-SFML n'est pas adaptée pour les jeux plus gourmand en performance (car elle ne permet pas de faire du rendu non synchronisé), je vais donc utiliser SDL à la place qui lui le permet sans problèmes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
#include "odfaeg/Graphics/sdlRenderWindow.hpp"
#include <SDL2/SDL.h>
using namespace odfaeg::core;
using namespace odfaeg::math;
using namespace odfaeg::physic;
using namespace odfaeg::graphic;
using namespace odfaeg::audio;
bool end = false;
void renderingThread(SDLRenderWindow* mainWindow)
{
    while (!end)
    {
        mainWindow->clear();
        // Up until now everything was drawn behind the scenes.
        // This will show the new, red contents of the window.
        mainWindow->display();
    }
}
 
int main (int argv, char* argc[]) {   
    SDL_Init(SDL_INIT_VIDEO);
    SDLRenderWindow rw(800, 600, "SDL window");
    SDL_Event event;
    std::thread theThread(&renderingThread, &rw);
    while(!end) {
        SDL_PollEvent(&event);
        if (event.window.event == SDL_WINDOWEVENT_CLOSE)
            end = true;
    }
    theThread.join();
    SDL_Quit();
    return 0;
}

Tout ceci sera encapsulé bien sûr, il suffira juste de préciser lors de l'héritage de la classe application quelle librairie l'on souhaite utiliser. (Bon, plus tard se sera remplacé par une option dans cMake si j'ai bien compris ce que m'a dit Neckara)
Mais, on pourra bien sûr aussi utiliser SFML ou encore une autre librairie en réimplémentant les interfaces communes pour tout les modules.

Mon module continuera d'utiliser les fonctions d'opengl directement avec SDL et non plus SFML pour le fenêtrage, cependant, on pourra encore utiliser les fonctions de la SDL ou bien de la SFML après la création de la fenêtre pour dessiner, cela ne posera pas de problèmes.

Maintenant il faut encore que je voie au niveau de la création de contexte opengl, avec les textures de rendu, comment je vais m'y prendre, car, SFML et SDL utilise deux structures différentes pour la création de contexte opengl, je vais donc devoir faire diffférents implémentation pour tout ce qui est "render target".

[maeiky]

Je croyais que tu ajoutait de la 3D à SMLF, mais si je comprend bien tout est indépendant?

Comment compte tu rendre ton moteur payant?

[Invité]

Oui tout est indépendant.

J'ai essayé de créer un contexte opengl avec SFML pour une fenêtre SDL mais ça ne fonctionne pas, les fonctions de opengl ne sont pas appelée. (La fenêtre n'est plus effacée avec la couleur de fond. :/)

Je vais créer une sorte de site avec payement sécurisé et système de license, je ne vois que ça comme solution, mais étant donné que je ne m'y connais pas de trop là dedans je vais sans doute devoir suivre une formation.

[skeud]

Vendre ton moteur? C'est une blague ou c'est sérieux?

Tu crois réellement que des personnes vont t'acheter des licences?

En général avant de vendre quelquechose, on fait une étude de marché. En l'occurence l'étude de marché est la suivante:
Il existe de nombreux moteur 3D open Source ou gratuit (ogre, unity par exemple) fait par des équipes professionnelles, avec un vrai contenu, une vrai puissance, et un vrai rendu.

Et ensuite, il y a toi, un dev amateur, qui fait un moteur de jeu bancal, qui ne possède pas un rendu correct, des lacunes en performance. Je serais curieux de savoir si même toi tu payerais pour un tel moteur.

Les étapes pour vendre un projet:
Travailler longtemps (pas juste quelques mois, mais plusieurs année).
Engager un commercial (la com, c'est pas notre boulot, les devs sont nuls la dedans).
Se faire connaitre (grace à son projet en gratuit d'abord).
Faire payer son projet (une fois qu'on a acquis une renommé, le payement sera justifié).

Juste pour rigoler un coup, tu comptes le faire payer combien?

[Invité]

Non, contrairement à toi, je suis sérieux.

Je sais qu'il y a déjà de gros moteurs sur le marché mais, il faut savoir que :

-Un développeur indé comme moi n'a pas spécialement besoin de tels moteur, ça sera plus encombrant qu'autre chose, et encore faut t'il pouvoir le maîtriser, tu sais, les formations et les tutoriels au sujet de gros moteurs ça va vite et il faut pouvoir maîtriser beaucoup de savoir faire en très peu de temps.

Bref, ça sert juste à attirer le client, rien d'autre.

Une fois qu'il faut se plonger dans le code du moteur (souvent non accessible dans le cas de projets commerciaux) et innover, je préfère me plongé dans le code d'un moteur avec 1 000 lignes de codes plutôt qu'avec des millions de lignes de codes.

Et je suis sûr que les utilisateurs n'auront pas envie d'attendre que j'implémente une nouvelle fonctionnalités si ils en ont besoin et auront envie d'être plus indépendant à l'avenir.

Il faut parfois arrêter de vouloir à tout prit faire des clones avec des moteurs de jeux existant et pouvoir instaurer sa propre marque de fabrique.

Par contre, pour les entreprises, là, c'est différent, car eux, ils n'utilisent pas les même outils, ils ont plus de contrainte, alors ils doivent dépendre des outils utilisé par d'autres entreprises, mais personnellement, je n'aime pas ça, car, l'auteur peut à tout moment décidé de faire ce qu'il veut avec son moteur.

Et ont peut faire des moteurs performant sans qu'ils soient très gros, il faut juste qu'ils soient flexible un maximum.

[skeud]

Faut vraiment que tu écoutes ce qu'on dit, je recommence donc:

Qui va acheté ton moteur?

c'est simple comme question, on peut y répondre simplement, donc donne nous ton avis et ce sur quoi tu te bases. On ne veut pas des trucs du genre: "Moi, j'aimerais bien qu'un mec fasse ça, blabla, moi, moi, moi, moi".

Si tu veux vendre ton moteur, il faut qu'il soit attractif, et compétitif. A l'heure actuel, il ne possède ni l'un ni l'autre. Et ne le possèdera pas avant longtemps.

Prouves moi que j'ai tort et je te prendrais au sérieux. Mais pour l'instant, tu me fais penser à ces kevin qui se lancent dans un mmorpg en pensant révolutionner le monde ....

Tu n'as pas conscience de tout les problème que tu peux avoir en vendant ton moteur. Je vais te les apporter message par message comme tu ne semble pas aptes a recevoir plusieurs information par message.

[Invité]

Bon, je vois que tu ne comprends pas, je l'ai pourtant déjà dis plus haut sur ce sujet sur quel type de marché je me base mais je vois que tu ne lis pas les messages, c'est décevant. :/

Bref, je perd mon temps ici avec toi, et comme je te l'ai déjà dis, je dois terminer le moteur car à l'heure actuelle il manque juste encore d'un peu de performance pour les applications plus complexe.

Et puis tu sais sur le marché ce n'est pas le fait d'avoir un moteur et un jeux tel que celui utilisé par de nombreuses entreprises qui fait le succès, c'est le travail et le temps que tu auras passé sur ton propre projet. (et pas sur le forum)

Une fois que tu comprendras cela peut être pourras tu mieux avancer et ça fait déjà longtemps que j'ai abandonné mon projet de MMORPG, au profil de mon propre moteur, et de petites applications en 2D ou encore en 3D isométrique.

[skeud]

Et puis tu sais sur le marché ce n'est pas le fait d'avoir un moteur et un jeux tel que celui utilisé par de nombreuses entreprises qui fait le succès, c'est le travail et le temps que tu auras passé sur ton propre projet. (et pas sur le forum)

Je crois que tu es complètement déconnecté du monde actuel, que tu vis complètement dans ton monde. Si il suffisait de passer du temps sur un projet pour pouvoir le vendre, personne ne travaillerait en entreprise.

Je vais donc réécrire ce que j'ai mis plus haut pour réussir un projet et le vendre:

1) Avoir une idée (ça c'est bon tu l'as)
2) Développé son idée en un prototype (c'est ce que tu es en train de faire, d'ailleurs ton prototype avance bien)
3) Faire une étude de marché (pour savoir si son idée va se vendre, sinon ça ne sert à rien de la vendre).
4) Supprimer le prototype, et développé le vrai projet (ça tu en es loin).
5) Proposer une version beta à des développeur (qui seront présent et attendront ton projet car tu as fait une étude de marché donc tu sais que des personnes sont intéressés par ton projet).
6) Ouvrir une société (bah oui on ne peut pas vendre un projet en temps que particulier)
7) vendre son projet (en priant pour qu'il se vende au prix qu'on a proposer)
8) payer les charge inhérente à une société (qui sont plutôt conséquente).
9) faire vivre le projet.
10) gagner (un peu) d'argent suite aux ventes qu'on a fait.

Tu es au milieu du point 2 pour l'instant. Donc arrête de te croire supérieur à tout le monde. Écoute ce qu'on te dit. Si tu n'es pas d'accord, prouve le nous, au lieu de nous sortir des trucs du genre, "je suis différent, ça se passera pas comme ça, etc ....". ACCEPTE LES CRITIQUES. On ne dis pas ça pour t’embêter, mais pour t'aider, afin que tu réussisses ton projet.

[Invité]

Salut à tous.

SFML et SDL utilisant deux classes totalement dépendante de la librairie afin de créer un contexte opengl valide, cela pose problème :
En effet, ceci cause de nombreux crashs une fois que j'essaye d'utiliser les structures de la SDL pour le fenêtrage et les classes de la SFML pour le dessin.

J'ai décidé de coder mon propre module de fenêtrage.

Le but est de pouvoir créer un contexte opengl avec une fenêtre window ou bien SDL et de pouvoir utiliser soit SDL ou bien SFML, le module du moteur ou encore son propre module pour le dessin et de pouvoir dessiner des choses avec un module graphique totalement indépendant du module de fenêtrage.

Le contexte opengl ne sera donc pas créer dans la fenêtre comme c'est le cas avec SFML, mais dans la fenêtre de rendu!

Et le contexte opengl sera totalement indépendant de la librairie utilisée pour le dessins. (ce qui n'est pas le cas avec SFML ou bien SDL actuellement)

[skeud]

Quitte à tout refaire, tu veux pas refaire un système d'exploitation au passage? Car ton module de fenêtrage sera gêné par windows non?

[Invité]

Je ne pense pas repasser par windows, je compte rester sur du libre.

Et je ne compte pas faire un module de fenêtrage aussi conséquent que celui de SFML qui est en plus, assez chiadé, et cause des crashs insensé bien souvent, donc oui, si ça me gêne, je refais, c'est plus rapide que de chercher des erreurs dans un tas de lignes de code. :/

PS : plongé dans le code d'un OS ou encore le modifier ? Pourquoi pas, après tout, c'est grâce à ça que toutes les applis peuvent tourner.

[skeud]

Il t'es jamais venu à l'esprit que les crash était du à une mauvaise utilisation plutôt qu'une mauvaise libraire?

Donc si j'ai bien compris:
Tu veux vendre un moteur qui tournera sur un système gratuit et utilisé principalement par une communauté qui apprécie les logiciel open source?

Tu trouves pas que ça sonne faux?

[Scriuiw]

Petite question : Tu veux vendre ton moteur mais y existe t-il des démos de jeux développés dessus ?
As-tu essayé de faire quelques prototypes ou as-tu donné la main à d'autres développeurs pour qu'ils essayent de développer une démo jouable (Et avoir des retours et impressions) ?

J'avoue ne pas avoir lu tout le poste et mis à part deux vidéos sur la gestion des ombres et de l'éclairage, je n'ai rien vu de tel.
Peut-être suis-je passé à côté d'un autre fil..

[Invité]

Là j'ai deux solutions sous la main :

-Soit je continue de développer le moteur, en tentant de l'optimiser avec du traitement en parallèle (un genre à openCL) pour les scènes les plus complexe. (J'ai lu sur certains site que il y en avaient qui arrivaient à avoir du 30 FPS sur mobiles comme ça même avec des shaders, je vais essayer de trouver une solution avec SFML pour ne pas devoir tout refaire mais, ce n'est pas encore gagné. :/)

Et je laisse le soin à d'autres développeur de développez des petits jeux avec le moteur afin d'avoir du feedback comme le fait le développeur de la SFML.

-Ou bien, j'abandonne le développement du moteur et je fais moi même des petits jeux avec.

Je pencherai plutôt pour la 1ère solution car si je fais moi même pour le feedback ça risque d'être plus compliqué non ?

[Vetea]

Bonjour à toi,
Je te conseillerais de développer un petit projet 2d ou 3d mettant en avant ce que ton moteur peut faire.
Utilise des ressources libres de droit et le tour est joué.
Tu gagneras plus en crédibilité et ça te permettra aussi d'y voir plus clair car j'ai l'impression que tu pars parfois dans tous les sens.
Prends le temps de trouver l'idée pour ton projet, le gameplay et tout et tout et ensuite adapte le tout avec ton moteur comme si c'était celui d'un autre. Avec le recul que demande le dev. d'un jeu, ça va vraiment te donner une nouvelle dimension pour mieux te recadrer.
Bon courage.

[maeiky]

-Ou bien, j'abandonne le développement du moteur et je fais moi même des petits jeux avec.

Comment veux-tu faire un jeux avec ton moteur si t'abandonne ton moteur?

Tu es le mieux placer pour tester ton moteur, comment veux-tu savoir s'il fonctionne si tu ne le teste pas toi même en situation réel avec la conception d'un jeux? C'est comme ça que tu va voir si ta structure tien la route.

La solution est pourtant simple : Faire un jeux ou une démo des capacités du moteur en parallèle à sa conception.

Je vais créer une sorte de site avec payement sécurisé et système de license, je ne vois que ça comme solution, mais étant donné que je ne m'y connais pas de trop là dedans je vais sans doute devoir suivre une formation.

Tu risque d'être déçu si tu pense à vendre sans rien avoir de concret. Il ne faut pas vendre la peau de l'ours avant de l'avoir tué.

J'ai toutefois une bonne nouvelle pour toi, le site Binpress semble être parfait, tu peux vendre ton code open source et tout le système de licence et magasin est déjà conçu.

[Invité]

Bon, j'ai réinstallé mon OS et cette fois ça fonctionne correctement même avec le multi-threading par contre il y a vraiment un problème avec le driver, le blending ne fonctionne plus car j'ai des ombres toutes noires hors que je dessine un rectangle semi-transparent par dessus donc elle devrait être semi-transparentes.

Bref, je n'ai plus du tout le même résultat qu'avant, la semi-transparence n'est plus gérée non plus du coup avec mon shader.bref, il faudrait que je test sous window pour voir si j'ai le même problème. :/

Si oui je pense que je vais faire comme toi, c'est à dire, tout au niveau du CPU. (Mais ça risque d'être complexe surtout pour la 3D. :/)

C'est beaucoup plus facile au niveau des calculs lorsque les sommets sont projetés sur des plans 2D.

[Invité]

Je ne sais pas ce qui se passe avec le driver graphique mais, j'ai des résultats plutôt aléatoire, parfois ça fonctionne, parfois pas.

Bref ça marchait bien il y a quelques jours, j'ai même pu faire des vidéos et ici je me retrouve avec du noir entre les tiles, des ombres toutes noires et des lumières qui ne s'affichent plus, des tiles qui s'affichent par dessus les autres hors qu'elles ne devraient pas, des blending qui ne s'effectue pas bien, etc...

Alors je vais revoir la technique entièrement et comme je n'ai pas envie de recoder un OS, avec les drivers, SFML, ou quoi que ce soit. (surtout tout seul)

J'ai décidé de tout faire au niveau du CPU, d'autre part, ça augmentera la portabilité.

Car au niveau du GPU ça ne devient plus possible, les différentes techniques supportées par les différents drivers deviennent trop nombreuse, les fragments sont dessinés aléatoirement dans les shaders, le blending ne résous rien également.

Je cherche donc actuellement de nouvelles idées et je pense faire ceci :

Gestion de la semi-transparence :

Appliquer l'algorithme du peintre dans les composants de rendu, à la place des shaders, il me faut donc la coordonnée en z de tout les sommets en coordonnées vues ( et non pas en coordonnée monde vu que la position en z des objets change en fonction de l'orientation de la caméra)

Si des triangles pour les objets se croisent, reconstruire les triangles des objets en question et recalculer le centre en z, sinon, simplement calculer le centre en z et dessiner les objets dans l'ordre de leur centre en z.

Ca m'a l'air compliqué et je ne sais pas ce que ça va donner au niveau des performances, mais c'est le seul autre moyen de gérer la semi-transparence surtout en 3D.

Sinon pour la 2D, pas de problèmes.

Gestion de la lumière et des ombres via le raytracing :

Je pense entouré chaque objets d'un polygone (ou bien d'une sphere ou bien une boîte englobante, peu importe) et chercher l'intersection avec le rayon et enfin, calculer la couleur du pixel, cependant, j'aurai besoin de quelques conseils surtout pour recalculer la couleur d'un pixel avec le CPU là ou le rayon touche l'objet.

Dois je faire un screen de la scène, la sauver dans une image et changer sa couleur ?

Bref, je ne vois pas très bien comment m'y prendre.

Merci d'avance pour votre aide.

[skeud]

Tu commences à te rendre compte de la complexité de ton projet, en revanche, tu ne te poses pas du tout les bonne question et tu tire des conclusion qui sont complètement fausse. En l’occurrence, tu parles de ton driver, je te garantie que ton driver est correct, le problème vient plus probablement de ton moteur. De la manière dont il est fait.


Et maintenant tu viens demander des conseils, après la manière dont tu t'es comporté, n'espère clairement pas avoir de l'aide de ma part. Critiquer ton moteur, ça je peux le faire, mais ensuite t'aider, si tu ne m'écoutes pas (comme tu le fais jusqu'à présent), je ne pourrais rien pour toi...

Juste un conseil, le raytracing et opengl ne vont pas ensemble. Soit on choisit une technique soit l'autre. Donc renseignes-toi un peu, et quand tu auras compris le fonctionnement d'un moteur graphique, on en reparlera.