[SOURCE][SDL][OPENGL]Singleton pour gérer le fenêtrage

Citation:

---

Envoyé par shenron666

le problème rencontré était (je crois) en plein écran, l'affichage ne se faisait pas sur la totalité de l'écran
comme si l'écran était en 1024*768 et que l'affichage était en haut à gauche en 640x480 avec le bureau reste de l'écran et le viewport bien configuré dans le triangle qu'on ne voit qu'en partie dans le coin haut gauche

---

J'ai eu le même problème en jouant avec ton code... Mais comment j'ai réussi mon coup ?

Ah oui, cela est dû au fait que si tu déclares la taille de la fenêtre mais après avec ta fonction ResizeViewPort tu lui fais croire que c'est une autre taille, il va faire ce genre de chose.

C'est déjà tordu mais bon, cela m'est arrivé en triturant ton code.

Jc

PS: Si on voulait vraiment être exact, on utiliserait SDL_GL_GetAttribute pour vérifier que les paramètres voulus sont ceux obtenus... Je propose de mettre un commentaire après le SetVideoMode le signalant et laissant le code comme il est. Il est déjà assez complet à mon avis :wink:

Merci pour la source mais j'ai juste une petite remarque à faire.

Pourquoi un Main.h ???
Je trouve ça complétement illogique.

D'ailleurs j'en profite pour étendre ce débat car je vois ça de plus en plus souvent. Donc ça ne s'adresse pas spécialement à cette source.

Pour moi un header ça sert à déclarer des constantes, des structures ou des classes et des prototypes de fonctions. Et le fichier C/CPP correspondant sert à définir les fonctions de classes ou de structures déclarée dans le header.
Enfin bref ça compile et ça marche on est d'accord mais je trouve ça particulièrement moche et choquant.
Et pourquoi Main.cpp et non main.cpp ? Affaire de goût ?

Dernière chose, pourquoi structurer une déclaration de classe ainsi ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

class truc { private: {...} public: {...} private: {...} protected: {...} protected: {...} };

---

J'exagère bien sûr mais pourquoi ne pas faire seulement

Code:

---

1 2 3 4 5 6 7 8 9 10

class truc { private: {...} protected: {...} public: {...} };

---

??

Et enfin dernière chose: pourquoi des variables définies 'protected' dans une classe dont rien n'hérite ? Pourquoi ne pas mettre simplement 'private' ?

Voilà quelques remarques j'espère dites avec un ton pas aggressif du tout.
Mais j'aimerais quand même avoir les explications pour m'informer et savoir qu'est-ce qui vous a poussé à faire comme ça car je suis curieux.

Merci bien de m'avoir lu sans avoir péter un câble :mouarf:
Et merci encore pour la source :mouarf:

Citation:

---

Envoyé par Sixissor

Pourquoi un Main.h ???

---

La plus grande raison : pour ne pas faire de cas particulier lors de la compilation de mon Main.h

La 2ème raison : parce que j'aime avoir un seul include .h dans le .c/.cpp vers le meme nom .h... Mais je comprends entièrement ta discussion :

Beaucoup de gens utilisent le Main.h comme un Define.h -> un header qui contient toutes les constantes du programme... C'est aussi une solution mais je les sépare...

Citation:

---

D'ailleurs j'en profite pour étendre ce débat car je vois ça de plus en plus souvent. Donc ça ne s'adresse pas spécialement à cette source.

Pour moi un header ça sert à déclarer des constantes, des structures ou des classes et des prototypes de fonctions. Et le fichier C/CPP correspondant sert à définir les fonctions de classes ou de structures déclarée dans le header.
Enfin bref ça compile et ça marche on est d'accord mais je trouve ça particulièrement moche et choquant.

---

Pour moi, un header doit :

- être autonome (donc on est d'accord)

- donner une interface à ce qui sera utilisé a l'exterieur (donc on est d'accord)

