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

Pages: « Précédente 1 2 3 [4] 5 6 ... 12 Suivante »
46
Audio / Conteneurs de musiques
« le: Juin 30, 2014, 10:02:01 pm »
Bonjour,

Je travaille actuellement sur un projet pour une gestion de l'audio simplifiée

J'aimerais stocker des sf::Music dans un std::map

Mais le problème est que je n'arrive pas à initialiser la musique directement dans le std::map...

Voilà un exemple qui sera bien plus clair :

std::map<std::string,sf::Music> mMusics;

/*
Le fait que sf::Music soit NonCopyable m'empêche de faire ceci :

sf::Music a;
mMusics.at(filename) = a;
*/


    if(!mMusics.at(filename).openFromFile(filename))
        return false;
    mMusics.at(filename).play();
 

Voilà, je recherche s'il en existe, une façon de faire :)

47
Audio / Re : SoundSource et Status en protected
« le: Juin 22, 2014, 10:33:34 pm »
Ah okay, en effet ma classe SoundSource implémente bien son propre play(), pause(), stop() donc je n'ai pas pu remarquer cette chose...

Et ensuite, je m'en veux de ne pas avoir penser aux templates...

Et donc, pourquoi passer par ces fonctions plutôt qu'un test "basique" :

//Test avec les fonctions Template du type isPlaying(source) :
if (isPlaying(maMusique)) { ....}

//Test avec un appel basique, ça marche bien mais je trouve cela un peu moins clair...
if (maMusique.getStatus() == sf::SoundSource::Playing) { ... }
 

Ensuite si on utilse en plus des namespaces et/ou des pointeurs et/ou des conteneurs, on peut se retrouver avec des lignes vraiment plus difficile à lire.

Bon ça apporte vraiment pas grand chose mais je trouve cela un tout petit peu plus propre quand même :)

48
Audio / SoundSource et Status en protected
« le: Juin 22, 2014, 08:03:18 pm »
Bonjour,

J'aimerais savoir s'il y a une raison particulière au choix de mettre la fonction getStatus() en protected à la place de public dans les SoundSource ?

Je suis actuellement sur un projet et le fait de passer par les SoundSource est beaucoup plus simple que de refaire ma fonction plusieurs fois pour Music, pour Sound et pour mes classes héritant de SoundSource

Voilà un exemple de fonction qui bloque à cause de cela :

bool isPlaying(sf::SoundSource const& source)
{
    return source.getStatus() == sf::SoundSource::Status::Playing;
}

bool isPaused(sf::SoundSource const& source)
{
    return source.getStatus() == sf::SoundSource::Status::Paused;
}

bool isStopped(sf::SoundSource const& source)
{
    return source.getStatus() == sf::SoundSource::Status::Stopped;
}


Je l'ai contré actuellement en faisant comme ceci (mais c'est 4x fois moins simple dans le code appelant ces fonctions...) :

bool isPlaying(sf::SoundSource::Status const& statut)
{
    return statut == sf::SoundSource::Status::Playing;
}

bool isPaused(sf::SoundSource::Status const& statut)
{
    return statut == sf::SoundSource::Status::Paused;
}

bool isStopped(sf::SoundSource::Status const& statut)
{
    return statut == sf::SoundSource::Status::Stopped;
}


Voilà, merci d'avance pour la réponse et si il existe une bonne raison, je vais me résigner à employer ma deuxième méthode :)

49
Discussions générales / Re : Forum français
« le: Juin 21, 2014, 01:43:55 am »
Personnellement, ayant appris à programmer seul durant mes années collèges/lycées où je n'excellais pas (encore) en anglais, je pense que je n'aurais pas chercher à utiliser SFML si ce forum n'avait pas été là et dans notre belle langue :)

Je pense que je ne suis pas le seul et cela en fait donc un puissant argument.

Bien sûr, je trouve l'argument d'Excellium aussi très fort, "Tu vas fragmenter la communauté pour zéro gains (à part faire plaisir à certains membres)."

Je pense que lancer un sondage pourrait être une bonne idée

