Discussion :

[Invité]

Mais elle est où ta semi-transparence, moi je ne la voie pas :

C'est normal que tu ne la voie pas, mais le bords de chaque tile est transparent c'est juste qu'elles sont imbriquées les unes dans les autres afin de gérer les transitions entre tiles, de ce fait, on ne voit pas les bords des tiles et donc on ne voit pas qu'elles sont semi-transparentes, c'est le but.

Je ne sais plus comment te le dire, ça ne marche pas et tu n'as pas besoin de ça. Le calcul de la transparence c'est élémentaire, ça doit se faire dans l'ordre.

Regarde l'image ci-dessous, au centre des carrés la couleur ne sera pas la même si l'ordre change. Essai de faire ça avec ton moteur juste pour voir.

Tu crois que je n'ai pas déjà essayer d'afficher deux sprites semi-transparents en changeant l'ordre ?
Tu me prends pour un codeur du dimanche ou quoi ?
Ou alors tu essayes juste de te moquer de moi ?
J'ai essayé de les afficher en changeant l'ordre et la couleur reste bien la même au centre des carrés.

Tu part dans une bien mauvaise direction, si tu continue comme ça, c'est sur ton moteur qu'on va s'en "battre les couilles"

HAHAHAHAHA!

[maeiky]

C'est normal que tu ne la voie pas, mais le bords de chaque tile est transparent c'est juste qu'elles sont imbriquées les unes dans les autres afin de gérer les transitions entre tiles, de ce fait, on ne voit pas les bords des tiles et donc on ne voit pas qu'elles sont semi-transparentes, c'est le but.

C'est super d'avoir de la semi-transparence qui ne ce voie pas. Puis c'est une méthode un peu naïve de combiné des tiles.
Et pour la fumé et les ombres alors?

Tu crois que je n'ai pas déjà essayer d'afficher deux sprites semi-transparents en changeant l'ordre ?

Fait un petit print screen shot d'une série d'images semi-transparente de couleur différentes rendu par ton moteur, comme le montre l'image et je vais te croire.


Edit :

Tu crois que je n'ai pas déjà essayer d'afficher deux sprites semi-transparents en changeant l'ordre ?

Ok, si ton moteur se limite à 2 sprites, ça passe.

[Invité]

Oui, il se ne limite que a deux sprites. ^^

Avec plus que deux sprites, je n'ai jamais essayé, car je ne me limite que à deux sprites, mais, j'aimerais quand même essayer, juste par curiosité.

[Iradrille]

C'est normal que tu ne la voie pas, mais le bords de chaque tile est transparent c'est juste qu'elles sont imbriquées les unes dans les autres afin de gérer les transitions entre tiles, de ce fait, on ne voit pas les bords des tiles et donc on ne voit pas qu'elles sont semi-transparentes, c'est le but.

L'image de gauche est transparente (rgba = 0, 0, 0, 0 sur les bords), l'image de droite est semi transparente (rgba = 0, 255, 0, 127 sur les bords).

Il n'y à pas besoin d'ordre ni d'alpha blending pour l'image de gauche, seule l'image de droite est problématique.

Tes tiles sont biens semi transparentes du coup ?

[Jbx 2.0b]

Tu me prends pour un codeur du dimanche ou quoi ?

Oui, il se ne limite que a deux sprites. ^^

float current_depth = (gl_FragCoord.w != 1.f) ? (inverse(projMat) * vec4(0, 0, 0, gl_FragCoord.w)).w : gl_FragCoord.z;"
"colors[1] = current_color * current_color.a + previous_color * (1 - current_color.a);"
"colors[1].a = current_color.a + previous_color.a * (1 - current_color.a);"
"colors[0] = previous_color * previous_depth_alpha.a + current_color * (1 - previous_depth_alpha.a);"
"colors[0].a = previous_color.a + current_color.a * (1 - previous_color.a);"
"b = (current_depth >= previous_depth_alpha.z);"
"gl_FragColor = colors[int(b)];

Y a quand même un sacré problème. C'est quoi l’intérêt de ce merdier si au final tu ne fais que combiner deux sprites ? Pourquoi ne pas utiliser les glBlendFunc() / glBlendFuncSeparate() ?

[Invité]

Salut, voici un exemple de code qui dessine trois sprite semi-transparent (rouge, jaune et bleu) avec mon moteur, sans tenir compte de leur position en z.

Code cpp :

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
 
