Forum de Ti-Gen.org, le site francophone des TI

Bienvenue Invité ! Se connecter Mes sujets	Administrer
Utilisateurs actifs : Aucun membre + 1 visiteur

Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.

:: Index » Forum TI-Nspire » Algorithmie et optimisation » Zoomer (10 réponse(s))

./POST DE DEPART (post n°0) Marquer comme non lu.

Onur

Ecrit le: Dimanche 9 avril 2006 à 02:59

Membre: Maître Ultime

Groupe: Orage Studio

Messages: 1604

Membre n°341

Inscrit le 02 juillet 2004

Voila.. l'idée c'est d'écrire des routines asm qui permettraient de zoomer en temps réel sur une image, et pas forcément en multiple de 2, genre pas que 25%,50%,100%,200% ... mais aussi du 150% etc..

Pensez-vous que c'est possible de le réaliser en un temps raisonnable? (je parle de l'éxecution pas du codage bien sur

)

Je ne veux pas faire quelque chose de bien, je cherche l'excellence:ETP Studio...

et autres projets à finir avant 2010

./Post n°1 Marquer comme non lu.

Sasume

Ecrit le: Dimanche 9 avril 2006 à 10:32

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Bien sûr que c'est possible. ExtGraph le fait par exemple.

./Post n°2 Marquer comme non lu.

Pollux

Ecrit le: Mardi 11 avril 2006 à 17:38

Membre: Vétéran

Messages: 95

Membre n°306

Inscrit le 11 juin 2004

"En un temps raisonnable" ? Ca a changé, parce que la dernière fois que j'ai regardé (y a lgtps

) c'était affreusement lent ?

Hmm sinon y a plein de méthodes, que ce soit avec un zoom fixe ou variable...

./Post n°3 Marquer comme non lu.

Sasume

Ecrit le: Mardi 11 avril 2006 à 21:08

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Hum, en fait, pour faire un tilemap, les fonctions d'ExtGraph ne sont pas ce qu'il y a de plus efficace.

./Post n°4 Marquer comme non lu.

Onur

Ecrit le: Mercredi 12 avril 2006 à 02:36

Membre: Maître Ultime

Groupe: Orage Studio

Messages: 1604

Membre n°341

Inscrit le 02 juillet 2004

C'est koi les méthodes??

Je ne veux pas faire quelque chose de bien, je cherche l'excellence:ETP Studio...

et autres projets à finir avant 2010

./Post n°5 Marquer comme non lu.

Pollux

Ecrit le: Jeudi 13 avril 2006 à 15:28

Membre: Vétéran

Messages: 95

Membre n°306

Inscrit le 11 juin 2004

Zoom fixe :
- table précalculée de type 8 bits entrée -> N bits sortie
- table précalculée de type N bits entrée -> 8/16/32 bits sortie
- sans tables, zoom arrière :

  move.b (a0)+,d0
  add.w d0,d0
  add.w d0,d0
  add.b d0,d0
  add.w d0,d0
  add.b d0,d0
  add.w d0,d0
  add.w d0,d0
  add.b d0,d0
  move.b (a0)+,d0
  add.w d0,d0
  add.b d0,d0
  add.w d0,d0
  add.w d0,d0
  add.b d0,d0
  move.w d0,-(a7)
  move.b (a7)+,(a1)+
  ...

- etc...

Zoom variable :
- comme le zoom sans tables dont j'ai parlé, sauf qu'on utilise par exemple l'algorithme de Bresenham (add.w = déplacement en bas, add.b = déplacement à droite, hauteur de la ligne = taille de la sortie, largeur de la ligne = taille de l'entrée moins taille de la sortie)
- si on ne doit pas avoir une qualité d'image extraordinaire, utilisation de tables précalculées, avec un léger ajustement (e.g. si on veut faire un zoom 8 -> 13.5, on peut prendre une table précalculée 8 -> 13 et recopier un pixel en plus une fois sur 2)

Bon, et c'est juste des exemples vite fait, y en a évidemment plein d'autres

(et y a plein d'ajustements possibles à ces algorithmes, par exemple on peut changer les tailles de l'algo avec des add.w/add.b pour utiliser des add.l/add.w, ça peut devenir rentable si le facteur de zoom est élevé, etc...)

./Post n°6 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 13 avril 2006 à 16:45

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4813

Membre n°40

Inscrit le 08 février 2004

Il est optimisable, ton truc...

  move.b (a0)+,d0
   lsl.w #2,d0
   add.b d0,d0
   add.w d0,d0
   add.b d0,d0
   lsl.w #2,d0
   add.b d0,d0
   move.b (a0)+,d0
   add.w d0,d0
   add.b d0,d0
   lsl.w #2,d0
   add.b d0,d0
   move.w d0,-(a7)
   move.b (a7)+,(a1)+
   ...

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!

./Post n°7 Marquer comme non lu.

Pollux

Ecrit le: Samedi 15 avril 2006 à 21:05

Membre: Vétéran

Messages: 95

Membre n°306

Inscrit le 11 juin 2004

LOL :/ on parle d'optimisation vitesse, pas d'optimisation taille

(Kevin propose [pour changer...] une optimisation taille au détriment la vitesse)

(surtout qu'a priori ce type de code sera généré dynamiquement au runtime, donc même si tu veux optimiser en taille, le plus efficace serait d'éviter les cas particuliers style add+add=lsl#2

#htkc#)

./Post n°8 Marquer comme non lu.

Onur

Ecrit le: Dimanche 16 avril 2006 à 13:47

Membre: Maître Ultime

Groupe: Orage Studio

Messages: 1604

Membre n°341

Inscrit le 02 juillet 2004

généré au runtime???? #eek#

mince alors

sinon oui, là on a besoin de la vitesse.

Je ne veux pas faire quelque chose de bien, je cherche l'excellence:ETP Studio...

et autres projets à finir avant 2010

./Post n°9 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 20 avril 2006 à 06:24

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4813

Membre n°40

Inscrit le 08 février 2004

Pollux :
(Kevin propose [pour changer...] une optimisation taille au détriment la vitesse)

Je pensais que c'était le même nombre de cycles, mais en fait non, tes deux add.w prennent 8 cycles et un lsl.w #2 prend 10 cycles. En revanche, pour les longs, le lsl.l #2 est déjà plus efficace que deux add.l (12 cycles contre 16).