28 réponses à ce sujet

[draad]

Bonjour à tous,

D'après ce que j'ai pu lire sur les forums de starling, palier au LostContext de starling est très couteux, 2x la consomation de mémoire des assets normaux. Sur du devellopement mobile, consommer deux fois plus de mémoire vive peut être vraiment catastrophique, je me questionne donc de la pertinence d'utiliser un Atlas dans ce cas là.

En effet, pour que starling puisse récuperer d'un LostContext, il a besoin que le bitmap d'origine des textures soit toujours actif. Mais dans la documentation, il est fortement conseillé pour des question de performance du rendu d'utiliser le minimum d'atlas pour les passes graphiques. Ainsi, quel est la meilleur option ? Abandonner l'atlas, tirer chaque texture du bitmap d'origine, et perdre de la vitesse de rendu graphique, ou utiliser l'atlas, garder un doublon de chaque texture et consommer 2x plus de mémoire?

Merci pour vos conseils.

[tlecoz]

Hello

Citation

palier au LostContext de starling est très couteux, 2x la consomation de mémoire des assets normaux

Qu'est ce que le LostContext, tu peux développer un peu s'il te plait

Merci d'avance !

[draad]

Coucou tlecoz,

Le LostContext se produit sur Stage 3D lorsque la plateforme passe en veille alors que l'application est en train de tourner. Sur PC, tu peux reproduire un lostContext en faisant Ctrl + Alt + Suppr, ainsi, ton application sera vide et lancera cette erreur : Device lost Context

[tlecoz]

Merci

Et par curiosité, quelle est la solution proposé sur les forums starling ?

EDIT :
je ne comprend pas cette phrase

Citation

il a besoin que le bitmap d'origine des textures soit toujours actif.

Que veux tu dire par "actif" ?

Je suis sur de ne pas comprendre le problème

[draad]

Il y a une option a activer lorsque tu crée l'instance de starling :

Starling.handleLostContext = true;

Mais cela ne marche qu'a condition que les bitmaps qui t'ont servis a generer l'instance des textures soient toujours actifs. Tu ne peux donc pas les liberer la memoire de ces derniers :
http://forum.starlin...-device-context

[tlecoz]

Excuse cette question naïve, mais c'est pour bien comprendre...
Dans quel cas de figure tu affiches un truc à l'écran sans avoir le bitmapData en RAM ? Le bitmapData n'est pas forcément actif ?
Désolé mais un truc m'échappe

[tlecoz]

Et sinon, si Starling arrive - en interne - à comprendre quand le contexte est perdu, en quoi est ce un problème de regénérer toutes les textures ? Cela ajoutera quelques secondes d'attente - comme lorsqu'on éteint et qu'on rallume une partie de candy krush - mais rien de bien méchant je trouve.

[draad]

Je n'ai peut-etre pas bien compris le fonctionnement de cette aprtie de starling alors, si tu veux bien m'expliquer je suis tout ouie.

Citation

Dans quel cas de figure tu affiches un truc à l'écran sans avoir le bitmapData en RAM ? Le bitmapData n'est pas forcément actif ?
Désolé mais un truc m'échappe

