Game Develop 3.4.72

🇫🇷 Forum français (French Forums) Discussions générales
1

Game Develop 3.4.72 est disponible :

Nouvelle automatisme: Mouvement vu du dessus (4 ou 8 directions).
Traduction russe : merci à Airvikar de ubuntu-wine.ru
Plusieurs images peuvent être glissées deposées depuis la banque d’images vers une animation d’un objet Sprite.
Mise à jour de SFML : Améliorations graphiques et corrections d’erreurs et fuites de mémoire sur les vieilles cartes graphiques.
Mise à jour de Pixi.js : Rendu 400% plus rapide des jeux HTML5, améliorations du support de CocoonJS
Ajout du support de Intel XDK, pour exporter les jeux HTML5 vers Android ou iOS.
L’éditeur de scène affiche maintenant le cadre de la fenêtre de jeu.
Minification plus rapide des jeux HTML5 avec UglifyJS. Node.js doit être installé.
Correction de la prise en charge des chemins de fichier de type Windows sur Linux.
Correction d’un crash lors de la recherche dans les évènements.

Pour le moment, la version est disponible uniquement sur le forum
compilgames.net/dl/gd34722.exe (Windows)
compilgames.net/dl/gd34722.7z (Windows, version sans installateur)
compilgames.net/dl/game-deve … _amd64.deb (Ubuntu)

La version officielle arrivera plus tard si il n’y a pas de bug majeurs.
Pensez à faire des sauvegardes de vos fichiers de jeux en cas de problème avec cette version, car il ne pourront pas être ouvert avec une ancienne version.

2

Dès que ce sera la version définitive, il serait bien de faire un zip avec les sources, pour permettre aux gens de compiler une version stable.

3

Oui, c’est vrai tu fais bien de m’y faire penser, je viens d’ajouter ça sous forme d’une release sur GitHub : github.com/4ian/GD/releases :slight_smile:

4

Mince …
dire que ça fait des semaines que je bosse sur un projet et que aujourd’hui arrive la réponse a toute mes attentes : la vue du dessus 4 directions !!

5

Pas gg pour le moment …
L’explosion mémoire persiste, sauf qu’elle a lieu durant l’export, au lieu de l’exécution du jeu. :confused:

A chaque compil de scène, GD mange 200 Mo environ en RAM. Donc, au delà de 4 scènes compilées (1.5 Go en RAM), c’est “segmentation fault 02”. Même problème en windows, web ou android.

Testé sur une intel HD et GeForce avec le même résultat.

Je vais refaire d’autres tests pour comprendre d’où vient exactement le problème dans mon projet, et je reviens.

EDIT 1 :
Ca vient des évènements externes.
J’ai viré toutes les images : sans effet.
J’ai changé l’ordre des scènes : sans effet.
J’ai désactivé les évènements externes : moins de fuite mémoire.

Maintenant, il faut que je détermine lequel parmi eux provoque les 300 Mo en plus. Je teste et je reviens.

6

C’est super au contraire, ça veut dire que la MAJ de SFML a réglé tes problèmes ! Et que les jeux tourneront sur des vieux PC sans problème.

Je n’ai pas touché à la compilation par contre, donc tu est sur que ce problème n’était pas déjà présent auparavant ?
Est ce GD qui mange la mémoire ou un processus comme cc1plus.exe durant la compilation ? C’est normal que la carte graphique n’ai aucun effet, la compilation c’est une affaire de CPU :slight_smile:
Est ce que la mémoire mangée reste occupée après la compilation (vire quelques évènements externes au besoin) ou est ce qu’elle est libérée ?

7

Ca, j’en sais rien, puisque je ne peux plus rien exporter. Et donc rien tester pour voir si la sfml a un effet.

Avant l’'aperçu passait. L’export aussi. Je ne me suis donc jamais posé la question.
Maintenant, c’est ni l’un ni l’autre.

