</span>

Présentation

J'ai l'habitude de prendre le pseudo de Spootnik (quand il est disponible…). J'ai 17 ans et j'apprends à programmer depuis déjà près de 5 ans. Cela fait plusieurs années que j'utilise le C et l'objective-C et j'ai eu envie il y a quelques mois de me lancer dans la création de jeu vidéos avec OpenGL. J'ai voulu lors de mes essais, créer une intreface utilisateur et je me suis rendu compte que ce n'était pas du tout chose facile, d'où ce projet : une interface graphique avec OpenGL.

Le projet (bibliothèque)

Il s'agit bien d'un GUI entier dont je parle. Je veux créer une interface graphique libre et portable qui utilisera OpenGL pour l'affichage. Si je résume les points principaux cela donne :

• libre
• portable
• en objective-C
• utilisation d'OpenGL pour le rendu graphique
• basée sur un système de thèmes (afin de pouvoir personnaliser l'UI à volonté)
• gestion de la transparence afin de permettre des fenêtres de toutes les formes --> fondue parfaite dans n'importe quel jeu vidéo. Cela signifie qu'un clic sur une zone entièrement transparente d'une fenêtre sera ignoré.

Si le projet est concluant, je prévoie de permettre le chargement de l'interface l'interface à partir de fichiers (probablement sous forme d'arbre XML)

Si j'ai choisi l'objective-C, c'est parce que je conais assez bien ce langage, qu'il comporte une couche objet, et qu'il préserve la clarté et la rigueur du C (ce dernier point allant contre le C++).

Pour l'instant j'ai choisi comme nom FGL (Free Graphic Library) parce je trouve que cela sonne correctement, cependant je suis toujours à la recherche d'un nom plus précis, en effet quel rapport entre une bibliothèque graphique et une interface utilisateur…

Voici comment est organisée (en gros) l'interface utilisateur :


J'ai déjà codé les bases que vous pouvez trouver ici. Cela vous permettra d'avoir une petite idée de mon niveau et à quoi ressemblera très probablement le projet s'il aboutit (sachant qu'il n'y a pour l'instant que les classes de base).

Mes questions

Après cette présentation, venons-en au bût de cette discussion. J'ai bien conscience qu'il s'agit d'un projet relativement gros pour une personne ayant juste quelques années d'expérience derrière elle, c'est pourquoi je compte demander la participation de volontaires. Cependant j'aimerais d'abord m'assurer que je ne fais pas fausse route. J'ai parlé déjà de ce projet avec plusieurs personnes et ce qui en ressort est selon certaines personnes, qu'il est intéressant tandis que pour d'autres, il est inutile.

Etant donné l'ampleur du projet je précise bien qu'un simple bût d'apprentissage me paraît insuffisant pour justifier le travail. Il s'agit aussi et surtout de faire quelque chose à bût non lucratif qui servira à d'autres personnes. J'aimerais donc savoir ce que vous en pensez, si vous avez des remarques, des critiques (constructives) à faire.


1. Les commentaires que j'ai eu pour l'instant sont que le fait de vouloir utiliser un système de thèmes engendrera une bibliothèque "usine à gaz", pourtant je n'ai pas l'impression que cela soit si dur à intégrer.

2. La deuxième remarque concerne aussi les thèmes qui ne permettraient pas une totale liberté (puisque l'on se limiterait à des thèmes) mais encore une fois je ne vois pas le problème puisque n'importe qui pourra inventer son propre thème, ou personnaliser un thème existant.

3. On m'a aussi indiqué que l'objective-C est très peu utilisé pour les jeux vidéos, ce qui irait donc contre la popularité du projet. Tout ce que j'ai à dire contre ça est que je ne supporte pas le C++ car il me donne la migraine (c'est un avis personnel, donc pas de troll s'il vous plaît) et que la clarté et la rigueur de l'objective-C (ces deux qualités étant en fait originaires du C) sont pour moi non négligeables.

4. Je sais aussi qu'il existe déjà des bibliothèques de GUI se servant d'OpenGL pour le rendu, mais elles sont pratiquement toutes en C++, quelques unes en C dont aucune qui intègre le système de thème (pour celles en C) ainsi que les fonctionnalités que j'ai présentées plus haut.

5. Et enfin j'ai vu que certaines personnes trouvaient ce projet inutile, puisque si une entreprise veut faire son jeu vidéo, il va de soit qu'elle va aussi créer son système d'UI, mais je pense que tout le monde n'en a pas les possibilités (en autre sur le plan technique). Cela pourra donc aider beaucoup de personnes.

Voila, j'attends vos impressions, suggestions ou commentaires !
Merci pour votre aide,

Lucas

Salut,

Citation : Soltic Lucas

1. Les commentaires que j'ai eu pour l'instant sont que le fait de vouloir utiliser un système de thèmes engendrera une bibliothèque "usine à gaz", pourtant je n'ai pas l'impression que cela soit si dur à intégrer.

Je comprend ce point de vue : au niveau de l'algorithme, ce n'est pas paticulièrement difficile à implémenter, je pense que c'est surtout au niveau des performances (RAM + UC) que ça devient lourd, en tout cas plus lourd que si l'interface était gérée par le système d'exploitation de manière native. Mais évidemment, pour une GUI de jeux-vidéos, on ne peut pas utiliser les fonctions natives du système (comme Qt ou wxWidgets).

Il me semble que le projet avait "avorté" au moment où tu avais découvert d'autres libs qui faisaient ce que tu voulais faire ?
Qu'en est-il maintenant ?

Orienter le projet vers les thèmes est un choix, mais je pense que ce n'est pas ça le plus important dans le domaine du jeu-vidéo. Les interfaces de logiciels et de jeux sont très différentes, pourquoi pas repenser l'organisation du système par rapport aux autres libs ?
Quand on développe des interfaces pour le jeu vidéo, je pense qu'on est amené à "inventer" ses propres "widgets", et leurs interactions. Par exemple, faut-il conserver la notion de "fenêtre" ?

Citation : Soltic Lucas

3. On m'a aussi indiqué que l'objective-C est très peu utilisé pour les jeux vidéos, ce qui irait donc contre la popularité du projet. Tout ce que j'ai à dire contre ça est que je ne supporte pas le C++ car il me donne la migraine (c'est un avis personnel, donc pas de troll s'il vous plaît) et que la clarté et la rigueur de l'objective-C (ces deux qualités étant en fait originaires du C) sont pour moi non négligeables.

ça se défend… Ce n'est pas parce qu'il na pas été beaucoup utilisé qu'il ne le sera pas plus tard (surtout si des outils adaptés sont développés ). Ceci dit, la clarté d'un langage est assez subjective : tu t'est habitué à ce langage, donc tu le trouves plus clair que le C++. Tout reste une question de goût.

Voilà mes impressions, sugestions et commentaires…

Bonne continuation !

Citation : wetneb

Je comprend ce point de vue : au niveau de l'algorithme, ce n'est pas paticulièrement difficile à implémenter, je pense que c'est surtout au niveau des performances (RAM + UC) que ça devient lourd, en tout cas plus lourd que si l'interface était gérée par le système d'exploitation de manière native. Mais évidemment, pour une GUI de jeux-vidéos, on ne peut pas utiliser les fonctions natives du système (comme Qt ou wxWidgets).

Je narrive pas bien à comprendre où c'est plus lourd. En fonction du thème choisi les images correspondantes sont chargées, qu'est-ce qui pose problème ?

Citation : wetneb

Il me semble que le projet avait "avorté" au moment où tu avais découvert d'autres libs qui faisaient ce que tu voulais faire ?
Qu'en est-il maintenant ?

En effet j'avais remarqué qu'il existait d'autres bibliothèques de GUI. Cependant comme je l'ai dit dans mon post, beaucoup sont en C++ et je n'aime pas le C++. Quant à celles qui sont en C, elles ne sont pas pratiques à utiliser (d'après les quelques essais que j'ai fait), de plus je trouve l'aspect orienté objet intéressant, d'où mon choix pour l'objective-C. Ce que je regrette aussi c'est la limitation de ces GUI, en effet j'aimerais que ma bibliothèque se charge de vérifier si une zone d'un widget ou d'une fenêtre (en admettant que l'on conserve le système de fenêtres) est entièrement transparente, le clic reçu serait alors envoyé à ce qui est placé derrière. Mais de là à dire si cela mérite la création d'une bibliothèque entière, je ne le sais pas encore vraiment, et c'est aussi pour ça que j'ai créé ce fil de discussion.

Citation : wetneb

Orienter le projet vers les thèmes est un choix, mais je pense que ce n'est pas ça le plus important dans le domaine du jeu-vidéo. Les interfaces de logiciels et de jeux sont très différentes, pourquoi pas repenser l'organisation du système par rapport aux autres libs ?
Quand on développe des interfaces pour le jeu vidéo, je pense qu'on est amené à "inventer" ses propres "widgets", et leurs interactions. Par exemple, faut-il conserver la notion de "fenêtre" ?

Qu'est-ce que tu veux dire par "pourquoi pas repenser l'organisation du système par rapport aux autres libs ?" ?
Pour la notion de fenêtre en effet je vais devoir regarder ça de plus près, à vrai dire je n'avais pas pensé que cela pourrait devenir inutile.


Merci pour tes suggestions

Citation : Soltic Lucas

Qu'est-ce que tu veux dire par "pourquoi pas repenser l'organisation du système par rapport aux autres libs ?" ?

Chaque lib GUI est organisée à sa manière. Je prend l'exemple de Qt (que j'utilise en C++ ) :
On a des "widgets" qu'on peut assembler avec des "layouts", et qui comuniquent entre-eux par le biais des signaux et des slots.
Tout est construit sur ce modèle (que j'apprécie, d'ailleurs). Il faut déterminer les différences entre GUI pour logiciel et GUI pour jeu vidéo : je pense par exemple que dans bon nombre de jeux vidéos on n'utilise pas beaucoup les contrôles classiques (bouton radio, Combo box, check box… Je ne connais pas les noms en français ), mais on a plus recours aux mouvements de la souris, au clavier, aux "widgets" personnalisés, plus basiques. Quand je dis "repenser l'organisation du système", c'est mettre les doigts dans les diagrammes UML et créer des objets peut-être plus abstraits, insister sur la gestion des évènements,...

( C'est pas clair mon truc, c'est vrai... Je divague )

Citation : Soltic Lucas

Ce que je regrette aussi c'est la limitation de ces GUI, en effet j'aimerais que ma bibliothèque se charge de vérifier si une zone d'un widget ou d'une fenêtre (en admettant que l'on conserve le système de fenêtres) est entièrement transparente, le clic reçu serait alors envoyé à ce qui est placé derrière.

Voilà, par exemple, il faudrait creuser dans cette direction...

Enfin mes suggestions sont vagues, il faudrait que je me penche plus sur le projet pour y voir clair.
Mais je me dis, puisque tu pars de zéro, autant essayer quelque-chose de nouveau, pour éviter de réinventer la roue.
C'est à ce moment-là que le papier et le stylo se révèlent utiles.

Edit:

Citation : Soltic Lucas

Tu peux expliquer ? Qu'est-ce que les "layouts" et les "slots" ?

ça n'a pas tellement d'importance, c'était juste pour donner un exemple d'organisation d'une lib.
Un "layout" est une boîte dans laquelle tu peux aligner des widgets. Il existe des layouts horizontaux ou verticaux (comme ceci).
Un slot est une fonction appelée à la réception d'un signal. Voir cette page.

Citation : wetneb

Citation : Soltic Lucas

Qu'est-ce que tu veux dire par "pourquoi pas repenser l'organisation du système par rapport aux autres libs ?" ?

Chaque lib GUI est organisée à sa manière. Je prend l'exemple de Qt (que j'utilise en C++ ) :
On a des "widgets" qu'on peut assembler avec des "layouts", et qui comuniquent entre-eux par le biais des signaux et des slots.

Tu peux expliquer ? Qu'est-ce que les "layouts" et les "slots" ?

Citation : wetneb

Tout est construit sur ce modèle (que j'apprécie, d'ailleurs). Il faut déterminer les différences entre GUI pour logiciel et GUI pour jeu vidéo : je pense par exemple que dans bon nombre de jeux vidéos on n'utilise pas beaucoup les contrôles classiques (bouton radio, Combo box, check box… Je ne connais pas les noms en français ), mais on a plus recours aux mouvements de la souris, au clavier, aux "widgets" personnalisés, plus basiques.

Hmmm… là ça dépend des jeux, il est vrai que la plus grande partie ne fait pas appel à ce genre d'objets, mais il reste toujours l'interface d'accès au jeu. On peut aussi avoir des contrôles (widgets) dans le jeu lui-même pour effectuer des actions par exemple, et ici le fait de pouvoir personnaliser à volonté l'UI serait un gros avantage.

Citation : wetneb

Quand je dis "repenser l'organisation du système", c'est mettre les doigts dans les diagrammes UML et créer des objets peut-être plus abstraits, insister sur la gestion des évènements,...

( C'est pas clair mon truc, c'est vrai... Je divague )

Pour l'instant je rasseemble les idées afin de voir si le projet à un intérêt, je verrai donc plus tard pour ce qui est des schémas précis et diagrammes UML .

Citation : wetneb

Citation : Soltic Lucas

Ce que je regrette aussi c'est la limitation de ces GUI, en effet j'aimerais que ma bibliothèque se charge de vérifier si une zone d'un widget ou d'une fenêtre (en admettant que l'on conserve le système de fenêtres) est entièrement transparente, le clic reçu serait alors envoyé à ce qui est placé derrière.

Voilà, par exemple, il faudrait creuser dans cette direction...

Mais cela mérite-t-il la création d'une bibliothèque entière… à voir…