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 - gostron

Pages: [1] 2 Suivante »
1
Fenêtrage / Re : Splash art transparent
« le: Juillet 25, 2013, 05:16:44 pm »
Pour Windows oui. J'imagine que le rapide serait d'utiliser des frameworks qui permettent de le faire comme Qt par exemple qui te propose cette fonctionnalite pour les principaux OS en tout cas.

2
Graphique / Re : Impossible de déplacer une sprite sur axe négatif
« le: Juillet 23, 2013, 04:30:41 pm »
as-tu verifie la valeur de m_size.x ou m_size.y pendant l'execution ?

3
Graphique / Re : Impossible de déplacer une sprite sur axe négatif
« le: Juillet 23, 2013, 03:24:00 pm »
Salut,

Tout d'abord je t'aurais conseille de reduire ton code au minimum pour comprendre d'ou vient le probleme plutot que d'essayer de trouver la solution dans ton code entierement construit (nous facilitant la tache a nous aussi si tu ne le trouves pas toi-meme) meme s'il n'est pas tres grand deja.

Ensuite, je suis pas sur de cibler le probleme entierement. Est-ce uniquements les deplacements negatifs ou bien est-ce qu'aucun deplacement ne s'effectue ?

En dehors de ces details, ce qui me gene un peu dans ton code c'est que tu envoies une copie de Sprite dans ta methode getSprite() car tu envoies l'objet directement (sans referencement ni adressage). Je te conseillerais de renvoyer une reference vers l'objet ou un pointer, mais d'eviter absolument de renvoyer un objet lourd directement. Ensuite, je me demandais pourquoi tu checkais l'etat du clavier dans la boucle de pollEvent(). En effet, si tu utilises l'etat du clavier il ne faut pas dependre du fait qu'il y ait eu un evenement, ca te donnerait des mouvements un peu anarchique en te faisant bouger a chaque fois qu'il y a un evenement quelconque (appui sur n'importe quelle touche, clic ou meme deplacement de la souris) et que la bonne touche se trouve etre appuyee. Tu devra probablement ou bien diminuer la frequence a laquelle tu regardes le clavier ou bien faire un timer pour eviter de bouger trop souvent.

A priori je vois pas trop d'autres soucis meme si je m'y suis pas penche tres longtemps. Bon courage et j'espere que tout ca aide

4
Graphique / Re : Utilisation des VertexArray et des Sprites
« le: Juillet 17, 2013, 01:29:20 pm »
Tres legere reponse pour ce que j'en comprends.

On peut utiliser les vertex array des qu'on a besoin d'une seule texture.

De maniere generale on essaye de minimiser les apppels a la fonction draw car c'est elle qui est le plus chronophage, donc on utilise au maximum les vertex array mais c'est vrai que ca parait peu intuitif d'utiliser un seul vertex array pour ses 5 personnages s'ils sont independants parce que ca risque de devenir complexe dans l'utilisation. Les vertex array sont parfait pour les maps a cases (tilemap) et choses comme ca. Personnellement j'en ai utilise principalement pour le decor comme 200 chaises et tables et quelques tapis (que j'ai ensuite transforme en une texture unique pour avoir un seul appel final car ma map etait statique).

Si quelqu'un peut donner une reponse plus exacte et/ou precise je serais ravi d'en apprendre davantage aussi

5
Graphique / Re : VertexArray et déformation de texture
« le: Mai 14, 2013, 07:43:07 am »
Merci pour la réponse rapide, c'est bien ce que je pensais :)

Sujet clos j'imagine.

6
Graphique / [RESOLU] VertexArray et déformation de texture
« le: Mai 13, 2013, 08:17:18 pm »
Bonjour,

Un petit post pour m'étonner de quelque chose :)

Je comptais faire quelques tests pour faire un effet de perspective sur des textures (en utilisant des VertexArray et en leur donnant la forme de trapèzes comme pour le mode 7 de la SNES donc)

et je fus assez surpris avec le résultat (voir pièce jointe) avec à gauche l'image déformée (mais en deux triangles, et non comme je m'y attendais ^^) et à droite l'image d'origine.

D'où ma question, peut-on faire une déformation trapèze nativement ? Est-ce moi qui m'y suis mal pris ?

Dans le doute voici le code de création de l'array :

    sf::VertexArray array(sf::Quads, 4);
    int leftHeight(100);
    int rightHeight(100);
    int topWidth(50);
    int botWidth(100);
    array[0].position = sf::Vector2f(640-topWidth, 360-leftHeight);
    array[0].texCoords = sf::Vector2f(0, 0);
    array[1].position = sf::Vector2f(640+topWidth, 360-rightHeight);
    array[1].texCoords = sf::Vector2f(tex.getSize().x, 0);
    array[2].position = sf::Vector2f(640+botWidth, 360+rightHeight);
    array[2].texCoords = sf::Vector2f(tex.getSize().x, tex.getSize().y);
    array[3].position = sf::Vector2f(640-botWidth, 360+leftHeight);
    array[3].texCoords = sf::Vector2f(0, tex.getSize().y);
 

[attachment deleted by admin]

7
Graphique / Re : Effet de bord sur texture atlas.
« le: Mai 13, 2013, 07:38:35 am »
Au moment de l'appel de cette ligne
const sf::Uint8 * pixels = t->getTexture().copyToImage().getPixelsPtr();

Il se passe ceci:
on appelle
getTexture()
qui te renvoie une référence vers la texture courante de t.

Puis on appelle
copyToImage()
qui va créer une image au moment de cet appel (qui est donc une fonction lente). L'usage normal de cette fonction est la construction d'une véritable image comme ceci
sf::Image myImage(t->getTexture().copyToImage());

Finalement, tu récupères le pointeur de l'image que tu viens de créer, et c'est celui ci que tu stockes. A aucun moment tu ne récupères réellement l'image.

A chaque appel de copyToImage() tu récrées une image à partir de la texture actuelle, avec à chaque fois une adresse différente.

8
Graphique / Re : Taille d'un sf::Vertex
« le: Mai 11, 2013, 11:25:42 am »
Je dirais que tout est dans le tuto sur les vertex ou les vertexArray.

Je crois qu'il suffit de faire un setTexture() sur ton vertex, puis de donner les coordonnées de texture sur chacun  des points.

9
Graphique / Re : Texture::update() - problème de durée
« le: Mai 06, 2013, 03:19:40 pm »
J'ai testé la mise en commentaire de certains bouts de code openGL dans la SFML (dans Texture::update() pour le cas) mais même en commentant tout, j'obtiens des résultats des plus étonnants ! La fonction vide met parfois  entre 2 et 4 ms à s'exécuter si on suppose la clock exacte.

Avec ces résultats trop surprenants pour venir de la SFML, j'ai mis ma clock autour de la boucle événementielle également, et là...

Update took too much time ( 3 ms)
Update took too much time ( 3 ms)
Update took too much time ( 5 ms)
Update took too much time ( 11 ms)
Update took too much time ( 11 ms)
Update took too much time ( 11 ms)
Events took too much time ( 10 ms)
Update took too much time ( 11 ms)
Update took too much time ( 10 ms)
Update took too much time ( 11 ms)

Quelques petites millisecondes pour Texture::update() puis un ensemble trop important pour les deux...

Dans mon vrai programme il arrivait également que les événements prennent 30ms à être traités ou même n'importe quel élément pouvait prendre du temps pendant certaines frames.

J'ai peur que cela vienne uniquement de mon ordinateur et qu'il est temps de changer la carte mère.

Je pense que le sujet est clos :s


Le code :

int main(int argc, char *argv[])
{
    sf::Texture * _texture = new sf::Texture();
    _texture->create(1280, 720);
    qint64 time;

    sf::Window window(sf::VideoMode(1280, 720), "My window");

    // on fait tourner le programme jusqu'à ce que la fenêtre soit fermée
    while (window.isOpen())
    {
        sf::Clock myClock;
        // on inspecte tous les évènements de la fenêtre qui ont été émis depuis la précédente itération
        sf::Event event;
        while (window.pollEvent(event))
        {
            // évènement "fermeture demandée" : on ferme la fenêtre
            if (event.type == sf::Event::Closed)
                window.close();
        }

        time = myClock.restart().asMilliseconds();
        if ( time > 1 )
            qDebug() << "Events took too much time (" << time << "ms)";

        _texture->update(window);

        time = myClock.restart().asMilliseconds();
        if ( time > 1 )
            qDebug() << "Update took too much time (" << time << "ms)";
    }

    return EXIT_SUCCESS;
}

10
Graphique / Re : Texture::update() - problème de durée
« le: Mai 05, 2013, 11:08:19 pm »
Tout d'abord merci pour la réponse rapide encore une fois :)

J'ai bien retrouvé le post anglais, il est en effet très intéressant mais dépasse de loin mes connaissances actuelles ^^ Je vais prendre le temps de bien tout comprendre et de voir ce que je peux faire.

Il me semble avoir compris cependant que l'instabilité observée pouvait être dûe à m_context et qu'il avait résolu son souci en le remplaçant directement par le code openGL qui va bien.

Je posterai une suite si j'ai davantage d'informations quant à mon souci.

11
Graphique / Texture::update() - problème de durée
« le: Mai 04, 2013, 11:22:12 am »
Bonjour,

J'avais déjà posté un problème concernant des problèmes de durée sur le setActive() de sf::RenderTexture (en croyant que ça venait du clear() ), j'étais donc parti sur une autre méthode pour effectuer mon éclairage, qui était de draw toutes les lumières en additif, puis de sauvegarder l'image et de la draw en multiply pour l'effet de luminosité.

Pour sauvegarder l'image, je la stocke dans un object Texture en appelant le
myTexture.update(window);

Le problème, c'est que j'observe des problèmes de latence également. Voici le code minimal :


int main()
{
    sf::Texture * _texture = new sf::Texture();
    _texture->create(1280, 720);

    sf::Window window(sf::VideoMode(1280, 720), "My window");

    // on fait tourner le programme jusqu'à ce que la fenêtre soit fermée
    while (window.isOpen())
    {
        // on inspecte tous les évènements de la fenêtre qui ont été émis depuis la précédente itération
        sf::Event event;
        while (window.pollEvent(event))
        {
            // évènement "fermeture demandée" : on ferme la fenêtre
            if (event.type == sf::Event::Closed)
                window.close();
        }
        sf::Clock myClock;
        _texture->update(window);
        qint64 time = myClock.restart().asMilliseconds();
        if ( time > 1 )
            qDebug() << "Update took too much time (" << time << "ms)";
    }

    return EXIT_SUCCESS;
}
 

et voici ce que j'obtiens en sortie :

Update took too much time ( 2 ms)
Update took too much time ( 2 ms)
Update took too much time ( 4 ms)
Update took too much time ( 4 ms)
Update took too much time ( 20 ms)
Update took too much time ( 4 ms)
Update took too much time ( 4 ms)
 

Sachant que ces messages arrivent relativement lentement (c'est-à-dire que la plupart des update() prennent moins de 1 ms.)

J'utilise Win 8, la version release de SFML 2.0 que j'ai recompilée et que j'utilise en static et je compile à l'aide de QtCreator.

Dites-moi si j'oublie quelque chose :)

12
Général / Re : création d'un jeu 2d quel logiciel ???
« le: Mai 01, 2013, 01:33:11 pm »
photoshop :p si tu veux des graphismes.

Nan blague à part, théoriquement, t'as besoin d'aucun logiciel. Une petite console sous vim pis un makefile suffisent. Visual Studio t'aidera pour l'entretient et la vision global de ton projet, et la SFML est une librairie qui te permet de gérer à plus haut niveau les fonctions essentielles, comme le graphisme, le son, les fenêtres et le réseau.

Pour apprendre en tout cas, tu n'auras besoin de rien de plus, (à part un navigateur web sur le Site du Zero ^^), et pour ton jeu tu peux toujours utiliser d'autres librairies, comme Box2D qui te fournirait un moteur graphique.

Après, tu verras au fur et à mesure, mais sache qu'un tel projet est très difficile à mener à bien tout seul, surtout en partant de zero.

13
Général / Re : Gravityé et collisions
« le: Mai 01, 2013, 01:26:02 pm »
Bonjour,

Concernant la gravité je dirais que c'est relativement simple. Le moyen le plus évident serait d'entretenir une liste de toutes tes entitées sujettes à la gravité, et de la parcourir à chaque boucle pour en modifier la vitesse.
Puisque la gravité est une force, elle applique en continu une force vers le bas d'une intensité constante. On peut donc appliquer entre chaque calcul l'opération suivante : y += FORCE_GRAVITE*frameTime; où frameTime serait le temps passé entre deux calculs (ici entre deux affichages, mais on peut multithreader :p).

Concernant les collisions c'est relativement simple aussi. Si tu regardes un peu le forum tu verras que plusieurs ont déjà abordés le sujet. Le plus évident est de représenter tes éléments de collision par des formes simples (cercles et rectangles) puis de vérifier l'intersection de ces éléments entre eux pour vérifier s'il y a collision, et ce entre chaque calcul (ou image si on travaille sur un seul thread). Il suffit ensuite de réagir en conséquence de la collision.

Pour les rectangles, la fonctione intersects fait déjà tout le travail, et pour les cercles il suffit de vérifier la distance des centres.

Ai-je répondu à tes questions ?

14
Graphique / Re : Tiles terrain isométrique
« le: Avril 28, 2013, 08:27:35 pm »
Pour répondre à ta question, j'utilise souvent mes propres objets pour dessiner dans un jeu, et ces objets sont directement dessinables via plusieurs moyens différents.
On peut par exemple hériter de sf::Drawable, et réimplémenter la fonction draw() pour alors afficher tous les sprites que l'on contient.
On peut aussi juste contenir une liste de sprite, et implémenter une méthode qui prend en argument la cible d'affichage (RenderWindow par exemple) et qui va boucler pour afficher tous les sprites que l'objet contient.

Je ne sais pas quelle méthode est la plus propre ou la plus agréable, mais j'ai déjà utilisé les deux.

Concernant les soucis de devant/derrière, j'ai une petite idée qui vaudrait peut-être le coup d'être essayé.

Imaginons notre héros sur une minimap, et le souci est de l'afficher au bon moment pour être derrière notre arbre, mais devant la pierre et le sol. Il suffit donc d'affiche notre minimap, mais d'afficher le héro au bon moment (puisque le problème interne à la minimap ne se pose pas si tu l'as créée correctement).
On pourrait donc essayer par exemple de donnée les éléments qui bougent et les éléments qui ne bougent pas, puis de parcourir les éléments qui ne bougent pas, et quand on arrive aux bonnes ordonnées (le y du héro est entre les deux objets non bougeants), alors on affiche le héros, puis on continue le parcours de notre liste.

On peut généraliser cette méthode à plusieurs object bougeant, en triant d'abord la liste des bougeant (ou juste en swappant les éléments qui ont bougé d'ordre d'une image à l'autre, si on veut optimiser), puis on parcours les immobiles en insérant les mobiles au bon moment.

15
Graphique / Re : Problème redimentionnement
« le: Avril 28, 2013, 08:19:48 pm »
Si j'ai bien compris ton post, il suffit de considérer que la longueur du nouveau carré est la diagonale du petit carré (ou bien la diagonale du losange), et donc qu'on obtient un nouveau carré de côté a*racine(2).

Pages: [1] 2 Suivante »
anything