cc1 monte à 500 Mo mais finit par disparaitre. Le souci, c’est qu’à chaque export de scène (durant l’export en natif par exemple), GD augmente de 300 Mo.

Etant donné que GD plante systématiquement avant d’avoir terminé l’exportation, je ne peux pas répondre.
Il faut que je trouve un moyen de l’empêcher de bouffer autant de ram à chaque export de scène.
Là, je suis en train de désactiver/réactiver chaque évènement externe entre chaque tentative d’export, pour voir lequel provoque la surconso de ram.
Ca va être long …

EDIT 2 :
Marrant, ça …
Le problème vient de l’évènement externe qui gère la souris (curseur et clic).
A chaque fois que je change “éditer comme si les évènements étaient inclus dans la scène”, GD mange 250 Mo de plus en ram …
Et ce, même si je désactive tous les évènements … Il doit y avoir une instruction qui ne lui plait pas …

EDIT 3 :
Bon. En virant toute la partie qui gère le déclenchement du passage d’une scène à l’autre suite à un clic de souris, la fuite mémoire a disparu.
Il doit y avoir une instruction qui ne lui plait pas (mais en dehors du téléchargement d’un pdf et sa lecture, le reste n’est que de l’affectation de variable … ).

Toujours est-il que je peux exporter en natif et en web.
Mais ça ne marche toujours pas. :confused:

Maintenant, j’ai un exécutable trop petit pour être honnête (40 Mo au lieu de 100 Mo attendu), qui plante dès le lancement du jeu.
En web, ça passe. Mais comme je ne peux plus passer d’une scène à l’autre (vu que j’ai viré les évènements pour que ça exporte), le jeu demeure inutilisable.

Je remarque néanmoins que l’export en windows donne le même résultat que l’export en linux des versions d’avant : un dossier trop petit par rapport aux fichiers source et un exe qui plante dès l’apparition de la fenêtre.

8

Je possède les mêmes problèmes que mtarzaim. Chez moi, les aperçus de toutes les scènes plantent systématiquement (sauf si j’enlève la musique :laughing: ).

A la compilation, j’ai un message d’erreur. Voici son détail issu du fichier “LatestCompilationOutput.txt” généré automatiquement par GD :

[code]C:\Users\Dylan\AppData\Local\Temp/GDTemporaries/GD0x2321f4f8RuntimeEventsSource.cpp: In function ‘int GDSceneEventsMenu(RuntimeContext*)’:

C:\Users\Dylan\AppData\Local\Temp/GDTemporaries/GD0x2321f4f8RuntimeEventsSource.cpp:4442:50: error: too many arguments to function ‘void SetFullScreen(RuntimeScene&, bool)’

C:\Program Files (x86)\Game Develop/CppPlatform/include/GDCpp/GDCpp/BuiltinExtensions/RuntimeSceneTools.h:117:13: note: declared here

C:\Users\Dylan\AppData\Local\Temp/GDTemporaries/GD0x2321f4f8RuntimeEventsSource.cpp:4459:51: error: too many arguments to function ‘void SetFullScreen(RuntimeScene&, bool)’

C:\Program Files (x86)\Game Develop/CppPlatform/include/GDCpp/GDCpp/BuiltinExtensions/RuntimeSceneTools.h:117:13: note: declared here

[/code]

Et, par conséquent, je ne peux pas voir les améliorations apportées à la nouvelle version d’SFML… :frowning:

Il y a une ligne qui correspond au plein écran (car j’ai donné la possibilité de mettre en plein écran ou fenêtré dans mon jeu) et ça, Game Develop n’a pas l’air d’apprécier (de plus, c’était déjà bugué in-game auparavant, mais au moins le jeu pouvait tourner).

Après, je n’ai pas testé en retirant tous les évènements externes, mais sans ça, le jeu devient un diaporama d’images. Pas super intéressant vous l’accorderez :laughing:

9

Tu as aussi des problèmes de mémoire ? ou juste l’impossibilité de compiler à cause de cette erreur ?

10

