Etonnant, non ?
Même modèle d’ordi, même carte graphique (Intel HD 2000 Graphics), mêmes Windows 7 64bits pro, mêmes conditions de test.
Et pourtant, dans le deuxième, GD semble incapable de digérer ce qui s’apparente aux textures (toutes les images du jeu, quoi).
J’avais déjà eu un phénomène analogue, mais dans ce cas, cela annoncait un plantage en bonne et due forme, à cause de la conso mémoire qui faisait raler Windows.
Mais ici, c’est dès le premier aperçu. Pas après 4 ou 5 comme d’habitude, avec seulement les particules qui buggaient.
EDIT :
Autant pour moi, je viens de comprendre pourquoi ça coinçait …
C’est la lettre de la clé USB qui changeait d’un ordi à l’autre. Logique que GD ne retrouve plus ses fichiers dans ce cas.
C’est quand même ennuyeux que GD ne scanne pas le dossier du fichier game.gdg. Car en l’état actuel, si on change le dossier de travail de place, il faut refaire tous les chemins de tous les éléments.
Un peu longuet, donc …
Si j’enregistre en version portable, GD recopie tous les fichiers sources au même niveau que le fichier game.gdg. Ce qui fait des fichiers en double, et un joli boxon pour trouver le bon fichier par des centaines.
L’autre souci est que la sauvegarde en portable prend plus de temps, et je ne me vois pas attendre plusieurs secondes de plus avant chaque prévisualisation. Déjà qu’il lui faut 10 à 30 secondes pour me donner la main lors du passage du mode edition au mode aperçu …
… et que je dois redémarrer GD toutes les 3-4 prévisu sous peine de plantage.
EDIT :
D’ailleurs, je viens de tester l’enregistrement en version portable, et là aussi GD ne copie pas les ressources sonores. On a que les ressources présentes dans la bibliothèque d’images, sans le chemin d’accès d’origine (tout balancé à la racine, donc). Et les liens vers les fichiers sons ne sont pas mis à jour dans les évènements. On se retrouve donc avec un projet muet …