50
Général / Re : Problème avec les templates...
« le: Janvier 07, 2014, 05:59:56 pm »
Finalement le seul moyen qui a été trouvé sur openclassroom,  est de mettre les deux classes dans le même fichier

Voilà si ça peut servir après moi ;)

51
Général / Problème avec les templates...
« le: Janvier 06, 2014, 04:46:37 pm »
Bonjour à tous :)

Je travaille actuellement sur un projet de gestion de States pour SFML

J'ai récemment essayé d'adapté le framework du livre sur la SFML mais le problème était qu'il n'était pas trop possible de faire partager les informations du jeu entre plusieurs states, car le système de Context est propre au framework et donc pas vraiment pratique...

Du coup j'ai voulu implémenter ça avec des templates.

J'ai une petite erreur "undefined reference"...

Je sais pourquoi j'ai cette erreur :
J'ai deux classes et chacune utilise des templates que je déclare donc dans le .hpp de ma classe.
Et chacune des fonctions utilisant des templates à besoin d'inclure l'autre pour travailler avec...

State.hpp :
class StateManager;

class State
{
    template<typename T>
    void send(T object);

    template<typename T>
    void receive(T object);
};

#include "State.inl"
 

State.inl :

template <typename T>
void State::send(T object)
{
    mMgr->share<T>(object);
}

template <typename T>
void State::receive(T object)
{
//
}
 

StateManager.hpp :
class State;

class StateManager
{
    public:
        template <typename T>
        void share(T object);
};

#include "StateManager.inl"
 

StateManager.inl :
template <typename T>
void StateManager::share(T object)
{
    state->receive(object);
}


Voilà je vous ait réduit les fichiers au max, en laissant tout ce qui devrait être utile :)

Si quelqu'un pourrait m'aider ça serait plutôt cool car le projet serait utilisable par tout le monde :)

Le projet est actuellement sur GitHub et c'est la dernière fonctionnalité que je prévois d'ajouter pour le moment

Merci d'avance : https://github.com/Cmdu76/CmState

52
Graphique / Problème avec la fonction draw
« le: Décembre 24, 2013, 03:09:50 pm »
Bonjour à tous :)

