Discussion :

[Iradrille]

J'ai regardé un article Internet sur les boost::shared_ptr VS new. Sans les optimisations le new est au moins 2 fois plus rapide.

On revient au même: Boost et sûrement Qt ont des pans entiers qui sont optimisés mais il faut avoir les librairies bien compilées à la base.
Mais tu peux toujours trouver un truc non optimisé comme optimisé.

Il faut quand même comparer ce qui est comparable. Il est évident qu'un shared_ptr sera plus lent qu'un pointeur nu : un shared_ptr compte les références, ça a un coût.

Mais si on compare un unique_ptr à un pointeur nu, les performances sont strictement identiques.
De même pour array vs un tableau de taille fixe "style C".
De même pour vector vs un tableau dynamique géré à la main "style C" (ok, les vector c'est la STL, pas boost).
Etc...

Il y à peut être des parties mal optimisées (en tout cas le temps de compilation, lui, n'est pas optimisé ), mais ça doit être extrêmement rare : boost c'est quand même super sérieux comme projet.

[Bousk]

C'est bien là le problème : que se soit la STL ou la QTL, elles ne proposent que les algos de base et on utilise boost dès qu'on a besoin d'un algo qui sort un peu de l'ordinaire. Et donc on se retrouve avec des conversions entre les types Qt / STL un peu partout.

C'est pas un problème, c'est tout à fait normal.
Si tu veux utiliser Ogre, UDK, CryEngine, FMOD ou tout autre moteur, tu dois utiliser le moteur entier.
Qt est un moteur de GUI, tu l'utilises entièrement ou pas du tout.

Et Qt fait des threads aussi

Et comment crois-tu que les développeurs de Qt les utiliseraient sinon ?
Qt a besoin de threads, donc ils en implémentent
Btw, utiliser sa propre bibliothèque de thread, ou n'importe laquelle, à la place de celle de Qt n'est pas le plus compliqué : le code de threading est (généralement, toujours) simple à décoréler/isoler

Qt c'est comme Boost: tu as vu le nombre de DLLS que ces bibliothèques te génèrent.

Un projet de base sous Qt ne nécessite qu'une poignée de DLL
Quant à Boost, rapelle-moi le nombre de dll d'une bibliothèque header-only ?
Si les DLL te dérange, tu peux les linker en static

Par exemple, lorsque tu compiles les shared_ptr es-tu sûr que le compteur est protégé par des mutex?

Y'aurait pas une doc qui te le dit justement... ?
C'est vrai pour n'importe quel morceau de n'importe quelle bibliothèque à ce compte..

[jblecanard]

Salut

Quant à Boost, rapelle-moi le nombre de dll d'une bibliothèque header-only ?

Si c'est vrai pour pas mal de composants, Boost n'est pas que header only. program_options et filesystem par exemple ne le sont pas ! Ceci étant dit, les composants non header only de boost sont très bien séparés et il n'y a nul besoin de tirer des dépendances lourdes lorsqu'on les utilise.

Par exemple, lorsque tu compiles les shared_ptr es-tu sûr que le compteur est protégé par des mutex?

Oui, shared_ptr est thread safe de ce côté, et c'est aussi pour ça qu'il coûte cher.

[Kadesh]

Avant de commencer, voila ce que je veux réaliser pour que vous ayez une idée:
A partir de 2:40

C'est à peu près ca que je veux faire, pleins de petites fenetres facilement manipulables en drag and drop, redimensionnables... ces fenetres contiennent des photos ou des vidéos fichiers textes etc. et on peut faire pleins d'opérations dessus.
Biensur c'est hypothétique, mais dites moi comment vous feriez, vous?

Pour résumer :
-QT a une bibliotheque lourde, et ce n'est pas bien car ca augmente les temps de compilation et la grosseur de l’exécutable à la fin a cause de la dépendance des dll (pas trop compris ce concept, j'imagine que ca veut dire que si on utilise une dll, cette même dll utilise d'autres dll qu'on avait pas forcément prévu), c'est bien ca?
-Avec QT on doit faire des conversions entre sa bibliotheque QTL et la STL et ca prend du temps?
-Il faut se méfier des exemples trop datés car QT est vieux. Quelqu'un peut me proposer des tuto / livres récents outre la doc officielle?
-boost est mieux foutu que QT car moins de pb de dependance? ==> je devrais commencer par là directement donc ?
-On est rapidement limité avec les algorithmes de base dispo avec QTL.

Tout le monde confirme?

Pour vous répondre :

Je pense qu'une petite mise au point est nécessaire : bien programmer est difficile. C'est un métier, et il ne s'apprend pas en quelques soirées : tu as une masse de travail conséquente à abattre pour devenir un programmeur

Concernant mon projet personnel, effectivement je le fais pour m'amuser (car je pense que c'est la meilleure méthode pour apprendre, mais j'ai l'espoir de me réorienter professionnellement à terme, je suis dans les réseaux telecom actuellement, et à 25 ans, je pense qu'il y a encore une chance pour moi, en tout cas je l'espère. Donc enfaite c'est un projet très serieu, je bosse d'ailleurs minimum 4 h par jour.
Et ce genre de textes m'ont mit en condition XD :
http://www.gamedev.net/blog/355/entr...ly-hard-steps/
http://www.vizmatic.com/apprenez-a-p...en-dix-ans#ans

Si tu te lances dans l'aventure C++ malgré tout, prend garde de pratiquer le C++11 dès le début. De même que Qt, C++ a un lourd passif et on a vite faire de lire des tutos complètement périmés.

Alors justement, j'ai vu que la plupart des tuto sur C++11 reposent sur l'approche : comparer comment on faisait avant, et comment on doit faire maintenant. J'ai pas trop vu de tuto pour débutant total en programmation. Alors il semble bien que pour apprendre C++11 il faut apprendre C++ ancienne norme...
Sans compter le fait que si je deviens pro un jour, je vais tomber sur du code existant codé dans l'ancienne norme.
Je vais juste éviter de prendre des trucs qui datent d'avant la MAJ de 2003, et tout ce qui est l'approche C++ is C with class qui est obsolete.
Bonne stratégie?

Bienvenue dans le C++, où il existe de nombreuses bibliothèques spécialisées, et ce qu'on demande à une bibliothèque spécialisée c'est de remplir sa tâche, pas en plus de faire le café
______________
Quant à Qt.. tu l'utilises ou pas, mais quand tu l'utilises c'est entièrement. Là encore c'est le principe d'un moteur de GUI, tu peux pas dire "j'utilise Qt avec les boutons de WxWidget", ça n'a aucun sens
______________
Et puis bon, l'utilisation CPU d'une GUI dont la principale utilisation est d'attendre un input utilisateur..
_______________
C'est pas un problème, c'est tout à fait normal.
Si tu veux utiliser Ogre, UDK, CryEngine, FMOD ou tout autre moteur, tu dois utiliser le moteur entier.
Qt est un moteur de GUI, tu l'utilises entièrement ou pas du tout.

-Utiliser un moteur de GUI (IDE) comme QT creator, c'est obligatoire pour un débutant?
-Si j'utilise QT creator, je pourrais intégrer des libraries supplémentaires au besoin?

-Est-ce que QT ou boost suffisent pour ce que je veux faire?

Je suis à fond dans le design, l'originalité, et l'ergonomie alors je me rends pas bien compte des limitations techniques de telle ou telle méthode.
Je suis perdu avec toutes ces technologies!

Vais-je devoir inventer mes propres libraries et mon propre IDE? (évidemment il faut un certain passif pour en être capable).
Si oui, quelle stratégie me proposez vous pour en arriver là?

[jblecanard]

Salut

-QT a une bibliotheque lourde, et ce n'est pas bien car ca augmente les temps de compilation et la grosseur de l’exécutable à la fin a cause de la dépendance des dll (pas trop compris ce concept, j'imagine que ca veut dire que si on utilise une dll, cette même dll utilise d'autres dll qu'on avait pas forcément prévu), c'est bien ca?

