Toujours un petit problème de ROM CALL (toujours elles)! - Page 4

Non, ils y sont tous.

Je confirme.

Juste un dernier problème:
Pour ma routine "Gray_h" j'ai trouvé cette ligne dans le fichier Gray.h:

#define GrayAdjust(x) ((void)(*(volatile unsigned char*)0x600013=128-(signed char)(x)))

je voudrais le transcrir pour que CC la comprenne en faisant du style:

void GrayAdjust(x) unsigned short x;
{
...
}

Quelqu'un pourrait m'aider?

Ne mets pas cette fonction : elle est depreceted.

Elle marche toujours!

void GrayAdjust(x) unsigned short x;
{
*(volatile unsigned char*)0x600013=128-(signed char)x;
}
tout simplement

je l'ai deja testée et le voudrai tout de même la mettre (sa peut toujours servir) et de plus, elle ne risque rien. Sa revient en ordre dès que l'on éteint la calculatrice.

On pourrait m'aider alors???

MAIS ELLE NE SERT A RIEN AVEC LES NOUVEAUX NIVEAUX DE GRIS !

ok.

C bon, j'ai fini ma routine de gestion des gris pour CC en me basant sur celle de TIGCC. Des que je pourrait je l

Donc des que je pourrait, je la metterai en DL, si ca interresse quelqu'un!

Faudrai qu'on m'explique un truc, comment il marche exactement ce double buffer

Facile: tu alloues un buffer de taille GRAYDBUFFER_SIZE et tu le passes à GrayDBufInit (après avoir appelé GrayOn) et hop, tu es en mode double-buffering.
Ensuite, tu peux écrire dans les 2 plans cachés en utilisant GrayDBufGetHiddenPlane et rendre les 2 plans dans lesquels tu as écrit actifs avec GrayDBufToggleSync.
C'est tout ce qu'il te faut dans le cas général, mais les autres fonctions rajoutent de la flexibilité.
Quand tu as fini, tu utilises GrayOff (GrayDBufCleanup est appelé automatiquement par GrayOff) et tu libères le buffer passé à GrayDBufInit.

Je ne comprends pas comment on peut trouver ça compliqué. C'est tout bête, et en plus les noms des fonctions parlent d'eux-mêmes. Et c'est très bien documenté.

J'ai pas compris tous les details sur l'ímplantation Enfin moi j'ai un truc + simple et + souple.

Qu'est-ce que tu n'as pas compris?

Lorsqu'on toggle les screens, ca toogle les ecrans caches aussi ? Et donc getMachinHiddenTruc renvoie le truc original ?

Tout ce que fait GrayDBufToggle(Sync), c'est:
D_PLANE visible <-> D_PLANE caché
L_PLANE visible <-> L_PLANE caché
Et évidemment ça n'échange que les pointeurs, pas le contenu.

Et GrayDBufGetHiddenPlane donne donc les plans qui étaient actifs avant le toggle (et qui sont cachés après).

Encore moi. Vous pouvait DL les routines pour CC à l'adresse:
http://perso.wanadoo.fr/perso.messia/fichiers/routines_CC.zip

Je n'est pas qu'inclus la gestion des gris mais aussi sprintf, fgetchar, LCD_save, LCD_restore ainsi que la gestion des sprites en 8x8, 16x16 et 32x32

De plus, il marche sans le prog que ExtendeD a fait pour patcher le fichier "ams_c"
Je n'ai pas inclus la gestion du double buffer mais on peut rajouter ça trés facilement (le plus dur est fait). Je pense que je le metterai trés prochainement.

Dites-moi ce que vous en pensez!!! Et bonne prog avec CC

Dites-moi ca que vous voulez que j'adapte pour que CC et AS comprennent. Je me ferais une joie de l'adapter. Maintenant que je suis chaud

tigcclib

Tu as fait un printf ?
Tu fais comment pour gérer les coordonnées d'affichage du texte ?

Ben comme dans la TIGCCLIB puisque il a porté leur routine ...
printf utilise printf et met à jour une structure SCR_STATE je crois ...

Ouais, ce que je voulais savoir, c'est où est-ce qu'il chope les données 'curX' et 'curY' ?

C'est dans fputchar que se fait la mise à jour de la structure, je vais voir ...

En fait c'est fait avec MoveTo, qui est une fonction d'AMS ...

guigui17
a écrit : De plus, il marche sans le prog que ExtendeD a fait pour patcher le fichier "ams_c"

Ca n'a rien à voir avec les NVG. Essaie de compiler ça sans patch:
ScreenClear(); ScreenClear(); ScreenClear(); ScreenClear();

Et les gray de PreOS font une centaine d'octets de moins

zdr a écrit :
En fait c'est fait avec MoveTo, qui est une fonction d'AMS ...

D'accord, l'utilisateur se servira de MoveTo pour changer la place du curseur, mais ce que je me demandais, c'est où sont stockés les arguments que l'on transmet à MoveTo pour qu'il puisse les réutiliser avec printf ?

ExtendeD a écrit :
Et les gray de PreOS font une centaine d'octets de moins

Ah bon ? Et en plus, il est facile de faire du gray7 avec

J'ai plusieurs éclairsissement à faire!

- On positionne le curseur avec MoveTo(x,y) pour utiliser printf (c une ROM CALL)
- printf n'a rien à voir avec sprintf et utilise fputchar pour afficher les caractères
- Comme la dit ZDR, j'ai porté les routines TIGCCLIB, donc ce ne sont pas des ROMS CALL!
- En réponse a ExtendeD, j'utilise jamais 4 appels de ClrScr() d'affilé
- Pour la centaine d'octets de moin, pas trop grave! Elle gère le double buffering la tienne???

J'ai continué met routines et j'en ai crée une nommée
GrayDrawStr(x,y,"texte",mode,taille_police,couleur) a utiliser avec le gray!!!
Elle sera incluse dans ma prochaine version. De plus je doit optimiser les Sripte8, Sprite16 et Sprite32 en les codant diect en ASM (je pourrai gagner de l'ordre de la 100 aine d'octet facile!)

lol jamais 4 ClearScreen() à la suite ...
Mais peut-être 4 DrawLine à la suite ? Et là ça plantera ...