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

Pages: [1] 2 3 ... 5 Suivante »
1
Général / Re: Compilation SFML statique
« le: Juillet 04, 2017, 02:21:30 pm »
Je n'ai aucun problème de compilation donc toutes les librairies nécessaires sont bien dans SFML/lib.
Merci de ta réponse je vais checker sur le forum anglais :)

2
Général / Compilation SFML statique
« le: Juillet 03, 2017, 09:37:37 pm »
Bonjour !  ;D

Je suis sur Windows et je cherche à compiler mon programme en liant SFML de manière statique.

La compilation se passe à merveille. Seulement, lorsque je lance mon programme, seule la fenêtre de console s'affiche, rien d'autre. Mais où est donc ma fenêtre ?  :o Quand je liait SFML dynamiquement ma fenêtre s'affichait sans aucun soucis.

Voici mon makefile :

CXXFLAGS = -DSFML_STATIC  -ISFML/include/ -std=c++14 -c

SFMLLIB = -LSFML/lib/ -lsfml-graphics-s -lsfml-window-s -lsfml-audio-s -lsfml-system-s -lopenal32 -lvorbisfile -lvorbisenc -lvorbis -logg -lFLAC -ljpeg -lfreetype -lgdi32 -lopengl32 -lwinmm

OBJECTS = main.o Snake.o Inputs.o FoodPoints.o Point.o Random.o SoundSystem.o TileBackground.o ScoreSystem.o Gui.o

CCXX = g++

all : $(OBJECTS)
        $(CCXX) $(OBJECTS) $(SFMLLIB) -o snake

main.o : src/main.cpp
        $(CCXX) $(CXXFLAGS) src/main.cpp

Snake.o : src/Snake.cpp
        $(CCXX) $(CXXFLAGS) src/Snake.cpp

Inputs.o : src/Inputs.cpp
        $(CCXX) $(CXXFLAGS) src/Inputs.cpp

FoodPoints.o : src/FoodPoints.cpp
        $(CCXX) $(CXXFLAGS) src/FoodPoints.cpp

Point.o : src/Point.cpp
        $(CCXX) $(CXXFLAGS) src/Point.cpp

Random.o : src/Random.cpp
        $(CCXX) $(CXXFLAGS) src/Random.cpp

SoundSystem.o : src/SoundSystem.cpp
        $(CCXX) $(CXXFLAGS) src/SoundSystem.cpp

TileBackground.o : src/TileBackground.cpp
        $(CCXX) $(CXXFLAGS) src/TileBackground.cpp

ScoreSystem.o : src/ScoreSystem.cpp
        $(CCXX) $(CXXFLAGS) src/ScoreSystem.cpp

Gui.o : src/Gui.cpp
        $(CCXX) $(CXXFLAGS) src/Gui.cpp

clean :
        rm snake *.o
 

J'ai entièrement fait mon projet sous Linux et cherchant à le distribuer sous Windows au plus vite, j'ai trouvé sur internet un standalone pour Windows de la commande make. Peut-être est-ce utile de le préciser ? Sachant que je ne vois pas du tout à quel niveau le problème se situe  :-\


Merci d'avance !  8)

3
Graphique / Re : sf::View et monde déformé
« le: Février 26, 2015, 06:53:15 pm »
Oups! Oui, honte à moi!  ::)  :P
J'avais oublié que ma fenêtre n'était pas de la taille de la résolution!
Merci encore victor ;)

4
Graphique / Re : sf::View et monde déformé
« le: Février 26, 2015, 05:08:22 pm »
Merci de ta réponse rapide,
Pourtant, lorsque je fait:
view.setSize(sf::VideoMode::getDesktopMode().width, sf::VideoMode::getDesktopMode().height);
 
J'obtient cela. Ma carte est maintenant étirée. Est-ce une mauvaise chose d'utiliser des sf::View avec de l'isométrique?
Merci d'avance.

5
Graphique / sf::View et monde déformé
« le: Février 26, 2015, 04:42:57 pm »
Bonjour,  :)

