You are not logged in.
Pages: 1
Salut Yno,
Bravo pour le travail accompli !
Par curiosité, je vais télécharger la version disponible sur le svn et regarder de plus près les progrès effectués. (sous vista ).
Depuis que j'ai découvert ton projet, je viens régulièrement sur ton site (1 fois par mois ) et je suis vraiment impressionné par ce que tu fais.
Bonne continuation
Il est possible d'obliger le compilo à prendre en compte les inline et gcc gère les c99 en ajoutant l'option -std=c99 je crois.
Enfin, je voulais juste une opinion ^^, loin de moi l'idée de te faire renoncer à une norme qui date d'une vingtaine d'année et qui a fait ses preuves
Je me souviens de cette réponse, donc tu n'as pas changé d'avis --> c'est logique
Par contre, le contrôle sur des macros ... (pour le compilateur < surement non), pour toi, tu peux m'expliquer ?
Sinon, j'ai la même pratique pour les blocs et la portée des variabes et entièrement d'accord pour les ajouts.
LA portabilité ne doit pas, à mon 'humble' avis, poser de problème majeur avec les compilateurs les plus utiliser, si?
Au fait, on en a déjà parlé me semble-t'il mais quel est ton avis sur le c99 ?
Héhé, d'ailleurs, j'ai retrouvé quelque chose d'assez marrant hier sur mon ancien ordinateur portable :
-> la version 0.0.6 du moteur pour visual C++ !!
Que de souvenirs ... surtout que je n'ai pas poursuivi le dev et l'étude de ton projet sous Windows par la suite.
J'ai recalé un xubuntu sur mon XPS M1530 et la compilation du SCE est beaucoup plus aisée (donc j'ai laché Vista )
Salut,
Deux curieurx en fait, mais je n'ai pas eu le temps de poster pour te féliciter du travail accompli.
Bon boulot Yno
libwar intégrée au moteur ! Plus besoin d'aller la chercher et de l'installer indépendamment.
Sympa !!!
Salut,
J'y serais bien venu sur ce salon, ne serait-ce que pour papoter un peu sur le code source du moteur, mais il se trouve que je me connecte via mon téléphone portable. Je n'ai donc pas accès au port/protocole irc...Je déménage en région parisienne la semaine prochaine pour mon stage, j'espère avoir une bonne connexion fixe pour squatter le canal.
PS : Ça doit faire la sixième fois (entre aujourd'hui et il y a cinq mois) que je scrute le code de fond en comble, mdr. Il faut dire que je suis parti de zéro en prog 3D/OpenGL&compagnie. J'aurai souhaité t'aider davantage mais bon, le temps me manque un peu et les projets auxquels je participe s'enchaînent .... (notamment pour le travail)
ok ok, tout s'explique, je vais regarder çà.
Merci !
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!
Bonjour,
Dans la version accessible depuis GIT, il y a un soucis lors de la compilation du moteur.
Quelques fichiers (2 si mes souvenirs sont bons) requierent 'SCE\GLee.h' au lieu de 'SCE\SCEGLee.h'.
Rien de bien méchant mais bon
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
D'accord, merci du renseignement john !
Sorry, double post (je n'édite pas),
Je pense que c'est ta première hypothèse qui est la bonne car je travaille sur un ordinateur portable et j'avoue que l'acquisition d'une bonne carte graphique (et de tout ce qui va avec) n'était pas ma priorité au moment de son achat .
Dans les faits, je n'utilise mon pc que pour programmer sachant que je ne fais que très rarement des applications graphiques, surtout de l'algorithmique actuellement.
J'étais loin de me douter que je testerai ton moteur 3D...
Donc, pour en revenir au sujet, mon pc(ou le SDK????) semble ne pas supporter glGenBufers et ses copains mais glGenBuffersARB,glBindBufferARB, etc ...
Je vais modifier un peu les sources et voir si çà tourne
@++
Anian
EDIT : initialisation + finalisation ok, çà a l'air de fonctionner normalement après les "ajout d'ARB" , je poursuis donc ma démarche !
bonjour,
Je suis en cours de vérification là,
Ce que je peux dire pour le moment, c'est qu'il n'y a pas eu de problème lors de l'initialisation de GLEW puisque glewInit me retourne GLEW_OK (au tout tout début, j'avais effectivement oublié le context mais j'ai vite compris le soucis )
Après, j'avoue que je suis un peu ralenti par le fait que je n'ai jamais touché à OpenGL (ni fait de 3D à si bas niveau) mais je compte bien comprendre ce qui ne va pas exactement .
je vais me renseigner un peu plus sur la fonction glGenBuffers pour voir ce qu'il en est exactement .
@+
Anian
Bonsoir,
Voilà un petit problème qui pourrait éventuellement vous intéresser . Du moins, je pense que c'en est un !
J'ai créé ma première application de test qui consiste uniquement à l'initialisation du moteur (compilation sans prendre en compte gluBuild3DMipmaps à cause du soucis mentionné dans l'autre topic) .
Tout ce passe à peu près bien jusqu'à une Access violation sous vista donc j'ai lancé le débogueur et effectivement, il y a un os au niveau de la fonction SCE_CCreateIndexBuffer du fichier "SCECBuffers.c" lors de l'appel de la fonction glGenBuffers ligne 255:
le BT de mvc++ 'épuré' :
> Samples.exe!SCE_CCreateIndexBuffer() Ligne 255 + 0x12 octets
Samples.exe!SCE_Mesh_Create() Ligne 364 + 0x5 octets
Samples.exe!SCE_Init_Quad() Ligne 73 + 0x5 octets
Samples.exe!SCE_Init(_iobuf * outlog=0x66b91448, unsigned int flags=69) Ligne 128 + 0x5 octets
Samples.exe!main(int argc=1, char * * argv=0x00e21348) Ligne 50 + 0xb octets
(ouais, j'ai mis le flags à 69 mais bon, c'est le premier nombre qui m'est venu à l'esprit et l'utilité du truc est encore toute relative)
Le BT interne :
|- SCE_Init (48)...
| |- SCE_Init_Media (127)... ok
| |- SCE_Init_Resource (109)... ok
| |- SCE_CInit (47)...
| | |- SCE_CImageInit (83)... ok
| | |- SCE_CTextureInit (83)... ok
| | |- SCE_CShaderInit (129)... ok
| | ok
| |- SCE_Init_Shader (308)... ok
| |- SCE_Init_Mesh (68)... ok
| |- SCE_Mesh_Create (354)...
| | |- SCE_CCreateIndexBuffer (248)...
Le deuxième argument semble incorrect mais je ne me suis pas trop penché sur la question pour le moment .
Je poste le compte-rendu ici au cas où une solution pourrait être trouvé d'ici à demain sinon je verrai moi-même pour résoudre cela (je ne pense pas que ce soit bien compliqué vu que l'essentiel des variables en jeu sont locales) . Pour ce soir, je pense que je vais aller me coucher là, je n'ai pas la forme nécessaire à une séance de debug
@++
Anian
Désolé pour le double post ,
Voici un nouveau souci, le SDK de Microsoft ne contient pas de lien vers gluBuild3DMipmaps (utilisée à la ligne 1166 de SCECTexture.c par exemple), c'est assez chiant mais je vais tenter de contourner le problème
Ces gens qui se disent si forts ne savent même pas fournir une bibliothèque complète et à jour, même l'entête 'glu.h' ne contient pas la fonction et le compilo m'a retourner un simple avertissement
@++
Voilà, ma version est à présent mise à jour !
Tout se passe bien ... je vais effectivement prendre mon temps pour analyser tout çà et voir pour corriger quelques incohérences au niveau du code .
A plus tard,
Anian
Salut,
J'étais justement en train de parcourir les sources ...
Effectivement, j'ai pris la version disponible au téléchargement, je n'ai aucune connaissance sur le logiciel (protocole?) Git donc je vais voir ce qu'il en est et mettre à jour le truc
Pour memcpy, le prototype de la fonction est identique donc la vérité est ailleurs :
Sans rentrer dans les détails, le compilo ne comprends pas qu'en faisant :
ib->mapptr + d->first
on lui demande de deplacer le pointeur de first octets alors qu'avec mon petit hack qui lui fait croire que c'est un pointeur sur des caractères (char étant sur un octet en mémoire), il ne considère plus qu'il y a une erreur . Enfin, j'espère qu'il n'y en a plus
Hum, de ce que j'en sais et voit dans les sources, non, chaque fichier n'inclus que ce dont il a besoin. Sinon, quel rapport entre les inclusion de en-tête et les bibliothèques statiques .lib ? MSVC++ trouve seul de quelle bibliothèque statique il a besoin selon les en-têtes !?
Je revérifierai mais pour prendre un exemple, dans la partie 'utils' des sources que j'ai à ma disposition, il faut fournir le répertoire include de GLEW pour que la compilation passe mais l'éditeur de liens n'a pas besoin de la lib static à l'édition de lien car il n'y trouve effectivement pas de références nécessaires .
Pas certain d'avoir été clair là? si?
EDIT : après courte vérification, c'est juste une inclusion pour les types GL dans SCEMemory.c donc milles excuses, j'ai dis des bêtises ... d'où la nécessité que je consulte les sources . La lib n'est effectivement pas nécessaire dans ce cas de figure .
Pour le reste(les avertissements par exemple), il faudra attendre mes tests complets sachant que je vous fournirai les projets et les libs/dlls précompilées ... sous vista (personne n'est parfait). L'EDI que j'utilise étant en libre téléchargement bien entendu !
Ps : je précise que je compile en mode debug pour mes tests donc la multitudes d'avertissements vient en partie de là (j'ai passé une option au compilo pour qu'il me sorte la majeur partie des problèmes)
salut,
Comme je te l'avais dit sur le site du zéro, je m'apprête à tester ton moteur 3D et à regarder un peu ce qu'il a dans le ventre .
Pour y parvenir, je me suis créé une petite Solution sous Visual C++ 2008 Express avec 5 projets nommés respectivement :
-SCEBase (contient juste SCEngine.c + des liens vers les entêtes SCEMinimal.h et SCEngine.h)
-SCECore
-SCEInterface
-SCEUtils
-SCELibWar (ta lib pour charger les OBJ)
Avec tout çà, je me suis fait un petit groupe de configuration pour compiler en dynamic ou static et en debug ou en release tout cela sous Win32
pour bien préparer mon plan de travail . J'espère que ces petits arrangements ne te dérangent pas, je n'ai pas (encore) trop touché aux sources de toute manière
J'ajoute que j'ai récuperé les bibliothèques précompilées pour glew, DevIL et CG de la société NVIDIA pour me simplifier un peu le travail .
Tout d'abord, je t'annonce tout de suite l'erreur générée par le compilateur :
-> au niveau du fichier 'SCEBuffers.c", lignes 897 et 919 dans la documentation, pour le premier argument de la fonction memcpy :
Je te conseille de mettre ceci memcpy ((char*)(ib->mapptr) + d->first, d->data, d->data_size); et idem pour l'autre .
Etait-ce bien ce que tu souhaitais avoir comme résultat ?
Autre chose, j'ai le sentiment que tu as glissé un peu toutes les entêtes dans tous les fichiers car à l'édition de liens, j'ai des messages du styles :
'ça sert à rien de me donner blababla.lib, il n'y a pas de rapport'
Bref, c'est con de lui passer le répertoire d'inclusion juste pour le nourrir d'entêtes ^^
Concernant les avertissements, j'ai :
- des pertes de données hypothétiques pour cause d'incompatibilités de type
- des incompatibilités unsigned/signed
- des retours de void ^^(assez amusants)
- etc... (dont certains avertissements que je n'ai pas pris le temps d'analyser en profondeur)
Au final, je n'ai testé que la compilation en "static debug" pour mes tests ultérieurs et çà a l'air de fonctionner correctement (avec mes petites modifications).
Je te donnerai mes impressions détaillées plus tard ... à ton retour probablement (il me semble que tu as indiqué quelque part que tu étais en vacances) .
Bonne continuation !!
Anian
PS : - je posterai les binaires dès lors que j'aurai obtenu des résultants concluants (ou rien dans le cas contraire )
PPS : - j'ai un projet en cours qui repose sur plusieurs choses importantes parmi lesquelles se trouve un moteur 3D en langage C donc, si je pense que le SCEngine a du potentiel, je contribuerai au projet dans un premier temps et l'incorporerai au miens dès lors qu'il sera mature . A voir donc ...
Pages: 1