RenderWindow window (sf::VideoMode (800, 600), "Test", sf::Style::Default, sf::ContextSettings(0, 0, 4, 3, 0));
    window.getView().move(400, 300, 0);
    Texture tex;
    RectangleShape rs(Vec3f(100, 100, 0));
    rs.move(Vec3f(100, 100, 0));
    tex.loadFromFile("tilesets/herbe.png");
    Tile tile1 (nullptr, Vec3f(0, 0, 0), Vec3f(100, 100, 0), sf::IntRect(0, 0, 100, 100), sf::Color(255, 0, 0, 128));
    Tile tile2 (nullptr, Vec3f(10, 10, 1), Vec3f(100, 100, 0), sf::IntRect(0, 0, 100, 100), sf::Color(255, 255, 0, 128));
    Tile tile3 (nullptr, Vec3f(20, 20, 2), Vec3f(100, 100, 0), sf::IntRect(0, 0, 100, 100), sf::Color(0, 0, 255, 128));
    std::vector<Entity*> entities = {&tile1, &tile2};
    FastRenderComponent frc(window,0, "E_TILE", false);
    frc.clear();
    frc.loadEntitiesOnComponent(entities);
    //frc.draw(rs);
    frc.drawNextFrame();
    while (window.isOpen()) {
        window.clear();
        window.draw(frc);
        window.display();
        sf::Event event;
        while (window.pollEvent(event)) {
            if (event.type == sf::Event::Closed) {
                window.close();
            }
        }
    }
    return 0;

Le second paramètre du constructeur de ma classe Tile est la position de la tile, la troisième coordonnée est donc la position en z de la tile. (Et donc le numéro de sa couche, bref c'est l'ordre de la tile)

Voici ce que cela donne au rendu!



Je vais maintenant inverser l'ordre des tiles (leur position en z donc) :

Code cpp :

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

1
2
3
4
 
Tile tile1 (nullptr, Vec3f(0, 0, 0), Vec3f(100, 100, 0), sf::IntRect(0, 0, 100, 100), sf::Color(255, 0, 0, 128));
Tile tile2 (nullptr, Vec3f(10, 10, 2), Vec3f(100, 100, 0), sf::IntRect(0, 0, 100, 100), sf::Color(255, 255, 0, 128));
Tile tile3 (nullptr, Vec3f(20, 20, 1), Vec3f(100, 100, 0), sf::IntRect(0, 0, 100, 100), sf::Color(0, 0, 255, 128));

Le rendu reste le même :



Si l'on souhaite cependant avoir quand même un rendu différent, on peut changer la position des tiles dans le vecteur :

Code cpp :

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

1
2
 
std::vector<Entity*> entities = {&tile2, &tile3, &tile1};

La, vu que le sprite jaune est dessiné avant le sprite bleu et que le sprite bleu est dessiné avant le sprite rouge, le rendu est bien sûr différent.

Voilà!

PS : j'ai oublié de désactivé le blending alpha lors du rendu, donc, la couleur au centre n'est pas bonne mais le résultat reste le même pour les deux rendu!

[Jbx 2.0b]

Je vais maintenant inverser l'ordre des tiles (leur position en z donc) :

Code cpp :

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

1
2
3
4
 
Tile tile1 (nullptr, Vec3f(0, 0, 0), Vec3f(100, 100, 0), sf::IntRect(0, 0, 100, 100), sf::Color(255, 0, 0, 128));
Tile tile2 (nullptr, Vec3f(10, 10, 2), Vec3f(100, 100, 0), sf::IntRect(0, 0, 100, 100), sf::Color(255, 255, 0, 128));
Tile tile3 (nullptr, Vec3f(20, 20, 1), Vec3f(100, 100, 0), sf::IntRect(0, 0, 100, 100), sf::Color(0, 0, 255, 128));

Le rendu reste le même :

Ici, la tuile bleu a une z-value de 1, elle devrait donc être au centre ?

Edit : Ok, ouais, non, avec le décalage ça ne change rien effectivement. Il faudrait changer les x & y également.

[maeiky]

Tu sais c'est quoi ton problème?

C'est que tu te lance dans des méthodes tête baissé sans même avoir testé à fond et sans même te rendre compte que tout le reste en dépend.

Tu n'avais même pas testé jusqu'ici plus de 2 sprites semi-transparent. Et tu pense déjà à utilisé des variables atomiques. En continuant ainsi, même OGL 8 ne pourra pas supporter tes algos foireux.

Tu ne t'es jamais demandé, une seconde, pourquoi il y en a qui se casse l'arrière train à trouver une façon de gérer la transparence dans n'importe quel ordre. Et tu crois que ta méthode, la plus naïve possible, ils n'y ont pas pensé?

Bon, oui, 3 sprites ça "peu" marcher, mais tu n'as pas testé toutes les possibilités.