Je travaille sur un projet de Tile Mapping (oui je sais c'est pas original xD)
J'essaye que chacune de mes Tiles puissent gérer 3 couches de rendus, (plus facile pour gérer les Collisions de dire que la Tile entière entraîne une collision)

Mes tiles sont contenus dans ma classe Zone, et les Zones sont contenues dans ma classe World

Le World a donc un fonction draw comme ça :

void World::draw()
{
    mApp.setView(mWorldView);
    mActualZone->draw(mApp, Layer::Sol);
        mApp.sf::RenderTarget::draw(mSceneGraph); // mApp est de type Application qui hérite de pas mal de trucs dont plusieurs fonctions draw --> Je sais c'est pas tip-top...
}

Ensuite une zone se dessine comme ça :

void Zone::draw(sf::RenderWindow& window, Layer::ID const& layer) const
{
    for (int i = mZoneBounds.left/32; i < mZoneBounds.left/32 + mZoneBounds.width/32; ++i)
    {
        for (int j = mZoneBounds.top/32; j < mZoneBounds.top/32 + mZoneBounds.height/32; ++j)
        {
            mZone[i][j].draw(window,layer);
        }
    }
}

mZone est un : std::vector<std::vector<Tile>>

Ensuite, vous pouvez le deviner, une Tile se dessine comme ça :

void Tile::draw(sf::RenderWindow& window, Layer::ID const& layer) const
{
    if (layer < Layer::Count)
    {
        window.draw(mSprites[layer]);  /// C'est ici que le debugger marque une erreur
    }
}

Et au cas où, je vous montre ça :

namespace Layer
{
    enum ID
    {
        Sol = 0,
        Mid = 1,
        Top = 2,
        Count = 3,
    };
}

Et quand je défini mSprites (dans Tile), c'est un std::array d'une taille de Layer::Count (3, une case / couche)

Quand je lance un coup de debugger, j'obtient :

#0 68ED3151     sf::RenderTarget::draw(this=0x28fba0, drawable=..., states=...) (D:\developpement\sfml\sfml\src\SFML\Graphics\RenderTarget.cpp:147)
#1 00403FB3     Tile::draw(this=0x0, window=..., layer=@0x28fa2c: Layer::Sol) (C:\ProjetsC++\src\Tile.cpp:21)
#2 00404DB3     Zone::draw(this=0x3ba00e8, window=..., layer=@0x28fa2c: Layer::Sol) (C:\ProjetsC++\src\Zone.cpp:54)
#3 00404589     World::draw(this=0x3b85550) (C:\ProjetsC++\src\World.cpp:17)
#4 00403D82     GameState::draw(this=0x3b85548) (C:\ProjetsC++\src\GameState.cpp:11)
#8 0040155A     Application::Application(this=0x28fb78) (C:\ProjetsC++\src\Application.cpp:12)
#9 00401435     main() (C:\ProjetsC++\main.cpp:5)
 

Voilà, si le problème est connu ou que je suis tout simplement trop bête pour le voir... J'aimerais bien un petit coup de main :)

Edit: Bon j'ai essayé de trouver dans mon coin mais j'ai rien de bien...

Voilà ma nouvelle fonction pour Tile::draw :

void Tile::draw(sf::RenderWindow& window, Layer::ID const& layer) const
{
    if (layer < Layer::Count)
    {
        std::cout << mSprites.at(0).getPosition().x << std::endl; // Nouvelle Ligne de l'erreur...
        window.draw(mSprites.at(0));
    }
}

Maintenant la ligne de l'erreur a changée... Et je n'ai aucune idée de pourquoi l'erreur pourrait venir de cette ligne...

Voilà la déclaration de mSprites : std::array<sf::Sprite,  Layer::Count>   mSprites;

Et voilà son initialisation :

// On crée les sprites en fonction des codes
    for (unsigned int i = 0; i < Layer::Count; ++i)
    {
        mSprites[i].setTexture(mTexture);
        mSprites[i].setPosition(pos);
     mSprites[i].setTextureRect(sf::IntRect(posTexture.x,posTexture.y,32,32));
    }

53
Audio / Problème inconnu avec SoundBuffer
« le: Décembre 08, 2013, 06:59:17 pm »
Bonjour,

J'ai actuellement une erreur avec la classe SoundPlayer du livre SFML que j'ai légèrement modifié,

Voici les logs d'erreurs :
C:\SFML\include\SFML\Audio\Sound.hpp|46|erreur: expected class-name before '{' token|
C:\SFML\include\SFML\Audio\Sound.hpp|154|erreur: 'Time' has not been declared|
C:\SFML\include\SFML\Audio\Sound.hpp|182|erreur: 'Time' does not name a type|
C:\SFML\include\SFML\Audio\Sound.hpp|190|erreur: 'Status' does not name a type|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|89|erreur: expected type-specifier|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|89|erreur: expected '>'|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|94|erreur: '_Alloc' has not been declared|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|108|erreur: '_Alloc' does not name a type|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|112|erreur: '_Alloc' has not been declared|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|112|erreur: expected template-name before '<' token|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|112|erreur: expected identifier before '<' token|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|112|erreur: expected unqualified-id before '<' token|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|114|erreur: '_Rb_tree' does not name a type|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|116|erreur: '_Rep_type' does not name a type|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|121|erreur: '_Key_alloc_type' has not been declared|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|122|erreur: '_Key_alloc_type' has not been declared|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|123|erreur: '_Key_alloc_type' has not been declared|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|124|erreur: '_Key_alloc_type' has not been declared|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|128|erreur: '_Rep_type' has not been declared|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|129|erreur: '_Rep_type' has not been declared|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|130|erreur: '_Rep_type' has not been declared|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|131|erreur: '_Rep_type' has not been declared|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|132|erreur: '_Rep_type' has not been declared|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|133|erreur: '_Rep_type' has not been declared|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|150|erreur: 'allocator_type' does not name a type|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|183|erreur: 'allocator_type' does not name a type|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|206|erreur: 'is_nothrow_copy_constructible' was not declared in this scope|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|206|note: suggested alternative:|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\type_traits|1021|note:   'std::is_nothrow_copy_constructible'|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|206|erreur: expected primary-expression before '>' token|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|206|erreur: '::value' has not been declared|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|219|erreur: expected ')' before '<' token|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|270|erreur: declaration of 'operator=' as non-function|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|270|erreur: expected ';' at end of member declaration|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|270|erreur: expected ')' before '<' token|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|289|erreur: 'allocator_type' does not name a type|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|411|erreur: 'pair' in namespace 'cm::std' does not name a type|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|420|erreur: 'pair' in namespace 'cm::std' does not name a type|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|481|erreur: 'initializer_list' has not been declared|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|481|erreur: expected ',' or '...' before '<' token|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|673|erreur: 'pair' in namespace 'cm::std' does not name a type|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|677|erreur: 'pair' in namespace 'cm::std' does not name a type|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|684|erreur: nombre erroné d'arguments du patron (3 devrait être 2)|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|91|erreur: provided for 'template<class _Key, class _Compare> class cm::std::set'|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|684|erreur: nombre erroné d'arguments du patron (3 devrait être 2)|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|91|erreur: provided for 'template<class _Key, class _Compare> class cm::std::set'|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|684|erreur: 'bool cm::std::operator==(const int&, const int&)' must have an argument of class or enumerated type|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|688|erreur: nombre erroné d'arguments du patron (3 devrait être 2)|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|91|erreur: provided for 'template<class _Key, class _Compare> class cm::std::set'|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|688|erreur: nombre erroné d'arguments du patron (3 devrait être 2)|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|91|erreur: provided for 'template<class _Key, class _Compare> class cm::std::set'|
c:\mingw\bin\..\lib\gcc\mingw32\4.7.2\include\c++\bits\stl_set.h|688|erreur: 'bool cm::std::operator<(const int&, const int&)' must have an argument of class or enumerated type|
||More errors follow but not being shown.|
||Edit the max errors limit in compiler options...|
||=== Build finished: 50 errors, 0 warnings (0 minutes, 41 seconds) ===|
 


Le problème semble venir de la classe Sound de la SFML, pourtant elle marchait bien...

Je suis en 2.1

Voilà merci d'avance :)

54
Projets SFML / Re : Framework
« le: Décembre 07, 2013, 03:07:54 pm »
Le problème est que du coup peut etre que les id sont bien ordonnes (mais au final avec les enmus c'est pas si important)
mais après il fait récuperer l'id et le ressortir a chaque fois...

Par contre je pense que ducoup le getByPath peut être une solution

Aussi tant qu'à faire,

R get(const std::string& path) const;
R get(const int id) const;

C'est plus simple comme ça et ça ne perd pas son sens dans la doc

Et du coup je parlais de retourner l'id, donc tant quà faire :

/// \return The id of the loaded resource
int load(const std::string& filename);

Sinon comment moi (enfin je tire ça du livre SFML une fois de plus) je procède :

- L'utilisateur crée un fichier "ResourceIdentifiers.hpp" dedans il crée le namespace Textures avec l'enum en question contenant une entrée avec une valeur pour chaque texture qu'il voudrait utiliser.
- Ensuite dans la classe Application, tu donnes en paramètres de load(Textures::ID id, std::string const& filename);
- Du coup quand tu veux utiliser la texture ailleurs, tu as juste à faire : get(Textures::ID id);

Oui, mais une enum ça sert plutôt pour le développeur ça, pour définir un ensemble restreins de valeurs possibles que peut prendre une variable.

Du coup, dans mon exemple tu limites tes valeurs aux ID que tu veux.

Ainsi j'ai toujours des id qui se suivent pour tout les objets que j'ai créer et je me retrouve pas 2 fois avec le même id

Je ne vois pas en quoi le fait d'avoir des id qui ne se suivent pas est gênant...
Et moi non plus je ne peux pas me retrouver avec deux fois la même ID, mon Id (mon Id corresponds à une case un tableau basique ( monVector[ID] ) ) sera juste redéfinie avec le 2ème fichier que je donne.

Encore une fois pour les exemples, n'hésite pas à aller voir le livre SFML ou à checker mon projet GameTest sur GitHub : https://github.com/Cmdu76/GameTest

55
Projets SFML / Re : Framework
« le: Décembre 07, 2013, 02:31:30 pm »
Nan c'est pas dutout ce que je voulais dire, justement même tout le contraire !
Finalement on crée un State qui ne dessine RIEN, c'est l'utilisateur qui va choisir ce que son State va dessiner en créant par exemple une classe GameState (qui PAR EXEMPLE peut dessiner le monde + des GUI + des sprites banales (ce qui est presque inutile mais c'est pour montrer que c'est lui qui choisi))

Ensuite dans un enum, chaque entrée est associé à une valeur unique donc on a pas le problème de l'avoir deux fois...

56
Projets SFML / Re : Framework
« le: Décembre 07, 2013, 01:45:30 pm »
Je crois que tu n'as pas vraiment compris le but des States, la classe State doit être abstraite, c'est au développeur qui va créer son jeu de la reutiliser comme il le veut. Il peut creer un State qui melange le Monde et des GUI, il peit mettre un State qui est une sprite et des GUi... enfin bref il choisi tout ce qu'il veut au niveau de l'affichage, lui imposer des states speciaux est inutile si tu réduis les possibilités qui sont permises à la base...
Et pour le resource, le système que je t'avais envoyé par Skype avec des enums est plus simple et plus compréhensible pour l'utilisateur car il associe lui même les ID et il peut en faire autant qu'il veut

57
Projets SFML / Re : Framework
« le: Décembre 06, 2013, 02:36:34 pm »
Ouais je suis d'accord le dépôt sur github est très mal organisé... Jai ajouté le fichier .gitignore après que tu es ajouté les fichiers "inutiles"
Je pense qu'on pourrait virer tou ce qui est fichiers Cmake tant qu'on sort pas une version "stable"

Ensuite il a pas vraiment besoin de lier nos fichiers, c'est l'utilisateur qui va utiliser nos classes comme il veut nous on propose un "pack" après les utilisateurs en font ce qu'ils veulent

58
Projets SFML / Re : Framework
« le: Décembre 05, 2013, 10:44:47 am »
Bon okay dessiner un State c'est pas vraiment bien choisi, mais faut plus voir ça comme le fait dessiner tout ce qui représente ce State par exemple le système de Gui, le monde ou n'importe quoi d'autres que l'utilisateur va rajouter  tant qu'objet de son State.

N'hésite pas à aller voir mon projet GameTest sur Github qui justement utilise ce système,  tu vas voir que la fonction draw s'y prête très très bien.

Et je ne comprends pas ce que tu as voulu dire, la classe Application va dessiner juste le StateManager qui dessine ensuite tous les States chargés ça t'évite d'avoir trop d'objets dans l'Application et de pouvoir gérer les States un par un pour l'affichage

59
Projets SFML / Re : Framework
« le: Décembre 04, 2013, 08:03:33 pm »
Desolé Excellium j'ai pas pu passer aujourd'hui mais sinon tu peux poser tes questions ici :)

En effet je suis moi aussi pour le fait qu'on arrive à virer boost, moins on repose sur d'autres lib plus c'est simple pour l'utilisateur

Ensuite je vois pas réellement pourquoi tu te galères à retoucher les States, ils marchent déjà très très bien comme ça :)
Après toutes les utilisations que j'ai pu en faire, j'ai pas réellement trouver de moyen de les optimiser

Normalement je t'ai envoyé le diagramme "final" par Skype

60
Projets SFML / Re : Framework
« le: Décembre 04, 2013, 01:53:19 pm »
Salut Excellium,

J'ai une mini-base de Gui mais elle est loin d'être optimisée :)

Ducoup je te laisse travailler sur cette partie si tu veux :)

Pages: « Précédente 1 2 3 [4] 5 6 ... 12 Suivante »