Question :: nvg - Page 1

Vous preferez les nvg dans l'int1 ou 5?

1

Bonne question...
Aucune idée. Le systeme actuel + la technique postée je ne sais plus ou pour pouvoir quand même utiliser les fonctions ngetchx et cie en cas de besoin, ça me semble pas mal

Mais je pense qu'avec l'int5 on pourrais aller à 64 niveaux de gris sans problème même en pouvant utiliser correctement les fonctions ngetchx...

Car contre 320hz pour l'int1 et 8000 hz pour l'int5 y a une grande différence mais dans l'int5 pour faire 64 niveaux de gris, il faut faire preuve d'optimisation. Mais le gros problème c'est la mémoire car 6*3840=23040 donc c'est beaucoup quand même.

au dessus de 8 niveaix de gris, la différence ne se voit pas je pense

ca sert a rien

Deja que 8, c'est plus du snobinisme qu'une véritable utilité ...

AI1

geogeo
a écrit : Mais je pense qu'avec l'int5 on pourrais aller à 64 niveaux de gris sans problème

L'écran ne se rafraîchit que 90 fois par seconde. Ça ne sert donc à rien d'utiliser un règlage rapide de l'AI5, l'AI1 convient très bien. Les 64 niveaux de gris sont possibles, mais ils clignoteraient comme pas possible (et l'utilisation de l'AI5 n'y changerait rien)!!!

Ah bon.
Mais avec 64 niveaux de gris là on peut faire beaucoup de choses comme des dégradés, des textures, des effets...

Kevin> C'est bizarre car pourtant le controlleur du LCD fonctionne à 680 khz mais bon dans ce cas les 64 niveaux de gris ne sont pas envisageable.

Pour les 8 niveaux de gris, est-ce que ça clignote beaucoup?

8 nvg sur ma calc ça clignote déjà beaucoup, 64 c'est n'importe quoi...

aie aie aie mais ça clignote vraiment beaucoup pour que ça soit désagréable?

Avec la mienne c'esst comme les 4 niveaux de gris, ça clignote mais faiblement.

grrr
si la routine de TIGCC permettait de definir 2 buffer qu'on veux noux et non leur truc a la con
pour GrayOn, ca simplifirait bien les chose, ca permettrait d'utiliser le trip sp buffering sans modification de la routine, et c'est vraiment pas compliquer a faire...!

Notre système est fait pour consommer le moins de mémoire possible. (Sur HW1, on peut économiser 3840 octets en utilisant LCD_MEM pour un des plans.)

Il faut choisir entre vitesse et consommation en mémoire mais dans ce cas le mieux me semble quand même la vitesse!!!

non mais permettre une alternative...
genre:
iniGray(1);
=> permet de passer en mode triple swap buffering
si on l'appelle pas ca modifie rien (donc reste compatible)
il suffit d'ajouter cette fonction et apres on peut faire du triple swap buffering sans modifier les autre fonctions!!!!!!!
En bref permettre d'allouer nous meme les plan, car certain prefere avoir le 2 plans a la suite!

geogeo
a écrit : Il faut choisir entre vitesse et consommation en mémoire mais dans ce cas le mieux me semble quand même la vitesse!!!

Même au prix de 7680 octets (11520 en 8 niveaux de gris)??? C'est ce qu'il faut pour la méthode de Thibaut (qu'il appelle "triple swap-buffering").

TiMad
a écrit : En bref permettre d'allouer nous meme les plan, car certain prefere avoir le 2 plans a la suite!

Ça gaspille 3840 octets sur HW1 pour rien! Corrige tes routines.

Bas même en perdant de la mémoire ça vaut le coups.

ca permet surtout de rendre XLib 100% compaible avec tigcc lib, et je ne suis pas le seul a preferer avoir les 2 plans a coté, et en plus on a un gain de vitesse non negligeable...
au niveau de la fonction elle grossirait de 30 octets maxi!!!

TiMad
a écrit : ca permet surtout de rendre XLib 100% compaible avec tigcc lib,

Corrige tes routines. Adapte Xlib à TIGCCLIB, pas l'inverse. (C'est ce que je te dis depuis le départ.)

et je ne suis pas le seul a preferer avoir les 2 plans a coté, et en plus on a un gain de vitesse non negligeable...

N'importe quoi! On ne gagne strictement rien. Tu utilises un pointeur par plan et tu mets chacun dans son registre d'adresses. Je ne vois pas du tout ce que le fait de forcer les 2 plans de se suivre apporte pour la vitesse.

au niveau de la fonction elle grossirait de 30 octets maxi!!!

1. Même 1 octet serait trop pour cette "fonctionnalité" qui n'en est pas une!
2. Je refuse d'encourager les programmeurs à gaspiller 3840 octets de mémoire alors que ça ne sert strictement à rien.

avec les 2 plans a la suite on gagne en rapidité!
Et en plus c'est ridicule de ne pas modifier les routines, alors qu'on pourait avoir un gain en vitesse tres interessant...

question : si les 3840 octets du LCD_MEM ne sont pas utilises par les routines de gray, est-ce qu'on peut s'en servir pour memoriser des donnes (et donc, qu'(il ne soient pas gaspilles) ?
(par exemple, pour sauvegarder l'ecran au lancement du prog)

oui!

Bah oui mais comme ça n'est possible que sur hw1, autant s'en passer... par contre si tu es à la recherche de mémoire libre tu as toujours les écrans HOME et I/O

TiMad
a écrit : avec les 2 plans a la suite on gagne en rapidité!

On ne gagne rien si on sait coder ses routines correctement! Il faut utiliser un registre d'adresses par plan! Même s'ils sont contigus! Tu ne vas quand-même pas traîner des 3840(an) de partout?! Si c'est ce que tu fais, et ben, je peux te dire que c'est plus lent que d'utiliser un pointeur par plan!

Et en plus c'est ridicule de ne pas modifier les routines, alors qu'on pourait avoir un gain en vitesse tres interessant...

Ce gain de vitesse est inexistant.

adresse?

kevin> mais quand on connait la distance séparant les 2 buffers la valeur du deuxième registre d'adresse est plus facilement calculable... lea3840(a0),a1 pr ex...

Si on stocke les 2, ou passe les 2 en paramètre, ça va plus vite que de faire un lea à chaque fois.

mais c'est uand meme lent!

les écras home et IO, on peut les utiliser ?
pour les avoir, je suppose qu'on fait un DispHome (ou un truc equivalent), et qu'on recupere l'adresse de qqc ?