Voilà , c'est fait : la version eco20v3 ci-jointe a un output qui s'appelle "ValeurReculReelle". C'est une valeur qui varie entre "0" (fenêtres en position d'origine) et "1" (fenêtres en train de voler).
Donc il suffit que ton programme lise cette valeur à la fin, et ne quitte que lorsque "ValeurReculReelle" est strictement égale à "0"
Un tout premier truc : quand on bouge la souris ça quitte direct. Je suppose que tu n'a pas encore implémenté la fonction ; je te donne juste la péthode que nous avions prévue avec Boris : quand on bouge la souris, ça doit d'abord repasser ReculAutoOnOff sur FALSE, ce qui ramène hyper rapidement les fenêtres à leurs bonnes positions, et enfin, ça quitte.
C'est déjà implémenté, mais ça ne semble pas fonctionner. Pendant le "rendering", la fenêtre qui affiche le rendu (fenêtre en plein écran) monitore les événements. Dès qu'un événement souris ou clavier apparait, je repasse le flag "ReculAutoOnOff" à NO (FALSE dans votre langage). Mais, malgré un délai de 3 secondes (délai que je peux supprimer en scrutant ton "ValeurReculReelle"), les fenêtres ne reviennent pas à leur position originale.
Par ailleurs, ton "ValeurReculReelle" ne fonctionne pas : la valeur que retourne cet output est toujours la même (en flottant, ça donne 1.964847). La boucle d'attente à 0 est donc infinie.
Bon, alors prenons les deux problemes séparement : - Le probleme des fenêtre qui ne reviennent pas malgré le fait que tu laisses 3 secondes après que ton programme ai détecté un mouvement de souris. Ben là , je vois pas. Parce que le système qui gère le départ/retour des fenêtres dans la version eco20vX est exactement le même que celui de la version eco18 : la version 20, je peux pas la tester, elle a besoin de ton programme, mais la version 18, elle oui je peux la tester : elle marche impec : quand on passe "ReculAutoOnOff" sur NO, ben tout revient en une seconde. Petite remaque peut-être idiote sur ton programme preprepreview dece matin : quand je bouge la souris : ça attend pas dutout 3 secondes : ça quitte direct ! quoi en conclure ?
- Pour le probleme de "ValeurReculReelle" que j'ai ajouté dans la version eco20v3... :-\\ là aussi, c'est très étrange pour deux raisons : - la valeur ne peut pas être au dela de [0 à 1]... donc 1.964847 - quand je lis cette valeur dans QC, elle est correct. 0 quand tout est en place, 1 quand tout est au fond en train de voler, et à nouveau 0 quand tout est revenu. Donc peut-être qu'un module QC accepte de recevoir des valeurs venants de l'extérieur... mais peut-être que pour un envoyer vers l'extérieur, ça ne fonctionne pas.
Toi, de ton coté, ça ne signal pas d'erreur ? tu vois bien cette variable "ValeurReculReelle" ?
Comment l'as-tu contourné ? parce que ça donne un résultat bizzare : quand on bouge la souris, les fenêtres changent instantanément de position avant de revenir au premier plan. C'est bizzare. Elles devraient juste revenir mais pas changer de position.
Je viens d'aller voir le contenu de ton pacquet : est-ce normal que tu publie à la fois la version eco20 et la version eco20v3 ? (je dis ça au cas où ça puisse te mettre sur une piste... on sait jamais).
Il nous reste encore une manière de contourner la question des aller et retour des fenêtres : au lieu que ce soit le module QC qui gère ça, ça pourrait être ton module à toi : en fait tout se joue sur une seule variable que ton module pourrait commander : cette variable va de 0 à 1 (c'est justement l'output que je t'ai proposé). Peut-être que ce serai plus souple pour toi ? par contre, ce sera à toi de pondre la formule mathématique avec courbe douce qui va de 0 à 1 en 8 seconde (ça pourrait être réglé dans de futures préférence), et revenir de 1 à 0 en 0.5 seconde. Comme ça, ton module de programmation controle à 100% la position en profondeur des fenêtres.
Si ça t'intéresse de fonctionner comme ça : - Laisse définitivement ReculAutoOnOff sur OFF - Passe définitivement ModeReculManuel sur ON - et agit donc entre 0 et 1 sur ValeurReculManuel
Voilà . T'en dis quoi ?
EDIT : Après avoir un peu plus observé ta dernière version, il semble que ton retour soit comme si la valeur de recul fesait un brusque saut de 1 à 0.5, puis revenait progressivement à 0.
Aussi étonnant que ça puisse paraà®tre, eco20v3 se comporte différement suivant qu'elle soit exécutée dans QC, ou dans ton programme : Un simple module de comptage ne se déclanche pas pareil. Bref... J'ai contourné le problème en modifiant le module d'avance/recul automatique. Et là , ça marche PARTOUT.
J'ai rajouté deux variables qu'il faut maintenant que tu règles dès le tout début : - DureeAller qui correspond donc au temps que mettent les fenêtres pour aller en position arrière (je te conseille de mettre 8 secondes, mais ça pourrait devenir une valeur réglable dans les préférences) - DureeRetour : c'est le temps de retour (je te conseille 0.5 secondes)
Ci-jointe donc une version eco21 (et oui, j'ai fait des modifs profondent là : Boris, quand il reviendra nous filer un coup de main sur le rendu visuel, devra repartir de cette version 21, sinon ça marchera plus)
BILAN :
- Au niveau du retour, c'est maintenant magnifique, la transition est parfaite, on y voit que du feu !!! - Au niveau de l'allée : ben c'est bizzare parce que ça fait un flash tout noir entre l'écran normal, et la fenêtre plein écran que tu affiche... alors que vu l'ordre dans lequel tu fais faire les chose, ça devait pas ! Encore un bug qu'on va devoir contourner... mais là , y'a que toi, Bru, qui peut le faire... - Au niveau de l'animation elle-même, et bien bizzarement, le probleme des reflets qui se croisent avec leur image est revenu C'est Boris qui va pas être content !!! - Bru, ça doit être fait expres, mais y'a un mini fenêtre vide qui apparaà®t au lancement de l'appli...
Bon, ci-joint également l'appli avec le module eco20v3 qui fonctionne pour que tout le monde ici puisse voir ce que ça donne... mais il ne faut surtout plus utiliser la version eco20v3 qu'il y a dedans ! Sinon on va se meller les papates !
Et puis pour le fun (faut bien s'amuser un peu) ci-jointe une version corrigée mais sans le dégradé de gris de FrontRow ; juste les reflets : Et ben je trouve ça beaucoup plus classe ! Et vous ?
- Au niveau de l'allée : ben c'est bizzare parce que ça fait un flash tout noir entre l'écran normal, et la fenêtre plein écran que tu affiche... alors que vu l'ordre dans lequel tu fais faire les chose, ça devait pas ! Encore un bug qu'on va devoir contourner... mais là , y'a que toi, Bru, qui peut le faire...
Le flash est supprimé (enfin, plutôt atténué).
dans 1138612964:
- Bru, ça doit être fait expres, mais y'a un mini fenêtre vide qui apparaà®t au lancement de l'appli...
C'est juste une fenêtre de test. Elle est aisément supprimable, mais pour le moment je la laisse. Bien entendu, dans une release finale, elle ne sera plus là .
dans 1138648060:
Bru, une question qui me vient : est-ce que tu peux activer l'anti-aliasing pour la fenêtre de rendu ?
A priori, non. Si cela est faisable, c'est uniquement au niveau de QC. J'ai tenté d'enlever l'aliasing au niveau du contextre graphique, mais ça ne change rien.
A priori, non. Si cela est faisable, c'est uniquement au niveau de QC. J'ai tenté d'enlever l'aliasing au niveau du contextre graphique, mais ça ne change rien.
Cela se règle par OpenGL (FSAA si ça te dis quelque chose). Par contre pour les performances, c'est pas bon du tout. Qualité max, 7-11 fps (FSAA 6x), qualité moyenne, 11-13fps(FSAA 4x), et qualité basse 22-31fps (FSAA2x) et qualité min 55-61fps (pas de FSAA). (ATI 9700 Mobility 128Mo de VRAM, les réglages peuvent être modifiés avec ATI Displays pour ceux que ça intéresse ...à condition d'avoir une ATI).
Je pense que pour des raisons de performances, cela vaudrait vraiment la peine de diminuer la résolution des images (je n'avais que 4 fenêtres dans ces tests).
Note Pour les dual screen toujours, les fenêtres des 2 écrans sont intégrées dans l'animation.
Avant de passer au vif du sujet, une petite question sur le FSAA : oui, effectivement, je me suis amusé à l'activé via le dernier pilote ATI v4.5.7 (dispo ici : https://support.ati.com/ics/support/default.asp?deptID=894&task=knowledge&folderID=27 dans la partie Macos bien sur) Est-il possible d'activer le FSAA à partir du programme lui-même plutôt que par le pilote d'ATI ? Genre, une case décochée par défaut dans les prefs de l'eco d'écran, mais que l'on puisse cocher si on a une CG de fou !
Encore avant le vif du sujet, à propos de baisser la résolution : je pense qu'il faut parier sur l'avenir pour cet inutilitaire ; l'avenir, c'est des macs avec de grosses cartes graphiques. (sur mon PowerBook ATI mobility9700 128Mo de VRAM, j'ai 60fps avec 12 fenêtres... très très acceptable quand même // sur le macmini, j'ai 20 fps... bon... en même temps le mac mini...). Et puis baisser la résolution risque selon moi de faire un effet bizzare au moment de la transition normal/eco. Enfin, donnons nos avis et décidons !
Le vif du sujet : c'est un message pour Bru, mais également pour Boris Cargo : Vous avez fait un boulot formidable : Je voudrais vraiment vous remercier Je sais que ce n'est pas fini, mais là , quand même je ne peux pas ne pas le dire : BRA-VO Bru, j'ai été chiant, j'en suis conscient, j'assume ; mais là : pfiouuuuu !!! Ton boulot de l'ombre d'avoir décortiqué tout ce qui est non documenté : Ouaaaaa !!! Bref... voilà ...
La suite maintenant ? Ben... est-ce que la même chose fonctionnera pareil dans un eco d'écran ? est-ce qu'un flash noir au début et à la fin ne risque pas d'apparaà®tre ? est-ce qu'un mouvement de souris à la fin ne fera pas tout quitter avant même que les fenêtres n'aient le temps de revenir ?... Comment cela se passera-t-il s'il y a un second ecran ? (on peut peut-être simplement le rendre noir pour une première version publique si ça demandait trop trop de boulot)
Pour l'animation elle-même, si Boris revient parmis nous, j'aurai deux trois idée à proposer... sinon, ben j'esserai de comprendre ce qu'il à pondu pour améliorer de trois trucs... et essayer de corriger le probleme des reflets qui se chevauchent.
Voilà , un petit message en forme de bilan, de GRAND MERCI, et de "on continu ?"
Encore avant le vif du sujet, à propos de baisser la résolution : je pense qu'il faut parier sur l'avenir pour cet inutilitaire ; l'avenir, c'est des macs avec de grosses cartes graphiques. (sur mon PowerBook ATI mobility9700 128Mo de VRAM, j'ai 60fps avec 12 fenêtres... très très acceptable quand même // sur le macmini, j'ai 20 fps... bon... en même temps le mac mini...). Et puis baisser la résolution risque selon moi de faire un effet bizzare au moment de la transition normal/eco. Enfin, donnons nos avis et décidons !
L'avenir c'est aussi un déplacement de la gestion de Quartz du CPU/RAM vers le GPU/VRAM (ça s'appelle Quartz 2D Extreme). Autrement dit, lorsque qu'un scroll sera effectué dans une page web, c'est la carte graphique qui sera sollicitée et pas le processseur. Donc sur cette base, faire un truc sans compter sur base "les prochains macs auront une grosse carte graphique" peut etre dangereux, dans la mesure où 1. cette carte graphique va être nettement plus sollicitée et 2. les transferts massifs entre RAM et VRAM sont assez lents, donc un gars qui aurait beaucoup de fenêtres risquerait de voir son ordi "immobilisé" un peu de temps après avoir désactivé le screen (pour te donner un exemple, sur mon Powerbook après avoir quitté Call of Duty, OmniWeb (les navigateurs seraient parmi les applications les plus gourmandes en VRAM) reste figé pendant plus de 5min avec Quartz 2D Extreme activé contre une ou deux sans l'avoir activé). C'est un point à ne pas négliger, surtout pour un inutilitaire. Quand à la diminution de la résolution, ça ferait un drole d'effet pour la première et la dernière image, mais tant que c'est en mouvement pas de problème.
Oui, je vois très bien ce que tu veux dire, et effectivement, il ne faut pas qu'un eco d'écran monopolise la machine.
J'avoue que baisser la résolution me ferai très très bizzare : c'est comme si on baissait la résolution de FrontRow : ça aurait beaucoup moin de classe.
En revanche, tu fais bien de mettre le doight sur ce probleme, parce que une idée que l'on avait eu me revient : dans les options de l'éco d'écran, que l'on puisse régler le nombre de fenêtre à faire voler : de 5 à 15. Si c'est 5 : on prend les 4 premières et le fond. Si c'est 15 : on prend les 14 premières et le fond. Sachant qu'au delà de 6 ou 7 fenêtres, souvent, on ne voit plus vraiment celles de derrière, donc on ne s'appercevra pas qu'elles ne sont pas prises en compte dans l'éco.
En poussant l'idée, je me demande s'il serait possible de laisser l'économiseur d'écran choisir lui-même combien de fenêtre prendre en fonction des ressources dispos au moment où il se lance. Là , je suppose que ça complique vraiment le projet, et ça pourrait n'être inclu que dans une seconde version. Mais qu'en dites vous ? Et pour les spécialistes, dans quelle mesure est-ce faisable ? Et si c'est faisable, est ce que quelqu'un d'autre que Bru aimerai s'en charger, histoire de le libérer un peu (a moins que t'en ai très envie Bru ;-)) ?
FSAA est une technique OpenGL d'anti-aliaser les "scènes" (terminologie OpenGL). Il est possible, par programme, d'utiliser ou non FSAA, mais dans l'affirmative, cela impose de modifier un certain nombre de paramètres au niveau du contexte OpenGL, et surtout, au niveau du buffer des pixels.
Or, tel qu'est architecturé le screen-saver de Vinc26, je n'ai aucune maà®trise sur le rendu QC, puisque c'est QC lui-même qui se charge de l'affichage. Le programme ne fait qu'exploiter une QCView dans laquelle tourne le rendu, mais cela reste essentiellement pour le programme une boite noire.
Utiliser FSAA imposerait de ne plus utiliser QC et ses .qtz, et de gérer par programme, via OpenGL, le flottement des images. Ce n'est pas impossible (c'était même, au début du projet, l'une des pistes sérieusement envisagée).
Oui, et peut-être qu'un jour, quequ'un aura envie de tenter une version OpenGL de la chose ; un bon support pour apprendre. Qui vivra verra.
Donc ok pour l'anti-aliasing j'ai bien compris qu'on doit laisser tomber. C'est vraiment pas grave dutout. Je sais perso que dans QC on ne peut pas l'activer. Donc voilou !
La suite maintenant ? Ben... est-ce que la même chose fonctionnera pareil dans un eco d'écran ? est-ce qu'un flash noir au début et à la fin ne risque pas d'apparaà®tre ? est-ce qu'un mouvement de souris à la fin ne fera pas tout quitter avant même que les fenêtres n'aient le temps de revenir ?... Comment cela se passera-t-il s'il y a un second ecran ? (on peut peut-être simplement le rendre noir pour une première version publique si ça demandait trop trop de boulot)
J'ai commencé la partie screen-saver.
Pour les dual-screen, faut que j'active le dual-screen de mon imac G5 afin de faire les tests adéquats.
Ok, de mon coté (même si j'espère que Boris revienne ici... mais il m'avait dit qu'il serait très peu là pendant quelques temps), je bosse sur le probleme des reflets. Ca risque de prendre quelques jours parce que j'ai deux gros boulots a finir ces temps-ci.
A très bientôt
[EDIT : C'est très bizzare ce probleme de reflets. J'ai regardé dans d'anciennes versions v17 ou v18 qui a l'époque n'en avait pas, maitenant elles en ont... enfin je crois... bref, une seul personne peut reprendre cette partie : c'est BorisCargo :why?: Je vais essayer de le joindre directement]
hello. Bon ça commence a avoir de la gueule cette histoire.
il me semble avoir résolut le prb des reflets. Je viens d'y passer 2h, j'ai donc pu me planter, tous ces spagettis sont difficiles à déméler quand on reviens sur un projet...
Je voudrais quand même ajouter que je préfere avec le dégradé, il me semble que ça asseoit les choses, j'ai apporté une modif au niveau de la luminosité des fenetres, plus elle est loin - elle est lumineuse, je pense que ça aide à lire les différents plans.
Je trouve genant que le fond vole également, je ferais bien un essais avec le fond d'écran qui recule mais en restant collé au sol.
Sinon dans QC on peut mettre un antialiasing au niveau des textures mais il faudrait que je regarde ça de plus pres parce que là les images sont par le programme et non pas en drag/drop. J'ai les yeux qui piquent mais je suis content de voir que ça avance dur. Bonne nuit à tous.
Oui, c'est vrai que c'est moins pratique maintenant qu'on bosse via le programme, et que c'est lui qui envoi les contenus. Ma méthode, c'est d'afficher le contenu du paquet du programme, d'aller dans Ressources, et d'éditer directement le module QC. Ainsi, avec un raccourcis du programme dans le doc, on peut éditer dans QC, sauver rapidement via pomme+s, et d'un clic sur le programme dans le dock pour voir ce que ça donne. Cela dit, ça ne permet plus d'utiliser la fonction pomme+T pour régler la volée certain paramêtre. Peut-être vas-tu devoir pondre un version "universelle" : qui, par une case cochée, charge ses propres textures et valeurs interne, ou décochée, laisse le programme s'en charger... ainsi, vous deux, Bru et Boris, pourriez bosser en parrallele avec le même module... enfin, juste une idée...
il me semble avoir résolut le prb des reflets. Je viens d'y passer 2h, j'ai donc pu me planter, tous ces spagettis sont difficiles à déméler quand on reviens sur un projet...
Ben tu as l'air de t'en être très bien tiré !!! J'ai pas encore réussi à reproduire le bug . En revanche, mais je suppose que c'est la rançon du succès, toutes les fenêtres un peu grande volent systèmatiquement très haut... c'est logique bien sûr. Tantpis
Alors pour donner l'impression que c'est moins "attroupé", je me demande si ce serait pas mieux d'élargir un peu l'espace de flotaison, quite à ce que des fenêtres quittent carrement temporairement l'écran à droite ou à gauche. T'en dit quoi ?
Je voudrais quand même ajouter que je préfere avec le dégradé, il me semble que ça asseoit les choses,
Ben là , les deux versions se défendent. Juste que depuis que les fenêtres se retourne, et donc depuis de le dégradé était composé de 2 couches gris (une en fond, et une par dessus les reflets) et ben ça avait un rendu très moche sur LCD : ça fait pas un dégradé lisse, mais des tranches franche... (Merci les LCD.........) D'où l'idée du fond noir, que je trouve pas mal. Enfin voilà le pourquoi du comment. Pour info, dans cette version noir, il y a encore un dégradé noir par dessus les reflets. Bref... je suis partagé entre du pas très beau sur certain LCD, et du beau sur les très bons LCD et CRT... Alors ? on fait quoi ? une future option dans l'economiseur ? (bien que je pense qu'il faille trancher sans quoi y'aura trop d'option)
j'ai apporté une modif au niveau de la luminosité des fenetres, plus elle est loin - elle est lumineuse, je pense que ça aide à lire les différents plans.
Par-fait !!! Dans la même idée qu'élargir l'espace (voir ci-dessus) est ce qu'on ne pourrait pas le "profondir" aussi un peu ?
Je trouve genant que le fond vole également, je ferais bien un essais avec le fond d'écran qui recule mais en restant collé au sol.
Vas-y, tente le si tu te sens. Bonne idée. A voir. Un peu comme dans FrontRow...
Sinon dans QC on peut mettre un antialiasing au niveau des textures
A essayer aussi... en surveillant les performances Je sais juste que quand on agit sur le FSAA (voir posts précédents) ça n'agit que sur le bord des fenêtres, et pas sur le contenu. Faudrait donc voir sur quoi agit ton anti aliasing
Moi aussi j'ai les yeux qui piquent ! Mais j'ai pô fini... un boulot à rendre pour demain matin, que je suis en train de calculer en FinalCutPro, avant de le poster sur un serveur... c long....... et les yeux piquent !!!
(moi content que toute l'équipe soit réunie... merci les gars... j'espère que vous y apprenez des trucs dans ce projets... moi oui )
Une ou deux idées qui me sont venues après un tout petit sommeil...
- A propos de l'élargissment de l'espace de flotaison, en profondeur et en largeur, je me disait que cet élargissment pourrait-être proportionel au nombre de fenêtre à l'écran : à 5 fenêtres ou moins, tout reste dans l'écran (en gros hein), et à 15 fenêtres, l'espace est multiplié par 2 (et donc en moyenne, la moitié des fenêtres sont à l'extérieur à gauche et à droite). Z'en dites quoi ?
- A propos des reflets, je confirme, ça se chevauche plus. Il ne reste plus qu'un seul bug, c'est que si une fenêtre (de préférence au premier plan) a été déplacée de manière à ce que son contenu aille loin au delà du bords de l'écran en bas, lors de l'animation de "départ", ça fait un truc bizzare avec les reflets : y'a un flash de reflet. De mon coté, je viens de fouiller là dessus, et je fouille encore... si je trouve, j'édite ce post.
Bon, je trouve pas pour le dernier bug de reflet Désolé, j'aurai bien voulu aider.
Et en plus, j'ai trouvé un nouveau bug introduit par eco22 : quand on l'integre au programme (en le mettant dansle paquet et en l'appelant eco21) et bien le fond fait une inversion verticale au tout tout départ des fenêtres, et à la toute fin de leur retour (ça se voit surtout au retour puisque Bru à mis une tempo d'une seconde là ou ça revient en fait en 0,5secondes... il reste donc 0,5seconde pour voir le bleme...
Des nouvelles du screen-saver... En fait des mauvaises nouvelles !
Le module screen-saver est à peu près fait. Tout fonctionne nickel, jusqu'au moment où intervient l'événement qui va faire disparaitre le SC.
Et "disparaitre" est bien le mot : pas d'effet de retour des fenêtres en position initiale !
Bref pour le moment, c'est l'impasse !
Edit : j'ai peut-être une solution... C'est un peu crasse, mais ça peut marcher ! Edit2 : je supprime la version du SC. Voir post plus bas pour nouvelle version. .
Réponses
Donc il suffit que ton programme lise cette valeur à la fin, et ne quitte que lorsque "ValeurReculReelle" est strictement égale à "0"
J'espère que ça va te convenir ::)
[Fichier joint supprimé par l'administrateur]
Juste une petite remarque: pour les dual screen seul l'écran principal est OK, l'écran secondaire reste normal.
C'est déjà implémenté, mais ça ne semble pas fonctionner.
Pendant le "rendering", la fenêtre qui affiche le rendu (fenêtre en plein écran) monitore les événements.
Dès qu'un événement souris ou clavier apparait, je repasse le flag "ReculAutoOnOff" à NO (FALSE dans votre langage). Mais, malgré un délai de 3 secondes (délai que je peux supprimer en scrutant ton "ValeurReculReelle"), les fenêtres ne reviennent pas à leur position originale.
Par ailleurs, ton "ValeurReculReelle" ne fonctionne pas : la valeur que retourne cet output est toujours la même (en flottant, ça donne 1.964847). La boucle d'attente à 0 est donc infinie.
.
Ceci est normal.
C'est une appli qui simule un screen-saver.
La simulation se contente de créer une fenêtre "plein écran" au dimension du "mainScreen" (voir classe NSScreen).
Quand tout sera transformé en module screen-saver, l'effet sera différent.
La question est : quel sera cet effet ?
.
Bon, alors prenons les deux problemes séparement :
- Le probleme des fenêtre qui ne reviennent pas malgré le fait que tu laisses 3 secondes après que ton programme ai détecté un mouvement de souris. Ben là , je vois pas. Parce que le système qui gère le départ/retour des fenêtres dans la version eco20vX est exactement le même que celui de la version eco18 : la version 20, je peux pas la tester, elle a besoin de ton programme, mais la version 18, elle oui je peux la tester : elle marche impec : quand on passe "ReculAutoOnOff" sur NO, ben tout revient en une seconde.
Petite remaque peut-être idiote sur ton programme preprepreview dece matin : quand je bouge la souris : ça attend pas dutout 3 secondes : ça quitte direct ! quoi en conclure ?
- Pour le probleme de "ValeurReculReelle" que j'ai ajouté dans la version eco20v3... :-\\ là aussi, c'est très étrange pour deux raisons :
- la valeur ne peut pas être au dela de [0 à 1]... donc 1.964847
- quand je lis cette valeur dans QC, elle est correct. 0 quand tout est en place, 1 quand tout est au fond en train de voler, et à nouveau 0 quand tout est revenu.
Donc peut-être qu'un module QC accepte de recevoir des valeurs venants de l'extérieur... mais peut-être que pour un envoyer vers l'extérieur, ça ne fonctionne pas.
Toi, de ton coté, ça ne signal pas d'erreur ? tu vois bien cette variable "ValeurReculReelle" ?
A suivre donc,
J'ai contourné le problème.
Voici le résultat ci-joint.
Edit : suppression du fichier joint. Voir les messages suivants pour une nouvelle version.
.
Je viens d'aller voir le contenu de ton pacquet : est-ce normal que tu publie à la fois la version eco20 et la version eco20v3 ? (je dis ça au cas où ça puisse te mettre sur une piste... on sait jamais).
Il nous reste encore une manière de contourner la question des aller et retour des fenêtres : au lieu que ce soit le module QC qui gère ça, ça pourrait être ton module à toi : en fait tout se joue sur une seule variable que ton module pourrait commander : cette variable va de 0 à 1 (c'est justement l'output que je t'ai proposé). Peut-être que ce serai plus souple pour toi ? par contre, ce sera à toi de pondre la formule mathématique avec courbe douce qui va de 0 à 1 en 8 seconde (ça pourrait être réglé dans de futures préférence), et revenir de 1 à 0 en 0.5 seconde.
Comme ça, ton module de programmation controle à 100% la position en profondeur des fenêtres.
Si ça t'intéresse de fonctionner comme ça :
- Laisse définitivement ReculAutoOnOff sur OFF
- Passe définitivement ModeReculManuel sur ON
- et agit donc entre 0 et 1 sur ValeurReculManuel
Voilà . T'en dis quoi ?
EDIT : Après avoir un peu plus observé ta dernière version, il semble que ton retour soit comme si la valeur de recul fesait un brusque saut de 1 à 0.5, puis revenait progressivement à 0.
A l'arrivée d'un événement :
.
Aussi étonnant que ça puisse paraà®tre, eco20v3 se comporte différement suivant qu'elle soit exécutée dans QC, ou dans ton programme : Un simple module de comptage ne se déclanche pas pareil. Bref... J'ai contourné le problème en modifiant le module d'avance/recul automatique. Et là , ça marche PARTOUT.
J'ai rajouté deux variables qu'il faut maintenant que tu règles dès le tout début :
- DureeAller qui correspond donc au temps que mettent les fenêtres pour aller en position arrière (je te conseille de mettre 8 secondes, mais ça pourrait devenir une valeur réglable dans les préférences)
- DureeRetour : c'est le temps de retour (je te conseille 0.5 secondes)
Ci-jointe donc une version eco21 (et oui, j'ai fait des modifs profondent là : Boris, quand il reviendra nous filer un coup de main sur le rendu visuel, devra repartir de cette version 21, sinon ça marchera plus)
BILAN :
- Au niveau du retour, c'est maintenant magnifique, la transition est parfaite, on y voit que du feu !!!
- Au niveau de l'allée : ben c'est bizzare parce que ça fait un flash tout noir entre l'écran normal, et la fenêtre plein écran que tu affiche... alors que vu l'ordre dans lequel tu fais faire les chose, ça devait pas ! Encore un bug qu'on va devoir contourner... mais là , y'a que toi, Bru, qui peut le faire...
- Au niveau de l'animation elle-même, et bien bizzarement, le probleme des reflets qui se croisent avec leur image est revenuÂ
- Bru, ça doit être fait expres, mais y'a un mini fenêtre vide qui apparaà®t au lancement de l'appli...
Bon, ci-joint également l'appli avec le module eco20v3 qui fonctionne pour que tout le monde ici puisse voir ce que ça donne... mais il ne faut surtout plus utiliser la version eco20v3 qu'il y a dedans ! Sinon on va se meller les papates !
[Fichier joint supprimé par l'administrateur]
En plus c'est un poil moins lourd à calculer...
[Fichier joint supprimé par l'administrateur]
Ca c'est décoinssé d'un seul coup ce projet!
Vraiment impressionnant.
Le flash est supprimé (enfin, plutôt atténué).
C'est juste une fenêtre de test. Elle est aisément supprimable, mais pour le moment je la laisse. Bien entendu, dans une release finale, elle ne sera plus là .
A priori, non. Si cela est faisable, c'est uniquement au niveau de QC. J'ai tenté d'enlever l'aliasing au niveau du contextre graphique, mais ça ne change rien.
.
[Fichier joint supprimé par l'administrateur]
Cela se règle par OpenGL (FSAA si ça te dis quelque chose). Par contre pour les performances, c'est pas bon du tout. Qualité max, 7-11 fps (FSAA 6x), qualité moyenne, 11-13fps(FSAA 4x), et qualité basse 22-31fps (FSAA2x) et qualité min 55-61fps (pas de FSAA). (ATI 9700 Mobility 128Mo de VRAM, les réglages peuvent être modifiés avec ATI Displays pour ceux que ça intéresse ...à condition d'avoir une ATI).
Je pense que pour des raisons de performances, cela vaudrait vraiment la peine de diminuer la résolution des images (je n'avais que 4 fenêtres dans ces tests).
Note Pour les dual screen toujours, les fenêtres des 2 écrans sont intégrées dans l'animation.
Est-il possible d'activer le FSAA à partir du programme lui-même plutôt que par le pilote d'ATI ? Genre, une case décochée par défaut dans les prefs de l'eco d'écran, mais que l'on puisse cocher si on a une CG de fou !
Encore avant le vif du sujet, à propos de baisser la résolution : je pense qu'il faut parier sur l'avenir pour cet inutilitaire ; l'avenir, c'est des macs avec de grosses cartes graphiques. (sur mon PowerBook ATI mobility9700 128Mo de VRAM, j'ai 60fps avec 12 fenêtres... très très acceptable quand même // sur le macmini, j'ai 20 fps... bon... en même temps le mac mini...). Et puis baisser la résolution risque selon moi de faire un effet bizzare au moment de la transition normal/eco. Enfin, donnons nos avis et décidons !
Le vif du sujet : c'est un message pour Bru, mais également pour Boris Cargo : Vous avez fait un boulot formidable : Je voudrais vraiment vous remercier
Bru, j'ai été chiant, j'en suis conscient, j'assume ; mais là : pfiouuuuu !!! Ton boulot de l'ombre d'avoir décortiqué tout ce qui est non documenté : Ouaaaaa !!! Bref... voilà ...
La suite maintenant ? Ben... est-ce que la même chose fonctionnera pareil dans un eco d'écran ? est-ce qu'un flash noir au début et à la fin ne risque pas d'apparaà®tre ? est-ce qu'un mouvement de souris à la fin ne fera pas tout quitter avant même que les fenêtres n'aient le temps de revenir ?... Comment cela se passera-t-il s'il y a un second ecran ? (on peut peut-être simplement le rendre noir pour une première version publique si ça demandait trop trop de boulot)
Pour l'animation elle-même, si Boris revient parmis nous, j'aurai deux trois idée à proposer... sinon, ben j'esserai de comprendre ce qu'il à pondu pour améliorer de trois trucs... et essayer de corriger le probleme des reflets qui se chevauchent.
Voilà , un petit message en forme de bilan, de GRAND MERCI, et de "on continu ?"
L'avenir c'est aussi un déplacement de la gestion de Quartz du CPU/RAM vers le GPU/VRAM (ça s'appelle Quartz 2D Extreme). Autrement dit, lorsque qu'un scroll sera effectué dans une page web, c'est la carte graphique qui sera sollicitée et pas le processseur. Donc sur cette base, faire un truc sans compter sur base "les prochains macs auront une grosse carte graphique" peut etre dangereux, dans la mesure où 1. cette carte graphique va être nettement plus sollicitée et 2. les transferts massifs entre RAM et VRAM sont assez lents, donc un gars qui aurait beaucoup de fenêtres risquerait de voir son ordi "immobilisé" un peu de temps après avoir désactivé le screen (pour te donner un exemple, sur mon Powerbook après avoir quitté Call of Duty, OmniWeb (les navigateurs seraient parmi les applications les plus gourmandes en VRAM) reste figé pendant plus de 5min avec Quartz 2D Extreme activé contre une ou deux sans l'avoir activé). C'est un point à ne pas négliger, surtout pour un inutilitaire. Quand à la diminution de la résolution, ça ferait un drole d'effet pour la première et la dernière image, mais tant que c'est en mouvement pas de problème.
J'avoue que baisser la résolution me ferai très très bizzare : c'est comme si on baissait la résolution de FrontRow : ça aurait beaucoup moin de classe.
En revanche, tu fais bien de mettre le doight sur ce probleme, parce que une idée que l'on avait eu me revient : dans les options de l'éco d'écran, que l'on puisse régler le nombre de fenêtre à faire voler : de 5 à 15.
Si c'est 5 : on prend les 4 premières et le fond.
Si c'est 15 : on prend les 14 premières et le fond.
Sachant qu'au delà de 6 ou 7 fenêtres, souvent, on ne voit plus vraiment celles de derrière, donc on ne s'appercevra pas qu'elles ne sont pas prises en compte dans l'éco.
En poussant l'idée, je me demande s'il serait possible de laisser l'économiseur d'écran choisir lui-même combien de fenêtre prendre en fonction des ressources dispos au moment où il se lance. Là , je suppose que ça complique vraiment le projet, et ça pourrait n'être inclu que dans une seconde version. Mais qu'en dites vous ? Et pour les spécialistes, dans quelle mesure est-ce faisable ? Et si c'est faisable, est ce que quelqu'un d'autre que Bru aimerai s'en charger, histoire de le libérer un peu (a moins que t'en ai très envie Bru ;-)) ?
FSAA est une technique OpenGL d'anti-aliaser les "scènes" (terminologie OpenGL).
Il est possible, par programme, d'utiliser ou non FSAA, mais dans l'affirmative, cela impose de modifier un certain nombre de paramètres au niveau du contexte OpenGL, et surtout, au niveau du buffer des pixels.
Or, tel qu'est architecturé le screen-saver de Vinc26, je n'ai aucune maà®trise sur le rendu QC, puisque c'est QC lui-même qui se charge de l'affichage. Le programme ne fait qu'exploiter une QCView dans laquelle tourne le rendu, mais cela reste essentiellement pour le programme une boite noire.
Utiliser FSAA imposerait de ne plus utiliser QC et ses .qtz, et de gérer par programme, via OpenGL, le flottement des images. Ce n'est pas impossible (c'était même, au début du projet, l'une des pistes sérieusement envisagée).
.
Donc ok pour l'anti-aliasing j'ai bien compris qu'on doit laisser tomber. C'est vraiment pas grave dutout. Je sais perso que dans QC on ne peut pas l'activer. Donc voilou !
Concentrons-nous sur l'essentiel.
J'ai commencé la partie screen-saver.
Pour les dual-screen, faut que j'active le dual-screen de mon imac G5 afin de faire les tests adéquats.
.
A très bientôt
[EDIT : C'est très bizzare ce probleme de reflets. J'ai regardé dans d'anciennes versions v17 ou v18 qui a l'époque n'en avait pas, maitenant elles en ont... enfin je crois... bref, une seul personne peut reprendre cette partie : c'est BorisCargo :why?: Je vais essayer de le joindre directement]
il me semble avoir résolut le prb des reflets. Je viens d'y passer 2h, j'ai donc pu me planter, tous ces spagettis sont difficiles à déméler quand on reviens sur un projet...
Je voudrais quand même ajouter que je préfere avec le dégradé, il me semble que ça asseoit les choses, j'ai apporté une modif au niveau de la luminosité des fenetres, plus elle est loin - elle est lumineuse, je pense que ça aide à lire les différents plans.
Je trouve genant que le fond vole également, je ferais bien un essais avec le fond d'écran qui recule mais en restant collé au sol.
Sinon dans QC on peut mettre un antialiasing au niveau des textures mais il faudrait que je regarde ça de plus pres parce que là les images sont par le programme et non pas en drag/drop.
J'ai les yeux qui piquent mais je suis content de voir que ça avance dur. Bonne nuit à tous.
[Fichier joint supprimé par l'administrateur]
Oui, c'est vrai que c'est moins pratique maintenant qu'on bosse via le programme, et que c'est lui qui envoi les contenus.
Ma méthode, c'est d'afficher le contenu du paquet du programme, d'aller dans Ressources, et d'éditer directement le module QC. Ainsi, avec un raccourcis du programme dans le doc, on peut éditer dans QC, sauver rapidement via pomme+s, et d'un clic sur le programme dans le dock pour voir ce que ça donne. Cela dit, ça ne permet plus d'utiliser la fonction pomme+T pour régler la volée certain paramêtre. Peut-être vas-tu devoir pondre un version "universelle" : qui, par une case cochée, charge ses propres textures et valeurs interne, ou décochée, laisse le programme s'en charger... ainsi, vous deux, Bru et Boris, pourriez bosser en parrallele avec le même module... enfin, juste une idée...
Ben tu as l'air de t'en être très bien tiré !!! J'ai pas encore réussi à reproduire le bug
Alors pour donner l'impression que c'est moins "attroupé", je me demande si ce serait pas mieux d'élargir un peu l'espace de flotaison, quite à ce que des fenêtres quittent carrement temporairement l'écran à droite ou à gauche. T'en dit quoi ?
Ben là , les deux versions se défendent. Juste que depuis que les fenêtres se retourne, et donc depuis de le dégradé était composé de 2 couches gris (une en fond, et une par dessus les reflets) et ben ça avait un rendu très moche sur LCD : ça fait pas un dégradé lisse, mais des tranches franche... (Merci les LCD.........) D'où l'idée du fond noir, que je trouve pas mal. Enfin voilà le pourquoi du comment.
Pour info, dans cette version noir, il y a encore un dégradé noir par dessus les reflets.
Bref... je suis partagé entre du pas très beau sur certain LCD, et du beau sur les très bons LCD et CRT... Alors ? on fait quoi ? une future option dans l'economiseur ? (bien que je pense qu'il faille trancher sans quoi y'aura trop d'option)
Par-fait !!!
Dans la même idée qu'élargir l'espace (voir ci-dessus) est ce qu'on ne pourrait pas le "profondir" aussi un peu ?
Vas-y, tente le si tu te sens. Bonne idée. A voir. Un peu comme dans FrontRow...
A essayer aussi... en surveillant les performances
Je sais juste que quand on agit sur le FSAA (voir posts précédents) ça n'agit que sur le bord des fenêtres, et pas sur le contenu. Faudrait donc voir sur quoi agit ton anti aliasing
Moi aussi j'ai les yeux qui piquent ! Mais j'ai pô fini... un boulot à rendre pour demain matin, que je suis en train de calculer en FinalCutPro, avant de le poster sur un serveur... c long....... et les yeux piquent !!!
(moi content que toute l'équipe soit réunie... merci les gars... j'espère que vous y apprenez des trucs dans ce projets... moi oui
Une ou deux idées qui me sont venues après un tout petit sommeil...
- A propos de l'élargissment de l'espace de flotaison, en profondeur et en largeur, je me disait que cet élargissment pourrait-être proportionel au nombre de fenêtre à l'écran : à 5 fenêtres ou moins, tout reste dans l'écran (en gros hein), et à 15 fenêtres, l'espace est multiplié par 2 (et donc en moyenne, la moitié des fenêtres sont à l'extérieur à gauche et à droite). Z'en dites quoi ?
- A propos des reflets, je confirme, ça se chevauche plus. Il ne reste plus qu'un seul bug, c'est que si une fenêtre (de préférence au premier plan) a été déplacée de manière à ce que son contenu aille loin au delà du bords de l'écran en bas, lors de l'animation de "départ", ça fait un truc bizzare avec les reflets : y'a un flash de reflet. De mon coté, je viens de fouiller là dessus, et je fouille encore... si je trouve, j'édite ce post.
Et en plus, j'ai trouvé un nouveau bug introduit par eco22 : quand on l'integre au programme (en le mettant dansle paquet et en l'appelant eco21) et bien le fond fait une inversion verticale au tout tout départ des fenêtres, et à la toute fin de leur retour (ça se voit surtout au retour puisque Bru à mis une tempo d'une seconde là ou ça revient en fait en 0,5secondes... il reste donc 0,5seconde pour voir le bleme...
Voilà !
Le module screen-saver est à peu près fait.
Tout fonctionne nickel, jusqu'au moment où intervient l'événement qui va faire disparaitre le SC.
Et "disparaitre" est bien le mot : pas d'effet de retour des fenêtres en position initiale !
Bref pour le moment, c'est l'impasse !
Edit : j'ai peut-être une solution... C'est un peu crasse, mais ça peut marcher !
Edit2 : je supprime la version du SC. Voir post plus bas pour nouvelle version.
.
Bon, ça fonctionne. Je relivre une nouvelle version.
Edit : version supprimée au profit d'une plus récente quelques posts plus bas.
.
Par contre quand je teste l'eco dans les prefSystem le retour est "violent"...