[DIRMX04] Toujours le bug : maj champ = updateStage
4 réponses
PJ
Bonjour,
J'avais laissé Director à sa version 8.5 et je travaille maintenant sur
la version MX 2004.
J'ai aussi retrouvé un viel ami : le bug de la mise à jour des champs.
En pratique : toute mise à jour d'un champ dans un "prepareFrame" (ou
autre script de préparation de la frame) force un rafraichissement de la
scene en cours de préparation, et montre ainsi la mise en place des
éléments (changement d'images...), alors que vous auriez aimé une
apparition unique et propre de votre écran terminé. Inutile de dire que
le rendu final est très amateur !
Seule parade : décaler les maj de champs le plus tard possible (même si
le 1er champ mis à jour déclenchera un updateStage et montrera les
autres changements)
Avez-vous une meilleure parade ?
Combien de versions de Director "enrichies" en nouveautés faudra-t'il
attendre avant que ce bug pénible soit corrigé ? (pourquoi proposer du
neuf quand le "vieux" ne marche pas correctement !)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Bubar
PJ wrote:
Bonjour,
J'avais laissé Director à sa version 8.5 et je travaille maintenant sur la version MX 2004.
J'ai aussi retrouvé un viel ami : le bug de la mise à jour des champs.
En pratique : toute mise à jour d'un champ dans un "prepareFrame" (ou autre script de préparation de la frame) force un rafraichissement de la scene en cours de préparation, et montre ainsi la mise en place des éléments (changement d'images...), alors que vous auriez aimé une apparition unique et propre de votre écran terminé. Inutile de dire que le rendu final est très amateur !
Seule parade : décaler les maj de champs le plus tard possible (même si le 1er champ mis à jour déclenchera un updateStage et montrera les autres changements)
Avez-vous une meilleure parade ?
Malheureusement non, rien de propre en tout cas.
Essayer de "sortir" les champs de l'écran, puis de les remplir _à la frame suivante_ (sinon ça ne change rien). Donc bidouille pour faire la mise à jour sur 2 frames. Ca peut vite être complexe.
Toujours en 2 frames : placer une image, copie du stage, sur le plus haut sprite. Ca va cacher le fond
Modifier les champs en 1er, plutôt qu'en dernier. Puis tous les autres éléments.
Utiliser des double-buffers pour les champs. Tu utilises 2 membres pour chaque champ. 1 version du champ est sur la scène, l'autre est en dehors. Tu modifies le contenu de celui qui est dehors, puis tu inverses les coordonnées des 2 champs. C'est la méthode que j'utiliserai, car assez simple à programmer.
Combien de versions de Director "enrichies" en nouveautés faudra-t'il attendre avant que ce bug pénible soit corrigé ? (pourquoi proposer du neuf quand le "vieux" ne marche pas correctement !)
MX2004 n'est pas très enrichi, je trouve. C'est plutôt une version pas trop mal débugguée, même si je n'ai pas eu trop le temps de la tester. Mais comme me disait à peu près Ned une fois, ça fait mal au c** de payer pour un patch ! (pas sur qu'il ait employé ces termes précis :))
-- Bubar
PJ wrote:
Bonjour,
J'avais laissé Director à sa version 8.5 et je travaille maintenant
sur la version MX 2004.
J'ai aussi retrouvé un viel ami : le bug de la mise à jour des champs.
En pratique : toute mise à jour d'un champ dans un "prepareFrame" (ou
autre script de préparation de la frame) force un rafraichissement de
la scene en cours de préparation, et montre ainsi la mise en place des
éléments (changement d'images...), alors que vous auriez aimé une
apparition unique et propre de votre écran terminé. Inutile de dire
que le rendu final est très amateur !
Seule parade : décaler les maj de champs le plus tard possible (même
si le 1er champ mis à jour déclenchera un updateStage et montrera les
autres changements)
Avez-vous une meilleure parade ?
Malheureusement non, rien de propre en tout cas.
Essayer de "sortir" les champs de l'écran, puis de les remplir _à la frame
suivante_ (sinon ça ne change rien). Donc bidouille pour faire la mise à
jour sur 2 frames. Ca peut vite être complexe.
Toujours en 2 frames : placer une image, copie du stage, sur le plus haut
sprite. Ca va cacher le fond
Modifier les champs en 1er, plutôt qu'en dernier. Puis tous les autres
éléments.
Utiliser des double-buffers pour les champs. Tu utilises 2 membres pour
chaque champ. 1 version du champ est sur la scène, l'autre est en dehors. Tu
modifies le contenu de celui qui est dehors, puis tu inverses les
coordonnées des 2 champs. C'est la méthode que j'utiliserai, car assez
simple à programmer.
Combien de versions de Director "enrichies" en nouveautés faudra-t'il
attendre avant que ce bug pénible soit corrigé ? (pourquoi proposer du
neuf quand le "vieux" ne marche pas correctement !)
MX2004 n'est pas très enrichi, je trouve. C'est plutôt une version pas trop
mal débugguée, même si je n'ai pas eu trop le temps de la tester.
Mais comme me disait à peu près Ned une fois, ça fait mal au c** de payer
pour un patch ! (pas sur qu'il ait employé ces termes précis :))
J'avais laissé Director à sa version 8.5 et je travaille maintenant sur la version MX 2004.
J'ai aussi retrouvé un viel ami : le bug de la mise à jour des champs.
En pratique : toute mise à jour d'un champ dans un "prepareFrame" (ou autre script de préparation de la frame) force un rafraichissement de la scene en cours de préparation, et montre ainsi la mise en place des éléments (changement d'images...), alors que vous auriez aimé une apparition unique et propre de votre écran terminé. Inutile de dire que le rendu final est très amateur !
Seule parade : décaler les maj de champs le plus tard possible (même si le 1er champ mis à jour déclenchera un updateStage et montrera les autres changements)
Avez-vous une meilleure parade ?
Malheureusement non, rien de propre en tout cas.
Essayer de "sortir" les champs de l'écran, puis de les remplir _à la frame suivante_ (sinon ça ne change rien). Donc bidouille pour faire la mise à jour sur 2 frames. Ca peut vite être complexe.
Toujours en 2 frames : placer une image, copie du stage, sur le plus haut sprite. Ca va cacher le fond
Modifier les champs en 1er, plutôt qu'en dernier. Puis tous les autres éléments.
Utiliser des double-buffers pour les champs. Tu utilises 2 membres pour chaque champ. 1 version du champ est sur la scène, l'autre est en dehors. Tu modifies le contenu de celui qui est dehors, puis tu inverses les coordonnées des 2 champs. C'est la méthode que j'utiliserai, car assez simple à programmer.
Combien de versions de Director "enrichies" en nouveautés faudra-t'il attendre avant que ce bug pénible soit corrigé ? (pourquoi proposer du neuf quand le "vieux" ne marche pas correctement !)
MX2004 n'est pas très enrichi, je trouve. C'est plutôt une version pas trop mal débugguée, même si je n'ai pas eu trop le temps de la tester. Mais comme me disait à peu près Ned une fois, ça fait mal au c** de payer pour un patch ! (pas sur qu'il ait employé ces termes précis :))
-- Bubar
Ned
Bubar a tapotylographié : || MX2004 n'est pas très enrichi, je trouve. C'est plutôt une version | pas trop mal débugguée, même si je n'ai pas eu trop le temps de la | tester. | Mais comme me disait à peu près Ned une fois, ça fait mal au c** de | payer pour un patch ! (pas sur qu'il ait employé ces termes précis :))
En effet, je ne permettrai jamais d'utiliser une putain de saloperie de formulation aussi chatiée sur un ng public ;oD -- ------------------ Ned ---------------------------------------- Bien faire et laisser braire ----------------------------------------
Bubar <bubarnet_SPAM_DE_M@yahoo.fr> a tapotylographié :
|| MX2004 n'est pas très enrichi, je trouve. C'est plutôt une version
| pas trop mal débugguée, même si je n'ai pas eu trop le temps de la
| tester.
| Mais comme me disait à peu près Ned une fois, ça fait mal au c** de
| payer pour un patch ! (pas sur qu'il ait employé ces termes précis :))
En effet, je ne permettrai jamais d'utiliser une putain de saloperie de
formulation aussi chatiée sur un ng public ;oD
--
------------------
Ned
----------------------------------------
Bien faire et laisser braire
----------------------------------------
Bubar a tapotylographié : || MX2004 n'est pas très enrichi, je trouve. C'est plutôt une version | pas trop mal débugguée, même si je n'ai pas eu trop le temps de la | tester. | Mais comme me disait à peu près Ned une fois, ça fait mal au c** de | payer pour un patch ! (pas sur qu'il ait employé ces termes précis :))
En effet, je ne permettrai jamais d'utiliser une putain de saloperie de formulation aussi chatiée sur un ng public ;oD -- ------------------ Ned ---------------------------------------- Bien faire et laisser braire ----------------------------------------
Twinky
Hello
Et dans un beginsprite ça change rien non plus ??? tjs pas de mise à jour des champs.
Ah les champs sous Director... ont besoin d'être labourés par un tracteur :)
Twinky
Hello
Et dans un beginsprite ça change rien non plus ???
tjs pas de mise à jour des champs.
Ah les champs sous Director... ont besoin d'être labourés
par un tracteur :)
