GuieA_7 a écrit 704 commentaires

Tu oublies de dire que les linuxiens sont des gros barbus repoussants qui ne copulent qu'avec leur main, et que par conséquent, niveau enfants.... (je te taquine hein, en fait je trouve ton commentaire très pertinent :).

Je trouvais ta remarque intérresante, alors je suis allé sur le site de scummvm (que je connaissais) pour creuser la question. Voici ce que j'ai trouvé dans la FAQ:

Can I use ScummVM to make new games?

While it is theoretically possible to write a new game that uses ScummVM it is not advisable. ScummVM has many hacks to support older games and no tools geared towards creating content usable by ScummVM. Potential game authors are encouraged to look at open source technologies such as libSDL for a cross platform DirectX like library, and the Lua and Python scripting languages for game logic.

L'idée d'utiliser scumm était séduisante, mais si même les codeurs de scummvm le déconseillent...

Je ne me suis pas fait bien comprendre ; je m'explique donc.
J'ai tilté lorsque j'ai vu que tu utilisais le #pragma pack(). Je me suis dit que tu devais faire un truc du style "write(mysocket, &mystruct, sizeof(mystruct));", ce qui est mal, car pas portable (au sens ou des machines différentes peuvent produire des trames différentes, donc ne pas se comprendre), en espérant produire une trame de la taille minimum.
Pourtant tu as l'air de connaitre htonl() et c'est très bien ; donc peut être utilises tu le #pragma pack() pour une autre raison. Mais j'espère qu'elle est bonne, puisque ton code risque d'être plus lent comme je te l'ai dit.

Donc non je ne dit pas que garder l'alignement rend les trames portables, je dit que comme tu vas serialiser les membres de ta structure un a un dans un gros buffer, tu vas pouvoir aligner les données comme bon te semble : l'alignement dans tes trames n'a rien à voir avec celui de ta structure en mémoire (donc ce que modifie pack()).

Bon code ! :)

Oui le module struct est bien, xdrlib est pas mal non plus.

En revanche une petite remarque. Je ne sais pas pour quelle raison tu utilises une structure avec des #pragmas pack(), mais si c'est pour écrire toute ta structure d'un coup dans ta socket sans perte de place, tu fais probablement une erreur. En effet :
- ton code sera lent quand il manipulera ta structure autrement que pour l'envoyer sur le réseau (des manipulations supplémentaires à cause de l'alignement pas 'naturel'). Cependant rien n'empêche de mettre les membres de ta structure dans un ordre intelligent (char ensemble par exemple).
- tes trames réseau ne sont pas portables : en écrivant d'un coup toute ta structure, le comportement variera suivant les machines(32/64 bits, big endian/little endian...). Il faut faire une fonction qui va sérialiser ta structure dans un buffer, avec des fonctions comme htonl()/htons(), puis écrire ce buffer dans ta socket.

Désolé du dérangement si tu savais tout ça!! :)

Je pense que comme pas mal de monde ici, je trouve ce langage vraiment prometteur, mais pas question de faire quelque chose avec tant que ça ne sera pas entièrement libre.