Je ne peux pas compiler à cause de cette erreur.
De plus, je ne peux pas faire fonctionner les aperçus, parfois le logiciel plante directement (GDIDE.exe a cessé de fonctionner), parfois il fige et ne reprend pas…

11

Si il y a cette erreur, c’est sur que tu ne peux pas faire les aperçus (car ils ont besoin de la compilation aussi).

EDIT : J’ai corrigé l’erreur, ce peut être disponible pour la version définitive. :wink:

12

J’ai mis en ligne une nouvelle version pour corriger notamment le soucis du fullscreen :

compilgames.net/dl/gd34721.exe
compilgames.net/dl/gd34721.7z (version sans installateur)

Blady peux tu me dire si c’est mieux ?

13

De mon coté, cette nouvelle version ne change pas le souci.

GDBug-FuiteMemoire.jpg
GDBug-FuiteMemoire.jpg823×350 46.3 KB

J’ai essayé avec une version sans les évènements qui explose la ram, et qui accélère grandement le temps de compilation, mais le résultat final est le même : l’exécutable plante au lancement et le fichier egd est trop petit par rapport aux assets d’origine.

Si 4ian veut s’amuser à reproduire mon bug, j’ai une archive de 200 Mo qui contient les fichiers sources et les fichiers projets.
http://dix.thefrogstudio.net/Sources/DIX-archive20140801.zip
Dix-TestAllege pour le projet complet
Dix-TestAllegeQuiCompilSansClicSouris pour la version qui compile mais qui plante à l’exécution.

14

La version “qui compile” compile bien et se lance bien chez moi (malgré que l’on puisse pas faire grand chose :smiling_imp: )

15

Je regarde la version qui compile pas ce soir alors.

16

j’ai le même problème GDIDE passe 1700k de mémoire et la compilation crache

17

Tu as le même problème avec le jeu de mtarzaim ou avec un de tes jeux ?

18

De mon côté, la compilation s’achève à succès sans la fuite mémoire qu’évoque mtarzaim.
Malheureusement, j’ai toujours les problèmes concernant des scènes où l’aperçu ne fonctionne pas (GD fige). Ces mêmes scènes, une fois compilé, fait planter le jeu…

Je pense que ces scènes peuvent planter à cause du canal utilisé par la musique. A l’instant, je viens de faire un test : la musique joué entre le canal 0 et le canal 5 ne pose pas de soucis. En revanche, si je dépasse, le logiciel est instable (il plante parfois lors du retour au mode édition, parfois directement dans l’aperçu). Après, cela peut peut-être venir de mes .ogg (j’ai déjà eu un problème auparavant, certains ne pouvait mystérieusement pas se lire, fallait juste que je ré-exporte le .ogg avec les mêmes paramètres et ça marchait ! Je me disais à moi-même “cherche pas à comprendre” :laughing: )

Si tu veux 4ian, je peux te passer directement les fichiers sources pour mieux analyser mes problèmes :wink:

19

victor excuse moi de ne pas l’avoir préciser c’est le jeu de mtarzaim je n’est pas de jeux aussi volumineux que le sien mais tous ceux que j’ai test marche correctement

20

Ben oui, toute la partie clic de souris est passée à la trappe. Du coup, les clics ne déclenchent plus aucune action.

De mon coté, j’ai avancé un peu.
Le problème semble venir du groupe d’objet CurseurReaction, qui contient tous les sprites susceptibles d’avoir une réaction au contact de la souris.
J’ai viré un objet sprite du groupe (FantomeMaleCorps, une grosse image de 800x1200), et GD s’est mis à répondre beaucoup mieux.
La compil crashe toujours, mais j’ai moins de fuite mémoire quand j’édite une scène puis une autre. Peut-être qu’il y a un ou plusieurs objets dans ce groupe d’objets qui posent problème.
Je vais donc les sortir du groupe, et les gérer directement dans les scènes concernées, au lieu de les appeler dans toutes les scènes via un évènement externe.