Tes jeux créés avec GD seront réellement compilés en code C++ alors qu’actuellement, les événements sont dans le gam.edg. Quand cette nouvelle fonctionnalités fonctionnera, les événements seront dans l’exe.
ça serait génial, et les jeux seraient 10fois plus performant !
Ca se peut, mais ça reste à voir. 
Aussi, il se pose un problème : la cross-compilation. 
Ben, GD peut inclure ce qu’il faut pour compiler sur les 3OS…
Ou mieux, si c’est pas possible: 4ian sort une version Natty de GDLinux, (si possible stable) et le problème est réglé. 
Pour info, si GD fait 100mo, c’est pas un problème
Sachant qu’on le télécharge un peu près une fois tous les mois, ça n’as rien de dramatique…
Aussi, pour améliorer: ça serait bien de choisir si l’on a un gam.egd, ou si l’on met les ressources ailleurs, et du coup, ça rends possible plus facilement les ressources externes (et ça fait moins à trimballer si l’on corrige des bugs, et qu’on le passe en réseau…)
Merci
PS: En parlant de ça, si WxWidget merde sur Linux, y a pas des paquets pour corriger ça?
Il me semble que d’autres programmes utilisent ça, et ça marche plutôt bien…as tu essayé de demander de l’aide sur les forums d’Ubuntu par exemple? (eux ils doivent avoir pas mal d’aide pour tes problèmes de compatibilité…)
Tout le monde n’a pas de bonne connexion, moi il me faut près de 6 heures pour dl 100mo… Et crois moi les nouveaux venus vont pas attendre si longtemps.
Et ba dic donc , je comprend pourquoi tu es si, enfin tu sais quoi
Ma connexion est lente, et je met environ 35min pour télécharger 100mo (a 125ko/s)
Comme je le disais, c’est 6H par mois, tu t’en fout
Non, je suis très rarement sur l’ordi 6 heures d’affilée. Et 6 heures par moi, ça fait quand même beaucoup.
Up pour mes questions.
Non, c’est là la différence avec embarquer simplement un compilateur : Je me base sur LLVM/Clang, un projet libre qui vise à recréer, entre autre, un compilateur C++ modulaire. Celui ci est ainsi notamment utilisable comme une “simple” bibliothèque.
Pour les bibliothèques, seuls les fichiers headers sont nécessaires.
Comme les évènements serait entièrement basés sur du code généré dynamiquement, il faudra un temps plus ou moins long de compilation en mémoire avant de pouvoir lancer l’aperçu.
J’ai déjà pu améliorer ce temps avec des fichiers d’entête précompilés, mais ça ne pourra sans doute en aucun cas être instantané.
Oui, mais rien d’extraordinaire non plus. Au contraire, le but est justement aussi de simplifier l’écriture des actions/conditions/expressions. Plutôt que d’écrire :
TonObjet::TaCondition(Arguments imposés par Game Develop)tu écrira :
TonObjet::TaCondition(Ce que tu souhaite)et tu déclarera ta condition en accord avec les arguments qu’elle souhaite. Game Develop générera un appel à la condition grâce aux paramètres qu’il a.
Le but est donc également de pouvoir utiliser beaucoup plus directement les concepts du C++. Genre, plutôt que :
-D’écrire une fonction pour accéder à la position X de ton objet.
-D’écrire la condition correspondante.
-De déclarer la condition correspondante.
Il n’y aura plus qu’à :
-D’écrire une fonction pour accéder à la position X de ton objet.
-De déclarer la condition correspondante.
Ce qu’on voit, c’est qu’on enlève véritablement une couche d’abstraction entre la machine et le jeu généré par Game Develop, pour :
-Augmenter les performances.
-Simplifier l’écriture des extensions.
-“Réconcilier” le monde de la création de jeux et les puristes de la programmation.
-Rendre Game Develop plus “pur”. Je me comprends.
Les évènements seront précompilés dans le jeu.
J’avais également pour projet d’essayer d’abstraire tout ce qui concerne la partie qui faire tourner les jeux, afin de permettre d’autre implémentation qu’une en C++. Mais pour le moment, une amélioration de l’implémentation actuelle par la compilation des évènements me semble plus prioritaire.
Donc, si j’ai bien compris, plus du tout de GetParameters, mais les paramètres seront envoyés directement en arguments ?
Il y aura toujours une sorte de MACRO pour déclarer l’action/condition/expression ?
GD nous donnera le code c++ de notre jeu ? Si oui, la création pour console deviendrait possible ? Juste a adapter les bibliotheques…
Ca n’aurait pas d’intérêts, le code généré pour les évènements est très spécifique. De plus, la plupart des évènements sont des fonctions codés dans les extensions, et puis, ce n’est pas avec un code C++ ou en adaptant simplement les bibliothèques qu’on porte un jeu sur console. Sinon, il y aurait longtemps que Game Develop permettrait de faire des jeux pour tout et n’importe quoi.
Oui, elles seront sans doute retravaillées, mais un mécanisme de ce genre est nécessaire pour exposer à Game Develop ce que ton extension propose.
Oui. Par exemple, plus besoin de demander à Game Develop d’évaluer une expression numérique, vu que celle ci sera déjà évalué directement dans le code C++ des évènements avant d’être envoyée à ta fonction.
Je m’vais me dire comme toi dayvid, ca sert juste a aller plus vite ;D Ce sera plus simple…
Sinon, que devient ObjectsConcerned ? Parce que c’est quand même utile des fois.
Pourras-t-on toujours évaluer nous même une expression (mon événement en a besoin) ?
A propos de Clang, on compilera toujours nos extensions avec GCC (j’ai vu “GCC compatibility” sur le site du projet) ?
J’ai regardé, je comprend pourquoi tu as choisi Clang, il est beaucoup plus rapide que GCC.
En tout cas, ça va me faire du boulot le jour où GD2 sortira. J’aurai quelques 75 conditions/actions/expressions à refaire… 
Oui, c’est un peu près ça, mais tout va changer sous le capot de Game Develop.
En tout cas, si ça fonctionne ça sera la modif du siècle (qui méritera a GD de passer en 1.6 ou 2.0 )
4ian a dit que GD passera en 2.0 lorsque cela sera prêt.
C’est géré au niveau des évènements, mais tu pourra toujours demander une liste d’objets.
Qu’a tu besoin exactement ?
Il y a des chances pour qu’il n’y ait plus de parseur d’expression de disponible, à part pour l’éditeur.
Oui, le principe est que Clang est juste utilisé pour la compilation des évènements, qui s’interfacent avec les extensions compilées avec GCC.
Mais dans le futur, je pourrai peut être passer entièrement à Clang, pour minimiser le risque d’incompatibilités.
Encore une fois, il s’agira surtout de les réécrire de façon plus simple et plus directe, il suffira de prendre un moment pour le faire, et ça sera fait.
Enfin bref, on en est pas encore là.
En fait, mon événement “Parcoureur de tableaux associatif” demande une expression de texte qui est le nom du tableau associatif à parcourir, lors du lancement de l’événement, l’expression est évaluée grâce à un GDExpression.
Et bien cette expression sera déjà évaluée par le code des évènements, et ce qui sera envoyé à ta fonction sera le texte qui en résultera.
Tu n’aura qu’à bien spécifier que ta fonction attend bien un texte en (1er/2eme/3eme…) paramètre.