Salut tout le monde,

j'ai eu une révélation il y a quelques jours : en fait, j'aime pas tellement que ça le c++.
Je trouve que le c++, c'est hyper compliqué et j'ai l'impression que je suis encore trop un noob pour apprécier ce langage.
Je me suis donc tourné vers le premier langage que j'ai appris, le C. Je ne m'attendais pas à ça, mais en fait, j'adore le C. Je trouve ça simple et rafraîchissant (ne plus penser qu'avec des objets, ça fait du bien).
Du coup, pour continuer le dev de jeux, j'ai regardé ce que j'avais comme alternative à la SFML que j'utilisais auparavant, et rien ne m'a vraiment plus. Je me suis donc mis à l'OpenGL.

Je suis donc un tuto pour le moment et c'est là que vient ma question. La personne du tuto utilise la GLM pour gérer les matrices qui n'est qu'en C++.
J'ai un peu fouiller pour trouver des alternatives mais tout ce que j'ai trouvé c'est la GSL (qui ne propose pas la multiplication d'un vecteur et d'une matrice ou alors le produit scalaire (J'ai peut être mal regardé. Si c'est le cas, j'en suis désolé)).

Du coup, qu'ai-je comme alternatives ? tout coder moi même ?

Opengl et SFML ne sont pas comparables.

Le sfml est une librairie multimédia qui permet de:
-Créer une fenêtre
-Gérer les boutons appuyés
-Jouer du son
-Créer des connections en réseau
-Charger des textures
-Faire du graphisme 2d ultra simple

Le OpenGL est une libraire graphique complète (3d autant que 2d), mais rien d'autre. OpenGL seul, tu ne verra même pas le résultat car elle te permet de faire du graphisme, mais pas de l'afficher.

Il existe des bindings du SFML qui te permet d'utiliser le SFML en C, ou bien tu utilises une librairies comme le SDL2 qui est une librairie multimédia qui offre des fonctionnalités comme le SFML, mais en C natif.

C'est pas ce que je demandais, je cherche juste à savoir si il y a une librairie qui gère les matrices en C (excepté celles que j'ai citée) ou si je dois tout coder moi même.

Le texte avant c'est pour introduire (j'ai tendance à trop parler, je sais, j'essaye de faire un effort pourtant)

Je pense que tu as une mauvaise façon de penser. Le C++ est une extension du C, ca ajoute tout ce qu'il manque dans le C.
Perso j'adore le C, j'ai commencé par ça et autant que possible je programme en C.
Ceci dit certaines choses sont très penibles en C, comme par exemple l'impossibilité d'avoir des types complexes (matrices et vecteur) et de faire des operations sur ceux la.
Rien que ca : MatriceB = Matrice A * MAtrice C. C'est genial en C++.

Peut etre que tu n'aimes les concepts les plus avancés en C++. Mais rien ne t'oblige a les utiliser. Le C++ c'est un vaste ensemble de mecanismes. Tu utilise ce que tu veux.

Ne pas vouloir utiliser les classes GLM pour gerer les matrice, c'est un peu comme s'attacher des boulot au pieds avant d'aller à la piscine. Tu pourras nager, mais tu vas en baver

Pour répondre directement à la question de l'OP, tu as kazmath qui a l'air d'être assez complète:
https://github.com/Kazade/kazmath

Sinon par curiosité, pourquoi SDL2 ne fait pas l'affaire par rapport à la SFML ?

@lapintade:

J'ai choisit le c pour plusieurs raisons.
Premièrement, j'ai l'impression d'être débordé de toutes les notions du C++. Plus j'en apprend sur le langage, plus j'ai l'impression que je ne connais rien. Et ça se confirme dans les forums, lorsque je vois des explications sur les header, les optimisations faites par le compilateur, les 3 milliards de mots clés qui font la même choses mais avec des petites différences qui apparemment changent tout. Le fait de me sentir noyer sous les infos, ça m’empêche d'avoir du fun en codant et je peux pas m’empêcher d'y penser. Je veux "bien" programmer, pas juste faire ce que je veux et avoir un code de qualité médiocre.
Deuxièmement, j'ai l'impression de vraiment coder des choses en C. Quand je code en C++ (et même dans d'autres langage), j'ai tendance à vouloir abstraire tout et je complexifie mon code à outrance pour rien au final. C'est probablement du à mon inexpérience mais bon, au moins, en C, aller droit au but semble plus naturel.
Enfin, le coté défis. J'ai l'impression que je devient un meilleur programmeur quand je code en C car je dois faire beaucoup plus de choses moi même ou avec une logique différente. J'ai l'impression de pouvoir être "plus fier de moi" quand je code des trucs. Ça peut paraître con, mais ça me motive à coder.
En gros, je m'amuse vachement plus en C.

@nounoursheureux:

Merci pour la librairie, je vais tester ça.

Pour ce qui est de la SDL, il y a 2 raisons dont une est extrêmement conne.
Commençons pour la raison débile. J'avais fait un projet de test avec la sdl2 et tout fonctionnait pas mal puis à un moment, je ne sais pas pourquoi (surement une mauvaise manip'), mon code ne compilait plus. J'avais une erreur de linker ("impossible d'ouvrir sdl2main.lib") et j'avais beau vérifier toute la configuration de mon projet, impossible de trouver le soucis. Même l'ouverture d'une fenêtre ne marchait plus. J'ai donc ragé, puis j'ai tout envoyé balader.
La deuxième raison, c'est que j'ai l'impression que pour faire du code vraiment optimiser, même si j'utilisais la SDL, j'aurais été obligé de passer par la case OpenGL. Bon, pour le moment, je suis très loin d'avoir besoin de performances de monstres, mais bon, mon passage au C et le fait d'avoir un nouveau projet en tête me fait me dire que c'est peut être le bon moment de me jeter à l'eau et d'apprendre cette mystérieuse technologie. Et pour le moment, je ne suis pas déçu. C'est vachement plus facile que ce que j'avais imaginé (enfin je ne suis pas vraiment très avancé, donc il vaudrait mieux que je ne m'avance pas trop).

Tu as choisis quoi pour faire ton fenêtrage si tu n'utilises pas la SDL? Le Win32 API? GLFW? GLU?

GLFW. C'est ce qu'il utilisait dans le tuto et ca a l'air vraiment cool. Ca fait juste ce qu'il faut et j'ai vu que c'est compatible Vulkan donc une fois que j'aurais maîtriser OpenGL, je pourrais au moins garder ces bases la si j'ai envie de tester.

j'ai tendance à vouloir abstraire tout et je complexifie mon code à outrance pour rien au final.

Bah voila cherches pas. Ca s'est utilisé le C++ juste pour faire du C++. Ca sert a rien.

Je code en C++ mais exactement de la façon dont tu as dis "en allant droit au but".
Je pense que tu as compris ce que je voulais dire, je vais te laisser la dans ta reflexion. tu n'aimes pas le C++ pour de fausses raison, et tu te rendras compte qu'en C tu va galerer pour faire certaines choses qui existent dans le C++ et tu les reintroduiras progressivement.

Peut-être. Mais je pense qu'il faut quand même que je teste le C plus en profondeur. Puis le C, ça a quand même des avantages (excepté la simplicité).

D'ailleurs, c'est peut-être un peu HS mais le fait que OpenGL et Vulkan soit écrit en C, c'est juste pour la portabilité ou il y a d'autres raisons ? (parce que j'ai lu que niveau vitesse d’exécution, les 2 langages se valent)

Le 28 août 2016 à 20:09:39 Dam979 a écrit :
Peut-être. Mais je pense qu'il faut quand même que je teste le C plus en profondeur. Puis le C, ça a quand même des avantages (excepté la simplicité).

D'ailleurs, c'est peut-être un peu HS mais le fait que OpenGL et Vulkan soit écrit en C, c'est juste pour la portabilité ou il y a d'autres raisons ? (parce que j'ai lu que niveau vitesse d’exécution, les 2 langages se valent)

Ben vu que le C est entierement contenu dans le C++, les avantages tu les as aussi en C++. On ne peut pas dissocier les deux.

D'ailleurs, c'est peut-être un peu HS mais le fait que OpenGL et Vulkan soit écrit en C, c'est juste pour la portabilité ou il y a d'autres raisons ? (parce que j'ai lu que niveau vitesse d’exécution, les 2 langages se valent)

Je miserais sur la propreté du langage. Le C++ est bourré de milliers de fonctionnalités complètement inutiles ou trop lentes pour une librairie graphique et ils en ajoutent presque à chaque année.

Le 28 août 2016 à 22:50:57 romtrep a écrit :

D'ailleurs, c'est peut-être un peu HS mais le fait que OpenGL et Vulkan soit écrit en C, c'est juste pour la portabilité ou il y a d'autres raisons ? (parce que j'ai lu que niveau vitesse d’exécution, les 2 langages se valent)

Je miserais sur la propreté du langage. Le C++ est bourré de milliers de fonctionnalités complètement inutiles ou trop lentes pour une librairie graphique et ils en ajoutent presque à chaque année.

Qu'est ce qu'il est imperatif en C++ et qui plomberait les performance d'une lib graphique?
Je demande parceque, moi, je l'ecrirais en C++. Mais, bon, je ne dois pas etre tres fort en performance...

Le 29 août 2016 à 04:05:41 godrik a écrit :

Le 28 août 2016 à 22:50:57 romtrep a écrit :

D'ailleurs, c'est peut-être un peu HS mais le fait que OpenGL et Vulkan soit écrit en C, c'est juste pour la portabilité ou il y a d'autres raisons ? (parce que j'ai lu que niveau vitesse d’exécution, les 2 langages se valent)

Je miserais sur la propreté du langage. Le C++ est bourré de milliers de fonctionnalités complètement inutiles ou trop lentes pour une librairie graphique et ils en ajoutent presque à chaque année.

Qu'est ce qu'il est imperatif en C++ et qui plomberait les performance d'une lib graphique?
Je demande parceque, moi, je l'ecrirais en C++. Mais, bon, je ne dois pas etre tres fort en performance...

Dit moi, qu'est-ce que tu utiliserais du C++ que le C n'est pas capable de faire?

Je ne suis pas expert en la matière, mais une petite recherche Google vient confirmer ce que je pensais.
Voilà une réponse qui vient de stack overflow:

-Le point d'une API de bas niveau est de tout rendre aussi minime et portable que possible. En lui donnant une architecture orientée objet, ce n'est pas idéal pour les raisons suivantes:

-Le polymorphisme ajoute des coûts inutiles d'appel de fonction.
-La POO vous oblige à utiliser une certaine convention d'appel relativement difficile, ce qui réduit la portabilité.
-Vous ne pouvez pas envelopper une architecture orientée objet dans une architecture procédurale, mais vous pouvez faire l'inverse; donc, il est logique de faire des choses aussi flexible que possible. Il est trivial d'écrire un wrapper orienté objet autour OpenGL si vous voulez.
-Enfin, vous devriez vraiment remettre en question ce que vous avez appris à propos de POO. Malgré ce que votre collège ou une université peut vous dire, OOP est pas une panacée de la conception du programme.

L'orientation objet est utile dans certains cas, mais vous devriez apprendre quand il est utile, et quand il est pas, et en aucun cas vous ne devez croire que tout ce qui est pas OOP est "mauvais style".

Le 29 août 2016 à 13:07:46 romtrep a écrit :

Le 29 août 2016 à 04:05:41 godrik a écrit :

Le 28 août 2016 à 22:50:57 romtrep a écrit :

D'ailleurs, c'est peut-être un peu HS mais le fait que OpenGL et Vulkan soit écrit en C, c'est juste pour la portabilité ou il y a d'autres raisons ? (parce que j'ai lu que niveau vitesse d’exécution, les 2 langages se valent)

Je miserais sur la propreté du langage. Le C++ est bourré de milliers de fonctionnalités complètement inutiles ou trop lentes pour une librairie graphique et ils en ajoutent presque à chaque année.

Qu'est ce qu'il est imperatif en C++ et qui plomberait les performance d'une lib graphique?
Je demande parceque, moi, je l'ecrirais en C++. Mais, bon, je ne dois pas etre tres fort en performance...

Dit moi, qu'est-ce que tu utiliserais du C++ que le C n'est pas capable de faire?

Capable, a la fin les deux generent de l'assembleur. La vrai question est de productivite du programmeur et de performance obtenu. Quelques exemple:

-Avec les templates, tu peux facilement facilement parametrer l'algebre utilise pour tes operations matricielles et donc facilement reutiliser du code et faire de l'arithmetique double precision, simple precision, voir half-precision. Tu peux aussi faire de l'arithmetique entiere pour porter vers des machines qui n'ont pas de support de support de nombre flottant et faire de la precision fixe. J'ai cru comprendre que ca aide a faire des quaternions aussi, mais perso, je n'ai jamais fait.

-tu peux aussi faire de la redifinition d'operateur ce qui permet d'avoir un code plus simple a lire et encore une fois qui ne depend pas de ton type de matrices. ce qui permet de faciliter la portabilite de code entre des graphiques vectoriel 2D et 3D.

-tu peux aussi utiliser les systemes de constructeur et de conversion de type pour que tes operateur ne retourne pas une matrice, mais un arbre d'evaluation qui est automatiquement caste vers une matrice quand tu en as besoin. Ca permet d'avoir un code qui lit: mat<float> a = b+c*d*(a-b*c); et qui construuit explicitementl'arbre d'evaluation et laisse le compilateur reordonnre les operations dans l'ordre qu'il veut et qui permet de reduire le nombre d'appel de fonction et la pression registre tout en ayant un code simple.

La, a chaud, c'est tout. Mais ca m'a l'air deja pas mal...