J'ai du mal à comprendre le comportement bizarre que j'obtient lorsque je soumet l'application à une vue "neutre",
appelée avec le constructeur par défaut...
Lorsque je ne met pas de sf::View, tout va bien, et qu'en j'en met, tout est "aplatit".
Je ne comprend pas ce comportement, j'ai utilisé différents constructeurs avec les bons paramètres, toujours le même problème.

Merci d'avance...

6
Graphique / Re : Ordre de dessin avec sprites et vertexarrays
« le: Février 24, 2015, 11:16:24 pm »
Ta méthode m'a fait réfléchir aux différences qu'il pourrait y avoir, et BINGO! Problème résolu!  ;D
En fait, un layer peut être une couche de tuile comme une couche d'ombres sous ces tuiles.
Et le code dessinait par layer:
  • Le sprite
  • la tuile qui cache
  • l'ombre de la tuile, qui ne cache pas le sprite
  • et donc encore une fois le sprite! Qui se retrouve par-dessus!
Encore merci, tes conseilles m'ont encore une fois aider, merci merci merci!  ;D
Bonne soirée.

PS: En effet, le code minimal aurait marché!

7
Graphique / Re : Ordre de dessin avec sprites et vertexarrays
« le: Février 24, 2015, 11:04:08 pm »
Je comprend cela mais, comment pourrais-je espérer reproduire l'erreur de code dans le main sachant que je ne la connais pas? Tu me dis bidouiller, bidouiller, mais je peux bidouiller longtemps ça peut venir de beaucoup de choses ;D
Il doit bien y avoir une erreur simple à déceler quelque part après tout!
Merci encore de ton aide.

8
Graphique / Re : Ordre de dessin avec sprites et vertexarrays
« le: Février 24, 2015, 09:29:45 pm »
Je ne pense pas que cela m'aiderait, car même si dans le main ça fonctionnerait, je ne verrait pas d'autres manières d'agencer la chose que la manière dont je le fait actuellement.
Je vais continuer mes recherches concernant l'origine du problème, en espérant qu'un jour ça paie. En tout cas, c'est pas un comportement attendu/inattendu d'SFML?

9
Graphique / Re : Ordre de dessin avec sprites et vertexarrays
« le: Février 24, 2015, 08:32:38 pm »
Merci de ta réponse,
Oui, le quad devrait être le bon, puisque quand je test m_layer==0 mon objet est caché derrière les tuiles du layer suppérieur. Donc avec m_layer==1 les tuiles concernées doivent être logiquement les bonnes.
J'ai essayé et même résultat, le sprite apparaît au dessus des 4 derniers vertices. C'est très louche  :o
Merci de ton aide.

10
Graphique / Ordre de dessin avec sprites et vertexarrays
« le: Février 24, 2015, 07:54:57 pm »
Bonjour à tous!

Allez, pour aller droit au but, dans mon système isométrique:
  • La carte est composée de layers, un par étage, un layer étant un sf::VertexArray;
  • Les objets de map sont dessinés entre chaque bon étage, et doivent être intercalés derrières les tuiles situées devant eux, etc;

J'expérimente actuellement une méthode pour dessiner mon objet entre 4 vertices (1 tuile).
En gros, j'aimerai effectuer dans l'ordre le dessin de:
  • La partie du layer qui ne cache pas l'objet
  • L'objet
  • La partie du layer qui cache l'objet

Ce à l'aide de cette fonction. (Ne vous préoccupez pas de la re-déclaration du sprite à chaque frame, des valeurs brutes, tout cela n'est pas encapsulé mais le sera: pour l'instant c'est juste un test) :
void Layer::draw(sf::RenderTarget &target, sf::RenderStates states) const
{
    sf::Texture tex;
    tex.loadFromFile("objet.png");

    sf::Sprite sprite;
    sprite.setTexture(tex);
    sprite.setPosition(410, 300); //La position appropriée pour que l'objet soit sensé être caché

    states.transform *= getTransform();
    states.texture = &m_texture;

    if(m_layer==1) // Si le layer actuel est le n°1, alors on doit se charger de dessiner l'objet entre 2 tuiles
    {
        target.draw(&m_vertices[0], 396, sf::Quads, states); // Les 99 premières tuiles
        target.draw(sprite); //L'objet
        target.draw(&m_vertices[396], 4, sf::Quads, states); //La dernière tuile, qui doit cacher l'objet
    }
    else //Autrement, on ne se préoccupe pas de l'objet, on dessine tout le layer d'un coup
    {
        target.draw(m_vertices, states);
    }
}
 