Le problème c'est que tu ne peux additionné des sprites semi-transparent dans un sens et revenir pour additionné le sprites intermédiaire dans l'autre sens et ainsi de suite.
Quand tu combine des couleurs, tu ne peux pas skipper celle du milieu pour la calculer après, ça fais partie des 10 commandements.

Dire que j'ai crue un instant qu'il y avais de l'espoir.

[Invité]

Quand tu combine des couleurs, tu ne peux pas skipper celle du milieu pour la calculer après, ça fais partie des 10 commandements.

Bah, là je l'ai fais et ça marche...

J'ai dû me casser l'arrière train aussi mais bon...

PS : Désolé mais je suis plus orienté résultat que commandement, et, il faudra s'y faire...

[maeiky]

Ça marche avec quoi? Des sprites composé d'une couleur R, G ou B? Évidement les combinaisons se font sur des couleurs vide.

Pourquoi ne me montrerais-tu pas un exemple d'une dizaine de vrai sprite, dessiné de façon aléatoire.

[Cirrus Minor]

Bonsoir tout le monde !

Alors, j'y connais pas grand-chose en moteurs graphiques, mais si j'affiche deux carrés qui possèdent une couche alpha dans un ordre ou dans l'autre, je n'obtiens pas la même chose.
Comment gères-tu ça ?

Un exemple avec un carré rouge et un carré bleu, avec un alpha de 200, sur un fond blanc:



Code (SFML):

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
 
    _window.clear(sf::Color::White);
 
    sf::RectangleShape rectangle1(sf::Vector2f(200, 200));
    rectangle1.setPosition(50, 50);
    rectangle1.setFillColor (sf::Color(255, 0, 0, 200));
 
    sf::RectangleShape rectangle2(sf::Vector2f(200, 200));
    rectangle2.setPosition(100, 100);
    rectangle2.setFillColor (sf::Color(0, 0, 255, 200));
 
    _window.draw(rectangle1);
    _window.draw(rectangle2);
 
    rectangle1.setPosition(350, 50);
    rectangle2.setPosition(400, 100);
 
    _window.draw(rectangle2);
    _window.draw(rectangle1);
 
    _window.display();

[Invité]

Salut, bah moi j'obtiens la même chose!

C'est d'ailleurs pour cela que si j'affiche du sable sur de l'herbe, ou bien de l'herbe sur du sable, la couleur de la transition entre l'herbe et le sable est de la même couleur et pas de deux couleurs différentes comme c'est le cas avec le blending alpha par défaut de opengl. :/ (Qui n'est d'ailleurs pas bon et il est évidemment déconseillé de l'utiliser)

[maeiky]

L'algo de Lolilolight le gère, mais il est rempli de lacunes pour en afficher plusieurs.
En gros il y a 2 formules :
alpha_out = alpha_a + alpha_b (1 - alpha_a)
color_out = color_a + color_b (1 - alpha_a)
Pour un affichage du dernier au premier plan.
Et respectivement son inverse pour du premier au dernier.

Lolilolight pense qu'il peu appliquer un depth test dessus pour pouvoir afficher les pixels individuellement dans n'importe quel ordre et ainsi révolutionner le OIT.
Dans cette logique, Il peu arrivé que qu’il affiche le dernier, le premier en ensuite celui du milieu. Dans ce cas il a déjà interpolé les couleurs opposé et il tente d’obtenir la couleur intermédiaire, ce qui est faux. Sans parler de l’imprécision du point flottant qu’a va varier d’un affichage aléatoire à l’autre dans le cas d’un batching par exemple.

[foetus]

L'algo est plutôt celui-ci pour 2 images, une devant (fg) et une derrière (bg)

Code :

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

1
2
3
4
5
6
    var r = new Color();
    if (r.A < 1.0e-6) return r;
    r.A = 1 - (1 - fg.A) * (1 - bg.A);
    r.R = fg.R * fg.A / r.A + bg.R * bg.A * (1 - fg.A) / r.A;
    r.G = fg.G * fg.A / r.A + bg.G * bg.A * (1 - fg.A) / r.A;
    r.B = fg.B * fg.A / r.A + bg.B * bg.A * (1 - fg.A) / r.A;

Trouvé sur http://stackoverflow.com Algorithm for Additive Color Mixing for RGB Values

[Aloah41]

Pourquoi vous lui répondez ?

C'est un troll obligé personne ne peut être aussi idiot .... Fin je sais pas comment vous faites pour le feeder là ... Vous croyez franchement qu'il va vivre de son truc ??