Bien imaginons que tu crée un atlas de textures, tu vas d'abord charger ton bitmap data, puis en extraire un objet de classe texture que tu vas stocker dans ton Atlas. A ce point, tu as deux fois la même donnée : le bitmap d'origine, et la texture, qui chaqu'un prennent leur lot de mémoire. D'apres la doc de starling, si tu utilise les Atlas comme source de toutes les textures utilisées, tu gagne en rapidité d'affichage car le GPU peut alors ne faire qu'une seule et unique passe (si j'ai bien compris, le GPU réalise une passe par source de texture), a ce point, etant donné que tu ne vas plus utiliser qu'un seul atlas, tu peux te permettre de supprimer tous les doublons Bitmap de la mémoire.

A ce point, si starling perd le contexte, il semble incapable de regenerer les textures si les bitmaps sont disposés.

[tlecoz]

Désolé mais ce n'est pas clair

Un Atlas n'est qu'une bitmapData contenant plusieurs images dont chacune est accessible en jouant sur le repère de texture (UV).
Que tu utilises ou non les Atlas, il y a forcément un bitmapData.

si cela est possible, il est effectivement préférable d'avoir le moins d'objet Texture possible, car chaque objet Texture sous entend une "passe" de rendu, et c'est pourquoi il est hautement recommandé d'utilisé des "Atlas" qui permettent à plusieurs images de partager la même texture et donc d'économiser des "passes" de rendu.

Ah je crois que je commence à comprendre.
Actuellement, tu "dispose" ton bitmapData coté CPU après l'avoir injecté dans le GPU sous forme d'un objet Texture, c'est ça ?
Je suis un peu étonné par ce genre d'optimisation à vrai dire, mais pourquoi pas

Dans ce cas, j'appliquerais la solution dont je parles plus haut, à savoir gérer le 'lostContext' par toi-même
Il suffit de retrouver le moment ou le lostContext est déclenché (j'imagine qu'il y a un évenement) et à ce moment là vider toutes les Textures, recharger les assets et recréer les texture. Le temps de faire ça - car ca va risque de prendre quelque secondes s'il y a beaucoup de texture - tu met une image genre splashScreen à la place du jeu avec un message "please wait" et voilà !

EDIT : je crois vraiment qu'il vaut mieux faire attendre les gens 3 secondes au démarrage et que tout soit fluide partout plutôt que de lancer le jeu instantanément et que ça rame.

[draad]

Ha d'accord merci !

Je vais essayer de monter ce systeme pour mon prochain projet.

Oui je dispose le bitmpa d'origine ainsi que son loader afin de recuperer le maximum de memoire possible. Tu semble surpris, est-ce que je devrais éviter de faire ça ?

[tlecoz]

J'ai relativement peu d'expérience sur mobile, c'est peut être une pratique courante

L'idée est intéressante je trouve, je pensais jusqu'à maintenant que l'objet Texture pointait vers l'objet BitmapData (et que celui ci ne pouvait de fait qu'être actif) mais donc non - et maintenant que j'y pense c'est logique - .

Ceci dit, à part économiser de la batterie - c'est toujours ça de pris - , je doute que cela améliore les perfs de l'appli de faire ça - mais ça ne peut pas leur faire de mal -

Donc si ! si ! Continue de faire ça, ça ne peut être que mieux

[tlecoz]

De toute façon dans le contexte d'une appli Air et du texturing, les BitmapDatas ne sont pas vraiment utile car tu peux avoir accés instantanément aux fichiers (puisque tout est local) donc à leur Bytes , et n'avoir qu'un seul BitmapData que tu remplis avec setPixels avant de l'uploader vers le GPU

[draad]

Citation

De toute façon dans le contexte d'une appli Air et du texturing, les BitmapDatas ne sont pas vraiment utile car tu peux avoir accés instantanément aux fichiers (puisque tout est local) donc à leur Bytes

Ha bon ? Jusqu'a présent j'ai toujours utilisé des loaders pour charger mes images, je n'aurais donc pas besoin de faire cela?

Citation

Ceci dit, à part économiser de la batterie - c'est toujours ça de pris - , je doute que cela améliore les perfs de l'appli de faire ça - mais ça ne peut pas leur faire de mal

Sur mobile, une application n'a qu'une certaine quantité de mémoire vive autorisée, si l'appli dépasse celle-ci, le device ferme l'application afin de garantir la stabilité de la plateforme. Ainsi, si tu garde le bitmap et la texture, tu multiplie par deux la mémoire utilisée, ce qui deviens très rapidement un problème...

[tlecoz]

Merci pour ces précisions

Citation

Ha bon ? Jusqu'a présent j'ai toujours utilisé des loaders pour charger mes images, je n'aurais donc pas besoin de faire cela?

En fait, tu n'as même pas besoin de bitmapData du tout puisque tu peux uploader les images dans les textures directement depuis un ByteArray (je suppose que c'est plus rapide en plus d'être plus léger car on zappe l'étape de conversion Bytes -> BitmapData->Byte->Texture ; on fait directement Bytes->Texture , ce qui ne peut qu'être plus rapide

[tlecoz]

Bon sinon, pour revenir à la question de départ.

Un Atlas correspond au duo BitmapData + donnée de positionnement de chaque image dans la texture.
Du coup, il me parait tout à faire possible de faire un "dispose" du BitmapData de L'alias tout en conservant ces données de positionnement qui reste valable coté GPU

[tlecoz]

Voilà le bout de code qui va bien pour choper les bytes de tes images directement, sans chargement ni BitmapData

var file:File = File.applicationDirectory.resolvePath("monImage.jpg");
var fileStream:FileStream = new FileStream();
fileStream.open(file, FileMode.READ);
var bytes:ByteArray = new ByteArray
fileStream.readBytes(bytes);
fileStream.close();
 

[draad]

Coucou, merci je suis tombé sur ce bout de code aussi, mais j'ai du mal a voir comment en extraire une texture a stocker dans l'atlas sans passer par une conversion on BitmapData :/

[tlecoz]

Je n'utilise jamais Starling alors je peux pas trop t'aider pour le coup des atlas (mais je pense que c'est pas sorcier)
Pour ce qui est de la Texture

var texture:Texture = context3D.createTexture();
texture.uploadFromByteArray(bytes)
 

[tlecoz]

Si tu n'as pas trouvé comment faire dans 1 semaines, remonte le sujet et je regarderai ce que je peux faire.
Là j'ai pas trop le temps

[draad]

Apparement, la classe Texture de starling n'a pas la function uploadFromByteArray, néanmoins, je pense que je pourrais faire ma propre classe Texture avec cette fonction incluse.

Je vais tenter ça, et je reviens ici pour te tenir au courant, merci !

[draad]

Coucou,

J'ai tourné un peu autour de cette approche et je suis un peu bloqué.

Dans un premier temps j'aimerais transformer le byteArray en bitmapData afin d'en extraire une texture (starling propose une fonction pour faire ça), mais je n'ai aucune idée de comment faire pour connaitre les valeurs width et height de mon bitmapData final a partir du bytesArray, y-a-t-il un moyen de retrouver ça ?

Merci.

[tlecoz]

Hello !

Je ne connais pas la solution mais à ta place - sauf si tu as un nombre astronomique de bitmapData - , je coderais les valeurs en dur

Ceci dit, si quelqu'un a la réponse à la question que tu poses, ca m'intéresse aussi

[draad]

Oui il y a la solution de faire des xml de definitions de tailles, mais si je pouvais faire ça de maniere automatisée, ca serait quand même vraiment mieu ^^

[tlecoz]

ben euh....fais toi un outil qui te fait automatiquement avec Air

[tlecoz]

Ah bah en fait ca existe
- éh dis donc, tu n'as pas beaucoup cherché ! C'est le premier lien que j'ai trouvé en tapant "as3 bytearray bitmapdata width" sur google... -

http://www.bytearray.org/?p=1089

[draad]

Merci pour le lien, j'avais deja commencé a me pencher sur comment decoder moi même un PNG, je suis tombé sur cette doc qui est deja très instructive.

http://www.w3.org/TR...-Structure.html

Quand j'aurais fini ma classe je la partagerais ici.

Citation

- éh dis donc, tu n'as pas beaucoup cherché ! C'est le premier lien que j'ai trouvé en tapant "as3 bytearray bitmapdata width" sur google... -

J'ai au contraire pas mal cherché sans trouver ma réponse, je ne cherche pas un outil qui puisse faire cela, mais la comprehension un peu plus profonde de comment lire ces data et les traiter de mon bord.

[tlecoz]

Citation

J'ai au contraire pas mal cherché sans trouver ma réponse, je ne cherche pas un outil qui puisse faire cela, mais la comprehension un peu plus profonde de comment lire ces data et les traiter de mon bord.

Je ne savais pas ce que j'allais trouvé en tapant les mots clé que j'ai tapé tu sais... Mais je suis un peu surpris d'avoir pour ma part trouver si facilement mais bon c'est pas grave

[draad]

Désolé, j'avoue que je n'ai pas eu l'idée d'ajouter le mot clef "width", mais je pense avoir essayé a peu près toutes les combinaisons de "As3 bytesArray to bitmap", "As3 bytesArray to image" ou encore du "As3 loadBytes" ou "As3 understanding byteArray".

[draad]

C'est pas mal compliqué de faire une classe qui interprete un png en fait ^^ Enfin bref, just un coucou pour dire que le sujet n'est pas a l'abandon mais que je risque de mettre un petit moment avant de poster cette fameuse classe ^^