Bienvenue, Invité. Merci de vous connecter ou de vous inscrire. Avez-vous oublié d'activer ?

Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - Samuel Proulx

Pages: [1] 2 3 ... 8 Suivante »
1
Général / Re : GCC 4.8.1 64 bits
« le: Octobre 16, 2013, 07:33:44 pm »
Ah ben oui ! J'avais pas pensé qu'il fallait changer le PATH... puisqu'en temps normal je voulais remplacer le 32 bits par le 64, mais finalement j'ai gardé les deux pour un besoin pratique...

Merci, ça fonctionne nickel ! :)

2
Général / GCC 4.8.1 64 bits
« le: Octobre 16, 2013, 05:10:20 am »
Bonjour à tous et à toutes :)

J'ai réussi (finalement) à installer correctement mingw64 avec code blocks et tout fonctionne à merveille si je me limite à la STL.

Lorsque je veux utiliser la SFML (32 bits) que j'avais compilé pour 4.8.1... On dirait que ça ne fonctionne pas (toujours des erreurs du type undefined reference to...). J'imagine donc que les libs.a doivent être recompilé en 64 bits (logique sinon je ne vois pas pourquoi on peut télécharger SFML en 32 ou 64 bits...)

Or, la version 64 bits dans les download est seulement avec GCC 4.7. J'aimerais donc savoir comment je dois faire pour compiler la lib en 64 bits.

Merci et bonne journée ! :)

Ps. avec CMake, j'ai essayé de choisir Specify a native compilers au lieu de la détection automatique, mais quand j'entre les mingw64.....g++.exe, CMake me dit que c'est pas un compilateur valide. Pourtant, c'est bien ces exécutables qui sont dans mon toolchain dans code blocks.

3
Général / Re : Thread plutôt lent
« le: Juillet 14, 2013, 11:16:15 pm »
ah ok, donc si je comprends bien, l'OS, après avoir fait juste un tour de boucle (donc une opération minable), il en profite pour changer de contexte et c'est là que ça marche pas...


J'ai refait un test en appliquant plus d'opérations et ça a beaucoup plus de sens : 117 000 en multithreading face à 93 000 sans thread.

Mais petite question comme ça, pourrais-tu m'expliquer pourquoi le fait de créer un thread engendre un changement de contexte dans les boucles ?

Je crois que c'est un truc direct dans l'OS, mais... l'OS doit bien ce rendre compte que la boucle est très court et qu'il pourrait l'exécuter plusieurs fois pour atteindre X microsecondes et ensuite effectuer un changement de contexte non ?

4
Général / Re : Thread plutôt lent
« le: Juillet 14, 2013, 08:26:05 pm »
Les rapport de temps mentionné était sur des multiplications matricielles, là on constate que sur une simple affectation de variable, c'est terriblement lent (1.3 millions vs. 210 000)

De plus, si je fais le travaille des 3 threads dans le principal, (une boucle de 300 000 000 donc) ça donne 628 000... soit deux fois moins long dans un thread...

5
Général / Re : Thread plutôt lent
« le: Juillet 14, 2013, 08:24:04 pm »
#include <iostream>
#include <SFML/System.hpp>

using namespace std;
using namespace sf;

int64_t aa = 0;
int64_t bb = 0;
int64_t cc = 0;

int64_t timea = 0;
int64_t timeb = 0;
int64_t timec = 0;

void a()
{
    for (size_t i = 0; i < 100000000; ++i)
        aa = i;
}
void b()
{
    for (size_t i = 0; i < 100000000; ++i)
        bb = i;
}
void c()
{
    for (size_t i = 0; i < 100000000; ++i)
        cc = i;
}

int main()
{
    Thread thread1(a);
    Thread thread2(b);
    Thread thread3(c);

    Clock clock;

    thread1.launch();
    thread2.launch();
    thread3.launch();

    thread1.wait();
    timea = clock.getElapsedTime().asMicroseconds();
    thread2.wait();
    timeb = clock.getElapsedTime().asMicroseconds();
    thread3.wait();
    timec = clock.getElapsedTime().asMicroseconds();

    cout << timea << "\n" << timeb << "\n" << timec << endl;
    return 0;
}
 

