(Mise à jour de SFML) Correction des crashs liés aux fichiers audios
Correction des calques mal cachés pour les jeux HTML5
Mise à jour de la traduction russe (Merci à Komencanto)
(Nouveautés de la version 3.4.72 par la suite:)
Nouvel 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.
Sinon, les fichiers pour télécharger GD sont maintenant hébergés sur GitHub : quand vous téléchargez sur le site, vous téléchargez en fait ces fichiers et profitez donc d’un téléchargement à vitesse maximale (du moins plus rapide que sur le serveur un peu lent qui héberge le site)
De mon coté, avec cette version, la compilation sous windows donne bien un jeu qui se lance.
Le fuite mémoire est encore présente en revanche (Intel Graphics HD). Le jeu libère bien de la mémoire à chaque changement de scène (à priori les images), mais pour en reprendre encore davantage au chargement de la suivante (à priori les évènements). J’ai la sensation que le problème se pose moins avec les scènes “uniques” (celles qui sont spécialement dédiées aux minijeux) qu’avec les scènes fourre-tout (nommément Pieces1 et Pieces2 dans mon projet).
Je vais continuer à tester de mon coté pour voir s’il y a quelque chose qui provoque spécifiquement cette bouffe mémoire.
Faut aussi que je teste sous Ubuntu64, qui jusqu’à présent ne marchait pas pour mon projet.
De mon côté l’éditeur “lag” toujours même si je pense que c’est due à ma carte graphique (AMD Radeon HD 5700 series) car sur un pc avec chipset intégrer ça rame moins…
Sinon aucun problème pour le moment.
La compil sous Linux (Ubuntu 64bits) fonctionne et le jeu se lance. Mais il plante au bout de quelques salles (on dirait qu’il n’arrive pas à charger un effet sonore).
Impossible de lancer ExeLinux sous Mint xfce 32Bits. Il me dit “Erreur de format pour exec()”.
Testé sous Windows 7 64bits et une nvidia n210. Pas de fuite mémoire (reste à 170 Mo max), mais plantage quand même au bout d’une dizaine de minutes de balade.
A noter qu’entre temps, j’ai mis en “non” la plupart des images pour la conservation en mémoire.
Pour les PC les plus vieux, c’est bien dommage en effet, je comprends bien. Mais je développe pour le présent et pour l’avenir ! Et absolument tous les ordis qui sortent maintenant ou même ceux qui ont 2, voir même 3 ans sont en 64bit
Le but de GD, c’est de pouvoir permettre par exemple la création facile de jeux indie. Les joueurs Steam sont consommateurs de jeux Indie pas cher, et quand on regarde les stats ( store.steampowered.com/hwsurvey ), on a bien plus que 1/4 des PC en 64bit, une majorité plutôt
Sachant que windows continuera de faire tourner du 32bits pendant encore 10 ans minimum. La comparaison ne tient donc pas.
Si j’achète une tour à 600 euros, c’est pas pour y mettre du linux et faire tourner du team fortress. C’est pour les derniers jeux en DX12, et donc du Windows. Windows qui se moque de savoir si c’est 32 ou 64, tant que c’est un exe.
Linux, c’est pour mes vieux pc qui marchent encore, mais pas assez costaud pour les windows d’aujourd’hui. Donc du mono/dual core, tout à fait capable de faire tourner du web ou du flash. Et de bon benchmark pour juger de la gourmandise d’une appli.
Un jour peut-être, la commu linux se sortira la tête de l’arrière-train, regardera les stats mondiales, y verront que les 3/4 de la planète tourne encore sous windows XP, et comprendront où se trouve vraiment leur marché. Autrement dit, dans la récup/recyclage. Pas dans le high-end.
Pour en revenir au sujet de base, j’ai testé l’export en android.
C’est long (exporter sous GD, upload sur Intel XDK, création du projet, build), mais pas d’erreur particulière à signaler.
Le test dans l’intel XDK se passe bien. Mais avec Bluestack, l’appli plante (je suppose qu’elle bouffe trop de mémoire).
Testé sur un Galaxy Fame Lite (entrée de gamme donc), le jeu se lance, passe deux écrans et freeze à l’écran titre (là encore, une image trop grande j’imagine).
Au moins, le système d’export à l’air au point. Reste maintenant à scaler ses projet pour des terminaux ultra-légers.
EDIT :
Toujours à propos des fuites mémoires, de ce qu’en j’en ai lu, le fautif serait les pilotes des CG, notamment Intel qui n’a pas l’air pressé de patcher ses drivers. A chaque appel openGL (texture mais aussi texte) la ressource n’est pas libérée après utilisation (alors qu’elle devrait l’être). Elle s’accumulerait donc en mémoire jusqu’à saturation puis kill du processus par l’OS.
Cela veut dire que le problème de saturation de mémoire vidéo se pose dès qu’on appelle (et qu’on détruit) une image ou un texte.
Je viens de tester sur ma GTS 250 (pas un grosse CG mais quand même), et la saturation progressive de la mémoire embarquée apparait nettement à chaque changement de salle (gestionnaire des tâches → Performances → Moniteur de ressources → Mémoire). Ce serait donc commun à toutes les CG Intel et nVidia ?
Double-post parce que je le vaux trop bien, et que les couches, j’en rajoute tellement je suis généreux, tellement je donne à tout le monde, tellement l’abbé pierre il passe pour une radasse à coté de moi.
Je viens de commencer un nouveau projet.
Et je retombe sur ces crashs à répétition liés à la mémoire qui sature.
Même si ça ne se voit pas dans le gestionnaire des tâches, on remarque dans “charge dédiée” que quelque chose dévore de la mémoire façon ogre lillois.
Le projet est tout petit pourtant, donc ce n’est pas un problème d’évènements de 50 000 lignes. Idem pour les ressources graphiques ou sonores (15 Mo en tout).
GD plante au bout d’une trentaine d’aperçus/modifs.
Bon, je sauvegarde toutes les trois secondes, donc c’est pas trop grave.
Mais ça signifie que mon projet exporté va encore être injouable au bout de 10 minutes.
Pas glop !
Un détail aussi qui a une sacrée importance : le HTML5 ne gère pas le son multi-canal.
Si on lui dit de jouer une musique différente sur deux canaux, il les ajoute en boucle sans pouvoir les arrêter et finit par bugger toute la partie sonore.
Donc, dans un projet destiné au web (et donc à Android), il ne faut utiliser qu’un seul et unique canal.
Il faudrait le rajouter dans les textes des actions, histoire de prévenir l’utilisateur.
Tu peux me passer ce projet ? S’il est petit et qu’on arrive à faire vite planter GD, il y a peut être une fuite mémoire en effet à un autre endroit (la dernière fois c’était la copie des listes d’événements qui mangeait la mémoire).
Pour l’audio, tu dis donc qu’il faut ajouter deux musiques sur deux canaux différents pour que ça ne marche plus après ?
Envoyé en MP.
C’est peut-être dû à Windows XP. C’est vrai que j’ai pas encore testé sous 7 64bits.
Mais bon … Voilà quoi.
Ah au fait, pour passer d’une “scene” à l’autre, il faut cliquer sur le bouton FastFoward.
C’est juste un projet tout basique pour le moment : ça crée un agencement en fonction d’une variable, charge la musique qui va avec, et attend que le joueur appuie sur FastForward pour passer à la scène suivante.
Uniquement en HTML5, sous windows pas de problème.
Sur DIX, les sons ne se lancent jamais bien, les musiques ne changent pas quand elles devraient et le tout fini par s’accumuler dans le buffer sonore, pour tout sortir d’un coup 5 minutes plus tard.
Sur le nouveau projet, aucun de ces problèmes pour le moment.
Car j’utilise un seul canal de musique. Contre 6 pour le précédent. Donc …
