[ODFAEG] (Open Source Development Framework Adapted For Every Game)

[Lolilolight]

Je n'en met pas maintenant, j'ai des choses plus urgentes à faire pour la bibliothèque : réorganisation des fichiers, génération de la docs et finir de commenter le code source, et le site web afin de faire une librairie digne de son nom tout comme SFML. (Et réorganisation du répertoire git-hub pour un meilleur usage)

J'en ai aussi profiter pour utiliser std::function les outils pour la gestion automatique de la mémoire.

Je mettrai à jour le git-hub quand j'aurai fini. (juste avant de commencer le site web)

De plus je dois m'arranger aussi pour le nom de domaine avec une connaissance du web.

Donc vous comprenez bien que j'ai trop de boulot pour encore faire des vidéos ou bien des images.

[Lolilolight]

Je voudrais réagir suite à une remarque qui a été faîtes sur le forum Anglais au sujet d'une ombre. (celle d'un mur)

Je viens juste d'ajouter la possibilité de pouvoir changer le type d'ombre pour les murs, pour les murs qui se suivent donc j'utilise des shapes pour afficher les ombres, pour les murs qui ne se suivent pas, (comme l'unique mur près du feu de bois qui paraissait étrange), j'utilise un sf::Sprite ce qui rend beaucoup mieux!

On a donc maintenant le choix pour les modèles lors la génération d'une sf::Shape pour l'ombre ou bien d'un sf::Sprite.

Wall* w = new odfaeg::g2d::Wall(3, 80, t,odfaeg::g2d::AmbientLight::getAmbientLight(), odfaeg::g2d::Shadow::SHADOW_TYPE::SHADOW_TILE);
 

Je vais update le git-hub dès que possible, ici je suis entrain de mettre des commentaires partout pour générer la doc et ensuite je séparerai le code du mieux que je peux et je dois aussi rendre le linkage dynamique fonctionnel, et enfin je pourrai poster plus de vidéos!
J'essaye d'utiliser RAII et std::function le plus possible, et j'ai changé complètement ma classe FastDelegate. (Suite aux remarques qui ont été faîtes sur le forum Anglais à se sujet)

[Lolilolight]

Sortie de la release 1.0 et optimisations pour la version pro.

Quelques nouvelles :

Le moteur va devenir payant, cependant le code source de la version 1.0 restera disponible sur la plateforme git mais risque de ne pas bien fonctionné pour les rendus plus complexe et ne sera plus maintenu.

Objectif de la version payante ?

L'optimisation, et l'amélioration des rendus, en effet :

La version actuelle utilise beaucoup de shaders, le FPS est bas, et les shaders dépendent de la compatibilité avec la carte graphique. :/

Lors de la version pro je compte faire tout les calculs ainsi que toutes les textures de rendus avec le CPU.
Mais on pourra bien sûr encore utiliser le GPU, pour afficher le framebuffer dans une fenêtre SFML par exemple ou bien SDL.

La version pro vise un rendu complexe en peu de temps, donc, le moteur utilisera son propre système de rasterisation, ainsi, plus besoin de récupérer le pixel dans un shader avec une texture de rendu et de faire pleins de if.