Les trois tournent autour de 1.3 millions

int main()
{
    Thread thread1(a);
    Thread thread2(b);
    Thread thread3(c);

    Clock clock;

    for (size_t i = 0; i < 100000000; ++i)
        aa = i;

    cout << clock.getElapsedTime().asMicroseconds() << endl;
    return 0;
}
 

~210 000

Par contre, si tu essaies le premier code en faisant juste un thread1.lauch() et thread1.wait(), là ça arrive à peu près au même temps... (~220 000)

6
Général / Re : Thread plutôt lent
« le: Juillet 14, 2013, 08:13:26 pm »
Ah voici un truc assez bizarre : si je crée un thread, là ça prend le même temps que si je n'en créais pas. Si j'en crée deux, le temps est triplé et si j'en crée trois, le temps est presque quadruplé.

Est-ce normal ?

7
Général / Thread plutôt lent
« le: Juillet 14, 2013, 07:50:14 pm »
Bonjour à tous et à toutes :)

J'ai fait un petit code simple qui démarre un thread et je mesure le temps avec un sf::Clock en attendant thread.wait();

Comment se fait-il que pour la même charge de travail (ex. une boucle qui tourne 100 millions de fois et affecte i à une variable) un thread créé prend toujours environ 3 fois plus de temps pour exécuter le même code que le thread "principal" du processus ?

L'intérêt du multithreading est totalement perdu si ces derniers ne s'exécutent pas aussi vite que le processus même... (y a-t-il un problème dans le scheduler de windows face à ça ?)

Merci et bonne journée ! :)

8
Fenêtrage / Faire du rendu 3D pour produire des sprites
« le: Avril 08, 2013, 02:01:22 am »
Bonjour à tous et à toutes :)

Je fais un moteur un peu spécial qui me demande de faire du rendu 3D (pour du réalisme et des problèmes de consommation mémoire monstrueuse si c'était en image) pour ensuite afficher les modèles 3D les uns par dessus les autres comme des sprites.

On m'a donc fortement conseillé l'utilisation des FrameBuffer Object étant donné que j'utilise OpenGL 3.

En fouillant un peu dans les classes de la SFML, j'ai aperçu un RenderTexture qui permet de faire exactement ce que j'ai besoin.

Ma question est donc la suivante : est-ce que la classe renderTexture est équivalente au FBOs en performance ou suis-je mieux de faire ma propre implémentation ?

Je sais que la SFML est faite principalement pour OpenGL 2, et l'extension des FBO n'était pas prise entièrement en charge via l'extension. Je me demande donc s'il procède directement sur la carte graphique ou s'il s'agit d'une ancienne méthode moins optimisé (transfert CPU/GPU), mais qui permet de garder une compatibilité.

Merci et bonne journée 8)

9
Général / Re : Utiliser Window.pollevent abusivement
« le: Novembre 21, 2012, 04:10:18 am »
Hum... je suis curieux de savoir c'est quoi ce fonctionnement étrange ? :o

Je ne comprends pas pourquoi faire plusieurs pollevent pour gérer la GUI et le render (jeu).... ???

Quelqu'un peut m'expliquer ce qu'il fait ?

Merci et bonne journée ! :)

10
Général / Re : [1.6] isKeyDown
« le: Novembre 20, 2012, 01:25:26 am »
Par contre, je ne crois pas qu'il y ait une méthode pour connaître la position antérieur du curseur (pas vu dans les tutos cités en tous cas).

Donc pour créer un déplacement, là je suppose qu'il faut conserver l'ancienne position du curseur, non ?

11
Général / Re : [1.6] isKeyDown
« le: Novembre 20, 2012, 01:21:45 am »
Ah effectivement, tu as raison (je suis allé voir dans les headers).

Je crois qu'elle n'existait pas dans un ancien snapshot (je ne suis pas sûr...). Du moins, les tutoriaux n'existaient pas à cette époque et je n'avais jamais vu la méthode statique dans le header dans ce temps ::)

C'est toujours bon à savoir ;D

12
Général / Re : [1.6] isKeyDown
« le: Novembre 20, 2012, 12:18:25 am »
Dans la 1.6, la SFML gérait cette commande pour accommoder les utilisateurs. Aujourd'hui (2.0), ceci n'existe plus.