- montrer les bibliotheques annexes qui seront utilisees (là je pense qu'on se sépare, je préfére avoir un include <SDL.h> dans un .h pour me dire, si je veux utiliser le .c/.cpp je dois avoir SDL... Sans avoir à regarder dans le .c/.cpp

- montrer les dépendances entre les fichiers par les include (encore une fois on se sépare), je préfére voir directement les liens entre les fichiers.

Du coup, pour moi, le .c/.cpp sert de boîte noire, je n'ai pas besoin de savoir ce qui s'y trouve pour avoir une idée de ce qui est utilisé derrière.

Il est vrai que je porte le vice un peu loin vu que je mets TOUTS les includes dans le .h... On pourrait simplement mettre ce qu'il faut pour bien définir le .h, je te l'accorde...

Certes, la compilation se rallonge mais je trouve que cela est plus clair...

Citation:

---

Et pourquoi Main.cpp et non main.cpp ? Affaire de goût ?

---

En effet, question de goût... Tous les autres fichiers avaient une majuscule, j'ai donc passé main.cpp à Main.cpp...

Citation:

---

Dernière chose, pourquoi structurer une déclaration de classe ainsi ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

class truc { private: {...} public: {...} private: {...} protected: {...} protected: {...} };

---

---

Je ne sais pas, j'ai discuté sur le contenu du code et de son fonctionnement, pas directement de l'organisation de la classe. En effet, c'est une bonne remarque.

Citation:

---

Et enfin dernière chose: pourquoi des variables définies 'protected' dans une classe dont rien n'hérite ? Pourquoi ne pas mettre simplement 'private' ?

---

Juste parce que la classe n'hérite rien, on peut la préparer à cette éventualité, non ? Cela ne me choque pas vraiment.

Citation:

---

Voilà quelques remarques j'espère dites avec un ton pas aggressif du tout.

---

Pas du tout... C'était des points très intéressants !
Jc

pour revenir au probleme de viewport, j'ai deja eut ce genre de chose avec glut mais uniquement sur les ecran LCD... pourquoi ? je n'en sais rien :?

sinon, pour le debat dans le .h/dans le .cpp, au debut je faisait comme fearyourself, tout dans le .h et un minimum dans le .cpp, jusqu'au jour ou je suis tombé sur des problèmes de compilation croisée pas croyables avec de la compilation croisée par transitivitée et autre, bref des truc incompilable, et depuis, j'ai inversé la technique, c'est minimum syndical dans le .h (le moins possible d'include, le maximum de forward declaration quans on utilise que des pointeur ou references) et le maximum dans le .cpp, et du coup, plus de problèmes de compilation tordu :D

Fearyourself a répondu aux questions et je n'ai rien à ajouter ormis sur celle-ci :

Citation:

---

Envoyé par Sixissor

Dernière chose, pourquoi structurer une déclaration de classe ainsi ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

class truc { private: {...} public: {...} private: {...} protected: {...} protected: {...} };

---

J'exagère bien sûr mais pourquoi ne pas faire seulement

Code:

---

1 2 3 4 5 6 7 8 9 10

class truc { private: {...} protected: {...} public: {...} };

---

??

Et enfin dernière chose: pourquoi des variables définies 'protected' dans une classe dont rien n'hérite ? Pourquoi ne pas mettre simplement 'private' ?

---

Premièrement, ça fait 2 dernières choses qui se suivent de près :mouarf:
Plus sérieusement, je préfère lorsqu'on déclare une classe, avoir le ontructeur et le destructeur en premier donc en private pour un singleton, éventuellement après une structure de données interne ou des enum qui seraient public, suivi des méthodes publiques puis protégées et seulement après les méthodes je met les données

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

class truc { public: // types de données (struct, enum) // constucteur et destructeur private: // constructeur, destructeur et opérateurs de copie si singleton public: // méthodes publiques protected: // méthodes protégées protected: // données protégées };

---

notez qu'il s'agit d'un avis perso et que chacun fait comme il veut du moment que ça compile et que c'est lisible

Citation:

---

Envoyé par shenron666

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

class truc { public: // types de données (struct, enum) // constucteur et destructeur private: // constructeur, destructeur et opérateurs de copie si singleton public: // méthodes publiques protected: // méthodes protégées protected: // données protégées };

---

notez qu'il s'agit d'un avis perso et que chacun fait comme il veut du moment que ça compile et que c'est lisible

---

Tu pourrais peut-être mettre ces commentaires dans les .h pour le faire comprendre (sans les accents par contre)

Jc

J'y pense... et puis j'oublie, la flemme des commentaire :roll:

dès que j'ai un moment je le fais sur la dernière source que tu as modifié et je met à jour le zip du premier post

[EDIT]c'est fait, le zip est à jour, j'ai également enlevé tous les accents dans tous les commentaires des fichiers .h et .cpp