Oui, c'est celà. Sauf qu'on a rien sans rien. Si Qt est lourd, c'est parce qu'il y a plein de choses dedans ! Et il n'y pas vraiment d'alternative de cette qualité en open-source et multiplateforme.

Maintenant, au regard des vidéos que tu nous a montrées... là tu brises complètement les codes de l'UI "classique". L'intérêt principal de Qt est qu'il fait une grosse partie du boulot pour toi, en utilisant des composants d'UI déjà existant. Si tu fais des trucs complètement what the fuck comme dans les vidéos tu nous montres, j'ai bien peur que Qt ne te soit pas d'une grande utilité. Moi je partirais sur une solution à base d'OpenGL, éventuellement avec un moteur de rendu open comme Ogre, éventuellement avec l'aide d'un système de GUI OpenGL (exemple) et d'un moteur physique (exemple). Plus généralement, je pense que vu la complexité de ton objectif, il te faut bien écrire tes spécifications avant de faire un choix technique.

Alors justement, j'ai vu que la plupart des tuto sur C++11 reposent sur l'approche : comparer comment on faisait avant, et comment on doit faire maintenant. J'ai pas trop vu de tuto pour débutant total en programmation. Alors il semble bien que pour apprendre C++11 il faut apprendre C++ ancienne norme...
Sans compter le fait que si je deviens pro un jour, je vais tomber sur du code existant codé dans l'ancienne norme.
Je vais juste éviter de prendre des trucs qui datent d'avant la MAJ de 2003, et tout ce qui est l'approche C++ is C with class qui est obsolete.
Bonne stratégie?