Event::KeyPressed c'est un événement déclenché par l'utilisateur (il a appuyé une touche). isKeyDown servait à savoir à n'importe quel moment dans le code si une touche est actuellement appuyé (tu ne vas pas recevoir infiniment l'événement KeyPressed quand on tiens une touche enfoncé (bien que c'est possible de setter la répétition des événements...)

Tu dois donc, avec la 2.0, avoir un tableau de booléen stockant l'état de chaque touche du clavier. Ainsi, lorsque tu reçois un Event::KeyPressed, tu mets le nouvel état de la touche dans le tableau. C'est dans ce tableau que tu vas lire pour savoir si l'utilisateur appuie actuellement une touche.

Voilà tout :)

13
Général / Re : [OpenGL] bug lorsque deux carrés superposés
« le: Novembre 19, 2012, 10:57:49 pm »
Petite précision : le problème vient tout simplement lorsque plein de surfaces sont superposées (même sans le depth test).

Voici un code utilisant glew :

10 000 carrés (20 000 triangles)
Vertex Buffer : oui
Indices Buffer : oui
Texture : non
Shader : non

#include <iostream>
#include <sstream>
#include <GL/glew.h>
#include <SFML/Graphics.hpp>
#include <SFML/OpenGL.hpp>
#include <random>

#define NB_POLY 10000

using namespace std;
using namespace sf;

int main()
{
    RenderWindow app(VideoMode(800,600),"OpenGL");
    glewInit();
    float* vertexData = new float[12*NB_POLY];
    for(int i=0;i<NB_POLY;i++)
    {
        vertexData[0+i*12] = -0.05f;
        vertexData[1+i*12] = 0.05f;
        vertexData[2+i*12] = -1.0f;

        vertexData[3+i*12] = 0.05f;
        vertexData[4+i*12] = 0.05f;
        vertexData[5+i*12] = -1.0f;

        vertexData[6+i*12] = 0.05f;
        vertexData[7+i*12] = -0.05f;
        vertexData[8+i*12] = -1.0f;

        vertexData[9+i*12] = -0.05f;
        vertexData[10+i*12] = -0.05f;
        vertexData[11+i*12] = -1.0f;
    }
    short* indiceData = new short[6*NB_POLY];
    for(int i=0;i<NB_POLY;i++)
    {
        indiceData[0+i*6] = 0+i*4;
        indiceData[1+i*6] = 1+i*4;
        indiceData[2+i*6] = 2+i*4;

        indiceData[3+i*6] = 0+i*4;
        indiceData[4+i*6] = 2+i*4;
        indiceData[5+i*6] = 3+i*4;
    }
    //Buffer Object
    GLuint vertexBufferObject;

    glGenBuffers(1,&vertexBufferObject);
        glBindBuffer(GL_ARRAY_BUFFER,vertexBufferObject);
        glBufferData(GL_ARRAY_BUFFER,sizeof(float)*12*NB_POLY,vertexData,GL_STATIC_DRAW);
        glBindBuffer(GL_ARRAY_BUFFER,0);

        GLuint indiceBufferObject;
        glGenBuffers(1,&indiceBufferObject);
        glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,indiceBufferObject);
    glBufferData(GL_ELEMENT_ARRAY_BUFFER,sizeof(short)*6*NB_POLY,indiceData,GL_STATIC_DRAW);
        glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,0);

    Clock time;
    int nbFPS = 0;
    while(app.isOpen())
    {
        if(time.getElapsedTime().asMilliseconds() >= 1000)
        {
            ostringstream ss;
            ss << nbFPS;
            nbFPS = 0;
            app.setTitle(ss.str());
            time.restart();
        }
        else
            nbFPS++;
        Event event;
        while(app.pollEvent(event))
        {
            if(event.type == Event::Closed)
                app.close();
        }
        glClear(GL_COLOR_BUFFER_BIT);

        glEnableVertexAttribArray(0);
        glBindBuffer(GL_ARRAY_BUFFER,vertexBufferObject);
        glVertexAttribPointer(0,3,GL_FLOAT,GL_FALSE,0,0);
        glBindBuffer(GL_ARRAY_BUFFER,0);

        glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,indiceBufferObject);
        glDrawElements(GL_TRIANGLES, 6*NB_POLY, GL_UNSIGNED_SHORT, 0);
        glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,0);

        glDisableVertexAttribArray(0);

        app.display();
    }
    glDeleteBuffers(1,&vertexBufferObject);
    glDeleteBuffers(1,&indiceBufferObject);
    return 0;
}
 

