zPosition
Chers tous,
Je constate que le fait de changer la position z d'une view ne donne nullement l'impression qu'elle s'éloigne ou se rapproche de nous.
Je suppose que c'est dû à un rendu de type orthogonal, et non en perspective (corrigez-moi si je me fourvoie, svp).
Conséquence: La view a beau s'éloigner en Z, elle ne "rapetisse" pas.
(Cela permettrait donc simplement d'organiser la superposition des views ?
Bien inutile à mon goût...)
Contre-attaque envisagée: utiliser le scale plutôt que le z.pos
Defaut anticipé: absence d'effet de parallaxe entre les views.
Contre-contre-attaque: utiliser le scale ET le z.pos
J'ai entendu parler de qq1 qui programmait une classe camera,
ça vous dit quelque-chose ?
Sinon, existe t'il une autre solution ?
Merci,
Amicales salutations du roi de la patate ^^
Je constate que le fait de changer la position z d'une view ne donne nullement l'impression qu'elle s'éloigne ou se rapproche de nous.
Je suppose que c'est dû à un rendu de type orthogonal, et non en perspective (corrigez-moi si je me fourvoie, svp).
Conséquence: La view a beau s'éloigner en Z, elle ne "rapetisse" pas.
(Cela permettrait donc simplement d'organiser la superposition des views ?
Bien inutile à mon goût...)
Contre-attaque envisagée: utiliser le scale plutôt que le z.pos
Defaut anticipé: absence d'effet de parallaxe entre les views.
Contre-contre-attaque: utiliser le scale ET le z.pos
J'ai entendu parler de qq1 qui programmait une classe camera,
ça vous dit quelque-chose ?
Sinon, existe t'il une autre solution ?
Merci,
Amicales salutations du roi de la patate ^^
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Décidément, t'es vraiment sur tous les fronts, AliGator (mon premier code promo sera pour toi
Que je comprenne bien, je déplace ma view en z comme à l'habitude, et je rajoute juste ça, tel quel ?
CATransform3D aTransform = CATransform3DIdentity;
zDistance = 850;
aTransform.m34 = 1.0 / -zDistance;
Voici un exemple de code :
Par contre j'ai de gros problèmes de fluidité des animations !!
Les mouvements sont assez saccadés, et ça c pas terrible
(j'ai une view pour le background de 960 x 640 pixels en png, animée en position x,y et z et ça rame déjà . Le pire c'est que pour l'instant c'est juste un png, mais j'avais l'intention d'animer le décors de fond avec plusieurs subviews...mais du coup j'hésite.)
Apple recommande le png pour l'iphone, mais est-ce qu'un jpg compressé ne serait qd-même pas plus gerable en terme de mémoire ?
Vos conseils concernant le mémoire sont les bienvenus ^^
Vico
La décompression des images prend du temps, BEAUCOUP de temps. L'OS ne vas pas s'amuser a décompresser les graphismes à chaque affichage, sous peine d'effondrement des performances. Donc les graphismes sont stockés en mémoire sous une forme bitmap non compressé simple à manipuler.
Le .pnj et le .jpg ne sont utiles que pour économiser de la place de stockage sur le disque. C'est déjà pas mal !
Cette histoire de compression trompe souvent les gens. "Je ne comprend pas pourquoi mon programme est aussi lent. Mes images ne prennent que quelques Mo !".
L'ennui c'est qu'une image en mémoire prend toujours 4 octets par pixel (32 bits), quelque soit sa taille sur le disque.
Histoire d'illustrer mes propos, j'ai examiné les ressources graphiques de l'exemple Metronome présent sur le site de développement Apple.
J'ai regardé les images de l'exemple Metronome fournis par Apple, pour m'apercevoir avec étonnement que toutes les ressources graphiques sont stockées dans des fichiers .png de 320x480 pixels.
Le fichier base.png contenant le dessin de la base du metronome, ne fait que 40 Ko sur le disque, malgré une taille de 320x480 pixels. C'est DRAMATIQUE !
Pourquoi ? Parce qu'une image de 320x480 pixels occupe 320x480x4 octects en mémoire, soit 614.400 octets..
40 Ko sur le disque, et 600 Ko en mémoire !
Il y a 5 images de 320x480 pixels dans le dossier des ressources graphiques du métronome, pour une taille globale de 232 Ko (sans compter l'icône de l'application!). Pourtant ces 5 images occupent 3.000 Ko (5x600 Ko), une fois chargée en mémoire !
Quand on voit que la mémoire de l'iphone n'est que de 128 Mo, ça fait peur.
Evidement, le programme Metronome fonctionne très bien. Parce qu'il ne fait pas grand chose. Une véritable application graphique, comme un jeu vidéo, a besoin de beaucoup d'images.
Pour en revenir à ton background de 960x640 pixels. Il occupe 2,4 Mo de mémoire, quelque soit son format de stockage sur le disque (png ou jpg).
Je présume que Apple conseille les png parce que leurs temps de chargement est plus rapide que celui des jpg.
Dans le cas d'une multitude d'image à afficher (comme un coverflow d'une centaine d'image de taille 200*200px ), on a donc 100*200*200*4 = 16 000 000 octets soit à la louche 16 Mo !! (et sans compter le background)
Il y a t'il des techniques d'affichage ? Du genre décharger les images non affichées etc...
les PNJ? World of Warcraft? ;D
EDIT : Et non, je n'ai jamais joué à World Of Warcraft ! Mais j'ai passé pas mal de temps a jouer en ligne avec Never WinterNight 1, avant de laisser tomber les MMO.
J'avais écrit ce texte peu de temps après avoir ma découverte de l'iPhone, en transposant des informations venus du monde Pc. J'en sais davantage maintenant, pas forcément en bien..
Grâce à un post d'AliGator, j'ai appris que le système et les applications permanentes de l'iPhone consomment beaucoup de mémoire. Et qu'au final, il ne reste que 40 Mo de disponible sur un iPhone 3G, et 156 Mo sur un 3GS. C'est bien peu !
Alors oui, il faut une stratégie sur l'utilisation des images. Ne charger en mémoire que les graphismes nécessaires sur le moment, et les décharger dés que possible.
Je te recommande d'utiliser l'outil Instrument pour connaà®tre la consommation mémoire en temps réel de tes applications. Et de n'optimiser que les endroits critiques.
Tu peut aussi utiliser des images 16 bits, pour réduire la charge mémoire. Cela ne prend que 2 octets par pixels, à la place de 4 ! Mais tu perd la transparence du canal alpha, et l'image n'a plus que 65.000 couleurs, au lieu de 16 millions.
Pour ma part, j'ai décidé de délaisser la programmation iPhone classique, pour tout faire en OpenGL. Je ne m'intéresse qu'aux jeux vidéo, et l'OpenGL est très bien pour cela.
L'un des intérêts de l'OpenGL est qu'il permet d'utiliser les textures compressées PVR. Avec ce format les images restent compressées en mémoire, ne prenant pas plus de place que sur le disque. C'est un énorme gain de place !
Dommage que CoreGraphics ne puisse utiliser ce format, et qu'il faille passer par OpenGL, dont l'emploi n'est pas spécialement simple.
La décompression des textures PVR se fait directement au sien de la puce vidéo de l'iPhone, sans recourir au processeur.
Le sample PVRTextureLoader présent sur le site Apple montre comment utiliser les textures compressées. C'est assez impressionnant.
J'ai joint à ce topic la texture utilisée en exemple.
Occupation mémoire normale : 1 Mo
Taille du fichier png sur le disque : 584 Ko
Compression PVR en haute qualité : 132 Ko
Compression PVR en moyenne qualité : 88 Ko