Flib 3.2 - Page 3

et comme les niewbies ont souvent des calcs neuves, ils ont ams 2.5 donc ca reduit le probelme

Fusion PaWa !!!!!!

mais non pas de fusion cq marchera jamais avec les anciennes ROM et FL veut pas de ca (moi je trouve qu'il a raison)

encore un post: pour préciser mon exemple de bug, je vais pas envoyer sur le forum 5 ko de code (c'est dans un prog de résolution de triangle) mais ça affiche n'importe quoi tant qu'il y a des symboles du code ASCII dans le même ordre à chaque fois, sans faire buguer flib, ou le prog, et sans crash de la calc

nounoun
a écrit : mais non pas de fusion cq marchera jamais avec les anciennes ROM et FL veut pas de ca (moi je trouve qu'il a raison)

Nan, il ne fonctionneras pas avec la rom 2.03 seulement. Il y a encors plus de monde qui utilise la 2.08 que la 2.03

oui mais même, FL veut que ça reste compaptible et c'est bien!

MacIntoc a écrit :
Bah... à part les newbs qui y connaisse que dalle, y a pus personne qui utilise ams 2.03

Si, il y a Lionel (XDanger).

vi, mais il exècres les progs basic autant que toi

Comme wakmek par ex

il programme ou utilise des prog en basic qui utilise un lib ????

Dsl j'avais pas vu qu'il y avait une 3e page.
Ct une remarque à ton post 59

J'ai rajouté une fonction zoom dans Flib, je ne sais pas si ça intéresse du monde... En fait c'est assez lent (1.5 s pour afficher une image en 160*100), mais bon.

Si vous voulez tester, leiber.free.fr/ti/flib/Flib.89z ou leiber.free.fr/ti/flib/Flib.9xz.

Syntaxe : zoom:x,y,h,l,mode,image
mode est comme dans pix, le reste est clair je pense.

x,y,h,l ?
Pourquoi 4 coordonnées ?

Sinon, à l'usure, je me suis rendu compte qu'une routine de zoom comme ça n'est pas tellement utilisable (ta routine est probablement la même que celle que j'utilisais), et comme ça prend pas mal de place...
Il faudrait peut-être utiliser une méthode moins précise mais plus rapide...

bah tu peux déformer l'image en spécifiant un factuer de zoom différent pour la Hauteur et la Largueur, enfin c'est comme ca que je le comprends

ca affiche l'image directement a l'ecran ? (dsl pas testé)

ca serait ptet mieux de l'enregistrer dans une autre pic pour pouvoir la reutiliser, non ?

Microbug > Bah oui mais l'ancienne fonction de vertel c'était "d_zoom","pic1","pic2",x,y. Ça redimentionnait "pic1" à la taille x,y et ça sauvait dans "pic2". Je ne vois pas ce que sont h et l.

bah lui ca affiche directement l'image
donc x et y c l'endroit ou tu affiches l'image et h et les les facteurs de zoom

Tout à fait. Pour la place, ça doit faire 200-300 octets. Et pour le "plus rapide, moins précis", je ne vois pas... à la rigueur je pourrai un peu l'accélérer en dessinant chaque pixel à la main et non avec DrawPix, c'est tout... si c'est lent, c'est à cause des multiplications/divisions que je suis obligé de calculer à chaque fois.

Enfin, dites-moi si vous préférez stocker l'image dans une variable plutôt que l'afficher directement à l'écran. Ca risque de prendre un peu plus de place, dites-moi si la fonction zoom vous paraît à garder ou pas...

exact! cè 2.05 pour tout le monde et 2.08 quand elle marchra correctement
et toc.

dsl j'ai pas vu la page 3
c'était en réponse au dernier post de la page 2

FL
a écrit : Et pour le "plus rapide, moins précis", je ne vois pas...

Pas de divisions, que des décalages de bits.

FL
a écrit : Enfin, dites-moi si vous préférez stocker l'image dans une variable plutôt que l'afficher directement à l'écran. Ca risque de prendre un peu plus de place, dites-moi si la fonction zoom vous paraît à garder ou pas...

Mais n'est t'il pas possible de sauvegarder l'image en enchainant zoom et savscr si la fonction zoom ne fait que l'afficher à l'écran?

oui, mais on ne veut pas forcement l'afficher a l'ecran avant de l'enregister...

et puis a propos des decalages, vertyos, tu veux utiliser la methode de multiplication puis de decalage ? ( x/10=x*6554 par exemple)
deja, en utilisant ca a la place de la division, (enfin je ne sais pas si les denominateurs des divisions changent bcp dans un appel a la fct zoom), ya de schance que ca accelere

FL, t'avais vu mon report de bug??? Merci d'en tenir compte!!!




Je peux te demander deux trois truc si c'est possible dans cette nouvelle version???

1) J'ai des bugs de temps en temps avec drawstr, quand l'argument texte est assez compliqué avec des string(abc[3*e+5]) ou des choses dans ce genre.
->Ca affiche à la place de la string, aux bonnes coordonnées, un ensemble des 12 premiers caractères du code ASCII, qui n'ont en tout cas rien à voir avec ce à quoi on s'attendait

2) Est-ce que ça serait possible que tu fasses en sorte que les rectangles pleins s'affichent même quand la seconde ordonnée est inférieure à la première???
-> J'ai essayé de corriger avec des min() et des max(), mais le prog fait une erreur de syntaxe, et comme c'est avec des niveaux de gris, FLib est quitté, l'écran clignotte et en deux minutes c'est le crash... snif

Au fait, j'ai une hw2 2.05 avec FLib 3.1

Voilà sinon merci bien, Joyeux Noël et bonne année!!!

azerty83 a écrit :
et puis a propos des decalages, vertyos, tu veux utiliser la methode de multiplication puis de decalage ? ( x/10=x*6554 par exemple) deja, en utilisant ca a la place de la division, (enfin je ne sais pas si les denominateurs des divisions changent bcp dans un appel a la fct zoom), ya de schance que ca accelere

Non non je ne parle pas du tout de ça. Il ne s'agit pas du tout d'un bidouillage de ce genre, mais d'une toute autre méthode, BEAUCOUP plus rapide, qui parrait-il est la méthode la plus classique (d'après Vark, qui me l'avait expliquée il y a un moment).

tu peux expliquer cette methode, stp ?

Décidement

Jackiechan vient de me demander sur IRC, je suis désolé mais ça date d'il y a un an, je me souvient plus du tout comment on fait
Mais j'ai surement gardé un prog quelque part, donc à l'occasion rappelle le moi sur #3l33t j'essayerais de retrouver ça.

d'accord...

c pas ce que t'utilises pour Vertad ???