You are not logged in.
Pages: 1
Salut ,
Je suis en train de suivre l'avancement de ton moteur depuis presque 6 mois ,mais j'arrive pas à comprendre son interet ou la nouveauté qu'il apporte par rapport aux autres moteurs open source ??!!!!C'est vraiment inutile de répéter la meme tache à moins que c'est pour s'entrainer.
Il y 'a pleins de moteurs open source de qualité et qui sont développées depuis des années par des professionels , si tu veux contribuer , il faut chercher une idée originale (un moteur physique par exemple).
Je ne te dis pas ça pour te décourager mais c'est juste mon point de vue .
Je te féliçite comme meme pour le travail que tu as accompli jusqu'à maintenant.
@+
D-POWER
ps:j'attends avec impatience les démos de ton SCEngine.
Offline
Salut,
Il me semble qu'il existe actuellement très peu de moteurs 3D OpenSource en C ; à part le Quake3 Engine qui commence à vieillir, et peut-être Raydium. Donc avant tout, il apporte un moteur OpenSource en C, chose assez rare donc. De plus en effet, Yno l'a débuté du moins en partie dans une optique d'apprentissage et de perfectionnement.
Pour ce qui est des moteurs physiques, il y en a aussi : ODE ou Bullet par exemple. Qui plus est, ODE est utilisables en C.
Offline
Ban a déjà très bien répondu, et effectivement pour l'option du moteur physique je ne vois pas en quoi ça serait super génial, non seulement il existe déjà des moteurs physique open source, mais également des addons comme OgreNewt ou autres, donc euh, j'vois pas trop la finalité de l'argument là.
Quand au professionnalisme des développeurs des autres moteurs 3D, j'en doute, il y a peut-être quelques développeurs « éveillés » sur Ogre, mais c'est tout. Ce sont des gens qui s'amusent tout comme moi, rien de plus.
Offline
Bonjour Yno,
Me revoilà après une longue absence (du forum) qui m'a permis d'avancer dans mon projet personnel. J'ai suivi le tiens de près néanmoins car le SCE va très probablement m'être utile.
Bref merci pour le travail effectué.
Sinon, j'ai une petite remarque à faire concernant le moteur 3D (ou plutôt sa compilation sous Windows)...
il est assez aisé en réalité de compiler le SCE sous ms visual c++ express mais, lorsqu'on passe sous mingw, ça devient rapidement le parcours du combattant. La raison? la bibliothèque DevIL !!
Je m'explique ... pour des raisons qui m'échappent, la page de téléchargement openil sur sourceforge ne met pas à disposition des programmeurs de binaires précompilés pour mingw alors que c'est cas pour vcpp. Il faut donc compiler DevIL avant de compiler le moteur 3D.
Jusque là, ça passe encore ... mais c'était sans compter les dépendances de DevIL (Libpng, Zlib, Libjpeg, Libtiff, Libmng, Little CMS, JasPer) dont il faut posséder les bibliothèques static pour mingw.
Personnellement, je n'ai pas le temps de me lancer dans toutes ces compilations et je pense que les personnes qui souhaiteraient utiliser le SCE avec mingw seront vite découragées. Qui ne le serait pas ?,Voilà, c'était juste une petite remarque concernant l'accessibilité du moteur 3D
Offline
Salut Anian,
Ça fait plaisir de te revoir :]
Hum je vois le problème... le must serait évidemment de proposer DevIL pour mingw, et pour cela pourquoi pas d'aller gentiment demander aux dev DevIL de faire le boulot. Mais bon, je suppose qu'ils ne l'ont pas fait pour les mêmes raisons que toi. Éventuellement je trouverai le courage (chez moi ou chez quelqu'un d'autre) pour le faire moi-même, mais pour l'instant le moteur est encore assez jeune côté fonctionnalités/utilité, sa présentation et sa diffusion ne sont donc pas des priorités. En effet il a encore beaucoup de lacunes sur ces points comme tu as pu le constater. Même le Makefile Linux manque de robustesse. Idem pour la documentation/les tutoriels, ils sont pour l'instant pauvres/inexistants.
Ce sont des points sur lesquels je me pencherai lorsque le moteur sera digne d'être utilisé, je pense qu'il est inutile de s'attarder sur une belle couverture pour un livre qui n'en vaut pas la peine. Cela dit s'il y a des gens motivés pour participer de ce côté, moi je ne dis pas non
Offline
Héhé, en fait, je n'utilise jamais mingw habituellement mais je voulais être certain que la bibliothèque passerait bien avec ce compilateur.
Pour le makefile, as-tu déjà pensé à utiliser un logiciel tel que cmake ou qmake ? ces outils pourraient s'avérer bien pratiques par la suite pour la compilation sous différentes plateformes.
je pense qu'il est inutile de s'attarder sur une belle couverture pour un livre qui n'en vaut pas la peine
^^, disons que le livre n'est pas terminé, voilà tout.
Enfin, je suis partisan d'une fusion de libwar avec le sce même si je comprends pourquoi ils ne sont pas regroupés actuellement .
Il me semble que ce serait plus simple du point de vue de la maintenance du code et cela réduirait les dépendances externes.
Sinon, j'ai des commentaires à faire sur le "livre" en lui-même mais je préfère finir d'étudier complétement le code avant de les divulguer!
Offline
Héhé, en fait, je n'utilise jamais mingw habituellement mais je voulais être certain que la bibliothèque passerait bien avec ce compilateur.
Pour le makefile, as-tu déjà pensé à utiliser un logiciel tel que cmake ou qmake ? ces outils pourraient s'avérer bien pratiques par la suite pour la compilation sous différentes plateformes.
J'y pense plus ou moins en effet, je connais l'existence de tels outils mais ne me suis pas encore penché dessus. Il y a aussi des trucs genre scons, etc.
Enfin, je suis partisan d'une fusion de libwar avec le sce même si je comprends pourquoi ils ne sont pas regroupés actuellement .
Il me semble que ce serait plus simple du point de vue de la maintenance du code et cela réduirait les dépendances externes.
C'est vrai, d'ailleurs il y a déjà une lib perso qui est intégrée au moteur, lib4fm, qui permet de lire un format 3D binaire de ma conception. Je fusionnerai probablement libwar au SCE par la suite, vu que personne n'utilise libwar.
Sinon, j'ai des commentaires à faire sur le "livre" en lui-même mais je préfère finir d'étudier complétement le code avant de les divulguer!
Chouette ! Pense bien à chopper la dernière version sur la page téléchargements et non sur le GIT rep
Si jamais tu utilises IRC, tu peux venir sur le canal #opengl@irc.epiknet.org, j'y suis assez souvent.
PS: c'est dangereux d'être admin, j'ai failli cliquer sur "supprimer" au lieu de "citer".
Offline
libwar intégrée au moteur ! Plus besoin d'aller la chercher et de l'installer indépendamment.
Sympa !!!
Offline
Libwar sert à quoi ? :-°
Pour SteamLib (que je développe), je voudrais savoir si tu pouvais modifier ton code afin de pouvoir gérer le dessin dans plusieurs contextes (donc dans plusieurs fenêtres). Je ferai en sorte de gérer les contextes partagés afin de ne charger chaque texture qu'une seule fois
Ceci aurait pour but d'utiliser à 100% les capacités de ma bibliothèque.
Le switch de contexte se fait via ma lib (fonction nommée makeCurrentContext), mais il faut initialiser chaque contexte indépendamment des autres... :-°
Voilà, j'espère que je ne te pose pas trop de soucis --'
Offline
libwar pour Wavefront Reader. Ça lit des fichiers .obj.
Hum, il me semble qu'une ressource OpenGL chargée dans un contexte n'est utilisable que dans ce contexte... ? Et que pour les autres contextes, il faut recharger la ressource. Faudra que je me penche dessus, et bien que ça ne soit pas infaisable à l'heure actuelle (je crois), ça demanderait de tripatouiller à des fonctions bas niveau du moteur, ce qui serait chiant.
Offline
Pour partager des ressources entre contexte, il faut juste déclarer le contexte comme partagé dans la création de la fenêtre... --'
C'est donc moi qui m'occupe de tout cela
Par contre, j'aurai besoin que tu fasses en sorte qu'il y ait une fonction d'initialisation de contexte, que j'appellerai pour chaque contexte
Offline
Je parle pour tous les appels à glLoadIdentity, aux modification des matrices via gluOrho2d ou etc...
Ces fonctions modifient le contexte actuel, donc si on gère plusieurs fenêtres, il faut un appel à ces fonction par contexte.
En gros, on doit faire:
SLWindow_makeCurrentContext(window1);
gluOrtho2d(0, 0, 1, 1); /* On modifie les matrices du contexte via des appels à glOrtho2d ou autre... */
SLWindow_makeCurrentContext(window2); /* Ce contexte n'a jamais servi, on le désigne comme le contexte à modifier */
gluOrtho2d(0, 0, 1, 1); /* On modifie les matrices du contexte, */
Voilà.
Aussi, ma bibliothèque permettra aussi de choisir le niveau d'anti-crénelage du contexte ainsi que différentes options fournies par OpenGL.
Il n'y a rien à changer dans on code pour cela
Ma demande de modification de ta lib ne touche que pour l'utilisation de ma bibliothèque, mais aussi de la SFML et de Qt qui permettent de gérer plusieurs fenêtres
Bon courage
Offline
Ah ok, donc c'est parfait
Offline
Pages: 1