En effet, le moteur positionnera la vue à la position des lumières pour générer les ombres pour les fragments qui sont dans le champs de vision de la caméra et convertira les coordonnées des fragments de la vue de la lumière à la vue de la caméra pour les ombres. (Chose qu'il est plus difficile de faire avec les textures de rendu)

Le moteur gérera aussi la réfraction (effet de miroir) et la disfraction de la lumière.

PS : par contre je ne sais pas si il est possible d'afficher une image directement sur la fenêtre avec SFML, au pire, j'afficherai la framebuffer avec un sprite dans la fenêtre.

L'avantage de se système : aucune connaissance de openg, de la SFML ou bien de la SDL sera requise, juste une connaissance du langage c++.
Le moteur sera compatible peu importe la plateforme utilisée.
Le moteur permettra de faire de beau rendu en peu de temps (aussi possible avec opengl mais plus compliqué car nécessite d'avoir une très bonne connaissance d'opengl et un driver qui supporte les versions modernes de opengl (je n'ai pas cette version))

Le framework va aussi bien sûr changer de nom.

Voici un aperçu de ce que le framework sera capable d'afficher :

http://www.massal.net/article/raytrace/page5.html

[G.]

C'est le début de la richesse !!!

[Lolilolight]

Bon, ce n'est que le début parce que là j'ai juste de quoi avoir maison et voiture à 26 ans avec quelques loisirs en plus quand même.

Bon, je vise plus haut après bien sûr, car il me faut un garde du corps, une limousine, une maison de luxe comme celle du développeur de mine craft et tant que je suis dans mon délire et que je me lâche, pourquoi pas ma 1ère petite copine!!! é_é  (Après 5 ans de pur développement à développez pendant 11 heures par jour derrière un fichu PC)

Haaaa si seulement la vie était si belle!!!

Laurent Gomilla sera tellement jaloux qu'il va encore plus me troll avec ses messages du genre : "Met un code minimal" ou bien fermera encore mes topiques parce que ça part en sucette.

Non mais plus sérieusement, ça coûte la peau des fesses en Belgique, parfois je me demande, pourquoi je ne me retrouve pas à la rue ?

Le seul avantage c'est que les soins sont remboursé mais maintenant c'est devenu partout pareil surtout avec OBAMA.

Voici quelque vidéos  pour les rendus :







A venir, les 1er jeux (enfin), mais je suis encore un petit peu loin de la version commerciale pour parler de richesse, car, il me faut encore faire un site de vente en ligne dans un 1er temps ensuite bien sûr, terminer d'ajouter les dernières fonctionnalités du moteur en priant pour qu'il se vende, et pour avoir ainsi assez pour héberger les futurs projets commerciaux.

Et comme je dois me charger de tout ça tout seul, c'est pas pour demain.

Mais a 30 ans j'espère!

[victorlevasseur]

Faire les rendus avec le CPU c'est pas une bonne idée,ça va être super lent non ?

[Lolilolight]

Oui, c'est trop lent avec le CPU, mais pour la version pro je vais quand même faire un système de raytracing au niveau du CPU mais cela servira juste pour créer des logiciels d'imageries. (Car c'est trop lent pour les jeux vidéos)

Par contre j'ai effectué toutes les transformations au niveau du CPU (avec du batching) et désormais je n'effectue qu'un seul appel à draw pour un ensemble de tiles utilisant les même matériaux!
J'ai également optimisé mon algorithme de frustrum culling.

Je passe donc d'un FPS de 15-20 à 30-40 avec les shaders, et 60 sans shaders.

Bref c'est beaucoup plus rapide que avec SFML qui effectue les transformations au niveau du GPU.

Bref mon FPS double je passe de 15-20 à 30-40 FPS :

Ici

[G.]

Mais 30 FPS avec 2 lumières, c'est un peu de la merde non ? 

[Lolilolight]

Je peux en mettre plus ça ne changera rien, le moteur est en "biased raytracing", donc, j'effectue tout les calculs au niveau du GPU.
A partir du moment ou j'utilise des shaders le FPS descend, mais le driver opensource est plus lent..., d'après ce que j'ai lu, sur un driver propriétaire peut être que cela tournerais à 60 FPS surtout que j'effectue du dereffered shading. (C'est à dire que je calcule la lumière seulement dans la zone d'influence de la lumière)

C'est à dire en jouant avec les coordonnées de texture et en projetant des rayons entre le centre de mes lumières et les fragments de la scene.

PS : maintenant un rendu basique de lumière sans shaders avec juste du blending ça aura un FPS plus élevé oui, et pour la 2D je peux comprendre qu'un tel FPS paraisse nul, par contre pour le bumpmapping, le normalmapping, la réfraction et la composante spéculaire, un shader c'est obligatoire. :/

[Lolilolight]

Pour cause de bugs SFML (bien que il y en avec SDL2 aussi), j'ai décidé de faire une interface qui permettra de choisir entre SDL ou bien SFML pour le fenêtrage.

SDL_Init(SDL_INIT_VIDEO);
    SDLRenderWindow window(800, 600, "SDL Render window", sf::ContextSettings(0, 0, 4, 3, 0));
    RectangleShape shape(Vec2f(100, 50));
    while (window.isOpen()) {
        window.clear();
        window.draw(shape);
        window.display();
        SDL_Event event;
        while (window.pollEvent(event)) {
            if (event.type == SDL_QUIT) {
                window.close();
            }
        }
    }
    SDL_Quit();
    return 0;
 

Bien sûr, au niveau de l'application il faudra choisir quel librairie utiliser.

SDL s'en sort mieux également au niveau du multi-threading et de la gestion multi-fenêtre/multi-écran, mais je n'ai pas encore testé avec les textures de rendus et les shaders.

PS : Les events ne seront plus de type sf::Event mais de type IEvent, et lors de la création de l'application il y aura une interface commune de type IRenderWindow quis ervira pour les fenêtres SFML et SDL.

[Laurent]

Dans ce cas quel est l'intérêt de garder SFML ? Ca fait au moins 3 fois que tu dis que tu vas passer à SDL, fais le une bonne fois pour toute et tu seras tranquille...

[Lolilolight]

Dans ce cas quel est l'intérêt de garder SFML ? Ca fait au moins 3 fois que tu dis que tu vas passer à SDL, fais le une bonne fois pour toute et tu seras tranquille...

Il y a encore des développeurs qui adore SFML car il la trouve plus simple à prendre en main que la SDL, donc, je pense que pouvoir choisir entre les deux, n'est pas une si mauvaise idée.

[mazertys17]

Salut.

Je m'invite un peu dans le débat, mais, ayant essayé la SDL et la SFML, je peux témoigner, ( bien que je sois débutant ), et pour moi, il y a pas photo  .
La SFML, est non seulement, en effet, bien plus pratique à prendre en main, mais en plus, plus efficace en performance ( d'après des test qui ont été fait il me semble ).
Il y a une documentation très propre et clair pour travailler, chose moins évidente avec la SDL.
Une communauté active qui permet d'avancer plus rapidement et de faire face a des pbs.
Enfin, la SFML est très complète et permet de faire tout ce qui est nécessaire pour la créatiation d'apli comme le jeu vidéo.

Alors pourquoi vouloir mélanger 2 bibliothèques qui proposent la même chose..?
C'est probablement des complications pour pas grand chose...( mais bon c'est mon avis de débutant ).

[Lolilolight]

Je ne suis pas sûr que SDL soit faîtes pour faire du c++, ni optimisée pour, car, dès que j'essaye d'encapsuler les fonctions de la SDL dans des classes je me retrouve avec une fenêtre qui ne s’efface pas.

SFML marche bien à partir du moment ou tu n'as pas trop de fenêtre et surtout de fenêtre invisible. :/ (Avec X11 en tout cas)

Je galère à faire mon jeux à cause de ça. :/

Si je dois recoder un module fenêtre j'en ferai un mais vraiment très simple, avec juste la création de fenêtre x11.

PS : et oui au niveau de la communauté aussi c'est cela qui m'a fait vraiment hésiter plusieurs fois entre SFML et SDL et comme le dis Laurent ça fait trois fois que je dis que je vais passer à la SDL. XD

Et encore, ce n'est que des petits libs SDL et SFML pour faire des applications basique donc imagine ce que ça doit être lorsque j'utilise des frameworks plus conséquent. XD

[G.]

Dans ce cas quel est l'intérêt de garder SFML ? Ca fait au moins 3 fois que tu dis que tu vas passer à SDL, fais le une bonne fois pour toute et tu seras tranquille...

Il y a encore des développeurs qui adore SFML car il la trouve plus simple à prendre en main que la SDL, donc, je pense que pouvoir choisir entre les deux, n'est pas une si mauvaise idée.

Dans le cas improbable où un jour quelqu'un utilise ta bouse, il utilisera tes interfaces et pas la SFML ou la SDL non ?