ma routine de zoom 240*128 =>160*85 - Page 2

PpHd> tu me prends pour un abruti ??????????
ce n'est pas parce que tu es fort que tu as le droit pour autant de sous-sous-estimer les autres !

merci gugusg pour etre allé chercher un peu plus loin que le bout de ton nez !

je trouve ça effectivement important comme perte d'infos, car un écran de 92 sers avant tout a exploiter sa taille généreuse, rétreci, le résultat sera de mauvaise qualité, sauf s'il y a une bonne méthode de moyennage des points d'environnement.

Pen²> tu fais comment pour ce petit problème graphique ?

Erf c'est que pphd est un cas dans son genre....

Oui, theoriquement on doit faire une moyenne des couleurs...

Je te pries de bien vouloir accepter mes humbles excuses pour ne pas avoir compris ce que tu as ecrit. Je n'ai voulu en aucune maniere te sous-estimer. Il me semblait seulement que lorsqu'on veut retrecir un ecran, on perd de l'information. donc ta remarque etait soit de nature evidente, soit elle etait innapropie a la methode de PenPen. En aucune maniere je n'ai pense que tu te sentirais vexe par mes propros.
Je suis le premier a mal comprendre ce que disent les autres (la preuve dans la remarque que je t'ai formulee a tord).
Et encore, pardon pour ses propos blessants.
[edit]Edité par PpHd le 06-02-2002 à 10:08:02[/edit]
[edit]Edité par PpHd le 06-02-2002 à 14:09:47[/edit]

un dieu qui s'excuse
on aura tout vu

arf, g bcp de posts à repondre..

>nEUrOne
>explique comment tu as fait ?
c ac une table que je crée au debut du prog.
(le prog ac la routine de zoom un peu déroulée fait environ 280 octets)


>Kevin Kofler
>160×85... Tu n'utilises même pas l'écran entier sur TI-89!
ba c pas le zoom vertical qui est difficile à faire..
et puis cf post de Miles

>Miles
>C'est pour la proportionnalité...
et oui

>OxmAn
>PAN .... dans les dents Kevin


>HerveRV
>le fps est bien élevé je trouve !
>ta routine est optimisée pour ce format ou elle sait gerer n'importe quelle dimension ?
c pour ce format, mais le principe resterait le meme pour d'aures facteurs.

>@frekazoid
>ici, on parle d'une routine specifique, pour adapter a l'ecran, de la ti, je vois pas pourquoi, ca devrait etre genrealiste, mieux vaut une bonne routine specialisée pour une tacvhe, qu'un truc tout lent qui fait tout
oui, c aussi mon pt de vue.

>squale92
>arf...
>il en a profité, vu que c pas souvent que Kevin peut s'en prendre plein les dents


>Kevin Kofler
>Je ne m'en suis pas "pris plein les dents", je reste de l'avis que c'est beaucoup mieux d'utiliser tout l'écran de la TI-89, même si c'est légèrement déformé!
bof.. pas moi. En plus ça fait plus de lignes à aficher


>Bob 64
>La dernière question d'Herve était interessante, mais elle risque de passer inaperçu...
g dû y repondre, non ?


>PpHd
>Disons que tu lis 3 octets, et tu en ecris 2. Si c'est un poil bien optimise et bien specifique§.
le pb c que 2^24 mots ça fait une grosse table.. g été obligé de ralentir un peu de ce coté là.


>Thibaut
>Pen², un pinguin surdoué
bahh, il y a sûrement moyen de faire mieux


>HerveRV
>BoB64, merci pour ta remarque pertinante
>mais PpHd, le coup de j'en prends 3 et j'en largue 2, ça marche, mais qu'est-ce que tu perds comme infos !
ba t bien obligé !

>PpHd
>Evidemement tu fais une compression de 3 octets en 2 octets. C'est evident.
vi.

>Benjamin
>bravo penpen pour ta routine !
>au fait c'est quand que tu nous finis ton jeu ?
merci
ba ça avance (tres) doucement.
(j'ai refais des algos tout propre le meme jour.)


>TiMad
>heu dans une vraie routine de zoom, on doit faire une moyenne local des couleurs des pxl....
soit, mais ça ralentirait à mort..

>HerveRV
>PpHd> tu me prends pour un abruti ??????????
ce n'est pas parce que tu es fort que tu as le droit pour autant de sous-sous-estimer les autres !
oula, du calme !

>merci gugusg pour etre allé chercher un peu plus loin que le bout de ton nez !

>je trouve ça effectivement important comme perte d'infos, car un écran de 92 sers avant tout a exploiter sa taille généreuse, rétreci, le résultat sera de mauvaise qualité, sauf s'il y a une bonne méthode de moyennage des points d'environnement.
ba un zoom t bien obligé de réduire la resolution

>Pen²> tu fais comment pour ce petit problème graphique ?
quel pb ?
la baisse de résolution ?
ça j peux rien.


>TiMad
>Erf c'est que pphd est un cas dans son genre....
>Oui, theoriquement on doit faire une moyenne des couleurs...
je sais, mais c un prog sencé adapter en temps réel les jeux 92+ only.
pas le temps de faire la moyenne.
(et puis meme en n/b, c pas si moche que ça.. (mis à part le tramage, ça c pas terrible c vrai)


>PpHd
>Je te pries de bien vouloir accepter mes humbles excuses pour ne pas avoir compris ce que tu as ecrit. Je n'ai voulu en aucune maniere te sous-estimer. Il me semblait seulement que lorsqu'on veut retrecir un ecran, on perds de l'information.
ba c clair

Sinon tu as trouvé ta routine de mappage des touches ?

non
si qq1 s'y connait.. je suis preneur.
(à - qu'Extended ne m'ait envoyé un mail, sait on jamais !)

La maniere la plus rapide ... mais pas forcement au meilleur rendu, c'est de faire une table de precalculé de 256 octets.... tu peux ainsi faire des moyennes partielle tout en etant plus rapide que ta routine.. le probleme, c'est que il y aura peut etre un mauvais rendu sur les bordure (tout les 8 pxl...)

C'est ce qu'il utilise.

PpHd> j'accepte tes excuses , s'cuse moi aussi, je me suis emporté, mais tu sauras que je prends beaucoups de choses sur moi, et quand j'explose je suis pas toujours bon ...

euh, pour l'histoire du moyennage, je n'ai pas dit que c'était nécessaire, juste mieux, si les graphismes sont détaillés à l'origine, ça va pas trop bien rendre, sinon y a pas de problèmes ...

sinon, tu fais un zoom bourrin pis un blur

a mon avis y a moyen de faire un anti-aliasing rapide (sur l'horizontal)
octet par octet avec une table de 256*2 plans (n&b->gris), en n'oubliant pas les bords de chaque octet
ex:

01001110 n&b (0-1) devient
02001310 gris (0-3)

[edit]Edité par segaman le 08-02-2002 à 13:27:58[/edit]

pour l'histoire du moyennage, on verra, de toutes façons pour l'instant ct nb -> nb donc..
>segaman : oui, oui faut modifier la table effectivement. on verra ça plus tard.

segaman> c pas con du tout ta méthode !!!

Pas tres simple a implementer quand meme.

C'est surtout que ce sera hyper dur à implenter si on veut émuler des programmes en niveaux de gris.
J'ai fait un petit émulateur de démo, c'est rend pas trop mal même si on moyenne pas (sauf si on veut lire du texte bien sûr). Ma routine fait du 175 fps, mais ca n'est pas qu'ici qu'on perd du temps.

>C'est surtout que ce sera hyper dur à implenter si on veut émuler des programmes en niveaux de gris.
c clair..
j refechissais d'ailleurs l'autre jour..

d'ailleurs ça sera encore + dûr ac les libs statiques

Tu te met au _nostub ?

non non
je veux dire que les progs utilisant les libs statiques seront + dûrs à emuler..

ah ok

Pour l'implanter c'est pas tres dure...
tu detourne l'ai1 ou 5 et tu fais a propre routine de niveau de gris...

mais le prog active ses gris en interne
g l'impression que tu parles plutot du cas où on adapterait le prog en le recompilant.. ja bon ?

Tu actives l'AI3 par le bon port et tu redétournes l'AI1 au premier appel de l'AI3 à AI1 détourné. C'est très sale comme méthode, mais ça devrait marcher. Je ne connais aucun programme qui détourne l'AI3.

Si...
deja tgv detourne tout les ais))

et puis la prochaine version de Xlib aussi

ba c pas grave puisque c compatilbe 89 / 92+ :-) #ouff#
sinon Kevin et TiMad : ça va interresser Extended votre idée. (et moi aussi d'ailleurs, merci. (bien que je fasse ça sans avoir l'intention de faire une release puisqu'Extended est bcp plus avancé que moi sur ce sujet )

Je suis une merde en optimisation, alors me gueulez pas dessus, mais si on fait : je lis trois octets, s'il y en a plus d'un noir je fais tout noir, sinon c'est blanc, ca ralentit énormément ou pas ? En tout cas la qualité risque d'être meilleure...