Le peu que j'en ai lu (je me suis bien marré par ailleurs) il refait tout lui même, si il pouvait coder directement en assembleur le gpu il le ferait je pense.

Nan mais sans plaisanter, le mec attend opencl pour optimiser son "moteur" car opengl c'est nul en gros.


J'appelle pas ça un moteur, ça ressemble plutôt à un projet étudiant de première année, pour quelqu'un d'expérimenté c'est assez pitoyable, j'imagine même pas le code lui même, vu la personnalité de l'op, de forte chance que ce soit dégueulasse.

Tu te prends pour qui pour dire qu'opengl c'est nul ?
Tu te prends pour qui quand tu dis que tu vas faire ton propre driver car ton superbe moteur en avance sur son temps ne marche pas sur les pc d'aujourd'hui ?
Tu te prends pour qui avec ton moteur qui affiche 3 sprites, le tout en ne comprenant rien ?

Ah oui car j'ai vu la partie avec les swaps de techniques pour afficher ses trucs (et optimiser ses magnifiques 30fps avec des textures 4K 3000 animations en temps réel et 12 simulation de fluides etc ...) en gros tu fais des ctrl+c ctrl+v ça marche pas = c'est pourri






Pourquoi vous continuez à l'aider ? J'ai pas l'impression que ce soit de développeurs qu'il ait besoin. Moi je vais pas aider une personne comme ça.


Mais franchement tu te prends pour qui ?

[foetus]

Tu te prends pour qui quand tu dis que tu vas faire ton propre driver car ton superbe moteur en avance sur son temps ne marche pas sur les pc d'aujourd'hui ?

Il me semble que c'est le contraire : sur les vieux ordinateurs, il n'y a pas les fonctionnalités d'OpenGL 4.X.
C'est aussi pour cela qu'il attend Vulkan.

[CodeurPlusPlus]

Pourquoi vous lui répondez ?

Parce qu'aucune loi ne l'interdit.

C'est un troll obligé personne ne peut être aussi idiot ....

1er message... tu aurais donc créé un compte juste pour pouvoir insulter lolilolight en tout anonymat ?

J'appelle pas ça un moteur, ça ressemble plutôt à un projet étudiant de première année (...)

Hé bien disons que c'est un moteur codé avec le niveau d'un étudiant de première année

Mais franchement tu te prends pour qui ?

Je ne sais pas pour qui lolilolight se prend, mais je sais que tu as raté de quelques jours une chouette Game Jam où j'aurais été ravi de pouvoir mesurer ton savoir faire.

[nnovic]

Mais franchement tu te prends pour qui ?

Je te retourne la question...! On est dans un monde libre. Lolilolight réalise son projet comme il le souhaite, on lui donne des conseils si ça nous chante, ça ne fait de mal à personne. En revanche des messages comme le tien sont toxiques.

[Aloah41]

Concernant les deux whiteknights,

Aider une personne en soit n'est pas un problème et ce n'est pas ça que je remets en cause.

Pourquoi aider quelqu'un en avance sur son temps ?
Pourquoi aider quelqu'un qui sait tout ?
Pourquoi aider quelqu'un qui peu importe les solutions données n'écoute pas car :
-opengl c'est nul
-c'est l'os le problème pas son moteur
-si il existait des drivers mieux que ça ça marcherait bien (tu veux pas créer tes propres gpu ? pour être sur de tout contrôler ?)


Et le mec s'étonne de ne pas être fait pour le monde du travail, mais quelle blague, quelle blague.

Bien sur vous êtes libre de faire ce que vous voulez, mais faites, mais faites perdez votre temps.


"S'accrocher à une personne qui n'ajoute plus aucune valeur positive à ta vie, ce n'est pas de la loyauté, c'est de la stupidité" (première recherche google la flemme de trouver mieux, mais l'esprit est là quoi que ...)


Ouais bien sur il attend Vulkan, tous les jeux qui sortent utilisent Vulkan c'est bien connu, et ils tournent tous à 10fps car ils n'utilisent pas la super technique de Lolilolight XD.


Rien que son pseudo Lolilolight, il doit avoir +de 30ans le mec c'est ça le pire.


Il devrait arrêter le dev et commencer une carrière d’humoriste il fera mieux que Julien Courbet ça j'en suis sûr .

[nnovic]

Alors que toi, qui vient déverser ta colère sur ce fil de discussion, ce n'est pas une perte de temps, bien entendu... !

Si le sujet ne t'intéressais pas, tu pouvais simplement l'ignorer et faire quelque chose de plus intéressant à la place. C'est ce qu'une personne raisonnable aurait fait, en tout cas...