Sinon j'espère que le langage ne tombera pas dans un certain nombre d'écueils (en plus de la non-'libricité' - ça existe ça??!) : non standardisation/normalisation, pas de librairie standard, etc....
Parmi les écueils possibles, celui qui me semble être assez récurrent à l'INRIA, c'est de faire un langage avec des idées très puissantes (donc potentiellement très bon), mais qui néglige tout le reste qui n'est pas très conceptuellement intéressant, mais qui est pourtant indispensable dans la vraie vie (d'un codeur :).
Je m'explique : j'ai découvert OcamL dans mon école d'ingé, dans le cadre de la programmation fonctionnelle, et ça m'a bien plu. Plus tard sur LinuxFR j'ai appris qu'il était multi-paradigmique, qu'il pouvait être interprété, compilé ou dans une VM. Il montait encore dans mon estime. Pourtant plus tard, alors que j'errais sur le Net à la recherche d'un éventuel langage pour de futurs projets, je me suis aperçu qu'il avait l'air de manquer des choses assez essentielles (à mon sens) dans le langage :
- j'aime les systèmes de plugins, mais d'après la doc, on ne peut charger de module OcamL qu'en mode VM. Du coup c'est assez décevant, je dois me passer du mode compilé (le coup des 3 modes d'exécution est donc un peu faux). Peut-être qu'on peut charger des modules en C ??(mais alors ce n'est plus un programme en OcamL à proprement parler)
- je m'intéresse aux système multi-tâches, mais là encore déception : il y a des lightweight threads, c'est très bien, mais nulle trace de vrais threads qui permettent d'utiliser plusieurs processeur à la fois.
Je précise que je ne suis pas un spécialiste OcamL, donc j'ai très bien pu louper quelque chose (n'hésitez pas à me le signaler). Mais si je ne me trompe pas sur les 2 points plus haut, c'est assez gênant. Parce que s'il n'y avait pas de parser XML ou de bibliothèque d'envoi de mails par exemple, et ben il suffirait de les coder (du moment où il y a la gestion des fichiers ou des sockets pour mes exemples, ou qu'on peut binder avec du C), mais dans les cas que j'ai cités, il faudrait toucher au langage lui même, ce qui n'est plus du même niveau !!
J'ai vu les mêmes manques dans SmartEiffel (coder aussi par l'INRIA). Attention, les gars de l'INRIA sont certainement très compétants et je n'ai pas l'intention de casser du logiciel libre (au contraire). Mais d'un autre côté, on voit souvent des gens vanter leur outil de prédilection (moi le premier), et parfois se plaindre qu'il n'est pas assez utilisé alors qu'il est bien mieux que tout le reste sur tous les plans. Alors que ce n'est pas vrai : en C je vais peux être pas avoir des super objet dynamique sans Virtual Table, avec analyse du flot d'exécution le tout avec des paradigme de haut niveau etc..., mais si je veux faire des plugins, des threads, et ben je pourrais, je ne serais pas bloquer par le langage. Le seul truc qu'on ne pourrait pas techniquement faire sans VM serait une exécution 'sandboxée'. Alors évidemment on peut faire des tas de programmes très bien sans plugins ni threads, mais c'est dommage que ces langages modernes ne permettent pas ce que peuvent des langages vieillissants.
D'ailleurs même si ça me fait un peu mal de le dire, en parcourant rapidement la doc de Mono, je n'ai pas vu de manque si cruel. Ne vous méprenez pas, Mono n'est pas (encore?) installé sur ma machine, je ne fais pas de prosélytisme.

Voilà, en espérant que mes remarques soient constructives.

Je ne connais pas bien DirectX, alors ça c'est des vraies questions :
- il y a de la physique dans DirectX?? parce que s'il y en a, ça doit pas être aussi bien que ODE vu que des devs pro utilisent ODE avec DirectX.
- il y a un langage de script puissant dans DirectX?? parce que là encore Lua est utilisé par des pros avec DirectX.

Sinon, et c'est là où les LL sont beaux, c'est que si Ogre suffit pas, et bien il peut être intégré librement dans un moteur de jeu plus haut niveau encore (avec réseau, son etc...). C'est ce qui est fait avec Axiom par exemple :
http://realmforge.com/
(bon j'ai pas testé, mais après recherche rapide il semble que ça marche aussi avec Mono)

Ah mais on est bien d'accord sur les 2 points que tu soulèves !!

Je disais qu'un framework très portable ne changeait rien à l'affaire (vu que ça existe déjà), vu que les éditeurs ne font pas l'effort de fournir un binaire ; mais tu fais bien de préciser ma pensée (il faut fournir du support). D'un autre côté si Id software se le permet, même si ce n'est pas forcément un gain d'argent phénoménal pour eux, je doute que ça représente un gouffre financier. Donc pour un jeu qui utilise un moteur d'Id c'est vraiment pas compliqué. C'est pour ça que je parle de mentalité : il est bien connu que Carmack aime bien le libre ; mais sa boite lui laisserait pas jeter l'argent par les fenêtres.

Pour le 2ème point, je voulais juste dire que ça m'énerve les 'compatible PC' qui signifie en fait 'compatible windows', ainsi que les 'compatible Linux' pour 'compatible Linux/x86/libcN'. Après qu'une boite ne fasse pas de version NetBSD/Sparc, je le comprend évidemment, mais si c'était du libre (le code source j'entend), un courageux pourrait s'y coller.

Pour le wrapping de D3D, c'est pas moi qui le dit, c'est Carmack ; ce n'est pas Dieu le père mais je lui fait confiance. Mais si je devais faire la comparaison avec autre chose, je prendrais GTK et Qt. Ce sont là 2 excellentes bibliothèques, mais si coder une GUI avec GTK en C est quand même très cochon (alors que Qt est du C++ bien foutu), il faut reconnaître que GTK est wrappé dans plus de langage que Qt, et que ces wraps sont bien.

Pour les vecteurs/matrices/quaternions, ce n'est pas par hasard qu'on trouve pleins d'articles sur comment en faire, et ce même sur des sites parlant de dev de jeux sous win, c'est parce qu'on finit toujours par se les frapper. Et ça pour la bonne raison qu'on en a besoin dès qu'on veut faire des collisions 3D par exemple, ceux de D3D/OGL ne vont pas dans ce cas : ils sont fait pour l'affichage, pas pour récupérer les coordonnées résultats et ainsi faire les tests de collisions.

Mais au final on est d'accord : il faut un framework très puissant et ne pas partir de zéro. Mais ça n'a rien a voir avec OpenGL ou D3D, puisque les gars qui font ce framework vont se charger de les wrapper (dans la mesure où on peut faire les mêmes choses avec dans l'absolu). Pour ma part, même s'il n'est pas du tout parfait, j'aime beaucoup OGRE:
http://www.ogre3d.org/

PS : oui le moteur de loulou n'est pas utlisable tel quel sous Linux, mais ce n'est qu'un didacticiel ; je n'allais pas t'envoyer dans les sources de Ogre, qui lui aussi wrappe OGL et D3D entre autres.

Pas trop d'accord sur le coup ; je m'explique.

John Carmack, qui reste la référence pour moi, n'a abandonné le C pur que relativement récemment il me semble ; donc je doute qu'il dise que c'est inutilisable. Au contraire, pour lui Direct3D a une API beaucoup moins bien qu'OpenGL lorsque l'on doit la wrapper. Parce que tout ceux qui ont déjà fait du jeu vidéo savent que Direct3D/DirectX, aussi Orienté Objet soit-il, doit quand même être wrappé dans des objets de haut niveau (mesh, texture, squelette...). J'en profite pour donner un lien d'un didactiel pour faire un moteur 3D utilisant à l'envie OpenGL ou Direct3D:
http://loulou.developpez.com/tutoriels/moteur3d/

Sinon je suis d'accord avec toi, le C n'est pas adapté pour faire du jeu vidéo, le C++ est déjà bien mieux. En revanche la force du C est de pouvoir être 'bindé' facilement dans les autres langages. C'est flagrant, tous les langages du monde ont un binding OpenGL (et comme je l'ai dit wrapper OGL en C++ c'est pas plus difficile que wrapper D3D).

De toutes les façons un mec qui veut se lancer dans un jeu depuis zéro il ne choisit pas la facilité, même si VC++ propose de base un projet DirectX. Il existe tout un tas de moteurs 3D qui proposent des API de haut niveau. Parce qu'autant programmer des Octrees/BSPTree/etc.. c'est super marrant, autant wrapper les fonctions OGL/DX/SDL/etc, faire une nième bibliothèque de maths, faire des gestionnaires de ressources, etc..., et ben c'est déjà beaucoup plus rébarbatif, et DirectX n'y pourra pas grand chose.

Le plus gros problème pour avoir des jeux pros sous Linux, c'est une histoire de mentalité avant tout, c'est pas technique. Parce que des jeux qui ont utilisé le moteur de Quake 3 y en a eu quelques uns (No one lives forever...), et leur code dans l'absolu devait passer sans gros problème sous Linux ; pourtant on en a jamais vu la couleur. Et c'est parce que les éditeurs n'en ont rien a fiche !!! Même faire un build pour Linux/x86 ça les fait chier pour le peu que ça leur rapporterait. Donc une super-API3D-méga-portable-de-la-mort n'y changerait rien du tout.

Et puis n'oublions que Linux c'est pas que sur x86, et faire du code qui passe sous tout un tas d'archi, ça se fait pas tout seul (enfin surtout c'est avant tout un question de volonté, parce que des programmes java avec des 'C:\Program Files' ça existe !). Alors GNU/Linux c'est du Logiciel Libre, ça ne marche bien qu'avec d'autres logiciels libres, et c'est très bien comme ça à mon avis. Quelqu'un que ca gène pas de jouer à un jeu proprio, ca ne doit pas le géner beaucoup de garder un OS proprio.

GuieA_7, qui rêve d'avoir des jeux pros avec un code source libre ! :)

Tu sous-entends que Solaris est codé par la division hardware de Sun?? (c'est une vraie question)

Merci, ça passe nickel avec le '-nomusic -nosound'.
Je confirme donc : je suis très fan du style graphique, même si les arrières plans sont pour l'instant assez pauvres. Je présume, vu le niveau du reste, que vous allez les améliorer au fur et à mesure (parce l'air de rien c'est du boulot :). Avec du scrolling différentiel ça pourrait donner un truc bien sympa.

Du bon travail donc !

PS : je me demande si c'est pas trop dur dès le début pour les plus jeune (moi je m'en sort péniblement! :).

Voilà pour mes remarques (je l'espère) constructives:
- Chez moi la fenêtre se ferme immédiatement, avec un message "Unable to open audio!" dans le terminal. Le son marche bien a priori sur ma machine (elle est récente alors je ne saurais pas dire comment la SDL se comporte dessus), mais si le son n'est pas primordiale pour le jeu, j'aurais accepté de jouer même sans le son ! :) D'ailleurs je remarque que beaucoup de jeux plantent sous linux quand le son ne marche pas, ce qui est d'autant plus dommage que le son est un point faible sous linux à ma grande peine.
- Un petit README aurait été bien, au moins pour connaître les dépendances (comme un imbécile j'ai pas fait attention au SDL_*.dll, mais bon...). Enfin je présume qu'à terme il y aura un configure/scons/autre.

Tant pis j'aurais bien aimé tester ce petit jeu ; les graphismes avec un style SVG me plaisaient bien sur les screenshots.

Bon courage pour la suite.

J'espère que ces GROSSES boites ne vont pas se contenter de dire que "bouh the Gimp c'est de la merde !" et qu'elles vont aider d'une manière ou d'une autre ce projet (que j'adore) et qui a un grand besoin de développeurs (encore que vu l'activité ces derniers mois ça va peut être mieux).
Parce qu'à ce moment là, tant qu'on y est, Blender c'est moins bien que 3DS alors on peut aussi dire que c'est tout pourri une fois qu'on a plus que 3 cubes qui se courent après.

Evidement le plus simple/propre c'est d'avoir un modem ethernet, qui va marcher en DHCP ou PPP, là ça marche très bien en configurant dans le Control Center de Mandriva (suffit de savoir si c'est PPP ou DHCP, sinon on a des surprises !).
Mais bon la tu dois te coltiner ton modem USB tout caca, je sais ce que c'est. D'ailleurs à une époque les speedtouch 'raie manta' fonctionnaient pas trop mal avec les Mandrake ; mais je ne sais pas du tout pour ton modèle de modem.

Pour en revenir à tes moutons, le conseil du mec est à mon avis tout à fait viable, pour l'avoir fait il y a quelques années. Il te faut un 2ème (petit) PC sous win avec une carte ethernet, sur lequel tu installes ton modem USB. Ce PC va te servir de passerelle (gateway en anglais). Tu connectes tes 2 PC en réseau local ethernet (c'est le plus dur). Ensuite il faut configurer le PC avec win pour qu'il se comporte comme une passerelle ; win peut être configuré pour partager une connexion, mais quand on le faisait avec mes potes (il y a longtemps) on utilisaient tout simplement des logiciels comme wingate ou winroute (plutôt le 2ème d'ailleurs). Il ne reste plus qu'à aller, sur l'autre PC, dans ton Control Center pour lui dire de se connecter via la passerelle (en indiquant l'adresse IP dans le réseau local du PC sous win).

Donc rien de bien sorcier.

En espérant avoir été utile :)

Heu, il me semble que tu te contredis (mais j'ai pu mal comprendre) : tu dis "tous dans le même core" puis "un thread dans le core 1 et un autre thread dans le core 2".
Je reste donc sur mon impression de 'tous dans le même core', donc un problème potentiel de perfs avec du multithread (ce qui a entraîné les choix de la branche 5 de FreeBSD).

Si j'ai bien tout compris (c'est pas gagné :), avec DFBSD tous les threads d'un même processus s'exécutent sur le même CPU. Alors que même la machine de monsieur Tout-le-monde a tendance à devenir multicore/multiproc, n'est ce pas "petit bras" comme façon de faire (je ne dis pas ça méchamment, je suis sûr que les gars de DFBSD sont très compétents) ?
En même temps je ne connais pas le nombre de grosses applis du libre qui sont lourdement multitreadées (du genre des threads à 100 % du CPU pendant plusieurs secondes) et qui seraient donc pénalisées...

Merci beaucoup pour ta réponse bien détaillée (à un moment je me suis demandé si tu ne disais pas justement le contraire, c'est à dire que Blender était beaucoup moins bien).

Pourrais-tu préciser ta réflexion sur K3D s'il te plaît ??

Moi j'aimerais bien pouvoir mettre les fenêtres en mosaïque. C'est pas forcement utile tous les jours mais ça peut rendre service. Et puis ça fait mal au derrière de se dire que windows 3.1 savait déjà le faire :) ....

Autant je entièrement d'accord que la diversité du logciel libre est une de ses grandes forces. Je pense qu'il est sain d'avoir plusieurs environnements tel que Gnome et KDE (entre autres) avec des concepts/objectifs/langages/... différents.
Mais bon d'un autre côté la communauté n'est pas infinie, sa force de travail non plus ; aussi il vaut pour elle qu'elle ne s'éparpille pas trop. Comme dit plus haut, on a la chance d'avoir 2 moteurs HTML libres de qualité, c'est déjà trés bien. D'autant qu'une des choses que j'apprécie le plus avec le libre est la possibilité d'utiliser librement (dans la mesure des licences) le travail de la communauté.

Pour parler de ce que je connais un peu : les moteurs 3D. On en a plusieurs libres de bonne facture, mais au final il ne sont quasiment pas utilisés ! C'est dommage, un moteur 3D n'est pas une fin en soi. Quand je regarde les screenshots sur le site de Ogre, tous les jeux ayant l'air un tant soit peu abouti sont des jeux proprios (pro ou pas). Alors un moteur libre de plus pourquoi pas (qui suis-je pour juger?), mais bon avoir plus de moteurs que de jeux les exploitant, c'est un peu dommage je trouve.

Ah oui une dernière chose : un certain nombre de projets libres d'envergurs ont commencé avec des objectifs modestes (à commencer par Linux).

Bonne soirée à tous.

Ce 'petit' didacticiel est très sympathique ! J'ai bien aimé la façon dont les screenshots sont agrandies.

Ma petite contribution : en dessous de la 1ère image (celle de l'appli finale) tu as écrit 'sandalone' au lieu de 'standalone'.

Et toi tu as oublié de lire le mot 'libre' dans sa phrase ...

Le problème du Cell Shading c'est que ça a été très à la mode (le buzz est bien retombé depuis), et donc utilisé beaucoup à mauvais escient. Mais utilisé intelligemment et avec gout, ça peut le faire (Jet Set Radio, Zelda Wind Waker ...). Mais bon après les gouts et les couleurs.... :)
Mais un avantage du cell shading (pour les jeux libres), c'est que ça demande, je pense, moins de boulot de faire un perso en 3D avec toutes ses animations, plutôt qu'un perso en 2D avec toutes les animations qui vont avec : ça demande un nombre de sprites vraiment conséquent.

Premièrement, une remarque gentille : je pense avoir lu la plupart de tes post/journaux qui parlaient de Lisaac, et à chaque fois ça m'a donné envie. Mais pas question d'y toucher tant que ca sera pas libre et stable.

- Il faut voir que Quake 3 est sorti en 1999, est a du être commencé à coder au moins 2 ans avant : ça fait donc un bout de temps, et le paysage des langages était différent ; même le C++ n'était pas trés bien géré par les compilos (au niveau perf si on fait des truc un peu sophistiqué en tout cas) . Donc j'ose même pas imaginer SmartEiffel à cette époque.

- Je dois écrire un journal depuis quelques temps à ce sujet notamment mais j'ai pas eu trop le temps, donc j'en lache un morceau ici : il me semble que le smarteiffel ne gère ni les threads ni le chargement dynamique. Alors il supprime peut-être la virtual table mais je trouve que ça fait quand même 2 gros manques très cruels (au passage Quake 3 est threadé donc .... ).

- Carmack est quand même un très grand codeur, alors ne t'inquiète pas trop pour lui, il sait ce qu'il fait. D'autant qu'il est curieux et il sait que d'autre langages existent (cf java sur portables). C'est pas vraiment un guignol en technique, fait lui confiance.

Content de voir qu'on est d'accord.
Je voulais juste rajouter que moi aussi je suis fan de belle 3D (et de graphisme en général), et quand je vois un joli jeu, c'est pas parce qu'il est proprio que je vais le trouver moche ! :) Je suis entièrement d'accord, ça permet de se plonger plus facilement dans l'univers quand c'est visuellement crédible.

- Je serait ravi le jour où je pourrais aller acheter un jeu dans une boutique, et que le dvd contiendra des données proprio et le code source sous licence libre (ça serait bien aussi que l'éditeur relache les données lorsque le jeu n'est plus exploité). Ce jour là je recommencerait à acheter des jeux ; en attendant ça restera 'petits' jeux libres entre midi et deux, et des jeux console de temps en temps chez les potes.

- Tant que ce sera des amateurs (dans le bon sens) qui feront des jeux libres (contrairement au cas évoqué ci dessus), je pense qu'il va falloir faire comme souvent avec le libre : emprunter des voies différentes mais tout aussi intéressantes. Comme je le disais dans mon post précédent, le côté jetable ne me plait pas ; je trouve que ça ne correspond pas à la philosophie du libre, qui s'inscrit plutôt dans le durable. Pourquoi des bénévoles iraient se faire suer pendant des mois pour créer des arts qui seraient considérés comme moches 6 mois aprés ?? (les pros eux sont payés pour ça, ensuite ils passent au jeu suivant etc... : ils appellent ça le progrés :) C'est triste mais bon c'est comme ça. C'est pour ça que je parle de jeux qui ne se démoderaient pas ; par exemple je ne sais pas si tu connais Saga Frontier 2 ou Legend of Mana. Avec leurs graphismes 2D tout mignons (on diraient des peintures), ils restent aussi attrayants des années après, et ne vieilliront que très peu, justement parce qu'ils n'essayent pas d'être réalistes.