Avec 20 000 triangles, j'obtiens ~60 FPS.... C'est pas très optimal...

Selon ce que j'ai compris, il s'agit d'overdraw : tous les triangles sont dessinés. Cela signifie donc remplir environ 100x100x10 000 pixels à chaque frame. 100 M de pixels par frame, je crois que c'est très coûteux en ressources...

Maintenant, si je met des Z aléatoires, je tourne à 180 FPS avec 10 000 carrés :
    default_random_engine generator;
    uniform_real_distribution<float> distribution(-1,1);
    RenderWindow app(VideoMode(800,600),"OpenGL");
    glewInit();
    float* vertexData = new float[12*NB_POLY];
    for(int i=0;i<NB_POLY;i++)
    {
        float rand = distribution(generator);
        vertexData[0+i*12] = -0.05f;
        vertexData[1+i*12] = 0.05f;
        vertexData[2+i*12] = -1.0f+rand;

        vertexData[3+i*12] = 0.05f;
        vertexData[4+i*12] = 0.05f;
        vertexData[5+i*12] = -1.0f+rand;

        vertexData[6+i*12] = 0.05f;
        vertexData[7+i*12] = -0.05f;
        vertexData[8+i*12] = -1.0f+rand;

        vertexData[9+i*12] = -0.05f;
        vertexData[10+i*12] = -0.05f;
        vertexData[11+i*12] = -1.0f+rand;
    }
 

Remarque aussi que si l'on dessine 10 000 shape :
ConvexShape shape;
    shape.setPointCount(4);
    shape.setPoint(0,Vector2f(0,0));
    shape.setPoint(1,Vector2f(100,0));
    shape.setPoint(2,Vector2f(100,100));
    shape.setPoint(3,Vector2f(0,100));


    for(int i=0;i<10000;i++)
        app.draw(shape);
 

Ça tourne à 8 FPS. Sauf qu'il me semble que chaque draw(shape) est un appel à glDraw*(). Ce qui est tout à fait normal que ça coûte cher si on appelle 10 000 fois le driver par frame...

Comment faire pour gérer cela plus efficacement ?

Merci et bonne journée ! :)

14
Général / [OpenGL] bug lorsque deux carrés superposés
« le: Novembre 19, 2012, 02:49:30 am »
Bonjour à tous et à toutes :)

Lorsque deux carrés sont superposés (x,y,z identique) les FPS chute rapidement. Y a-t-il une raison à cela ?

Je peux dessiner 100 000 carrés (200 000 triangles) à des endroits différents et je vais tourner à 100 FPS. Si je met aucun offset à aucun carré, là je tourne à 3 FPS...

Merci et bonne journée ! :)

15
Général / OpenGl 3.1 Comment mieux optimiser ?
« le: Novembre 18, 2012, 04:50:46 am »
Bonjour à tous et à toutes :)

J'ai un modèle 3D entièrement stocké sur le buffer de la carte graphique (GL_ARRAY_BUFFER,GL_ELEMENT_ARRAY_BUFFER,GL_TEXTURE_BUFFER). J'utilise glDrawElements puisque mes triangles sont indexés.

Existe-t-il une méthode plus rapide pour dessiner quelque chose à l'écran ou ce que j'utilise est le plus rapide pour faire le rendu d'un objet ?

De plus, comment fait-t-on pour optimiser la vitesse de rendu si on veut afficher par exemple 100 fois le même objets ? La seule façon que je connaisse consiste à changer la matrice de transformation et d'appeler glDrawElements entre chaque objet, mais je crois que ce n'est pas très optimisé puisque je ferais appel 100 fois à glDrawElements alors qu'il s'agit du même objet, mais avec une matrice de transformation différente.

Merci de votre aide et bonne journée ! :)

Pages: [1] 2 3 ... 8 Suivante »