Oui je pense que c'est une assez bonne stratégie. Longue à mettre en oeuvre mais puisque tu as l'air déterminé et que tu comptes y consacrer beaucoup de temps, c'est possible.

Vais-je devoir inventer mes propres libraries et mon propre IDE? (évidemment il faut un certain passif pour en être capable).

Tes propres librairies (en théorie faut dire "bibliothèques" en français mais perso je m'en bat), probablement si tu fais des choses spécifiques qu'on ne fait pas trop ailleurs. Attention à ne pas réinventer la roue. De toute façon, un programme est toujours découpé en plusieurs modules qu'on pourrait assimiler à des bibliothèques.

Développer ton propre IDE, là je dis non, tu perdrais ton temps. Il existe assez d'outils. Idéalement, il vaut mieux écrire du code qui ne dépend pas de l'IDE utilisé, en utilisant un logiciel comme cmake. Avec le temps, tu évolueras et un IDE qui te convient à tes débuts pourrait ne pas te convenir à l'avenir. Du reste, si tu vend tes services de programmeur à une entreprise, l'IDE te sera peut être (probablement) imposé. Il faut savoir être souple et connaître les logicies les répandus.

[mintho carmo]

Qt est bien adapté pour ce genre d'application (via Qt Quick). Cf par exemple :

ou

[JolyLoic]

C'est pas un problème, c'est tout à fait normal.
Si tu veux utiliser Ogre, UDK, CryEngine, FMOD ou tout autre moteur, tu dois utiliser le moteur entier.
Qt est un moteur de GUI, tu l'utilises entièrement ou pas du tout.

Sauf qu'en plus d'être une bibliothèque d'UI, c'est aussi une bibliothèque de collections, une bibliothèque d'IO, une bibliothèque de threads, une bibliothèque d'accès aux bases de données, et j'en oublie certainement. Et autant dans le monde .NET par exemple, où il y a un standard de fait, ça ne me gène pas qu'un seul framework gère tous ces aspects, autant en C++ où des concurrents existent pour chacune de ces parties, je préfèrerais pouvoir composer mon application à ma sauce, en choisissant pour chaque partie ce que je préfère (et accessoirement, j'espèrerais qu'en se focalisant, ils puissent évoluer plus vite ce qui est leur cœur de métier).

En outre, même si à une époque, ça pouvait avoir un sens de redévelopper ça, de nos jours, ça n'est plus trop le cas. J'aurais apprécié qu'au fil des versions ils remplacent de plus en plus de leurs composants par des composants standards. Je peux dire pour corriger régulièrement des projets écrits en Qt qu'à les lire, on dirait presque que ce n'est plus du C++, mais une sorte de pidgin.

Après, je ça fait un sacré bout de temps que je n'en n'ai plus fait moi-même, mais pour avoir fait du WPF en .NET, cette bibliothèque présente des tas de concepts qui me manquaient dans Qt3. Je me demande dans quelle mesure ils sont désormais présents (composabilité extrème des contrôles (par exemple mettre un bloc avec combo box et check-box comme item d'une list, en 2 lignes de code, séparation vue/données à la MVVM, API d'affichage vectorielle déclarative, permettant d'appliquer aisément des effet sur tout composant...).

[Iradrille]

Alors justement, j'ai vu que la plupart des tuto sur C++11 reposent sur l'approche : comparer comment on faisait avant, et comment on doit faire maintenant. J'ai pas trop vu de tuto pour débutant total en programmation. Alors il semble bien que pour apprendre C++11 il faut apprendre C++ ancienne norme...

Énormément d'ajouts de C++11 ne sont que du sucre syntaxique : ils ne permettent rien de plus, juste de l'écrire de manière plus simple : range-based loops, lamdbas, auto, ...
Il y à aussi beaucoup d'ajouts à la STL de morceaux de boost : unique_ptr, shared_ptr, mutex, thread, ...
Et enfin l'ajout de certaines fonctionnalités, impossible en C++03 : move semantic, variadic templates ...

Dans un premier temps, connaitre ou pas ces choses n'est pas très important.

-Utiliser un moteur de GUI (IDE) comme QT creator, c'est obligatoire pour un débutant?

Tu sembles faire une confusion entre IDE et moteur de GUI.
Un IDE (Qt Creator, Visual Studio, Code::Blocks, Eclipse, ...) n'est rien d'autre qu'un outil qui te permet d'écrire du code plus facilement / rapidement, et qui t'aidera à gérer la phase de génération d'un exécutable (compilation / link).

Qt est par contre un moteur de GUI, quelque chose qui te permet de créer des interfaces graphiques.

Est-ce obligatoire pour un débutant ? Non.
Tu peux très bien créer des programmes sans interfaces graphique (en console). Un exemple simple : "ls".

-Si j'utilise QT creator, je pourrais intégrer des libraries supplémentaires au besoin?

Qt Creator est un IDE, tu utilises les libs que tu veux, tu peux même coder sur Qt Creator sans utiliser Qt.

-Est-ce que QT ou boost suffisent pour ce que je veux faire?

Qt et boost ne sont pas vraiment comparables mais plutôt complémentaires.
boost n'est pas "une simple bibliotheque", c'est un ensemble de plusieurs dizaines (centaines ?) de libs qui touchent un ensemble très large de domaines.
Qt permet aussi principalement de faire des interfaces graphiques, mais permet aussi d'autres choses : dev réseau / db / multithreading / etc...

En tout cas un conseil, commence simple (ton projet actuel est tout sauf simple), ça te permettra d'y voir un peu plus clair.

En outre, même si à une époque, ça pouvait avoir un sens de redévelopper ça, de nos jours, ça n'est plus trop le cas. J'aurais apprécié qu'au fil des versions ils remplacent de plus en plus de leurs composants par des composants standards. Je peux dire pour corriger régulièrement des projets écrits en Qt qu'à les lire, on dirait presque que ce n'est plus du C++, mais une sorte de pidgin.

A ce que j'ai compris, ils auraient réimplétmentés la STL à leur sauce car il était difficile de trouver une implémentation non buggée, ce que je comprend par contre pas, c'est pourquoi ils n'ont pas respectés la norme. Le passage de l'une à l'autre des implémentations aurait été tellement simple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
namespace qt {
   class vector;
   class list;
   //...
}
 
#define QT_NS qt
// #define QT_NS std
 
QT_NS::vector<int> vec;

[white_tentacle]

Sauf qu'en plus d'être une bibliothèque d'UI, c'est aussi une bibliothèque de collections, une bibliothèque d'IO, une bibliothèque de threads, une bibliothèque d'accès aux bases de données, et j'en oublie certainement. Et autant dans le monde .NET par exemple, où il y a un standard de fait, ça ne me gène pas qu'un seul framework gère tous ces aspects, autant en C++ où des concurrents existent pour chacune de ces parties, je préfèrerais pouvoir composer mon application à ma sauce, en choisissant pour chaque partie ce que je préfère (et accessoirement, j'espèrerais qu'en se focalisant, ils puissent évoluer plus vite ce qui est leur cœur de métier).

En fait, un des principaux problèmes est qu’il n’y a pas de classe de chaîne de caractères standard en c++ qui gère correctement les encodages non us-ascii. Dès lors, tu dois te taper une classe de chaîne spécifique à ta lib X et des conversions dans tous les sens si tu n’utilises pas celle de ta lib X partout. Et du coup, pour utiliser celle de ta gui partout, tu te retrouves à tout redévelopper.

Et je suis d’accord avec toi un point : certains composants de Qt sont bien pourris (genre la couche d’accès aux bases de données).

Après, je ça fait un sacré bout de temps que je n'en n'ai plus fait moi-même, mais pour avoir fait du WPF en .NET, cette bibliothèque présente des tas de concepts qui me manquaient dans Qt3. Je me demande dans quelle mesure ils sont désormais présents (composabilité extrème des contrôles (par exemple mettre un bloc avec combo box et check-box comme item d'une list, en 2 lignes de code, séparation vue/données à la MVVM, API d'affichage vectorielle déclarative, permettant d'appliquer aisément des effet sur tout composant...).

Il y a eu de gros changements entre Qt3 et Qt4, pas mal d’améliorations de ce point de vue là. Et depuis, il y a QtQuick, qui me semble une alternative crédible à WPF (tes exemples se font effectivement très simplement en qtquick), mais manque encore un peu de maturité.

[ternel]

Sache tout de même que la seconde vidéo est un prototype ayant demandé plusieurs années de travail à une équipe complète de chercheurs.
C'est un projet probablement hors de ta portée actuelle, vu que tu n'as pas encore les compétences GUI.

[mintho carmo]

Sache tout de même que la seconde vidéo est un prototype ayant demandé plusieurs années de travail à une équipe complète de chercheurs.
C'est un projet probablement hors de ta portée actuelle, vu que tu n'as pas encore les compétences GUI.

Bien sûr qu'il a fallut plusieurs années pour faire l'implémentation des fonctionnalités utilisées dans la vidéo. Mais cela ne veut pas dire qu'il faut des années pour faire cette vidéo à partir des outils actuels. Ni que ces techniques sont trop complexes ou trop longues à apprendre pour un débutant. Utiliser le moteur de particules nécessite 2-3 items, animer un item se fait en une ligne de code, lire une vidéo se fait également en 2 lignes de code. Rien de complexe a apprendre. A part la quantité de fonctionnalités qu'il y a dans le framework, cela nécessite forcement du temps pour faire le tour... mais ça sera également le cas avec n'importe quel framework riche. Et ça sera encore pire en utilisant une approche bas niveau (OpenGL, DirectX) ou des frameworks ne proposant pas de type de fonctionnalités (wxWidegts par exemple)

[Kadesh]

Merci à tous pour votre participation active et vos nombreux conseils c'est très intéressant, et je note tout.

Il est donc clair que QT ne fera pas l'affaire pour ce que je vous ai montré.

A partir de là, vous me proposez plusieurs solutions :
Comment choisir?

-2 partisans pour commencer simple. Pouvez-vous développer?

En tout cas un conseil, commence simple (ton projet actuel est tout sauf simple), ça te permettra d'y voir un peu plus clair.

Sache tout de même que la seconde vidéo est un prototype ayant demandé plusieurs années de travail à une équipe complète de chercheurs.
C'est un projet probablement hors de ta portée actuelle, vu que tu n'as pas encore les compétences GUI.

Acquérir les compétences GUI, ca veut dire commencer par QT/QTquick/Boost/WPF? Prérequis obligatoire/très conseillé avant de passer à quelque chose de plus complexe?

-Les solutions "simples"

-WPF en .NET.

mais pour avoir fait du WPF en .NET, cette bibliothèque présente des tas de concepts qui me manquaient dans Qt3. Je me demande dans quelle mesure ils sont désormais présents (composabilité extrème des contrôles (par exemple mettre un bloc avec combo box et check-box comme item d'une list, en 2 lignes de code, séparation vue/données à la MVVM, API d'affichage vectorielle déclarative, permettant d'appliquer aisément des effet sur tout composant...).

-QTQuick alternative à WPF.

Il y a eu de gros changements entre Qt3 et Qt4, pas mal d’améliorations de ce point de vue là. Et depuis, il y a QtQuick, qui me semble une alternative crédible à WPF (tes exemples se font effectivement très simplement en qtquick), mais manque encore un peu de maturité.

-Les solutions complexes :

-Moteur de rendu open comme Ogre, système de GUI OpenGL et moteur physique.

Moi je partirais sur une solution à base d'OpenGL, éventuellement avec un moteur de rendu open comme Ogre, éventuellement avec l'aide d'un système de GUI OpenGL (exemple) et d'un moteur physique (exemple). Plus généralement, je pense que vu la complexité de ton objectif, il te faut bien écrire tes spécifications avant de faire un choix technique.

-Utiliser des bibliotheque par ci par là en C++. Tu rejoins jblecanard sur OpenGL et Ogre?

je préfèrerais pouvoir composer mon application à ma sauce, en choisissant pour chaque partie ce que je préfère (et accessoirement, j'espèrerais qu'en se focalisant, ils puissent évoluer plus vite ce qui est leur cœur de métier).

-Utiliser un moteur à particule et animer les item plutot que OpenGL ou DirectX. Utiliser les acquis de la recherche ==> Par où dois-je commencer?

Bien sûr qu'il a fallut plusieurs années pour faire l'implémentation des fonctionnalités utilisées dans la vidéo. Mais cela ne veut pas dire qu'il faut des années pour faire cette vidéo à partir des outils actuels. Ni que ces techniques sont trop complexes ou trop longues à apprendre pour un débutant. Utiliser le moteur de particules nécessite 2-3 items, animer un item se fait en une ligne de code, lire une vidéo se fait également en 2 lignes de code. Rien de complexe a apprendre. A part la quantité de fonctionnalités qu'il y a dans le framework, cela nécessite forcement du temps pour faire le tour... mais ça sera également le cas avec n'importe quel framework riche. Et ça sera encore pire en utilisant une approche bas niveau (OpenGL, DirectX) ou des frameworks ne proposant pas de type de fonctionnalités (wxWidegts par exemple)

[Iradrille]

-2 partisans pour commencer simple. Pouvez-vous développer?

Ce thread me fait beaucoup penser à un des nombreux threads qu'on voit passer

Salut, J'ai aucune connaissance en dev, je veux faire un jeu mieux que WoW, j'ai plein d'idées, par ou je dois commencer ?

PS : je suis motivé.

Même si tu vises quelque chose de beaucoup plus simple que ça, tu vises quelque chose qui est généralement hors de portée du premier projet de quelqu'un qui débute.

Choisi un langage, une lib et commence à coder 2/3 trucs (genre une petite calculette, ou d'autres choses relativement simples du même genre).
Même si tu change de langage ou de lib par la suite, ça ne sera pas des connaissances perdues.

Le fait de coder te permettra de te confronter à certaines difficultés, de voir les différentes solutions possibles etc...

Oubli OpenGL / DirectX (et donc Ogre) pour le moment, sans un minimum de connaissances en C++, tu cours à la catastrophe.

Si tu veux commencer par du C++, part sur Qt, en C# tu as WPF (ou même Winforms), en Java tu as Swing, etc...
Si tu commences par du C++ ou Java, je te conseille quand même d'oublier les interfaces graphiques dans un premier temps, une fois que tu as quelques notions tu pourras te lancer sur les interfaces. Il n'y à qu'en C# où c'est tellement bien intégré que tu peux commencer directement avec des interfaces graphiques.

On peut résumer ça en 1 phrase au final : "chaque chose en son temps".

[Kadesh]

Ce thread me fait beaucoup penser à un des nombreux threads qu'on voit passerMême si tu vises quelque chose de beaucoup plus simple que ça, tu vises quelque chose qui est généralement hors de portée du premier projet de quelqu'un qui débute.

Choisi un langage, une lib et commence à coder 2/3 trucs (genre une petite calculette, ou d'autres choses relativement simples du même genre).
Même si tu change de langage ou de lib par la suite, ça ne sera pas des connaissances perdues.

Le fait de coder te permettra de te confronter à certaines difficultés, de voir les différentes solutions possibles etc...

Oubli OpenGL / DirectX (et donc Ogre) pour le moment, sans un minimum de connaissances en C++, tu cours à la catastrophe.

Si tu veux commencer par du C++, part sur Qt, en C# tu as WPF (ou même Winforms), en Java tu as Swing, etc...
Si tu commences par du C++ ou Java, je te conseille quand même d'oublier les interfaces graphiques dans un premier temps, une fois que tu as quelques notions tu pourras te lancer sur les interfaces. Il n'y à qu'en C# où c'est tellement bien intégré que tu peux commencer directement avec des interfaces graphiques.

On peut résumer ça en 1 phrase au final : "chaque chose en son temps".

Oui je suis parfaitement conscient des difficultés auxquelles je vais faire face, c'est pour ça que je vous demande la marche à suivre car je n'en ai aucune idée.
Ca ne me dérange absolument pas de commencer par quelque chose de simple si c'est necessaire. Je viens ici en toute humilité.

Je ne veux juste pas perdre mon temps inutilement en me dispersant.

Mais si tu me dis que c'est nécessaire de toucher à des trucs plus simples avant, je vais faire comme ça.

A part si quelqu'un me fournit un tuto OpenGl de la mort qui tue pour débutant et me donne des arguments prouvant que c'est possible de commencer directement par là. Et j'avoue que c'est la solution qui me plairait

[mintho carmo]

-Utiliser un moteur à particule et animer les item plutot que OpenGL ou DirectX. Utiliser les acquis de la recherche ==> Par où dois-je commencer?

Euh, tu as mal lu. Je parlais du moteur de particules utilisé dans le vidéo que j'ai donné, je n'ai pas dit que tu devais utiliser un moteur de particules. Ca n'aurait pas de sens d'utiliser un moteur de particules pour faire ce que tu veux

Il est donc clair que QT ne fera pas l'affaire pour ce que je vous ai montré.

Et je pense au contraire que Qt (Qt Quick) est adapté pour ce que tu veux faire. Cela semble assez similaire aux vidéos que j'ai donné
A mon avis, ça sera la solution la plus simple et la plus rapide d'utiliser le QML (Qt Quick). Et repasser au C++ que si nécessaire (j'ai l'impression que tu souhaites faire avant tout de l'UI, donc pas forcement besoin de beaucoup de C++. Voir pas du tout)

[Kadesh]

Euh, tu as mal lu. Je parlais du moteur de particules utilisé dans le vidéo que j'ai donné, je n'ai pas dit que tu devais utiliser un moteur de particules. Ca n'aurait pas de sens d'utiliser un moteur de particules pour faire ce que tu veux


Et je pense au contraire que Qt (Qt Quick) est adapté pour ce que tu veux faire. Cela semble assez similaire aux vidéos que j'ai donné
A mon avis, ça sera la solution la plus simple et la plus rapide d'utiliser le QML (Qt Quick). Et repasser au C++ que si nécessaire (j'ai l'impression que tu souhaites faire avant tout de l'UI, donc pas forcement besoin de beaucoup de C++. Voir pas du tout)

Ha autant pour moi!

Oui j'ai vu tes vidéos, je les trouve intéressantes. C'est limité par rapport à mes objectifs certes, mais c'est vrai qu'il y a beaucoup de possibilités pour débuter, j'aime beaucoup cette solution.

J'attends de voir si quelqu'un est en faveur de commencer directement par OpenGl et je passe en [Résolu].

[mintho carmo]

J'attends de voir si quelqu'un est en faveur de commencer directement par OpenGl et je passe en [Résolu].

Si quelqu'un le fait, au moins tu auras un nom à mettre dans ta liste des personnes qu'il ne faut pas écouter

J'aime beaucoup OpenGL, mais dans ton cas, une approche bas niveau serait une erreur. Peut être dans un second temps, pour apprendre à utiliser les shaders, pour faire des rendus spéciaux. Mais pas pour commencer

[Iradrille]

Je vais surement paraitre insistant, mais commence par simple. Tu vas déjà rencontrer un certains nombres de problèmes.

Quant à commencer par OpenGL, personne ne peut conseiller ça.

Si ça t'intéresse tu auras tout le temps d'apprendre par la suite.

[jblecanard]

J'ai suggéré OpenGL (via une couche plus haut niveau d'ailleurs) pour l'implémentation des vidéos montrées. Mais pour s'exercer lorsqu'on débute, en effet, c'est clairement une mauvaise idée.

[Bousk]

Oui je suis parfaitement conscient des difficultés auxquelles je vais faire face, c'est pour ça que je vous demande la marche à suivre car je n'en ai aucune idée.
Ca ne me dérange absolument pas de commencer par quelque chose de simple si c'est necessaire. Je viens ici en toute humilité.

Je ne veux juste pas perdre mon temps inutilement en me dispersant.

Mais si tu me dis que c'est nécessaire de toucher à des trucs plus simples avant, je vais faire comme ça.

Le fait est que ce n'est pas nécessaire, mais quasiment obligatoire.
Jusqu'à preuve du contraire, tu as appris à marcher avant de savoir courir, sauter ou faire du vélo ?
Là c'est pareil.

Le simple fait de se poser la question du "comment faire", indique que tu n'en es pas capable. Et je ne parle pas de capacités techniques, mais juste d'imaginer comment le faire, indépendamment du langage, techno ou quoi que ce soit.
Programmer c'est un métier, c'est pas par hasard. La conception de l'esprit ça se travaille, avant de savoir mettre des ; (ou pas selon le langage) c'est avant tout de la logique.

Bref, lance-toi, fais-toi les dents et échoue, de toutes façons c'est quasi couru d'avance que ça finira pas ou mal. Mais programme des trucs, sinon tu n'apprendras jamais. Les forums c'est pratique pour des besoins ponctuels, pas quand tout est à faire de A à Z.