Ici, pour info, mon personnage est positionné entre la 99ème tuile et la dernière, soit dans la dernière ligne de droite du layer.

Seulement voilà le problème: le sprite de l'objet n'est pas caché derrière ce dessin:
target.draw(&m_vertices[396], 4, sf::Quads, states);
 
Et je ne comprend mais vraiment pas pourquoi:
  • Erreur de logique de ma part, auquel cas je vous laisse tranquille et je vais repenser mon système?;
  • Qu'importe l'ordre d'appels des draw(), les entrailles d'SFML dessinent les sf::Drawable "type" par "type": sprite d'un coup, etc... ?

Merci d'avance.  ;)

11
Graphique / Re : Crash avec target.draw(*sprite, states)
« le: Février 08, 2015, 01:52:35 pm »
Bon je vais me débrouiller autrement dans mon code. Merci encore

12
Graphique / Re : Crash avec target.draw(*sprite, states)
« le: Février 08, 2015, 12:35:18 pm »
m_objects est un std::vector de pointeurs vers MapObject. Un MapObject a lui-même comme attribut un pointeur vers un sf::Sprite. J'ai bien vérifié tous les pointeurs qui *semblent* valide... Merci d'avance.

13
Graphique / Crash avec target.draw(*sprite, states)
« le: Février 08, 2015, 10:42:23 am »
Bonjour!

Me revoilà aussi tôt, car j'ai un problème que je n'arrive pas à fixer, même après plusieurs coups de debugger. J'ai cherché pendant 2 heures d'où le problème pourrait venir, et je n'en ai aucune idée. Dans ma classe Chunk héritée de sf::Drawable, j'ai cette fonction:

void Chunk::draw(sf::RenderTarget &target, sf::RenderStates states) const
{
    states.transform *= getTransform();
    states.texture = &m_texture;
    target.draw(m_vertices, states);
    target.draw(*m_objectManager->m_objects[0]->m_sprite, states);
}

Et le programme crash arrivé à cette ligne:
target.draw(*m_objectManager->m_objects[0]->m_sprite, states);

Où m_objectManager->m_objects[0]->m_sprite est un pointeur vers un sf::Sprite. J'ai bien vérifié et ce n'a pas l'air d'être une erreur de pointeur, m_sprite est valide...

Merci de votre aide.

14
Graphique / Re : Isométrique & gestion d'objets de map (entités)
« le: Février 07, 2015, 02:45:13 pm »
D'accord, je m'en souviendrais.

Merci encore pour tout.

15
Graphique / Re : Isométrique & gestion d'objets de map (entités)
« le: Février 06, 2015, 08:57:42 pm »
Bien sûr, comme tu as dis, plusieurs objets pourront faire partie du monde, mais je ne craint pas une éventuelle baisse de perfos avec cette méthode. Je vais donc tester cette technique premièrement, et si je me rend compte que c'est finalement trop vorace en CPU, je ferais la technique du dessin du vertexArray par lignes et me débrouillerait pour la "tuile de droite".

En tout cas merci énormément de ton aide, grâce à toi je vais pouvoir continuer le développement de mon chouchou.  8)  ;D

Dernière petite question :  ::)
Le dessin d'un gros vertexArray peut-il s'avérer plus vorace que le dessin de plein petits éléments?  Ou ce qui compte c'est juste d'avoir le nombre d'appel à draw() le plus faible possible?

Encore merci pour tout.  ;)

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