mViewer revient en version 3.2 avec le support JPEG

[critor]

Tu as mViewer 3.2 ou 3.1 ?
Le 3.1 te faisait pareil?

[AlexRider38]

oui j'ai la 3.2

[Levak]

Tu mélanges deux choses AlexRider, je pense.
1) mViewer qui a un bug incontrôlage/aléatoire qui fait que l'affichage en zoom/dezoom d'une image sera décallée de quelques pixels, et que lorsque que l'on sort de mviewer il n'y a aucune répercution sur l'OS
2) nDoom qui a un bug de décallage constant de 10 pixels qui peut affecter l'OS en sortie et où il suffit de reboot pour ne plus avoir ce décallage ou bien de relancer ndoom en espérant que le bug s'inverse.

Dans tous les cas, critor ne sait pas d'où vient ce bug et ne sera pas résolu avant qu'il en trouve la cause et le remède.

[AlexRider38]

Ma calculatrice à plantée, et du coup, le bug de nDoom à disparu. Mais pas celui de mViewer.
EDIT: en fait, il est revenu.

[critor]

Ma calculatrice à plantée, et du coup, le bug de nDoom à disparu. Mais pas celui de mViewer.
EDIT: en fait, il est revenu.

Il me semble avoir employé le mot 'aléatoire', oui.

Les bugs aléatoires sont les pires à détecter et corriger.

[AlexRider38]

Oui mais c'est pas grave. En soit ça me dérange pas beaucoup.

[Levak]

Oui mais c'est pas grave. En soit ça me dérange pas beaucoup.

HELP ME!!

· Levak essaie de comprendre le sens de "Help me"

[critor]

Moi j'ai un problème avec mViewer et nDoom, sur nDoom, l'écran est décalé pendant le jeu et donc la partie qui sort de l'écran est affichée de l'autre côté (en permanence) et avec mViewer, dès que l'image est chargée, dès que j’appuie sur un bouton, l'écran fait comme nDoom, mais avec des accoue: un coup bien, un coup décalé, très rapidement. J'ai essayé de redémarrer ma CX, réinstaller ndless; rien y fait. HELP ME.

Je viens de mettre à jour et de corriger le bug de décalage d'écran de mViewer qui nous embêtait depuis janvier, avec mViewer CX 3.21!

Corrigé ça d'une façon qui ne me plait pas, puisque j'ai désactivé le double-buffering sur CX.

J'ai deux buffers 16-bits, un visible (affiché à l'écran) et un invisible.
A chaque itération, j'écrivais dans le buffer invisible puis échangeais les deux buffers à la fin, pour afficher directement sans copie complète de l'écran (l'écran reçoit l'adresse du buffer invisible qui devient donc visible, et c'est l'ancien buffer visible qui devient invisible et sur lequel on va pouvoir écrire).

Bref, j'ai un changement d'adresse d'écran pour chaque itération de la boucle d'affichage.

A noter que cette technique est conservée pour les TI-Nspire non-CX.

L'écran se décalait ou tremblait aléatoirement sur quand on changeait son adresse sur TI-Nspire CX.
Comme c'était aléatoire, je comprends bien qu'il fallait changer l'adresse de l'écran à un moment donnée et donc qu'il y a une histoire d'interruption.

Le site Hackspire décrit l'interruption à vérifier
http://hackspire.unsads.com/wiki/index. ... controller

C0000020 (R): Raw interrupt status.
Bit 2: LCD next address base update. Signifies that a new Frame Base Address value can be loaded for double-buffering.

Mais attendre que le bit2 passe à 1 semble ne pas faire disparaître le problème.


Bref, ce n'est pas bien grave dans l'immédiat: la TI-Nspire CX a un processeur puissant et j'étais même obligée de la ralentir
Il y a de la marge et vous ne verrez aucune dégradation de vitesse, bien au contraire.

Le scrolling sur les images zoomées a été optimisée et la réactivité du pavé tactile améliorée!



Bref, AlexRider38, si tu peux tester et me confirmer que le bug de mViewer a disparu, ce serait sympa
archives_voir.php?id=6601

[critor]

mViewer passe en version 3.22.

Corrigé le bug et réactivé le double-buffering sur CX.
Lorsqu'on alloue un nouveau buffer écran autre que ce lui de l'OS, son adresse doit être alignée sur 8 octets (cad divisible par 8 ).

Mais bon, fallait la trouver l'info... 6 mois que l'on traînait cette saleté de bug...
http://infocenter.arm.com/help/index.js ... 99134.html

D'où le décalage d'écran si le malloc() retournait une adresse non divisible par huit: il prenait le multiple de 8 inférieur.

Si les adresses de buffer sont allouées sans règle particulière, le bug se produisait donc en théorie 7 fois sur 8.


Merci de télécharger de tester, et de confirmer qu'il n'y a plus le problème.
archives_voir.php?id=6601


nDoom a donc exactement le même bug sur CX, puisqu'il travaille en 8-bits (contre 16-bits pour l'OS) et doit donc s'allouer un nouveau buffer écran.
Si vous me confirmez que tout va bien, j'y appliquerai la même correction.

[AlexRider38]

Plus de bug. super!!