Quelle est ta carte graphique ? Tu arrive à faire tourner des jeux gourmands ?
Tu as quelle carte graphique?
EDIT: Oups j’ai pas vu le post de 4ian…
J’arrive à faire tourner “Liquid.gdg” facilement.
Comment je fais pour connaître ma carte graphique depuis linux ?
C’est là même que sur Windows 
Mais Ubuntu trouve automatiquement les pilotes qui faut dans cette appli :
Donc c’est un bug de GD.
Non.
Mais le système n’a pas détecté de mise à jour pilote, ce qui devrait être automatique, non ? J’ai bien fait ce que tu m’as dit en tout cas.
Non, ton système n’a pas trouvé de pilotes pour ta carte graphique. Sinon, c’est plutôt un bug de SFML/OpenGL.
Non, quelle est ta carte graphique, si c’est une intel, il n’y a pas de pilotes en plus a installer, elle est pris en charge directement par les pilotes intel.
Les ATI sont généralement prises en charge mieux que les Nvidia sur les pilotes libres, mais tu peux installer le pilote propriétaire.
Et les Nvidia, elles sont aussi prise sur pilote libre, mais si tu veux utiliser Unity, ou jouer a un jeu, il faut installer les pilotes propriétaire. (qui fonctionnent parfaitement…)
C’est une intel, donc je ne vois pas pourquoi ça ne marche pas… 
Je ne sais pas.
Moi je sais que sur un PC ayant une Intel et une ATI (un portable), j’avais quelques problèmes d’accélération 3D sur la Intel, et j’arrivais pas à lui dire d’utiliser la ATI… 
Et quel module d’accélération 3D tu me conseillerais dans ce cas ? Je devrais peut-être mettre a jour la bibliothèque de rendu openGL ?
C’était un PC portable.
Et GD je crois pas qu’il ai besoin de l’accélération 3D puisque c’est de la 2D qu’il fait…
Voilà déjà moi je sais que c’est foutu, je ne pourrais jamais plus créer de jeu avec GD… 
Dites-moi que ça peut être corrigé allez quoi…
Et pourquoi ça, si c’est un bug de GD
Chez moi GD est pas assez stable pour être utilisé, et la dernière fois que je l’ai utilisé fréquemment c’était en Début de Juillet 2010, et depuis, pas de version assez stable pour Linux donc j’utilise pas. (sauf de temps en temps sur Windows…la dernière fois c’était env 2H il y a 3 ou 4mois…)
Actuellement, ça deviens correct, mais pas encore stable.
@4ian: Tu devrais vraiment compiler GD sur 32 bits pour les Ubuntu 32bits, et sur 64bits pour les Ubuntu 64bits, et utiliser les bibliothèques installées sur le PC de l’utilisateur, ça t’éviterais sûrement des bugs 
Je peux par exemple ouvrir un jeu SFML sur mon PC en ayant un exécutable Unique, et sans bugs, quand je le compile moi même (avec Code::Blocks), mais mon niveau en C++ ne me permet pas de faire un jeu, c’est juste pour dire que c’est possible, fonctionnel, et beaucoup plus simple que si j’avais pleins d’incompatibilités, et que j’utilisais des bibliothèques différentes de celles des dépôts… (même pas adaptée à mon processeur)
Si tu crée un paquet avec des dépendances, tu pourrais être sur que ça marche, et envoyer GD qui pèserais beaucoup moins lourd aussi (GD sans envoyer les .so ça allège tout de suite )
D’ailleurs, pour lancer GD, je suis même pas sur que l’on aurait besoin du “Start Game Develop.sh” mais juste de l’exécutable en question.
Oui c’est vrai que ce serait bien d’utiliser les paquets du système, comme ça il n’y aurait plus aucun bug.
C’est de la magie ? J’utilise les bibliothèques du système et abracadabra plus de bug ?
Non sérieusmeent, je vois pas pourquoi utiliser les paquets du système serait mieux.
Au contraire, j’utilise des versions plus récentes, donc normalement moins buggées, et que j’ai compilé sur le même système que sur lesquelles elle tourne. Il n’y a pas avantage à passer du temps à adapter mon code pour utiliser les vieilles bibliothèques officielles.
Je passe déjà beaucoup de temps pour une version Ubuntu, j’ai pas vraiment le temps de recompiler pour Ubuntu 64 bits. Sur Windows tout marche très bien en 32 bits, je vois pas pourquoi ça coincerait pour Ubuntu.
Si ça crashait aléatoirement, peut être que ça serait envisageable, mais je crois pas que c’est le cas. Les gros problèmes que tu rencontre, genre les barres de défilement ou le déplacement des objets dans l’éditeur de scène ou les musiques qui ne se jouent pas, je les ai aussi. Une fois que se sera corrigé, GD serait déjà beaucoup plus utilisable.
Je pense que tu te trompe sur deux choses :
-Comme dit plus haut, c’est pas parce que j’utilise ou que tu utilise pas les bibliothèques des dépôts que c’est moins stable. Faut pas croire qu’il y a de la magie là dessous : Les bibliothèques du dépot, c’est juste les sources des bibliothèques compilés. Et bien moi avec Game Develop, c’est pareil, c’est juste des sources compilés. Et en plus, c’est des sources plus récentes.
-Game Develop n’est pas un simple jeu SFML : La complexité de GD entraine forcément la création de petites incompatibilité sur Linux que je n’ai pas pu détecter avant, parce que je développe et teste sur Windows.
Je suis tout à fait d’accord qu’utiliser les bibliothèques officielles allègerait l’exécutable, permettrait de se passer de scripts, et serait plus dans l’esprit de Linux. Mais je suis pas du tout d’accord quand tu dis que ça réduirait les incompatibilités et les bugs : Non, il n’y a pas de différence entre bibliothèque officielle et bibliothèque que je distribue avec GD, à part que mes bibliothèques sont plus récentes.
Tout ce qui est affiché par GD utilise OpenGL, et est donc considéré comme de la 3D. Autrement dit, tout ce qui est affiché à l’écran par GD est acceléré par la carte graphique, donc si les pilotes de celle ci posent problèmes, alors non GD va pas marcher correctement.
Tu utilisais quoi avant pour faire tourner GD ?
Il est passé de Windows a Ubuntu.
Tout allait bien quand j’étais sous Windows… Donc c’est pas un problème de matériel.
EDIT : Il m’a fallu aussi installer openal alors que je suis sous Ubuntu 32 bits.
Lorsque l’on ferme la fenêtre d’édition de texte, le texte précédent s’ajoute au nouveau texte.